Design och prestanda för Oracle-migreringar

Den här artikeln är en del av en serie i sju delar som ger vägledning om hur du migrerar från Oracle till Azure Synapse Analytics. Fokus i den här artikeln är metodtips för design och prestanda.

Översikt

På grund av kostnaden och komplexiteten med att underhålla och uppgradera äldre lokala Oracle-miljöer vill många befintliga Oracle-användare dra nytta av de innovationer som tillhandahålls av moderna molnmiljöer. Med molnmiljöerna Infrastruktur som en tjänst (IaaS) och PaaS (plattform som en tjänst) kan du delegera uppgifter som infrastrukturunderhåll och plattformsutveckling till molnleverantören.

Dricks

Mer än bara en databas – Azure-miljön innehåller en omfattande uppsättning funktioner och verktyg.

Oracle och Azure Synapse Analytics är båda SQL-databaser som använder MPP-tekniker (massivt parallell bearbetning) för att uppnå höga frågeprestanda på exceptionellt stora datavolymer, men det finns några grundläggande skillnader i metoden:

• Äldre Oracle-system installeras ofta lokalt och använder relativt dyr maskinvara, medan Azure Synapse är molnbaserat och använder Azure-lagrings- och beräkningsresurser.

• Att uppgradera en Oracle-konfiguration är en viktig uppgift som omfattar extra fysisk maskinvara och potentiellt lång databasomkonfiguration, eller dumpning och omläsning. Eftersom lagrings- och beräkningsresurser är separata i Azure-miljön och har elastisk skalningskapacitet kan dessa resurser skalas uppåt eller nedåt oberoende av varandra.

• Du kan pausa eller ändra storlek på Azure Synapse efter behov för att minska resursanvändningen och kostnaderna.

Microsoft Azure är en globalt tillgänglig, mycket säker och skalbar molnmiljö som innehåller Azure Synapse och ett ekosystem med stödverktyg och funktioner. Nästa diagram sammanfattar Azure Synapse-ekosystemet.

Azure Synapse ger bästa möjliga relationsdatabasprestanda med hjälp av tekniker som MPP och automatisk minnesintern cachelagring. Du kan se resultatet av dessa tekniker i oberoende benchmarks, till exempel den som nyligen kördes av GigaOm, som jämför Azure Synapse med andra populära molndatalagererbjudanden. Kunder som migrerar till Azure Synapse-miljön ser många fördelar, bland annat:

• Förbättrad prestanda och pris/prestanda.

• Ökad flexibilitet och kortare tid till värde.

• Snabbare serverdistribution och programutveckling.

• Elastisk skalbarhet – betala endast för faktisk användning.

• Förbättrad säkerhet/efterlevnad.

• Minskade kostnader för lagring och haveriberedskap.

• Lägre total TCO, bättre kostnadskontroll och effektivare driftsutgifter (OPEX).

För att maximera dessa fördelar migrerar du nya eller befintliga data och program till Azure Synapse-plattformen. I många organisationer omfattar migrering att flytta ett befintligt informationslager från en äldre lokal plattform, till exempel Oracle, till Azure Synapse. På hög nivå omfattar migreringsprocessen följande steg:

    Förberedelse 🡆

• Definiera omfång – vad som ska migreras.

• Skapa en inventering av data och processer för migrering.

• Definiera ändringar i datamodellen (om det finns några).

• Definiera mekanismen för källdataextrakt.

• Identifiera lämpliga Verktyg och funktioner från Azure och tredje part som ska användas.

• Utbilda personalen tidigt på den nya plattformen.

• Konfigurera Azure-målplattformen.

    Migrering 🡆

• Börja litet och enkelt.

• Automatisera när det är möjligt.

• Använd inbyggda Azure-verktyg och funktioner för att minska migreringsarbetet.

• Migrera metadata för tabeller och vyer.

• Migrera historiska data som ska underhållas.

• Migrera eller omstrukturera lagrade procedurer och affärsprocesser.

• Migrera eller omstrukturera inkrementella inläsningsprocesser för ETL/ELT.

    Efter migreringen

• Övervaka och dokumentera alla faser i processen.

• Använd upplevelsen för att skapa en mall för framtida migreringar.

• Återskapa datamodellen om det behövs (med nya plattformsprestanda och skalbarhet).

• Testa program och frågeverktyg.

• Prestandatesta och optimera frågeprestanda.

Den här artikeln innehåller allmän information och riktlinjer för prestandaoptimering när du migrerar ett informationslager från en befintlig Oracle-miljö till Azure Synapse. Målet med prestandaoptimering är att uppnå samma eller bättre informationslagerprestanda i Azure Synapse efter migreringen.

Utformningsbeaktanden

Migreringsomfång

När du förbereder migreringen från en Oracle-miljö bör du överväga följande migreringsalternativ.

Välj arbetsbelastningen för den första migreringen

Vanligtvis har äldre Oracle-miljöer utvecklats över tid för att omfatta flera ämnesområden och blandade arbetsbelastningar. När du bestämmer var du ska börja med ett migreringsprojekt väljer du ett område där du kan:

