Design och prestanda för Oracle-migreringar

Den här artikeln är del ett i 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 i 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.

Tips

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 (massively parallel processing) för att uppnå höga frågeprestanda på exceptionellt stora datavolymer, men det finns några grundläggande skillnader i metod:

• Äldre Oracle-system installeras ofta lokalt och använder relativt dyr maskinvara, medan Azure Synapse är molnbaserad 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 omkonfiguration av databaser, eller att dumpa och läsa in den igen. 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. I nästa diagram sammanfattas det Azure Synapse ekosystemet.

Azure Synapse ger bästa möjliga prestanda för relationsdatabaser 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ö 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 övergripande 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 datamodelländringar (om sådana finns).

• Definiera mekanismen för källdataextrahering.

• 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.

Designöverväganden

Migreringsomfång

När du förbereder migrering 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 med tiden 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 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.

Tips

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 den Azure Synapse miljön men inte för stor för att snabbt visa värde. En storlek på 1–10 terabyte är typisk.

En första metod för ett migreringsprojekt är att minimera risken, ansträngningen och tiden som behövs så att du snabbt ser fördelarna med Azure-molnmiljön. Följande metoder begränsar omfånget för den inledande migreringen till bara dataarkivet 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 har fyllts 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 omfattar ändringar.

Lift and Shift

I 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 dra nytta av fördelarna med att flytta till Azure-molnmiljön. Lift and shift-migrering passar bra för dessa scenarier:

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

Tips

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

Stegvis metod som omfattar ä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 omkonstruktionsprocessen 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 nya ä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-funktioner 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 prestandan i 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 dataarkiv 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 Machine Learning.

Data Factory kan användas för att migrera data vid källan till Azure SQL mål. Den här dataflytten offline bidrar till att minska stilleståndstiden för migreringen 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-resurser 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 metod 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: datainmatnings- och mellanlagringstabeller, kärnlagertabeller och dataförråd , som ibland kallas semantiskt lager. Bearbetning i ETL- eller ELT-pipelines kan implementera kopplingar mellan databaser och flytta data mellan separata databaser.

Däremot innehåller Azure Synapse-miljön en enkel databas och använder scheman för att separera tabeller i logiskt separata grupper. Vi rekommenderar att du använder en serie scheman i måldatabasen Azure Synapse för att efterlikna de separata databaser som migreras 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 tabellnamn 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.

Tips

Kombinera flera databaser till en enda databas i Azure Synapse och använd schemanamn för att logiskt avgränsa 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. 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 inom Azure Synapse. Andra interna prestandaoptimeringstekniker som tabelreplikering kan vara mer tillämpliga än att skapa raka like-for-like-index. SSMA för Oracle kan användas för att ge migreringsrekommendationer för tabelldistribution och indexering.

Tips

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. Följande lista över Oracle-databasobjekt som inte stöds beskriver 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 genom att:

  • 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%';
    

  • Fråga vyerna dba_index_usage eller v$object_usage när övervakning är aktiverat. Du kan köra frågor mot 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ågor som använder funktionsbaserade index för att mäta prestanda i Azure Synapse. 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 kolumnlagringsindex ä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örsorteringsdata på en eller flera sorteringsnycklar kan dra nytta av segmenteliminering som aktiveras av sorterade grupperade kolumnlagringsindex.
    • Tabeller med datatyperna varchar(max), nvarchar(max) eller varbinary(max), eftersom ett grupperat kolumnlagringsindex 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 sorterade 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 columnstore-index.

  • Grupperade och icke-klustrade 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 grupperat index är att endast frågor med ett mycket selektivt filter i den klustrade indexkolumnen kommer att gynnas. Om du vill förbättra filtreringen för andra kolumner kan du lägga till ett icke-grupperat index i de andra kolumnerna. Varje index som du lägger till i en tabell använder dock mer utrymme och ökar bearbetningstiden för att läsa in.

  • Heap-tabeller: När du tillfälligt landar data på Azure Synapse kan det hända att en heap-tabell gör den övergripande processen snabbare. Det beror på att inläsningen 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 heap-tabeller vanligtvis rätt val. Klusterkolumnlagringstabeller börjar uppnå 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 ta reda på 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 genom att använda materialiserade och/eller replikerade tabeller, eftersom dessa tabelltyper minimerar den 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örhandsgranskningsfunktion i Azure Synapse.

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

  • En DML-instruktion (Data Manipulation Language), 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 utloggning.

  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 stöder definition av synonymer som alternativa namn för flera typer av databasobjekt. Dessa objekttyper är: 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 för att matcha 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, antingen "platta ut" dem till en konventionell tabelldefinition, eller om de är matriser med data, normaliserar du dem i en separat tabell.

