Ontwerp en prestaties voor Oracle-migraties

Dit artikel is deel één van een zevendelige reeks met richtlijnen voor het migreren van Oracle naar Azure Synapse Analytics. De focus van dit artikel ligt op best practices voor ontwerp en prestaties.

Overzicht

Vanwege de kosten en complexiteit van het onderhouden en upgraden van verouderde on-premises Oracle-omgevingen, willen veel bestaande Oracle-gebruikers profiteren van de innovaties die worden geboden door moderne cloudomgevingen. Met Infrastructuur als een dienst (IaaS) en PaaS-cloudomgevingen (Platform-as-a-Service) kunt u taken zoals infrastructuuronderhoud en platformontwikkeling delegeren aan de cloudprovider.

Tip

Meer dan alleen een database: de Azure-omgeving bevat een uitgebreide set mogelijkheden en hulpprogramma's.

Hoewel Oracle en Azure Synapse Analytics beide SQL-databases zijn die MPP-technieken (Massively Parallel Processing) gebruiken om hoge queryprestaties te bereiken op uitzonderlijk grote gegevensvolumes, zijn er enkele fundamentele verschillen in aanpak:

• Verouderde Oracle-systemen worden vaak on-premises geïnstalleerd en maken gebruik van relatief dure hardware, terwijl Azure Synapse cloudgebaseerd is en gebruikmaakt van Azure-opslag- en rekenresources.

• Het upgraden van een Oracle-configuratie is een belangrijke taak met extra fysieke hardware en mogelijk langdurige databaseherconfiguratie, of dumpen en opnieuw laden. Omdat opslag- en rekenresources gescheiden zijn in de Azure-omgeving en elastisch kunnen worden geschaald, kunnen deze resources onafhankelijk van elkaar omhoog of omlaag worden geschaald.

• U kunt Azure Synapse zo nodig onderbreken of het formaat ervan wijzigen om het resourcegebruik en de kosten te verminderen.

Microsoft Azure is een wereldwijd beschikbare, zeer veilige, schaalbare cloudomgeving met Azure Synapse en een ecosysteem van ondersteunende hulpprogramma's en mogelijkheden. Het volgende diagram geeft een overzicht van het Azure Synapse ecosysteem.

Azure Synapse biedt de beste relationele databaseprestaties door gebruik te maken van technieken zoals MPP en automatische cache in het geheugen. U kunt de resultaten van deze technieken zien in onafhankelijke benchmarks, zoals de benchmark die onlangs is uitgevoerd door GigaOm, waarin Azure Synapse wordt vergeleken met andere populaire clouddatawarehouse-aanbiedingen. Klanten die naar de Azure Synapse-omgeving migreren, zien veel voordelen, waaronder:

• Verbeterde prestaties en prijs/prestaties.

• Meer flexibiliteit en kortere time to value.

• Snellere serverimplementatie en toepassingsontwikkeling.

• Elastische schaalbaarheid: betaal alleen voor het werkelijke gebruik.

• Verbeterde beveiliging/naleving.

• Lagere kosten voor opslag en herstel na noodgevallen.

• Lagere totale TCO, betere kostenbeheersing en gestroomlijnde operationele uitgaven (OPEX).

Als u deze voordelen wilt maximaliseren, migreert u nieuwe of bestaande gegevens en toepassingen naar het Azure Synapse-platform. In veel organisaties omvat migratie het verplaatsen van een bestaand datawarehouse van een verouderd on-premises platform, zoals Oracle, naar Azure Synapse. Op hoog niveau omvat het migratieproces de volgende stappen:

    Voorbereiding 🡆

• Bereik definiëren: wat moet worden gemigreerd.

• Inventaris maken van gegevens en processen voor migratie.

• Wijzigingen in het gegevensmodel definiëren (indien aanwezig).

• Mechanisme voor het extraheren van brongegevens definiëren.

• Identificeer de juiste hulpprogramma's en functies van Azure en derden die moeten worden gebruikt.

• Train personeel vroeg op het nieuwe platform.

• Het Azure-doelplatform instellen.

    Migratie 🡆

• Begin klein en eenvoudig.

• Automatiseer waar mogelijk.

• Maak gebruik van ingebouwde Azure-hulpprogramma's en -functies om de migratie-inspanning te verminderen.

• Metagegevens migreren voor tabellen en weergaven.

• Historische gegevens migreren die moeten worden onderhouden.

• Opgeslagen procedures en bedrijfsprocessen migreren of herstructureren.

• Processen voor incrementeel laden van ETL/ELT migreren of herstructureren.

    Na de migratie

• Controleer en documenteer alle fasen van het proces.

• Gebruik de opgedane ervaring om een sjabloon te maken voor toekomstige migraties.

• Herwerk het gegevensmodel indien nodig (met behulp van nieuwe platformprestaties en schaalbaarheid).

• Toepassingen en hulpprogramma's voor query's testen.

• Queryprestaties benchmarken en optimaliseren.

Dit artikel bevat algemene informatie en richtlijnen voor het optimaliseren van prestaties bij het migreren van een datawarehouse van een bestaande Oracle-omgeving naar Azure Synapse. Het doel van prestatieoptimalisatie is het behalen van dezelfde of betere prestaties van het datawarehouse in Azure Synapse na de migratie.

Overwegingen bij het ontwerpen

Migratiebereik

Wanneer u de migratie vanuit een Oracle-omgeving voorbereidt, moet u rekening houden met de volgende migratieopties.

Kies de workload voor de eerste migratie

Normaal gesproken zijn verouderde Oracle-omgevingen in de loop van de tijd ontwikkeld om meerdere onderwerpgebieden en gemengde workloads te omvatten. Wanneer u besluit waar u aan een migratieproject wilt beginnen, kiest u een gebied waarin u het volgende kunt doen:

• Bewijs de levensvatbaarheid van migreren naar Azure Synapse door snel de voordelen van de nieuwe omgeving te leveren.