• Bevisa hur bra det är att migrera till Azure Synapse genom att snabbt leverera fördelarna med den nya miljön.

• Låt din interna tekniska personal få relevant erfarenhet av de processer och verktyg som de kommer att använda när de migrerar andra områden.

• Skapa en mall för ytterligare migreringar som är specifika för Oracle-källmiljön och de aktuella verktygen och processerna som redan finns på plats.

En bra kandidat för en inledande migrering från en Oracle-miljö stöder föregående objekt och:

• Implementerar en BI/Analytics-arbetsbelastning i stället för en arbetsbelastning för onlinetransaktionsbearbetning (OLTP).

• Har en datamodell, till exempel ett star- eller snowflake-schema, som kan migreras med minimal ändring.

Dricks

Skapa en inventering av objekt som behöver migreras och dokumentera migreringsprocessen.

Mängden migrerade data i en inledande migrering bör vara tillräckligt stor för att demonstrera funktionerna och fördelarna med Azure Synapse-miljön, men inte för stor för att snabbt kunna visa värde. En storlek på 1–10 terabyte är typisk.

En första metod för ett migreringsprojekt är att minimera den risk, ansträngning och tid som behövs så att du snabbt ser fördelarna med Azure-molnmiljön. Följande metoder begränsar omfattningen för den inledande migreringen till bara data marts och hanterar inte bredare migreringsaspekter, till exempel ETL-migrering och historisk datamigrering. Du kan dock hantera dessa aspekter i senare faser av projektet när det migrerade data mart-lagret fylls på med data och de nödvändiga byggprocesserna.

Lift and shift-migrering jämfört med stegvis metod

I allmänhet finns det två typer av migrering oavsett syftet med och omfattningen av den planerade migreringen: lift and shift as-is och en stegvis metod som innehåller ändringar.

Lift and Shift

Vid en lift and shift-migrering migreras en befintlig datamodell, till exempel ett star-schema, oförändrad till den nya Azure Synapse-plattformen. Den här metoden minimerar risken och migreringstiden genom att minska det arbete som krävs för att utnyttja fördelarna med att flytta till Azure-molnmiljön. Lift and Shift-migrering passar bra för följande scenarier:

• Du har en befintlig Oracle-miljö med en enda data mart att migrera, eller
• Du har en befintlig Oracle-miljö med data som redan finns i ett väldesignade star- eller snowflake-schema, eller
• Du är under tids- och kostnadsbelastning för att övergå till en modern molnmiljö.

Dricks

Lift and shift är en bra utgångspunkt, även om efterföljande faser implementerar ändringar i datamodellen.

Stegvis metod som innehåller ändringar

Om ett äldre informationslager har utvecklats under en lång tidsperiod kan du behöva återskapa det för att upprätthålla de prestandanivåer som krävs. Du kan också behöva omkonstruera för att stödja nya data som IoT-strömmar (Internet of Things). Som en del av ombyggnadsprocessen migrerar du till Azure Synapse för att få fördelarna med en skalbar molnmiljö. Migrering kan omfatta en ändring i den underliggande datamodellen, till exempel en flytt från en Inmon-modell till ett datavalv.

Microsoft rekommenderar att du flyttar din befintliga datamodell som den är till Azure och använder prestanda och flexibilitet i Azure-miljön för att tillämpa de omdefinierade ändringarna. På så sätt kan du använda Azures funktioner för att göra ändringarna utan att påverka det befintliga källsystemet.

Använda Microsoft-anläggningar för att implementera en metadatadriven migrering

Du kan automatisera och samordna migreringsprocessen med hjälp av funktionerna i Azure-miljön. Den här metoden minimerar prestandaträffen för den befintliga Oracle-miljön, som kanske redan körs nära kapaciteten.

SQL Server Migration Assistant (SSMA) för Oracle kan automatisera många delar av migreringsprocessen, inklusive i vissa fall funktioner och procedurkod. SSMA stöder Azure Synapse som målmiljö.

SSMA för Oracle kan hjälpa dig att migrera ett Oracle-informationslager eller data mart till Azure Synapse. SSMA är utformat för att automatisera processen med att migrera tabeller, vyer och data från en befintlig Oracle-miljö.

Azure Data Factory är en molnbaserad dataintegreringstjänst som har stöd för att skapa datadrivna arbetsflöden i molnet som samordnar och automatiserar dataflytt och datatransformering. Du kan använda Data Factory för att skapa och schemalägga datadrivna arbetsflöden (pipelines) som matar in data från olika datalager. Data Factory kan bearbeta och transformera data med hjälp av beräkningstjänster som Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics och Azure Mašinsko učenje.

Data Factory kan användas för att migrera data vid källan till Azure SQL-målet. Den här offlinedataflytten bidrar till att minska migreringens stilleståndstid avsevärt.

Azure Database Migration Services kan hjälpa dig att planera och utföra en migrering från miljöer som Oracle.

När du planerar att använda Azure-anläggningar för att hantera migreringsprocessen skapar du metadata som visar alla datatabeller som ska migreras och deras plats.