Oracle-datatypsmappning

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 inte. Mappa till VARBINARY (MAX).
BINARY_FLOAT	Stöds inte. Mappa till FLOAT.
BINARY_DOUBLE	Stöds inte. 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).
DATE	DATE i Oracle kan också innehålla tidsinformation. Beroende på användningskarta till DATE eller TIMESTAMP.
DECIMAL	DECIMAL
DOUBLE	PRECISION DUBBEL
FLYTA	FLYTA
INTEGER	INT
INTERVALL FRÅN ÅR TILL MÅNAD	INTERVAL-datatyper stöds inte. Använd datumjämförelsefunktioner, till exempel DATEDIFF eller DATEADD, för datumberäkningar.
INTERVALL DAG TILL SEKUND	INTERVAL-datatyper stöds inte. Använd datumjämförelsefunktioner, till exempel DATEDIFF eller DATEADD, för datumberäkningar.
LÅNG	Stöds inte. Mappa till VARCHAR(MAX).
LONG RAW	Stöds inte. 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
RAW	Stöds inte. Mappa till VARBINARY.
REAL	REAL
ROWID	Stöds inte. Mappa till GUID, vilket är liknande.
Geospatiala SDO-datatyper	Stöds inte
SMALLINT	SMALLINT
TIMESTAMP	Funktionen DATETIME2 eller funktionen CURRENT_TIMESTAMP()
TIDSSTÄMPEL MED LOKAL TIDSZON	Stöds inte. Mappa till DATETIMEOFFSET.
TIDSSTÄMPEL MED TIDSZON	Stöds inte eftersom TIME lagras med wall-clock-tid utan en tidszonsförskjutning.
URIType	Stöds inte. Lagra i ett VARCHAR.
UROWID	Stöds inte. Mappa till GUID, vilket är liknande.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Stöds inte. 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 sin egen definition 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, antingen "platta ut" dem till en konventionell tabelldefinition, eller om de är matriser med data, normaliserar du dem i en separat tabell.

Tips

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 det 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 din migreringsplan.

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, som du ser i 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 SPRÅKET PL/SQL 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ärnycklar.

Azure Synapse implementerar CREATE SEQUENCEinte , men du kan implementera sekvenser med hjälp av 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 innehåller även implementeringsspecifika funktioner som indexering, tabelldistribution och partitioneringsalternativ.

Du kan redigera befintliga OracleCREATE 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ö för att Azure Synapse. SSMA för Oracle tillämpar lämpliga datatypmappningar 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.

Dataextrahering från Oracle

Du kan extrahera rådata från Oracle-tabeller till flata avgränsade filer, till exempel CSV-filer, med hjälp av vanliga Oracle-verktyg som Oracle SQL Developer, SQL*Plus och SCLcl. Sedan kan du komprimera de flata avgränsade filerna med hjälp av gzip och ladda upp de komprimerade filerna till Azure Blob Storage med hjälp av 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 datasegment eller med hjälp av verktyg som kan automatisera parallell extraktion genom partitionering.

Tips

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-, Optimized Row Columnar (ORC) eller Parquet-format.

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

Prestandarekommendationer för Oracle-migreringar

Målet med prestandaoptimering är samma eller bättre informationslagerprestanda efter migreringen till Azure Synapse.

Likheter i begrepp för prestandajusteringsmetod

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

• Använd datadistribution för att samordna 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 resurser används effektivt.

Tips

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

Skillnader i prestandajusteringsmetod

I det här avsnittet beskrivs 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 -instruktionenDISTRIBUTION. 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 hash-distributionsmetod 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.

Tips

Hash-distribution förbättrar frågeprestanda för 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 dataskevhet över tid utan förbättrar även frågeprestanda.

Anteckning

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 övervägas 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 stöder 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 kandidatkolumner för indexering i Azure Synapse miljö. Normalt 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.

• Minnesintern data och cachelagring av resultatuppsättningar.

• 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ållet och frågekörningen 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 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 Partitionera 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.

Tips

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 schema för arbetsbelastningshantering hanterar effektivt resurser, säkerställer högeffektiv resursanvändning och maximerar avkastningen på investeringar (ROI). Arbetsbelastningsklassificering, arbetsbelastningsbetydelse och arbetsbelastningsisolering ger större kontroll över hur arbetsbelastningen använder systemresurser.

I arbetsbelastningshanteringsguiden beskrivs 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 Portal- 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.