• Laat uw interne technische medewerkers relevante ervaring opdoen met de processen en hulpprogramma's die ze gebruiken wanneer ze andere gebieden migreren.

• Maak een sjabloon voor verdere migraties die specifiek is voor de bron-Oracle-omgeving en de huidige hulpprogramma's en processen die al aanwezig zijn.

Een goede kandidaat voor een initiële migratie vanuit een Oracle-omgeving ondersteunt de voorgaande items, en:

• Implementeert een BI/Analytics-workload in plaats van een OLTP-workload (Online Transaction Processing).

• Heeft een gegevensmodel, zoals een star of een sneeuwvlokschema, dat met minimale aanpassingen kan worden gemigreerd.

Tip

Maak een inventaris van objecten die moeten worden gemigreerd en documenteer het migratieproces.

Het volume van gemigreerde gegevens in een initiële migratie moet groot genoeg zijn om de mogelijkheden en voordelen van de Azure Synapse omgeving te demonstreren, maar niet te groot om snel de waarde aan te tonen. Een grootte in het bereik van 1-10 terabyte is typisch.

Een eerste benadering van een migratieproject is het minimaliseren van het risico, de inspanning en de benodigde tijd, zodat u snel de voordelen van de Azure-cloudomgeving kunt zien. De volgende benaderingen beperken het bereik van de eerste migratie tot alleen de datamarts en hebben geen betrekking op bredere migratieaspecten, zoals ETL-migratie en historische gegevensmigratie. U kunt deze aspecten echter in latere fasen van het project aanpakken zodra de gemigreerde datamartlaag is gevuld met gegevens en de vereiste buildprocessen.

Lift-and-shift-migratie versus gefaseerde benadering

Over het algemeen zijn er twee soorten migraties, ongeacht het doel en het bereik van de geplande migratie: lift-and-shift as-is en een gefaseerde benadering waarin wijzigingen zijn opgenomen.

Lift-and-shift

In een lift-and-shift-migratie wordt een bestaand gegevensmodel, zoals een star-schema, ongewijzigd gemigreerd naar het nieuwe Azure Synapse-platform. Deze aanpak minimaliseert risico's en migratietijd door het werk te verminderen dat nodig is om de voordelen van de overstap naar de Azure-cloudomgeving te realiseren. Lift-and-shift-migratie is geschikt voor deze scenario's:

• U hebt een bestaande Oracle-omgeving met één datamart om te migreren, of
• U hebt een bestaande Oracle-omgeving met gegevens die zich al in een goed ontworpen star of sneeuwvlokschema bevinden, of
• U staat onder druk van tijd en kosten om over te stappen naar een moderne cloudomgeving.

Tip

Lift-and-shift is een goed uitgangspunt, zelfs als in de volgende fasen wijzigingen in het gegevensmodel worden geïmplementeerd.

Gefaseerde benadering waarin wijzigingen zijn opgenomen

Als een verouderd datawarehouse zich gedurende een lange periode heeft ontwikkeld, moet u het mogelijk opnieuw ontwerpen om de vereiste prestatieniveaus te behouden. Mogelijk moet u ook opnieuw engineeren om nieuwe gegevens te ondersteunen, zoals IoT-streams (Internet of Things). Als onderdeel van het her-engineeringproces migreert u naar Azure Synapse om de voordelen van een schaalbare cloudomgeving te verkrijgen. Migratie kan een wijziging in het onderliggende gegevensmodel omvatten, zoals een verplaatsing van een Inmon-model naar een gegevenskluis.

Microsoft raadt u aan uw bestaande gegevensmodel as-is te verplaatsen naar Azure en de prestaties en flexibiliteit van de Azure-omgeving te gebruiken om de wijzigingen in de nieuwe engineering toe te passen. Op die manier kunt u de mogelijkheden van Azure gebruiken om de wijzigingen aan te brengen zonder dat dit van invloed is op het bestaande bronsysteem.

Microsoft-faciliteiten gebruiken om een migratie op basis van metagegevens te implementeren

U kunt het migratieproces automatiseren en organiseren met behulp van de mogelijkheden van de Azure-omgeving. Deze benadering minimaliseert de prestatietreffer in de bestaande Oracle-omgeving, die mogelijk al dicht bij de capaciteit wordt uitgevoerd.

De SQL Server Migration Assistant (SSMA) voor Oracle kan veel onderdelen van het migratieproces automatiseren, waaronder in sommige gevallen functies en procedurele code. SSMA ondersteunt Azure Synapse als doelomgeving.

Met SSMA voor Oracle kunt u een Oracle-datawarehouse of datamart migreren naar Azure Synapse. SSMA is ontworpen om het proces van het migreren van tabellen, weergaven en gegevens vanuit een bestaande Oracle-omgeving te automatiseren.

Azure Data Factory is een cloudservice voor gegevensintegratie die ondersteuning biedt voor het maken van gegevensgestuurde werkstromen in de cloud die gegevensverplaatsing en gegevenstransformatie organiseren en automatiseren. U kunt Data Factory gebruiken om gegevensgestuurde werkstromen (pijplijnen) te maken en te plannen die gegevens uit verschillende gegevensarchieven opnemen. Data Factory kan gegevens verwerken en transformeren met behulp van rekenservices zoals Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics en Azure Machine Learning.

Data Factory kan worden gebruikt om gegevens bij de bron te migreren naar Azure SQL doel. Deze offlinegegevensverplaatsing helpt de downtime van de migratie aanzienlijk te verminderen.

Azure Database Migration Services kan u helpen bij het plannen en uitvoeren van een migratie vanuit omgevingen zoals Oracle.

Wanneer u van plan bent om Azure-faciliteiten te gebruiken voor het beheren van het migratieproces, maakt u metagegevens met een lijst met alle gegevenstabellen die moeten worden gemigreerd en hun locatie.