Designskillnader mellan Oracle och Azure Synapse

Som tidigare nämnts finns det vissa grundläggande skillnader i metoden mellan Oracle- och Azure Synapse Analytics-databaser. SSMA för Oracle hjälper inte bara till att överbrygga dessa luckor utan automatiserar även migreringen. Även om SSMA inte är den mest effektiva metoden för mycket stora datavolymer är det användbart för mindre tabeller.

Flera databaser jämfört med en enskild databas och scheman

Oracle-miljön innehåller ofta flera separata databaser. Det kan till exempel finnas separata databaser för: datainmatning och mellanlagringstabeller, kärnlagertabeller och data marts – som ibland kallas semantiska lager. Bearbetning i ETL- eller ELT-pipelines kan implementera kopplingar mellan databaser och flytta data mellan de separata databaserna.

Azure Synapse-miljön innehåller däremot en enkel databas och använder scheman för att dela upp tabeller i logiskt separata grupper. Vi rekommenderar att du använder en serie scheman i Azure Synapse-måldatabasen för att efterlikna de separata databaser som migrerats från Oracle-miljön. Om Oracle-miljön redan använder scheman kan du behöva använda en ny namngivningskonvention när du flyttar befintliga Oracle-tabeller och vyer till den nya miljön. Du kan till exempel sammanfoga det befintliga Oracle-schemat och tabellnamnen till det nya Azure Synapse-tabellnamnet och använda schemanamn i den nya miljön för att underhålla de ursprungliga separata databasnamnen. Även om du kan använda SQL-vyer ovanpå de underliggande tabellerna för att underhålla de logiska strukturerna finns det potentiella nackdelar med den metoden:

• Vyer i Azure Synapse är skrivskyddade, så alla uppdateringar av data måste ske i de underliggande bastabellerna.

• Det kan redan finnas ett eller flera lager med vyer och att lägga till ett extra lager med vyer kan påverka prestandan.

Dricks

Kombinera flera databaser till en enskild databas i Azure Synapse och använd schemanamn för att logiskt separera tabellerna.

Tabellöverväganden

När du migrerar tabeller mellan olika miljöer är det vanligtvis bara rådata och metadata som beskriver dem fysiskt migrera. Andra databaselement från källsystemet, till exempel index, migreras vanligtvis inte eftersom de kan vara onödiga eller implementerade på olika sätt i den nya miljön.

Prestandaoptimeringar i källmiljön, till exempel index, anger var du kan lägga till prestandaoptimering i den nya miljön. Om till exempel frågor i Oracle-källmiljön ofta använder bitmappade index, tyder det på att ett icke-grupperat index ska skapas i Azure Synapse. Andra inbyggda tekniker för prestandaoptimering som tabelreplikering kan vara mer tillämpliga än att skapa ett direkt index som liknar varandra. SSMA för Oracle kan användas för att ge migreringsrekommendationer för tabelldistribution och indexering.

Dricks

Befintliga index anger kandidater för indexering i det migrerade lagret.

Oracle-databasobjekttyper som inte stöds

Oracle-specifika funktioner kan ofta ersättas av Azure Synapse-funktioner. Vissa Oracle-databasobjekt stöds dock inte direkt i Azure Synapse. I följande lista över Oracle-databasobjekt som inte stöds beskrivs hur du kan uppnå motsvarande funktioner i Azure Synapse.

• Olika indexeringsalternativ: i Oracle har flera indexeringsalternativ, till exempel bitmappade index, funktionsbaserade index och domänindex, ingen direkt motsvarighet i Azure Synapse.

  Du kan ta reda på vilka kolumner som indexeras och indextypen efter:

  • Köra frågor mot systemkatalogtabeller och vyer, till exempel ALL_INDEXES, DBA_INDEXES, USER_INDEXESoch DBA_IND_COL. Du kan använda de inbyggda frågorna i Oracle SQL Developer, som du ser i följande skärmbild.

    

    Eller kör följande fråga för att hitta alla index av en viss typ:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Köra frågor mot vyerna dba_index_usage eller v$object_usage när övervakning är aktiverat. Du kan fråga dessa vyer i Oracle SQL Developer, som du ser i följande skärmbild.

    

  Funktionsbaserade index, där indexet innehåller resultatet av en funktion på de underliggande datakolumnerna, har ingen direkt motsvarighet i Azure Synapse. Vi rekommenderar att du först migrerar data och sedan kör Oracle-frågorna i Azure Synapse som använder funktionsbaserade index för att mäta prestanda. Om prestandan för dessa frågor i Azure Synapse inte är acceptabel kan du skapa en kolumn som innehåller det förberäknade värdet och sedan indexera kolumnen.

  När du konfigurerar Azure Synapse-miljön är det klokt att bara implementera index som används. Azure Synapse stöder för närvarande de indextyper som visas här:

  

  Azure Synapse-funktioner, till exempel parallell frågebearbetning och minnesintern cachelagring av data och resultat, gör det troligt att färre index krävs för att datalagerprogram ska uppnå prestandamål. Vi rekommenderar att du använder följande indextyper i Azure Synapse:

  • Grupperade kolumnlagringsindex: När inga indexalternativ har angetts för en tabell skapar Azure Synapse som standard ett grupperat kolumnlagringsindex. Grupperade kolumnlagringstabeller erbjuder den högsta nivån av datakomprimering, bästa övergripande frågeprestanda och överträffar vanligtvis klustrade index- eller heap-tabeller. Ett grupperat columnstore-index är vanligtvis det bästa valet för stora tabeller. När du skapar en tabell väljer du klustrad kolumnlagring om du är osäker på hur du ska indexera tabellen. Det finns dock vissa scenarier där grupperade kolumnlagringsindex inte är det bästa alternativet:

    • Tabeller med försorterade data på en sorteringsnyckel kan dra nytta av segmenteliminering som aktiveras av ordnade grupperade kolumnlagringsindex.
    • Tabeller med datatyperna varchar(max), nvarchar(max) eller varbinary(max), eftersom ett grupperat columnstore-index inte stöder dessa datatyper. Överväg i stället att använda ett heap- eller klustrade index.
    • Tabeller med tillfälliga data, eftersom kolumnlagringstabeller kan vara mindre effektiva än heap- eller temporära tabeller.
    • Små tabeller med mindre än 100 miljoner rader. Överväg i stället att använda heap-tabeller.

  • Ordnade grupperade kolumnlagringsindex: Genom att aktivera effektiv segmenteliminering ger ordnade grupperade kolumnlagringsindex i Azure Synapse dedikerade SQL-pooler mycket snabbare prestanda genom att hoppa över stora mängder sorterade data som inte matchar frågepredikatet. Att läsa in data i en ordnad CCI-tabell kan ta längre tid än en icke-ordnad CCI-tabell på grund av datasorteringsåtgärden, men frågor kan köras snabbare efteråt med ordnad CCI. Mer information om sorterade grupperade kolumnlagringsindex finns i Prestandajustering med ordnat grupperat kolumnlagringsindex.

  • Grupperade och icke-grupperade index: klustrade index kan överträffa grupperade kolumnlagringsindex när en enskild rad snabbt behöver hämtas. För frågor där en enskild radsökning, eller bara några få radsökningar, måste utföras med extrem hastighet bör du överväga att använda ett klusterindex eller ett sekundärt index som inte visas. Nackdelen med att använda ett klustrade index är att endast frågor med ett mycket selektivt filter i den klustrade indexkolumnen kommer att gynnas. För att förbättra filtreringen på andra kolumner kan du lägga till ett icke-grupperat index i de andra kolumnerna. Men varje index som du lägger till i en tabell använder mer utrymme och ökar bearbetningstiden för att läsa in.

  • Heap-tabeller: när du tillfälligt landar data i Azure Synapse kanske du upptäcker att en heaptabell gör den övergripande processen snabbare. Det beror på att inläsning av data till heap-tabeller går snabbare än att läsa in data till indextabeller, och i vissa fall kan efterföljande läsningar göras från cacheminnet. Om du bara läser in data för att mellanlagra dem innan du kör fler transformeringar är det mycket snabbare att läsa in dem till en heap-tabell än en klustrad kolumnlagringstabell. Dessutom går det snabbare att läsa in data till en tillfällig tabell än att läsa in en tabell till permanent lagring. För små uppslagstabeller med mindre än 100 miljoner rader är heaptabeller vanligtvis rätt val. Klusterkolumnlagringstabeller börjar få optimal komprimering när de innehåller mer än 100 miljoner rader.

• Grupperade tabeller: Oracle-tabeller kan ordnas så att tabellrader som används ofta tillsammans (baserat på ett gemensamt värde) lagras fysiskt tillsammans för att minska disk-I/O när data hämtas. Oracle tillhandahåller också ett hash-klusteralternativ för enskilda tabeller, som tillämpar ett hash-värde på klusternyckeln och fysiskt lagrar rader med samma hash-värde tillsammans. Om du vill visa en lista över kluster i en Oracle-databas använder du frågan SELECT * FROM DBA_CLUSTERS; . Om du vill avgöra om en tabell finns i ett kluster använder du SELECT * FROM TAB; frågan som visar tabellnamnet och kluster-ID:t för varje tabell.

  I Azure Synapse kan du uppnå liknande resultat med materialiserade och/eller replikerade tabeller, eftersom dessa tabelltyper minimerar I/O som krävs vid frågekörning.

• Materialiserade vyer: Oracle stöder materialiserade vyer och rekommenderar att du använder en eller flera för stora tabeller med många kolumner där endast ett fåtal kolumner används regelbundet i frågor. Materialiserade vyer uppdateras automatiskt av systemet när data i bastabellen uppdateras.

  Under 2019 meddelade Microsoft att Azure Synapse kommer att stödja materialiserade vyer med samma funktioner som i Oracle. Materialiserade vyer är nu en förhandsversionsfunktion i Azure Synapse.