Ontwerpverschillen tussen Oracle en Azure Synapse

Zoals eerder vermeld, zijn er enkele fundamentele verschillen in benadering tussen Oracle- en Azure Synapse Analytics-databases. SSMA voor Oracle helpt niet alleen deze hiaten te overbruggen, maar automatiseert ook de migratie. Hoewel SSMA niet de meest efficiënte benadering is voor zeer grote hoeveelheden gegevens, is het handig voor kleinere tabellen.

Meerdere databases versus individuele database en schema's

De Oracle-omgeving bevat vaak meerdere afzonderlijke databases. Er kunnen bijvoorbeeld afzonderlijke databases zijn voor: gegevensopname- en faseringstabellen, kernwarehousetabellen en datamarts, ook wel de semantische laag genoemd. Verwerking in ETL- of ELT-pijplijnen kan cross-database joins implementeren en gegevens verplaatsen tussen de afzonderlijke databases.

De Azure Synapse omgeving bevat daarentegen één database en maakt gebruik van schema's om tabellen te scheiden in logisch gescheiden groepen. U wordt aangeraden een reeks schema's binnen de doeldatabase Azure Synapse te gebruiken om de afzonderlijke databases na te bootsen die zijn gemigreerd vanuit de Oracle-omgeving. Als de Oracle-omgeving al schema's gebruikt, moet u mogelijk een nieuwe naamconventie gebruiken wanneer u de bestaande Oracle-tabellen en -weergaven naar de nieuwe omgeving verplaatst. U kunt bijvoorbeeld de bestaande Oracle-schema- en tabelnamen samenvoegen in de nieuwe Azure Synapse tabelnaam en schemanamen in de nieuwe omgeving gebruiken om de oorspronkelijke afzonderlijke databasenamen te behouden. Hoewel u SQL-weergaven boven op de onderliggende tabellen kunt gebruiken om de logische structuren te behouden, zijn er mogelijke nadelen aan deze benadering:

• Weergaven in Azure Synapse zijn alleen-lezen, dus eventuele updates van de gegevens moeten plaatsvinden in de onderliggende basistabellen.

• Er bestaan mogelijk al een of meer weergavelagen en het toevoegen van een extra laag met weergaven kan van invloed zijn op de prestaties.

Tip

Combineer meerdere databases in één database binnen Azure Synapse en gebruik schemanamen om de tabellen logisch van elkaar te scheiden.

Tabeloverwegingen

Wanneer u tabellen migreert tussen verschillende omgevingen, worden doorgaans alleen de onbewerkte gegevens en de metagegevens die deze beschrijven fysiek gemigreerd. Andere database-elementen uit het bronsysteem, zoals indexen, worden meestal niet gemigreerd omdat ze mogelijk niet nodig zijn of anders worden geïmplementeerd in de nieuwe omgeving.

Prestatieoptimalisaties in de bronomgeving, zoals indexen, geven aan waar u prestatieoptimalisatie in de nieuwe omgeving kunt toevoegen. Als query's in de bron-Oracle-omgeving bijvoorbeeld vaak bit-toegewezen indexen gebruiken, betekent dit dat er een niet-geclusterde index moet worden gemaakt binnen Azure Synapse. Andere systeemeigen technieken voor het optimaliseren van prestaties, zoals tabelreplicatie, zijn mogelijk meer van toepassing dan het maken van een rechte, soortgelijke index. SSMA voor Oracle kan worden gebruikt voor migratieaanbeveling voor tabeldistributie en indexering.

Tip

Bestaande indexen geven kandidaten aan voor indexering in het gemigreerde magazijn.

Niet-ondersteunde Oracle-databaseobjecttypen

Oracle-specifieke functies kunnen vaak worden vervangen door Azure Synapse functies. Sommige Oracle-databaseobjecten worden echter niet rechtstreeks ondersteund in Azure Synapse. In de volgende lijst met niet-ondersteunde Oracle-databaseobjecten wordt beschreven hoe u een gelijkwaardige functionaliteit kunt bereiken in Azure Synapse.