• Utlösare i databasen: i Oracle kan en utlösare konfigureras så att den körs automatiskt när en utlösande händelse inträffar. Utlösande händelser kan vara:

  • En DML-instruktion (datamanipuleringsspråk), till exempel INSERT, UPDATEeller DELETE, körs på en tabell. Om du har definierat en utlösare som utlöses före en INSERT instruktion i en kundtabell utlöses utlösaren en gång innan en ny rad infogas i kundtabellen.

  • En DDL-instruktion, till exempel CREATE eller ALTER, körs. Den här utlösaren används ofta i granskningssyfte för att registrera schemaändringar.

  • En systemhändelse, till exempel start eller avstängning av Oracle-databasen.

  • En användarhändelse, till exempel inloggning eller inloggning.

  Du kan hämta en lista över utlösare som definierats i en Oracle-databas genom att fråga vyerna ALL_TRIGGERS, DBA_TRIGGERSeller USER_TRIGGERS . Följande skärmbild visar en DBA_TRIGGERS fråga i Oracle SQL Developer.

  

  Azure Synapse stöder inte Oracle-databasutlösare. Du kan dock lägga till motsvarande funktioner med hjälp av Data Factory, men om du gör det måste du omstrukturera de processer som använder utlösare.

• Synonymer: Oracle har stöd för att definiera synonymer som alternativa namn för flera databasobjekttyper. Dessa objekttyper omfattar: tabeller, vyer, sekvenser, procedurer, lagrade funktioner, paket, materialiserade vyer, Java-klassschemaobjekt, användardefinierade objekt eller en annan synonym.

  Azure Synapse stöder för närvarande inte definition av synonymer, men om en synonym i Oracle refererar till en tabell eller vy kan du definiera en vy i Azure Synapse som matchar det alternativa namnet. Om en synonym i Oracle refererar till en funktion eller lagrad procedur kan du i Azure Synapse skapa en annan funktion eller lagrad procedur, med ett namn som matchar synonymen, som anropar målet.

• Användardefinierade typer: Oracle stöder användardefinierade objekt som kan innehålla en serie enskilda fält, var och en med sina egna definitions- och standardvärden. Dessa objekt kan refereras i en tabelldefinition på samma sätt som inbyggda datatyper som NUMBER eller VARCHAR. Du kan hämta en lista över användardefinierade typer i en Oracle-databas genom att fråga vyerna ALL_TYPES, DBA_TYPESeller USER_TYPES .

  Azure Synapse stöder för närvarande inte användardefinierade typer. Om de data som du behöver migrera innehåller användardefinierade datatyper kan du antingen "platta ut" dem till en konventionell tabelldefinition, eller om de är matriser med data, normalisera dem i en separat tabell.

Mappning av Oracle-datatyp

De flesta Oracle-datatyper har en direkt motsvarighet i Azure Synapse. I följande tabell visas den rekommenderade metoden för att mappa Oracle-datatyper till Azure Synapse.

Oracle-datatyp	Azure Synapse-datatyp
BFILE	Stöds ej. Mappa till VARBINARY (MAX).
BINARY_FLOAT	Stöds ej. Mappa till FLOAT.
BINARY_DOUBLE	Stöds ej. Mappa till DOUBLE.
BLOB	Stöds inte direkt. Ersätt med VARBINARY(MAX).
CHAR	CHAR
CLOB	Stöds inte direkt. Ersätt med VARCHAR(MAX).
DATUM	DATE i Oracle kan också innehålla tidsinformation. Beroende på användningskarta till DATE eller TIMESTAMP.
DECIMAL	DECIMAL
DOUBLE	PRECISIONSDUBBLETT
FLYTA	FLYTA
INTEGER	INT
INTERVALL FRÅN ÅR TILL MÅNAD	INTERVALL-datatyper stöds inte. Använd datumjämförelsefunktioner, till exempel DATEDIFF eller DATEADD, för datumberäkningar.
INTERVALLDAG TILL SEKUND	INTERVALL-datatyper stöds inte. Använd datumjämförelsefunktioner, till exempel DATEDIFF eller DATEADD, för datumberäkningar.
LÅNG	Stöds ej. Mappa till VARCHAR(MAX).
LÅNG RÅ	Stöds ej. Mappa till VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMMER	FLYTA
NCLOB	Stöds inte direkt. Ersätt med NVARCHAR(MAX).
NUMERIC	NUMERIC
ORD-mediedatatyper	Stöds inte
RÅ	Stöds ej. Mappa till VARBINARY.
REAL	REAL
ROWID	Stöds ej. Mappa till GUID, vilket är liknande.
Geospatiala SDO-datatyper	Stöds inte
SMALLINT	SMALLINT
TIMESTAMP	DATETIME2 eller funktionen CURRENT_TIMESTAMP()
TIDSSTÄMPEL MED LOKAL TIDSZON	Stöds ej. Mappa till DATETIMEOFFSET.
TIDSSTÄMPEL MED TIDSZON	Stöds inte eftersom TIME lagras med wall-clock-tid utan en tidszonsförskjutning.
URIType	Stöds ej. Lagra i ett VARCHAR.
UROWID	Stöds ej. Mappa till GUID, vilket är liknande.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Stöds ej. Lagra XML-data i ett VARCHAR.

Oracle har också stöd för att definiera användardefinierade objekt som kan innehålla en serie enskilda fält, var och en med sina egna definitions- och standardvärden. Dessa objekt kan sedan refereras i en tabelldefinition på samma sätt som inbyggda datatyper som NUMBER eller VARCHAR. Azure Synapse stöder för närvarande inte användardefinierade typer. Om de data som du behöver migrera innehåller användardefinierade datatyper kan du antingen "platta ut" dem till en konventionell tabelldefinition, eller om de är matriser med data, normalisera dem i en separat tabell.

Dricks

Utvärdera antalet och typen av datatyper som inte stöds under migreringsförberedelsefasen.

Tredjepartsleverantörer erbjuder verktyg och tjänster för att automatisera migreringen, inklusive mappning av datatyper. Om ett ETL-verktyg från tredje part redan används i Oracle-miljön använder du verktyget för att implementera nödvändiga datatransformeringar.

Skillnader i SQL DML-syntax

SQL DML-syntaxskillnader finns mellan Oracle SQL och Azure Synapse T-SQL. Dessa skillnader beskrivs i detalj i Minimera SQL-problem för Oracle-migreringar. I vissa fall kan du automatisera DML-migreringen med hjälp av Microsoft-verktyg som SSMA för Oracle och Azure Database Migration Services eller produkter och tjänster för migrering från tredje part .

Funktioner, lagrade procedurer och sekvenser

När du migrerar ett informationslager från en mogen miljö som Oracle måste du förmodligen migrera andra element än enkla tabeller och vyer. Kontrollera om verktyg i Azure-miljön kan ersätta funktionerna i funktioner, lagrade procedurer och sekvenser eftersom det vanligtvis är mer effektivt att använda inbyggda Azure-verktyg än att koda om dem för Azure Synapse.

Som en del av förberedelsefasen skapar du en inventering av objekt som behöver migreras, definierar en metod för att hantera dem och allokerar lämpliga resurser i migreringsplanen.

Microsoft-verktyg som SSMA för Oracle och Azure Database Migration Services, eller produkter och tjänster från tredje part för migrering, kan automatisera migreringen av funktioner, lagrade procedurer och sekvenser.

I följande avsnitt beskrivs vidare migrering av funktioner, lagrade procedurer och sekvenser.

Functions

Precis som med de flesta databasprodukter har Oracle stöd för system- och användardefinierade funktioner i en SQL-implementering. När du migrerar en äldre databasplattform till Azure Synapse kan vanliga systemfunktioner vanligtvis migreras utan ändringar. Vissa systemfunktioner kan ha en något annorlunda syntax, men alla nödvändiga ändringar kan automatiseras. Du kan hämta en lista över funktioner i en Oracle-databas genom att ALL_OBJECTS fråga vyn med lämplig WHERE sats. Du kan använda Oracle SQL Developer för att hämta en lista över funktioner, enligt följande skärmbild.

För Oracle-systemfunktioner eller godtyckliga användardefinierade funktioner som inte har någon motsvarighet i Azure Synapse ska du koda om dessa funktioner med hjälp av ett målmiljöspråk. Användardefinierade Oracle-funktioner kodas i PL/SQL, Java eller C. Azure Synapse använder transact-SQL-språket för att implementera användardefinierade funktioner.

Lagrade procedurer

De flesta moderna databasprodukter stöder lagring av procedurer i databasen. Oracle tillhandahåller PL/SQL-språket för detta ändamål. En lagrad procedur innehåller vanligtvis både SQL-instruktioner och procedurlogik och returnerar data eller status. Du kan hämta en lista över lagrade procedurer i en Oracle-databas genom att ALL_OBJECTS fråga vyn med lämplig WHERE sats. Du kan använda Oracle SQL Developer för att hämta en lista över lagrade procedurer, som du ser i nästa skärmbild.

Azure Synapse stöder lagrade procedurer med T-SQL, så du måste koda om alla migrerade lagrade procedurer på det språket.

Sekvenser

I Oracle är en sekvens ett namngivet databasobjekt som skapats med hjälp av CREATE SEQUENCE. En sekvens ger unika numeriska värden via CURRVAL metoderna och NEXTVAL . Du kan använda de genererade unika talen som surrogatnyckelvärden för primära nycklar.

Azure Synapse implementerar CREATE SEQUENCEinte , men du kan implementera sekvenser med IDENTITY-kolumner eller SQL-kod som genererar nästa sekvensnummer i en serie.

Extrahera metadata och data från en Oracle-miljö

Generering av datadefinitionsspråk

ANSI SQL-standarden definierar den grundläggande syntaxen för DDL-kommandon (Data Definition Language). Vissa DDL-kommandon, till exempel CREATE TABLE och CREATE VIEW, är gemensamma för både Oracle och Azure Synapse men tillhandahåller även implementeringsspecifika funktioner som indexering, tabelldistribution och partitioneringsalternativ.