• Verschillende indexeringsopties: in Oracle hebben verschillende indexeringsopties, zoals bit-toegewezen indexen, op functies gebaseerde indexen en domeinindexen, geen direct equivalent in Azure Synapse.

  U kunt nagaan welke kolommen zijn geïndexeerd en het indextype door:

  • Query's uitvoeren op systeemcatalogustabellen en -weergaven, zoals ALL_INDEXES, DBA_INDEXES, USER_INDEXESen DBA_IND_COL. U kunt de ingebouwde query's in Oracle SQL Developer gebruiken, zoals wordt weergegeven in de volgende schermopname.

    

    Of voer de volgende query uit om alle indexen van een bepaald type te vinden:

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

  • Query's uitvoeren op de dba_index_usage weergaven of v$object_usage wanneer bewaking is ingeschakeld. U kunt query's uitvoeren op deze weergaven in Oracle SQL Developer, zoals wordt weergegeven in de volgende schermopname.

    

  Op functies gebaseerde indexen, waarbij de index het resultaat van een functie op de onderliggende gegevenskolommen bevat, hebben geen direct equivalent in Azure Synapse. U wordt aangeraden eerst de gegevens te migreren en vervolgens in Azure Synapse de Oracle-query's uit te voeren die gebruikmaken van op functies gebaseerde indexen om de prestaties te meten. Als de prestaties van deze query's in Azure Synapse niet acceptabel zijn, kunt u overwegen om een kolom te maken die de vooraf berekende waarde bevat en vervolgens die kolom te indexeren.

  Wanneer u de Azure Synapse-omgeving configureert, is het zinvol om alleen indexen in gebruik te implementeren. Azure Synapse ondersteunt momenteel de indextypen die hier worden weergegeven:

  

  Azure Synapse functies, zoals parallelle queryverwerking en in-memory caching van gegevens en resultaten, is het waarschijnlijk dat er minder indexen nodig zijn voor datawarehousetoepassingen om prestatiedoelen te bereiken. U wordt aangeraden de volgende indextypen te gebruiken in Azure Synapse:

  • Geclusterde columnstore-indexen: wanneer er geen indexopties zijn opgegeven voor een tabel, maakt Azure Synapse standaard een geclusterde columnstore-index. Geclusterde columnstore-tabellen bieden het hoogste niveau van gegevenscompressie, de beste algehele queryprestaties en presteren over het algemeen beter dan geclusterde index- of heap-tabellen. Een geclusterde columnstore-index is meestal de beste keuze voor grote tabellen. Wanneer u een tabel maakt, kiest u geclusterde columnstore als u niet zeker weet hoe u de tabel moet indexeren. Er zijn echter enkele scenario's waarin geclusterde columnstore-indexen niet de beste optie zijn:

    • Tabellen met vooraf sorteren van gegevens op een of meer sorteersleutels kunnen profiteren van de segmentverwijdering die wordt ingeschakeld door geordende geclusterde columnstore-indexen.
    • Tabellen met het gegevenstype varchar(max), nvarchar(max) of varbinary(max), omdat een geclusterde columnstore-index deze gegevenstypen niet ondersteunt. Overweeg in plaats daarvan het gebruik van een heap- of geclusterde index.
    • Tabellen met tijdelijke gegevens, omdat columnstore-tabellen mogelijk minder efficiënt zijn dan heap- of tijdelijke tabellen.
    • Kleine tabellen met minder dan 100 miljoen rijen. Overweeg in plaats daarvan heap-tabellen te gebruiken.

  • Geordende geclusterde columnstore-indexen: door efficiënte segmentverwijdering in te schakelen, bieden geordende geclusterde columnstore-indexen in Azure Synapse toegewezen SQL-pools veel snellere prestaties door grote hoeveelheden geordende gegevens over te slaan die niet overeenkomen met het querypredicaat. Het laden van gegevens in een geordende CCI-tabel kan langer duren dan een niet-geordende CCI-tabel vanwege de gegevenssorteerbewerking, maar query's kunnen daarna sneller worden uitgevoerd met geordende CCI. Zie Prestaties afstemmen met geordende geclusterde columnstore-indexen voor meer informatie over geordende geclusterde columnstore-indexen.

  • Geclusterde en niet-geclusterde indexen: geclusterde indexen kunnen beter presteren dan geclusterde columnstore-indexen wanneer er snel één rij moet worden opgehaald. Voor query's waarbij één rijzoekactie, of slechts enkele rijenzoekacties, extreem snel moeten worden uitgevoerd, kunt u overwegen een clusterindex of niet-geclusterde secundaire index te gebruiken. Het nadeel van het gebruik van een geclusterde index is dat alleen query's met een zeer selectief filter op de geclusterde indexkolom profiteren. Als u het filteren op andere kolommen wilt verbeteren, kunt u een niet-geclusterde index toevoegen aan de andere kolommen. Elke index die u aan een tabel toevoegt, gebruikt echter meer ruimte en verhoogt de verwerkingstijd om te laden.

  • Heap-tabellen: wanneer u tijdelijk gegevens op Azure Synapse plaatst, merkt u mogelijk dat het gebruik van een heap-tabel het algehele proces sneller maakt. Dit komt doordat het laden van gegevens naar heap-tabellen sneller gaat dan het laden van gegevens in indextabellen. In sommige gevallen kunnen latere leesbewerkingen vanuit de cache worden uitgevoerd. Als u gegevens alleen laadt om deze te fasereren voordat u meer transformaties uitvoert, is het veel sneller om deze in een heap-tabel te laden dan in een geclusterde columnstore-tabel. Bovendien gaat het laden van gegevens naar een tijdelijke tabel sneller dan het laden van een tabel naar permanente opslag. Voor kleine opzoektabellen met minder dan 100 miljoen rijen zijn heap-tabellen meestal de juiste keuze. Clusterkolomopslagtabellen beginnen optimale compressie te bereiken wanneer ze meer dan 100 miljoen rijen bevatten.

• Geclusterde tabellen: Oracle-tabellen kunnen zodanig worden ingedeeld dat tabelrijen die vaak samen worden gebruikt (op basis van een gemeenschappelijke waarde) fysiek worden opgeslagen om de schijf-I/O te verminderen wanneer gegevens worden opgehaald. Oracle biedt ook een hashclusteroptie voor afzonderlijke tabellen, waarmee een hash-waarde wordt toegepast op de clustersleutel en rijen met dezelfde hashwaarde fysiek worden opgeslagen. Gebruik de SELECT * FROM DBA_CLUSTERS; query om clusters in een Oracle-database weer te geven. Als u wilt bepalen of een tabel zich in een cluster bevindt, gebruikt u de SELECT * FROM TAB; query, die de tabelnaam en cluster-id voor elke tabel weergeeft.

  In Azure Synapse kunt u vergelijkbare resultaten bereiken met behulp van gerealiseerde en/of gerepliceerde tabellen, omdat deze tabeltypen de I/O minimaliseren die nodig zijn tijdens de queryuitvoering.

• Gerealiseerde weergaven: Oracle ondersteunt gerealiseerde weergaven en raadt aan om een of meer te gebruiken voor grote tabellen met veel kolommen waarbij slechts enkele kolommen regelmatig in query's worden gebruikt. Gerealiseerde weergaven worden automatisch vernieuwd door het systeem wanneer gegevens in de basistabel worden bijgewerkt.

  In 2019 heeft Microsoft aangekondigd dat Azure Synapse gerealiseerde weergaven zal ondersteunen met dezelfde functionaliteit als in Oracle. Gerealiseerde weergaven zijn nu een preview-functie in Azure Synapse.

• In-database-triggers: in Oracle kan een trigger worden geconfigureerd om automatisch te worden uitgevoerd wanneer er een triggeringgebeurtenis optreedt. Activerende gebeurtenissen kunnen zijn:

  • Een DML-instructie (Data Manipulation Language), zoals INSERT, UPDATEof DELETE, wordt uitgevoerd in een tabel. Als u een trigger hebt gedefinieerd die vóór een INSERT instructie in een klanttabel wordt geactiveerd, wordt de trigger eenmaal geactiveerd voordat een nieuwe rij wordt ingevoegd in de tabel klant.

  • Een DDL-instructie, zoals CREATE of ALTER, wordt uitgevoerd. Deze trigger wordt vaak gebruikt voor controledoeleinden om schemawijzigingen vast te leggen.

  • Een systeem gebeurtenis, zoals het opstarten of afsluiten van de Oracle-database.

  • Een gebruikersgebeurtenis, zoals aanmelden of afmelden.

  U kunt een lijst met triggers ophalen die zijn gedefinieerd in een Oracle-database door een query uit te voeren op de ALL_TRIGGERSweergaven , DBA_TRIGGERSof USER_TRIGGERS . In de volgende schermopname ziet u een DBA_TRIGGERS query in Oracle SQL Developer.

  

  Azure Synapse biedt geen ondersteuning voor Oracle-databasetriggers. U kunt echter gelijkwaardige functionaliteit toevoegen met behulp van Data Factory, hoewel u hiervoor de processen die triggers gebruiken, moet worden geherstructureerd.

• Synoniemen: Oracle ondersteunt het definiëren van synoniemen als alternatieve namen voor verschillende databaseobjecttypen. Deze objecttypen omvatten: tabellen, weergaven, reeksen, procedures, opgeslagen functies, pakketten, gerealiseerde weergaven, Java-klasseschemaobjecten, door de gebruiker gedefinieerde objecten of een ander synoniem.

  Azure Synapse biedt momenteel geen ondersteuning voor het definiëren van synoniemen, maar als een synoniem in Oracle verwijst naar een tabel of weergave, kunt u een weergave definiëren in Azure Synapse die overeenkomt met de alternatieve naam. Als een synoniem in Oracle verwijst naar een functie of opgeslagen procedure, kunt u in Azure Synapse een andere functie of opgeslagen procedure maken, met een naam die overeenkomt met het synoniem, waarmee het doel wordt aangeroepen.

• Door de gebruiker gedefinieerde typen: Oracle ondersteunt door de gebruiker gedefinieerde objecten die een reeks afzonderlijke velden kunnen bevatten, elk met hun eigen definitie en standaardwaarden. Er kan binnen een tabeldefinitie op dezelfde manier naar deze objecten worden verwezen als ingebouwde gegevenstypen zoals NUMBER of VARCHAR. U kunt een lijst met door de gebruiker gedefinieerde typen in een Oracle-database ophalen door een query uit te voeren op de ALL_TYPESweergaven , DBA_TYPESof USER_TYPES .

  Azure Synapse biedt momenteel geen ondersteuning voor door de gebruiker gedefinieerde typen. Als de gegevens die u wilt migreren door de gebruiker gedefinieerde gegevenstypen bevatten, 'platmaken' ze in een conventionele tabeldefinitie of als het matrices met gegevens zijn, normaliseert u ze in een afzonderlijke tabel.

Toewijzing van Oracle-gegevenstypen

De meeste Oracle-gegevenstypen hebben een direct equivalent in Azure Synapse. In de volgende tabel ziet u de aanbevolen aanpak voor het toewijzen van Oracle-gegevenstypen aan Azure Synapse.

Oracle-gegevenstype	Azure Synapse gegevenstype
BFILE	Wordt niet ondersteund. Wijs toe aan VARBINARY (MAX).
BINARY_FLOAT	Wordt niet ondersteund. Toewijzen aan FLOAT.
BINARY_DOUBLE	Wordt niet ondersteund. Wijs toe aan DOUBLE.
BLOB	Niet rechtstreeks ondersteund. Vervang door VARBINARY(MAX).
CHAR	CHAR
CLOB	Niet rechtstreeks ondersteund. Vervang door VARCHAR(MAX).
DATE	DATE in Oracle kan ook tijdinformatie bevatten. Afhankelijk van gebruikstoewijzing aan DATUM of TIMESTAMP.
DECIMAL	DECIMAL
DOUBLE	PRECISION DOUBLE
FLOAT	FLOAT
INTEGER	INT
INTERVAL VAN JAAR TOT MAAND	INTERVAL-gegevenstypen worden niet ondersteund. Gebruik datumvergelijkingsfuncties, zoals DATEDIFF of DATEADD, voor datumberekeningen.
INTERVALDAG TOT SECONDE	INTERVAL-gegevenstypen worden niet ondersteund. Gebruik datumvergelijkingsfuncties, zoals DATEDIFF of DATEADD, voor datumberekeningen.
LANGE	Wordt niet ondersteund. Wijs toe aan VARCHAR(MAX).
LANG RAW	Wordt niet ondersteund. Wijs toe aan VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMMER	FLOAT
NCLOB	Niet rechtstreeks ondersteund. Vervang door NVARCHAR(MAX).
NUMERIEKE	NUMERIEKE
ORD-mediagegevenstypen	Niet ondersteund
RAW	Wordt niet ondersteund. Wijs toe aan VARBINARY.
REAL	REAL
ROWID	Wordt niet ondersteund. Wijs toe aan GUID, wat vergelijkbaar is.
Georuimtelijke SDO-gegevenstypen	Niet ondersteund
SMALLINT	SMALLINT
TIMESTAMP	DATETIME2 of de functie CURRENT_TIMESTAMP()
TIJDSTEMPEL MET LOKALE TIJDZONE	Wordt niet ondersteund. Wijs toe aan DATETIMEOFFSET.
TIJDSTEMPEL MET TIJDZONE	Niet ondersteund omdat TIME wordt opgeslagen met behulp van wandkloktijd zonder tijdzoneverschil.
URIType	Wordt niet ondersteund. Opslaan in een VARCHAR.
UROWID	Wordt niet ondersteund. Wijs toe aan GUID, wat vergelijkbaar is.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Wordt niet ondersteund. XML-gegevens opslaan in een VARCHAR.