Du kan redigera befintliga Oracle CREATE TABLE och CREATE VIEW skript för att uppnå motsvarande definitioner i Azure Synapse. För att göra det kan du behöva använda ändrade datatyper och ta bort eller ändra Oracle-specifika satser som TABLESPACE.

I Oracle-miljön anger systemkatalogtabeller den aktuella tabellen och vydefinitionen. Till skillnad från användarunderhållen dokumentation är systemkataloginformationen alltid fullständig och synkroniserad med aktuella tabelldefinitioner. Du kan komma åt systemkataloginformation med hjälp av verktyg som Oracle SQL Developer. Oracle SQL Developer kan generera CREATE TABLE DDL-instruktioner som du kan redigera för att skapa motsvarande tabeller i Azure Synapse.

Du kan också använda SSMA för Oracle för att migrera tabeller från en befintlig Oracle-miljö till Azure Synapse. SSMA för Oracle använder lämpliga datatypsmappningar och rekommenderade tabell- och distributionstyper, enligt följande skärmbild.

Du kan också använda migrering från tredje part och ETL-verktyg som bearbetar systemkataloginformation för att uppnå liknande resultat.

Extrahering av data från Oracle

Du kan extrahera rådata från Oracle-tabeller till platta avgränsade filer, till exempel CSV-filer, med hjälp av oracle-standardverktyg som Oracle SQL Developer, SQL*Plus och SCLcl. Sedan kan du komprimera de platta avgränsade filerna med hjälp av gzip och ladda upp de komprimerade filerna till Azure Blob Storage med azcopy- eller Azure-datatransportverktyg som Azure Data Box.

Extrahera tabelldata så effektivt som möjligt, särskilt när du migrerar stora faktatabeller. För Oracle-tabeller använder du parallellitet för att maximera extraheringsdataflödet. Du kan uppnå parallellitet genom att köra flera processer som separat extraherar diskreta segment av data, eller med hjälp av verktyg som kan automatisera parallell extrahering genom partitionering.

Dricks

Använd parallellitet för den mest effektiva dataextraheringen.

Om det finns tillräckligt med nätverksbandbredd kan du extrahera data från ett lokalt Oracle-system direkt till Azure Synapse-tabeller eller Azure Blob Data Storage. Det gör du genom att använda Data Factory-processer, Azure Database Migration Service eller datamigrering från tredje part eller ETL-produkter.

Extraherade datafiler ska innehålla avgränsad text i CSV-, Optimerad radkolumn (ORC) eller Parquet-format.

Mer information om hur du migrerar data och ETL från en Oracle-miljö finns i Datamigrering, ETL och inläsning för Oracle-migreringar.

Prestandarekommendationer för Oracle-migreringar

Målet med prestandaoptimering är samma eller bättre prestanda för informationslagret efter migreringen till Azure Synapse.

Likheter i begrepp för prestandajusteringsmetoden

Många prestandajusteringsbegrepp för Oracle-databaser gäller för Azure Synapse-databaser. Till exempel:

• Använd datadistribution för att samla in data som ska kopplas till samma bearbetningsnod.

• Använd den minsta datatypen för en viss kolumn för att spara lagringsutrymme och påskynda frågebearbetningen.

• Se till att kolumner som ska kopplas har samma datatyp för att optimera kopplingsbearbetningen och minska behovet av datatransformering.

• Se till att statistiken är uppdaterad för att optimeraren ska kunna skapa den bästa körningsplanen.

• Övervaka prestanda med hjälp av inbyggda databasfunktioner för att säkerställa att resurserna används effektivt.

Dricks

Prioritera kunskaper om Azure Synapse-justeringsalternativ i början av en migrering.

Skillnader i prestandajusteringsmetod

Det här avsnittet visar skillnader i implementering av prestandajustering på låg nivå mellan Oracle och Azure Synapse.

Alternativ för datadistribution

För prestanda har Azure Synapse utformats med arkitektur med flera noder och använder parallell bearbetning. Om du vill optimera tabellprestanda i Azure Synapse kan du definiera ett alternativ för datadistribution i CREATE TABLE instruktioner med hjälp av -instruktionen DISTRIBUTION . Du kan till exempel ange en hash-distribuerad tabell som distribuerar tabellrader mellan beräkningsnoder med hjälp av en deterministisk hash-funktion. Många Oracle-implementeringar, särskilt äldre lokala system, stöder inte den här funktionen.

Till skillnad från Oracle stöder Azure Synapse lokala kopplingar mellan en liten tabell och en stor tabell via liten tabellreplikering. Tänk dig till exempel en liten dimensionstabell och en stor faktatabell i en star-schemamodell. Azure Synapse kan replikera den mindre dimensionstabellen över alla noder för att säkerställa att värdet för en kopplingsnyckel för den stora tabellen har en matchande, lokalt tillgänglig dimensionsrad. Omkostnaderna för replikering av dimensionstabeller är relativt låga för en liten dimensionstabell. För stora dimensionstabeller är en hashdistributionsmetod mer lämplig. Mer information om alternativ för datadistribution finns i Designvägledning för att använda replikerade tabeller och vägledning för att utforma distribuerade tabeller.

Dricks

Hash-distribution förbättrar frågeprestanda i stora faktatabeller. Resursallokeringsdistribution är användbart för att förbättra inläsningshastigheten.

Hash-distribution kan tillämpas på flera kolumner för en jämnare fördelning av bastabellen. Med distribution med flera kolumner kan du välja upp till åtta kolumner för distribution. Detta minskar inte bara datasnedvridningen över tid utan förbättrar även frågeprestanda.

Kommentar

Distribution med flera kolumner är för närvarande i förhandsversion för Azure Synapse Analytics. Du kan använda distribution med flera kolumner med CREATE MATERIALIZED VIEW, CREATE TABLE och CREATE TABLE AS SELECT.

Distributionsrådgivare

I Azure Synapse SQL kan du anpassa hur varje tabell distribueras. Tabelldistributionsstrategin påverkar frågeprestanda avsevärt.

Distributionsrådgivaren är en ny funktion i Synapse SQL som analyserar frågor och rekommenderar de bästa distributionsstrategierna för tabeller för att förbättra frågeprestanda. Frågor som ska beaktas av rådgivaren kan tillhandahållas av dig eller hämtas från dina historiska frågor som är tillgängliga i DMV.

Mer information och exempel på hur du använder distributionsrådgivaren finns i Distribution Advisor i Azure Synapse SQL.

Dataindexering

Azure Synapse har stöd för flera användardefinierbara indexeringsalternativ som har en annan åtgärd och användning jämfört med systemhanterade zonkartor i Oracle. Mer information om de olika indexeringsalternativen i Azure Synapse finns i Index för dedikerade SQL-pooltabeller.

Indexdefinitioner i en Oracle-källmiljö ger en användbar indikation på dataanvändning och kandidatkolumnerna för indexering i Azure Synapse-miljön. Vanligtvis behöver du inte migrera alla index från en äldre Oracle-miljö eftersom Azure Synapse inte förlitar sig för mycket på index och implementerar följande funktioner för att uppnå enastående prestanda:

• Parallell frågebearbetning.

• Cachelagring av minnesintern data och resultatuppsättning.

• Datadistribution, till exempel replikering av små dimensionstabeller, för att minska I/O.

Datapartitionering

I ett informationslager för företag kan faktatabeller innehålla miljarder rader. Partitionering optimerar underhåll och frågekörning av dessa tabeller genom att dela upp dem i separata delar för att minska mängden data som bearbetas. I Azure Synapse definierar -instruktionen CREATE TABLE partitioneringsspecifikationen för en tabell.

Du kan bara använda ett fält per tabell för partitionering. Det fältet är ofta ett datumfält eftersom många frågor filtreras efter datum eller ett datumintervall. Det går att ändra partitioneringen av en tabell efter den första inläsningen med hjälp av CTAS-instruktionen CREATE TABLE AS för att återskapa tabellen med en ny distribution. En detaljerad beskrivning av partitionering i Azure Synapse finns i Partitionering av tabeller i en dedikerad SQL-pool.

PolyBase eller COPY INTO för datainläsning

PolyBase stöder effektiv inläsning av stora mängder data till ett informationslager med hjälp av parallella inläsningsströmmar. Mer information finns i PolyBase-datainläsningsstrategi.

COPY INTO stöder också datainmatning med högt dataflöde och:

• Datahämtning från alla filer i en mapp och undermappar.
• Datahämtning från flera platser i samma lagringskonto. Du kan ange flera platser med hjälp av kommaavgränsade sökvägar.
• Azure Data Lake Storage (ADLS) och Azure Blob Storage.
• CSV-, PARQUET- och ORC-filformat.

Dricks

Den rekommenderade metoden för datainläsning är att använda COPY INTO tillsammans med PARQUET-filformat.

Arbetsbelastningshantering

Att köra blandade arbetsbelastningar kan innebära resursutmaningar i upptagna system. Ett lyckat arbetsbelastningshanteringsschema hanterar effektivt resurser, säkerställer högeffektiv resursanvändning och maximerar avkastningen på investeringen (ROI). Arbetsbelastningsklassificering, arbetsbelastningsbetydelse och arbetsbelastningsisolering ger mer kontroll över hur arbetsbelastningen använder systemresurser.

Guiden för arbetsbelastningshantering beskriver de tekniker som används för att analysera arbetsbelastningen, hantera och övervaka arbetsbelastningens betydelse samt stegen för att konvertera en resursklass till en arbetsbelastningsgrupp. Använd Azure-portalen och T-SQL-frågor på DMV:er för att övervaka arbetsbelastningen för att säkerställa att tillämpliga resurser används effektivt.

Nästa steg

Mer information om ETL och inläsning för Oracle-migrering finns i nästa artikel i den här serien: Datamigrering, ETL och inläsning för Oracle-migreringar.