Oracle ondersteunt ook het definiëren van door de gebruiker gedefinieerde objecten die een reeks afzonderlijke velden kunnen bevatten, elk met hun eigen definitie en standaardwaarden. Naar deze objecten kan vervolgens worden verwezen in een tabeldefinitie op dezelfde manier als ingebouwde gegevenstypen zoals NUMBER of VARCHAR. Azure Synapse biedt momenteel geen ondersteuning voor door de gebruiker gedefinieerde typen. Als de gegevens die u wilt migreren door de gebruiker gedefinieerde gegevenstypen bevatten, 'platmaken' ze in een conventionele tabeldefinitie, of als het matrices met gegevens zijn, normaliseert u ze in een afzonderlijke tabel.

Tip

Evalueer het aantal en het type niet-ondersteunde gegevenstypen tijdens de voorbereidingsfase van de migratie.

Externe leveranciers bieden hulpprogramma's en services voor het automatiseren van migratie, waaronder het toewijzen van gegevenstypen. Als een ETL-hulpprogramma van derden al in gebruik is in de Oracle-omgeving , gebruikt u dat hulpprogramma om vereiste gegevenstransformaties te implementeren.

Verschillen in SQL DML-syntaxis

Sql DML-syntaxisverschillen bestaan tussen Oracle SQL en Azure Synapse T-SQL. Deze verschillen worden uitgebreid besproken in SQL-problemen minimaliseren voor Oracle-migraties. In sommige gevallen kunt u DML-migratie automatiseren met behulp van Microsoft-hulpprogramma's zoals SSMA voor Oracle en Azure Database Migration Services, of migratieproducten en -services van derden.

Functies, opgeslagen procedures en reeksen

Wanneer u een datawarehouse migreert vanuit een volwassen omgeving zoals Oracle, moet u waarschijnlijk andere elementen dan eenvoudige tabellen en weergaven migreren. Controleer of hulpprogramma's in de Azure-omgeving de functionaliteit van functies, opgeslagen procedures en reeksen kunnen vervangen, omdat het meestal efficiënter is om ingebouwde Azure-hulpprogramma's te gebruiken dan om ze opnieuw te coderen voor Azure Synapse.

Als onderdeel van de voorbereidingsfase maakt u een inventaris van objecten die moeten worden gemigreerd, definieert u een methode voor de verwerking ervan en wijst u de juiste resources toe in uw migratieplan.

Microsoft-hulpprogramma's zoals SSMA voor Oracle en Azure Database Migration Services, of migratieproducten en -services van derden , kunnen de migratie van functies, opgeslagen procedures en reeksen automatiseren.

In de volgende secties wordt verder de migratie van functies, opgeslagen procedures en reeksen besproken.

Functions

Net als bij de meeste databaseproducten ondersteunt Oracle systeem- en door de gebruiker gedefinieerde functies binnen een SQL-implementatie. Wanneer u een verouderd databaseplatform migreert naar Azure Synapse, kunnen algemene systeemfuncties meestal zonder wijzigingen worden gemigreerd. Sommige systeemfuncties hebben mogelijk een iets andere syntaxis, maar eventuele vereiste wijzigingen kunnen worden geautomatiseerd. U kunt een lijst met functies in een Oracle-database ophalen door een query uit te voeren op de ALL_OBJECTS weergave met de juiste WHERE component. U kunt Oracle SQL Developer gebruiken om een lijst met functies op te halen, zoals wordt weergegeven in de volgende schermopname.

Voor Oracle-systeemfuncties of willekeurige door de gebruiker gedefinieerde functies die geen equivalent in Azure Synapse hebben, moet u deze functies opnieuw coderen met behulp van een doelomgevingstaal. Door de oracle-gebruiker gedefinieerde functies worden gecodeerd in PL/SQL, Java of C. Azure Synapse de Transact-SQL-taal gebruikt om door de gebruiker gedefinieerde functies te implementeren.

Opgeslagen procedures

De meeste moderne databaseproducten ondersteunen het opslaan van procedures in de database. Oracle biedt hiervoor de PL/SQL-taal. Een opgeslagen procedure bevat doorgaans zowel SQL-instructies als procedurelogica en retourneert gegevens of een status. U kunt een lijst met opgeslagen procedures in een Oracle-database ophalen door een query uit te voeren op de ALL_OBJECTS weergave met de juiste WHERE component. U kunt Oracle SQL Developer gebruiken om een lijst met opgeslagen procedures op te halen, zoals wordt weergegeven in de volgende schermopname.

Azure Synapse ondersteunt opgeslagen procedures met behulp van T-SQL, dus u moet alle gemigreerde opgeslagen procedures in die taal opnieuw coderen.

Reeksen

In Oracle is een reeks een benoemd databaseobject, gemaakt met behulp van CREATE SEQUENCE. Een reeks biedt unieke numerieke waarden via de CURRVAL methoden en NEXTVAL . U kunt de gegenereerde unieke getallen gebruiken als surrogaatsleutelwaarden voor primaire sleutels.

Azure Synapse implementeert CREATE SEQUENCEniet , maar u kunt reeksen implementeren met behulp van IDENTITEITSkolommen of SQL-code waarmee het volgende reeksnummer in een reeks wordt gegenereerd.

Metagegevens en gegevens extraheren uit een Oracle-omgeving

Gegevensdefinitietaal genereren

De ANSI SQL-standaard definieert de basissyntaxis voor DDL-opdrachten (Data Definition Language). Sommige DDL-opdrachten, zoals CREATE TABLE en CREATE VIEW, zijn gebruikelijk voor zowel Oracle als Azure Synapse, maar bieden ook implementatiespecifieke functies zoals indexeren, tabeldistributie en partitioneringsopties.

U kunt bestaande Oracle CREATE TABLE en CREATE VIEW scripts bewerken om gelijkwaardige definities in Azure Synapse te bereiken. Hiervoor moet u mogelijk aangepaste gegevenstypen gebruiken en Oracle-specifieke componenten TABLESPACEzoals verwijderen of wijzigen.

In de Oracle-omgeving geven systeemcatalogustabellen de huidige tabel- en weergavedefinitie op. In tegenstelling tot door de gebruiker onderhouden documentatie is de gegevens van de systeemcatalogus altijd volledig en synchroon met de huidige tabeldefinities. U hebt toegang tot systeemcatalogusgegevens met behulp van hulpprogramma's zoals Oracle SQL Developer. Oracle SQL Developer kan DDL-instructies genereren CREATE TABLE die u kunt bewerken om gelijkwaardige tabellen te maken in Azure Synapse.

Of u kunt SSMA voor Oracle gebruiken om tabellen te migreren van een bestaande Oracle-omgeving naar Azure Synapse. SSMA voor Oracle past de juiste toewijzingen van gegevenstypen en aanbevolen tabel- en distributietypen toe, zoals wordt weergegeven in de volgende schermopname.

U kunt ook migratie - en ETL-hulpprogramma's van derden gebruiken die systeemcatalogusgegevens verwerken om vergelijkbare resultaten te bereiken.

Gegevensextractie uit Oracle

U kunt onbewerkte tabelgegevens uit Oracle-tabellen extraheren naar platte bestanden, zoals CSV-bestanden, met behulp van standaard Oracle-hulpprogramma's zoals Oracle SQL Developer, SQL*Plus en SCLcl. Vervolgens kunt u de platte bestanden comprimeren met behulp van gzip en de gecomprimeerde bestanden uploaden naar Azure Blob Storage met behulp van AzCopy of Azure-hulpprogramma's voor gegevenstransport, zoals Azure Data Box.

Tabelgegevens zo efficiënt mogelijk extraheren, met name bij het migreren van grote feitentabellen. Voor Oracle-tabellen gebruikt u parallellisme om de extractiedoorvoer te maximaliseren. U kunt parallellisme bereiken door meerdere processen uit te voeren die afzonderlijke afzonderlijke gegevenssegmenten extraheren, of door hulpprogramma's te gebruiken waarmee parallelle extractie via partitionering kan worden geautomatiseerd.

Tip

Gebruik parallelle uitvoering voor de meest efficiënte gegevensextractie.

Als er voldoende netwerkbandbreedte beschikbaar is, kunt u gegevens uit een on-premises Oracle-systeem rechtstreeks extraheren in Azure Synapse tabellen of Azure Blob Data Storage. Hiervoor gebruikt u Data Factory-processen, Azure Database Migration Service of gegevensmigratie of ETL-producten van derden.

Geëxtraheerde gegevensbestanden moeten tekst met scheidingstekens bevatten in DE INDELING CSV, Geoptimaliseerde rijkolommen (ORC) of Parquet.

Zie Gegevensmigratie, ETL en laden voor Oracle-migraties voor meer informatie over het migreren van gegevens en ETL vanuit een Oracle-omgeving.

Prestatieaanbevelingen voor Oracle-migraties

Het doel van prestatieoptimalisatie is dezelfde of betere prestaties van het datawarehouse na de migratie naar Azure Synapse.

Overeenkomsten in concepten van de aanpak voor het afstemmen van prestaties

Veel concepten voor het afstemmen van prestaties voor Oracle-databases gelden voor Azure Synapse databases. Bijvoorbeeld:

• Gebruik gegevensdistributie om gegevens die moeten worden samengevoegd op hetzelfde verwerkingsknooppunt te plaatsen.

• Gebruik het kleinste gegevenstype voor een bepaalde kolom om opslagruimte te besparen en de verwerking van query's te versnellen.

• Zorg ervoor dat kolommen die moeten worden samengevoegd hetzelfde gegevenstype hebben om de joinverwerking te optimaliseren en de noodzaak van gegevenstransformaties te verminderen.

• Om het optimalisatieprogramma te helpen het beste uitvoeringsplan te produceren, moet u ervoor zorgen dat de statistieken up-to-date zijn.

• Bewaak de prestaties met behulp van ingebouwde databasemogelijkheden om ervoor te zorgen dat resources efficiënt worden gebruikt.

Tip

Geef prioriteit aan de bekendheid met Azure Synapse afstemmingsopties aan het begin van een migratie.

Verschillen in aanpak voor het afstemmen van prestaties

In deze sectie worden de verschillen in implementaties voor het afstemmen van prestaties op laag niveau tussen Oracle en Azure Synapse beschreven.

Opties voor gegevensdistributie

Voor prestaties is Azure Synapse ontworpen met architectuur met meerdere knooppunten en maakt gebruik van parallelle verwerking. Als u de tabelprestaties in Azure Synapse wilt optimaliseren, kunt u een optie voor gegevensdistributie definiëren in CREATE TABLE -instructies met behulp van de DISTRIBUTION -instructie. U kunt bijvoorbeeld een met hash gedistribueerde tabel opgeven, waarmee tabelrijen over rekenknooppunten worden verdeeld met behulp van een deterministische hashfunctie. Veel Oracle-implementaties, met name oudere on-premises systemen, bieden geen ondersteuning voor deze functie.

In tegenstelling tot Oracle ondersteunt Azure Synapse lokale joins tussen een kleine tabel en een grote tabel via kleine tabelreplicatie. Denk bijvoorbeeld aan een kleine dimensietabel en een grote feitentabel binnen een star schemamodel. Azure Synapse kunt de kleinere dimensietabel repliceren op alle knooppunten om ervoor te zorgen dat de waarde van elke joinsleutel voor de grote tabel een overeenkomende, lokaal beschikbare dimensierij heeft. De overhead van replicatie van dimensietabellen is relatief laag voor een kleine dimensietabel. Voor grote dimensietabellen is een hash-distributiebenadering beter geschikt. Zie Ontwerprichtlijnen voor het gebruik van gerepliceerde tabellen en Richtlijnen voor het ontwerpen van gedistribueerde tabellen voor meer informatie over opties voor gegevensdistributie.

Tip

Hash-distributie verbetert de queryprestaties op grote feitentabellen. Round robin-distributie is handig voor het verbeteren van de laadsnelheid.

Hash-distributie kan worden toegepast op meerdere kolommen voor een gelijkmatigere verdeling van de basistabel. Met distributie met meerdere kolommen kunt u maximaal acht kolommen kiezen voor distributie. Dit vermindert niet alleen het scheeftrekken van gegevens in de loop van de tijd, maar verbetert ook de queryprestaties.

Notitie

Distributie met meerdere kolommen is momenteel in preview voor Azure Synapse Analytics. U kunt distributie met meerdere kolommen gebruiken met CREATE MATERIALIZED VIEW, CREATE TABLE en CREATE TABLE AS SELECT.

Distributieadviseur

In Azure Synapse SQL kan de manier waarop elke tabel wordt gedistribueerd, worden aangepast. De tabeldistributiestrategie is aanzienlijk van invloed op de queryprestaties.

De distributieadviseur is een nieuwe functie in Synapse SQL die query's analyseert en de beste distributiestrategieën voor tabellen aanbeveelt om de queryprestaties te verbeteren. Query's die door de adviseur moeten worden overwogen, kunnen door u worden verstrekt of worden opgehaald uit uw historische query's die beschikbaar zijn in DMV.

Ga naar Distributieadviseur in Azure Synapse SQL voor meer informatie en voorbeelden over het gebruik van de distributieadviseur.

Gegevensindexering

Azure Synapse ondersteunt verschillende door de gebruiker gedefinieerde indexeringsopties die een andere bewerking en gebruik hebben dan door het systeem beheerde zonetoewijzingen in Oracle. Zie Indexen op toegewezen SQL-pooltabellen voor meer informatie over de verschillende indexeringsopties in Azure Synapse.

Indexdefinities binnen een Oracle-bronomgeving bieden een nuttige indicatie van het gegevensgebruik en de kandidaatkolommen voor indexering in de Azure Synapse-omgeving. Normaal gesproken hoeft u niet elke index te migreren vanuit een verouderde Oracle-omgeving, omdat Azure Synapse niet te veel afhankelijk is van indexen en de volgende functies implementeert om uitstekende prestaties te bereiken:

• Parallelle queryverwerking.

• In-memory gegevens en resultatenset caching.

• Gegevensdistributie, zoals replicatie van kleine dimensietabellen, om I/O te verminderen.

Gegevenspartitionering

In een datawarehouse voor ondernemingen kunnen feitentabellen miljarden rijen bevatten. Partitionering optimaliseert het onderhoud en het uitvoeren van query's op deze tabellen door ze op te splitsen in afzonderlijke delen om de hoeveelheid verwerkte gegevens te verminderen. In Azure Synapse definieert de CREATE TABLE instructie de partitioneringsspecificatie voor een tabel.

U kunt slechts één veld per tabel gebruiken voor partitionering. Dit veld is vaak een datumveld omdat veel query's worden gefilterd op datum of een datumbereik. Het is mogelijk om de partitionering van een tabel na de eerste belasting te wijzigen door de CREATE TABLE AS CTAS-instructie (CTAS) te gebruiken om de tabel opnieuw te maken met een nieuwe distributie. Zie Partitioning tables in dedicated SQL pool (Tabellen partitioneren in een toegewezen SQL-pool) voor een gedetailleerde bespreking van partitionering in Azure Synapse.

PolyBase of COPY INTO voor het laden van gegevens

PolyBase ondersteunt het efficiënt laden van grote hoeveelheden gegevens in een datawarehouse door gebruik te maken van stromen voor parallel laden. Zie PolyBase-strategie voor het laden van gegevens voor meer informatie.

COPY INTO biedt ook ondersteuning voor gegevensopname met hoge doorvoer, en:

• Gegevens ophalen uit alle bestanden in een map en submappen.
• Gegevens ophalen vanaf meerdere locaties in hetzelfde opslagaccount. U kunt meerdere locaties opgeven met behulp van door komma's gescheiden paden.
• Azure Data Lake Storage (ADLS) en Azure Blob Storage.
• CSV-, PARQUET- en ORC-bestandsindelingen.

Tip

De aanbevolen methode voor het laden van gegevens is om samen met de PARQUET-bestandsindeling te gebruiken COPY INTO .

Werklastbeheer

Het uitvoeren van gemengde workloads kan problemen met resources opleveren op drukke systemen. Een succesvol workloadbeheerschema beheert resources effectief, zorgt voor een zeer efficiënt resourcegebruik en maximaliseert het rendement op investeringen( ROI). Workloadclassificatie, workloadbelang en isolatie van werkbelastingen geven meer controle over hoe de workload gebruikmaakt van systeembronnen.

In de handleiding voor workloadbeheer worden de technieken beschreven voor het analyseren van de workload, het beheren en bewaken van het belang van de workload, en de stappen voor het converteren van een resourceklasse naar een workloadgroep. Gebruik de Azure Portal- en T-SQL-query's op DMV's om de workload te controleren om ervoor te zorgen dat de toepasselijke resources efficiënt worden gebruikt.

Volgende stappen

Zie het volgende artikel in deze reeks voor meer informatie over ETL en belasting voor Oracle-migraties: Gegevensmigratie, ETL en laden voor Oracle-migraties.