Share via

Gegevensmigratie, ETL en belasting voor Oracle-migraties

  • Artikel

Dit artikel is deel twee van een zevendelige reeks die richtlijnen biedt voor het migreren van Oracle naar Azure Synapse Analytics. De focus van dit artikel is aanbevolen procedures voor ETL en belastingmigratie.

Overwegingen voor gegevensmigratie

Er zijn veel factoren waarmee u rekening moet houden bij het migreren van gegevens, ETL en het laden van een verouderd Oracle-datawarehouse en datamarts naar Azure Synapse.

Initiële beslissingen over gegevensmigratie vanuit Oracle

Wanneer u een migratie plant vanuit een bestaande Oracle-omgeving, moet u rekening houden met de volgende gegevensgerelateerde vragen:

  • Moeten ongebruikte tabelstructuren worden gemigreerd?

  • Wat is de beste migratiebenadering om risico's en impact voor gebruikers te minimaliseren?

  • Wanneer u datamarts migreert: fysiek blijven of virtueel gaan?

In de volgende secties worden deze punten besproken binnen de context van een migratie vanuit Oracle.

Ongebruikte tabellen migreren?

Het is logisch om alleen tabellen te migreren die in gebruik zijn. Tabellen die niet actief zijn, kunnen worden gearchiveerd in plaats van gemigreerd, zodat de gegevens in de toekomst beschikbaar zijn. Het is raadzaam om systeemmetagegevens en logboekbestanden te gebruiken in plaats van documentatie om te bepalen welke tabellen worden gebruikt, omdat documentatie verouderd kan zijn.

Oracle-systeemcatalogustabellen en -logboeken bevatten informatie die kan worden gebruikt om te bepalen wanneer een bepaalde tabel voor het laatst is geopend. Op zijn beurt kan worden gebruikt om te bepalen of een tabel een kandidaat is voor migratie.

Als u een licentie voor het Oracle Diagnostic Pack hebt, hebt u toegang tot actieve sessiegeschiedenis, die u kunt gebruiken om te bepalen wanneer een tabel voor het laatst is geopend.

Tip

In verouderde systemen is het niet ongebruikelijk dat tabellen na verloop van tijd redundant worden. Deze hoeven in de meeste gevallen niet te worden gemigreerd.

Hier volgt een voorbeeldquery die zoekt naar het gebruik van een specifieke tabel binnen een bepaald tijdvenster:

SELECT du.username,
    s.sql_text,
    MAX(ash.sample_time) AS last_access ,
    sp.object_owner ,
    sp.object_name ,
    sp.object_alias as aliased_as ,
    sp.object_type ,
    COUNT(*) AS access_count 
FROM v$active_session_history ash         
    JOIN v$sql s ON ash.force_matching_signature = s.force_matching_signature
    LEFT JOIN v$sql_plan sp ON s.sql_id = sp.sql_id
    JOIN DBA_USERS du ON ash.user_id = du.USER_ID
WHERE ash.session_type = 'FOREGROUND'
    AND ash.SQL_ID IS NOT NULL
    AND sp.object_name IS NOT NULL
    AND ash.user_id <> 0
GROUP BY du.username,
    s.sql_text,
    sp.object_owner,
    sp.object_name,
    sp.object_alias,
    sp.object_type 
ORDER BY 3 DESC;

Het kan even duren voordat deze query wordt uitgevoerd als u meerdere query's hebt uitgevoerd.

Wat is de beste migratiebenadering om risico's en impact op gebruikers te minimaliseren?

Deze vraag wordt vaak gesteld omdat bedrijven mogelijk de impact van wijzigingen in het datawarehouse-datamodel willen verlagen om de flexibiliteit te verbeteren. Bedrijven zien vaak de mogelijkheid om hun gegevens verder te moderniseren of te transformeren tijdens een ETL-migratie. Deze benadering draagt een hoger risico omdat het meerdere factoren tegelijk wijzigt, waardoor het moeilijk is om de resultaten van het oude systeem te vergelijken versus het nieuwe. Het hier aanbrengen van wijzigingen in gegevensmodellen kan ook invloed hebben op upstream- of downstream ETL-taken naar andere systemen. Vanwege dit risico is het beter om na de migratie van het datawarehouse opnieuw te ontwerpen op deze schaal.

Zelfs als een gegevensmodel opzettelijk wordt gewijzigd als onderdeel van de algehele migratie, is het een goede gewoonte om het bestaande model as-is te migreren naar Azure Synapse, in plaats van een nieuwe engineering uit te voeren op het nieuwe platform. Deze aanpak minimaliseert het effect op bestaande productiesystemen, terwijl u profiteert van de prestaties en elastische schaalbaarheid van het Azure-platform voor eenmalige her engineeringtaken.

Tip

Migreer het bestaande model in eerste instantie, zelfs als er in de toekomst een wijziging in het gegevensmodel is gepland.

Migratie van datamart: fysiek blijven of virtueel gaan?

In verouderde Oracle-datawarehouse-omgevingen is het gebruikelijk om veel datamarts te maken die zijn gestructureerd om goede prestaties te bieden voor ad-hoc selfservicequery's en rapporten voor een bepaalde afdeling of bedrijfsfunctie binnen een organisatie. Een datamart bestaat doorgaans uit een subset van het datawarehouse met geaggregeerde versies van de gegevens in een formulier waarmee gebruikers eenvoudig query's kunnen uitvoeren op die gegevens met snelle reactietijden. Gebruikers kunnen gebruik maken van gebruiksvriendelijke queryhulpprogramma's zoals Microsoft Power BI, die ondersteuning biedt voor zakelijke gebruikersinteracties met datamarts. De vorm van de gegevens in een datamart is over het algemeen een dimensional gegevensmodel. Eén gebruik van datamarts is het beschikbaar maken van de gegevens in een bruikbare vorm, zelfs als het onderliggende datawarehouse-gegevensmodel iets anders is, zoals een gegevenskluis.

U kunt afzonderlijke datamarts gebruiken voor afzonderlijke bedrijfseenheden binnen een organisatie om robuuste systemen voor gegevensbeveiliging te implementeren. Beperk de toegang tot specifieke datamarts die relevant zijn voor gebruikers en verwijder, verdoof of anoniem maken van gevoelige gegevens.

Als deze datamarts worden geïmplementeerd als fysieke tabellen, hebben ze extra opslagbronnen en -verwerking nodig om ze regelmatig te bouwen en te vernieuwen. De gegevens in de mart zijn ook alleen zo up-to-date als de laatste vernieuwingsbewerking, en kunnen dus ongeschikt zijn voor zeer vluchtige gegevensdashboards.

Tip

Het virtualiseren van datamarts kan besparen op opslag- en verwerkingsbronnen.

Dankzij de komst van goedkopere schaalbare MPP-architecturen, zoals Azure Synapse, en hun inherente prestatiekenmerken, kunt u datamart-functionaliteit bieden zonder de mart te instantiëren als een set fysieke tabellen. Een methode is om de datamarts effectief te virtualiseren via SQL-weergaven naar het hoofddatawarehouse. Een andere manier is om de datamarts te virtualiseren via een virtualisatielaag met behulp van functies zoals weergaven in Azure of virtualisatieproducten van derden . Deze aanpak vereenvoudigt of elimineert de noodzaak van extra opslag- en aggregatieverwerking en vermindert het totale aantal databaseobjecten dat moet worden gemigreerd.

Er is nog een potentieel voordeel van deze aanpak. Door de aggregatie- en joinlogica binnen een virtualisatielaag te implementeren en externe rapportagehulpprogramma's te presenteren via een gevirtualiseerde weergave, wordt de verwerking die nodig is om deze weergaven te maken, naar het datawarehouse gepusht. Het datawarehouse is over het algemeen de beste plek om joins, aggregaties en andere gerelateerde bewerkingen op grote gegevensvolumes uit te voeren.

De belangrijkste stuurprogramma's voor het implementeren van een virtuele datamart via een fysieke datamart zijn:

  • Meer flexibiliteit: een virtuele datamart is eenvoudiger te wijzigen dan fysieke tabellen en de bijbehorende ETL-processen.

  • Lagere totale eigendomskosten: voor een gevirtualiseerde implementatie zijn minder gegevensarchieven en kopieën van gegevens vereist.

  • Het elimineren van ETL-taken voor het migreren en vereenvoudigen van datawarehouse-architectuur in een gevirtualiseerde omgeving.

  • Prestaties: hoewel fysieke datamarts historisch beter hebben uitgevoerd, implementeren virtualisatieproducten nu intelligente cachingtechnieken om dit verschil te beperken.

Tip

De prestaties en schaalbaarheid van Azure Synapse maken virtualisatie mogelijk zonder dat dit ten koste gaat van de prestaties.

Gegevensmigratie van Oracle

Inzicht krijgen in uw gegevens

Als onderdeel van de migratieplanning moet u in detail begrijpen hoeveel gegevens moeten worden gemigreerd, omdat dit van invloed kan zijn op beslissingen over de migratiebenadering. Gebruik systeemmetagegevens om de fysieke ruimte te bepalen die wordt gebruikt door de onbewerkte gegevens in de tabellen die moeten worden gemigreerd. In deze context betekent onbewerkte gegevens de hoeveelheid ruimte die wordt gebruikt door de gegevensrijen in een tabel, met uitzondering van overhead, zoals indexen en compressie. De grootste feitentabellen omvatten doorgaans meer dan 95% van de gegevens.

Met deze query krijgt u de totale databasegrootte in Oracle:

SELECT
  ( SELECT SUM(bytes)/1024/1024/1024 data_size 
    FROM sys.dba_data_files ) +
  ( SELECT NVL(sum(bytes),0)/1024/1024/1024 temp_size 
    FROM sys.dba_temp_files ) +
  ( SELECT SUM(bytes)/1024/1024/1024 redo_size 
    FROM sys.v_$log ) +
  ( SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 controlfile_size 
    FROM v$controlfile ) "Size in GB"
FROM dual

De databasegrootte is gelijk aan de grootte van (data files + temp files + online/offline redo log files + control files). De totale grootte van de database omvat gebruikte ruimte en vrije ruimte.

De volgende voorbeeldquery geeft een uitsplitsing van de schijfruimte die wordt gebruikt door tabelgegevens en indexen:

SELECT
   owner, "Type", table_name "Name", TRUNC(sum(bytes)/1024/1024) Meg
FROM
  ( SELECT segment_name table_name, owner, bytes, 'Table' as "Type" 
    FROM dba_segments 
    WHERE segment_type in  ('TABLE','TABLE PARTITION','TABLE SUBPARTITION' )
UNION ALL
    SELECT i.table_name, i.owner, s.bytes, 'Index' as "Type"
    FROM dba_indexes i, dba_segments s
    WHERE s.segment_name = i.index_name
    AND   s.owner = i.owner
    AND   s.segment_type in ('INDEX','INDEX PARTITION','INDEX SUBPARTITION')
UNION ALL
    SELECT l.table_name, l.owner, s.bytes, 'LOB' as "Type"
    FROM dba_lobs l, dba_segments s
    WHERE s.segment_name = l.segment_name
    AND   s.owner = l.owner
    AND   s.segment_type IN ('LOBSEGMENT','LOB PARTITION','LOB SUBPARTITION')
UNION ALL
    SELECT l.table_name, l.owner, s.bytes, 'LOB Index' as "Type"
    FROM dba_lobs l, dba_segments s
    WHERE s.segment_name = l.index_name
    AND   s.owner = l.owner
    AND   s.segment_type = 'LOBINDEX')
    WHERE owner in UPPER('&owner')
GROUP BY table_name, owner, "Type"
HAVING SUM(bytes)/1024/1024 > 10  /* Ignore really small tables */
ORDER BY SUM(bytes) desc;

Daarnaast biedt het Microsoft-databasemigratieteam veel resources, waaronder de Oracle Inventory Script Artifacts. Het hulpprogramma Oracle Inventory Script Artifacts bevat een PL/SQL-query die toegang heeft tot Oracle-systeemtabellen en biedt een aantal objecten op schematype, objecttype en status. Het hulpprogramma biedt ook een ruwe schatting van onbewerkte gegevens in elk schema en de grootte van tabellen in elk schema, met resultaten die zijn opgeslagen in een CSV-indeling. Een inbegrepen rekenmachine-spreadsheet neemt het CSV als invoer en biedt de groottegegevens.

Voor elke tabel kunt u een nauwkeurige schatting maken van het volume aan gegevens dat moet worden gemigreerd door een representatieve steekproef van de gegevens, zoals één miljoen rijen, te extraheren naar een niet-gecomprimeerd, plat ASCII-gegevensbestand met scheidingstekens. Gebruik vervolgens de grootte van dat bestand om een gemiddelde onbewerkte gegevensgrootte per rij op te halen. Ten slotte vermenigvuldigt u die gemiddelde grootte met het totale aantal rijen in de volledige tabel om een onbewerkte gegevensgrootte voor de tabel te geven. Gebruik die onbewerkte gegevensgrootte in uw planning.

SQL-query's gebruiken om gegevenstypen te vinden

Door een query uit te voeren op de weergave van de oracle statische gegevenswoordenlijst DBA_TAB_COLUMNS , kunt u bepalen welke gegevenstypen in een schema worden gebruikt en of een van deze gegevenstypen moet worden gewijzigd. Gebruik SQL-query's om de kolommen in een Oracle-schema te vinden met gegevenstypen die niet rechtstreeks worden toegewezen aan gegevenstypen in Azure Synapse. Op dezelfde manier kunt u query's gebruiken om het aantal exemplaren van elk Oracle-gegevenstype te tellen dat niet rechtstreeks wordt toegewezen aan Azure Synapse. Door de resultaten van deze query's te gebruiken in combinatie met de vergelijkingstabel voor gegevenstypen, kunt u bepalen welke gegevenstypen moeten worden gewijzigd in een Azure Synapse-omgeving.

Als u de kolommen wilt zoeken met gegevenstypen die niet zijn toegewezen aan gegevenstypen in Azure Synapse, voert u de volgende query uit nadat u de relevante eigenaar van uw schema hebt vervangen <owner_name> :

SELECT owner, table_name, column_name, data_type
FROM dba_tab_columns
WHERE owner in ('<owner_name>')
AND data_type NOT IN 
    ('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE') 
ORDER BY 1,2,3;

Gebruik de volgende query om het aantal niet-toe te wijzen gegevenstypen te tellen:

SELECT data_type, count(*) 
FROM dba_tab_columns 
WHERE data_type NOT IN 
    ('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE') 
GROUP BY data_type 
ORDER BY data_type;

Microsoft biedt SQL Server Migration Assistant (SSMA) voor Oracle om de migratie van datawarehouses uit verouderde Oracle-omgevingen te automatiseren, inclusief de toewijzing van gegevenstypen. U kunt Ook Azure Database Migration Services gebruiken om een migratie te plannen en uit te voeren vanuit omgevingen zoals Oracle. Externe leveranciers bieden ook hulpprogramma's en services voor het automatiseren van migratie. Als een ETL-hulpprogramma van derden al in gebruik is in de Oracle-omgeving , kunt u dat hulpprogramma gebruiken om vereiste gegevenstransformaties te implementeren. In de volgende sectie wordt de migratie van bestaande ETL-processen verkend.

Overwegingen voor ETL-migratie

Initiële beslissingen over Oracle ETL-migratie

Voor ETL/ELT-verwerking gebruiken verouderde Oracle-datawarehouses vaak aangepaste scripts, ETL-hulpprogramma's van derden of een combinatie van benaderingen die in de loop van de tijd zijn ontwikkeld. Wanneer u een migratie naar Azure Synapse plant, bepaalt u de beste manier om de vereiste ETL/ELT-verwerking in de nieuwe omgeving te implementeren en tegelijkertijd kosten en risico's te minimaliseren.

Tip

Plan de benadering van ETL-migratie van tevoren en maak waar nodig gebruik van Azure-faciliteiten.

In het volgende stroomdiagram wordt één benadering samengevat:

Stroomdiagram van migratieopties en aanbevelingen.

Zoals wordt weergegeven in het stroomdiagram, is de eerste stap altijd het bouwen van een inventaris van ETL-/ELT-processen die moeten worden gemigreerd. Met de standaard ingebouwde Azure-functies hoeven sommige bestaande processen mogelijk niet te worden verplaatst. Voor planningsdoeleinden is het belangrijk dat u de schaal van de migratie begrijpt. Bekijk vervolgens de vragen in de beslissingsstructuur van het stroomdiagram:

  1. Wilt u overstappen op systeemeigen Azure? Uw antwoord is afhankelijk van of u migreert naar een volledig systeemeigen Azure-omgeving. Zo ja, dan raden we u aan om de ETL-verwerking opnieuw te ontwerpen met behulp van pijplijnen en activiteiten in Azure Data Factory of Azure Synapse-pijplijnen.

  2. Gebruikt u een ETL-hulpprogramma van derden? Als u niet overstapt op een volledig systeemeigen Azure-omgeving, controleert u of een bestaand ETL-hulpprogramma van derden al in gebruik is. In de Oracle-omgeving kunt u merken dat sommige of alle ETL-verwerkingen worden uitgevoerd door aangepaste scripts met behulp van Oracle-specifieke hulpprogramma's zoals Oracle SQL Developer, Oracle SQL*Loader of Oracle Data Pump. De aanpak in dit geval is om azure Data Factory opnieuw te ontwikkelen.

  3. Biedt de derde partij ondersteuning voor toegewezen SQL-pools in Azure Synapse? Overweeg of er een grote investering is in vaardigheden in het ETL-hulpprogramma van derden, of of als bestaande werkstromen en planningen dat hulpprogramma gebruiken. Zo ja, bepaal dan of het hulpprogramma Azure Synapse efficiënt kan ondersteunen als doelomgeving. In het ideale voorbeeld bevat het hulpprogramma systeemeigen connectors die azure-faciliteiten, zoals PolyBase of COPY INTO , kunnen gebruiken voor het efficiënt laden van gegevens. Maar zelfs zonder systeemeigen connectors is het over het algemeen een manier om externe processen aan te roepen, zoals PolyBase of COPY INTO, en toepasselijke parameters door te geven. Gebruik in dit geval bestaande vaardigheden en werkstromen, met Azure Synapse als de nieuwe doelomgeving.

    Als u Oracle Data Integrator (ODI) gebruikt voor ELT-verwerking, hebt u ODI Knowledge Modules voor Azure Synapse nodig. Als deze modules niet beschikbaar zijn in uw organisatie, maar u ODI hebt, kunt u ODI gebruiken om platte bestanden te genereren. Deze platte bestanden kunnen vervolgens worden verplaatst naar Azure en worden opgenomen in Azure Data Lake Storage voor het laden in Azure Synapse.

  4. ETL-hulpprogramma's uitvoeren in Azure? Als u besluit een bestaand ETL-hulpprogramma van derden te behouden, kunt u dat hulpprogramma uitvoeren in de Azure-omgeving (in plaats van op een bestaande on-premises ETL-server) en Data Factory de algehele indeling van de bestaande werkstromen laten afhandelen. Bepaal dus of het bestaande hulpprogramma als zodanig wordt uitgevoerd of verplaats het naar de Azure-omgeving om kosten, prestaties en schaalbaarheidsvoordelen te bereiken.

Tip

Overweeg om ETL-hulpprogramma's in Azure uit te voeren om gebruik te maken van prestaties, schaalbaarheid en kostenvoordelen.

Bestaande Oracle-specifieke scripts opnieuw ontwerpen

Als sommige of alle bestaande Oracle Warehouse ETL/ELT-verwerking wordt verwerkt door aangepaste scripts die gebruikmaken van Oracle-specifieke hulpprogramma's, zoals Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader of Oracle Data Pump, moet u deze scripts opnieuw coderen voor de Azure Synapse-omgeving. Als ETL-processen zijn geïmplementeerd met behulp van opgeslagen procedures in Oracle, moet u deze processen opnieuw coderen.

Sommige elementen van het ETL-proces zijn eenvoudig te migreren, bijvoorbeeld door eenvoudige bulkgegevens te laden in een faseringstabel vanuit een extern bestand. Het kan zelfs mogelijk zijn om deze onderdelen van het proces te automatiseren, bijvoorbeeld met behulp van Azure Synapse COPY INTO of PolyBase in plaats van SQL*Loader. Andere onderdelen van het proces die willekeurige complexe SQL- en/of opgeslagen procedures bevatten, nemen meer tijd in beslag om opnieuw te worden ontworpen.

Tip

De inventaris van ETL-taken die moeten worden gemigreerd, moet scripts en opgeslagen procedures bevatten.

Een manier om Oracle SQL te testen op compatibiliteit met Azure Synapse, is door een aantal representatieve SQL-instructies vast te leggen van een join van Oracle v$active_session_history en v$sql deze query's te verkrijgen sql_text, en deze query's EXPLAINvervolgens te voorzien van een voorvoegsel. Als we ervan uitgaan dat een gemigreerd gegevensmodel als een like-for-like in Azure Synapse wordt gebruikt, voert u deze EXPLAIN instructies uit in Azure Synapse. Elke incompatibele SQL geeft een fout. U kunt deze informatie gebruiken om de schaal van de recoding-taak te bepalen.

Tip

Gebruik EXPLAIN deze functie om incompatibiliteit van SQL te vinden.

In het ergste geval kan handmatige recoding nodig zijn. Er zijn echter producten en services beschikbaar van Microsoft-partners om te helpen bij het opnieuw ontwikkelen van Oracle-specifieke code.

Tip

Partners bieden producten en vaardigheden om te helpen bij het opnieuw ontwikkelen van Oracle-specifieke code.

Bestaande ETL-hulpprogramma's van derden gebruiken

In veel gevallen wordt het bestaande verouderde datawarehouse-systeem al ingevuld en onderhouden door een ETL-product van derden. Zie Azure Synapse Analytics-gegevensintegratiepartners voor een lijst met huidige Microsoft-gegevensintegratiepartners voor Azure Synapse.

De Oracle-community maakt vaak gebruik van verschillende populaire ETL-producten. In de volgende alinea's worden de populairste ETL-hulpprogramma's voor Oracle-magazijnen besproken. U kunt al deze producten uitvoeren binnen een VIRTUELE machine in Azure en deze gebruiken om Azure-databases en -bestanden te lezen en te schrijven.

Tip

Maak gebruik van investeringen in bestaande hulpprogramma's van derden om kosten en risico's te verlagen.

Gegevens laden vanuit Oracle

Beschikbare opties bij het laden van gegevens uit Oracle

Wanneer u zich voorbereidt op het migreren van gegevens uit een Oracle-datawarehouse, moet u bepalen hoe gegevens fysiek worden verplaatst van de bestaande on-premises omgeving naar Azure Synapse in de cloud en welke hulpprogramma's worden gebruikt om de overdracht en belasting uit te voeren. Houd rekening met de volgende vragen, die in de volgende secties worden besproken.

  • Extraheert u de gegevens naar bestanden of verplaatst u deze rechtstreeks via een netwerkverbinding?

  • Organiseert u het proces vanuit het bronsysteem of vanuit de Azure-doelomgeving?

  • Welke hulpprogramma's gebruikt u om het migratieproces te automatiseren en te beheren?

Gegevens overdragen via bestanden of netwerkverbinding?

Zodra de databasetabellen die moeten worden gemigreerd, zijn gemaakt in Azure Synapse, kunt u de gegevens die deze tabellen uit het verouderde Oracle-systeem vullen, verplaatsen naar de nieuwe omgeving. Er zijn twee basismethoden:

  • Bestand extraheren: extraheer de gegevens uit de Oracle-tabellen naar platte bestanden, normaal gesproken in CSV-indeling. U kunt tabelgegevens op verschillende manieren extraheren:

    • Gebruik standaard Oracle-hulpprogramma's zoals SQL*Plus, SQL Developer en SQLcl.
    • Gebruik Oracle Data Integrator (ODI) om platte bestanden te genereren.
    • Gebruik de Oracle-connector in Data Factory om Oracle-tabellen parallel te verwijderen om het laden van gegevens per partitie mogelijk te maken.
    • Gebruik een ETL-hulpprogramma van derden.

    Zie de bijlage van het artikel voor voorbeelden van het extraheren van Oracle-tabelgegevens.

    Voor deze aanpak is ruimte nodig om de geëxtraheerde gegevensbestanden te landen. De ruimte kan lokaal zijn voor de Oracle-brondatabase als er voldoende opslagruimte beschikbaar is of extern is in Azure Blob Storage. De beste prestaties worden bereikt wanneer een bestand lokaal wordt geschreven, omdat hierdoor netwerkoverhead wordt vermeden.

    Als u de vereisten voor opslag en netwerkoverdracht wilt minimaliseren, comprimeert u de geëxtraheerde gegevensbestanden met behulp van een hulpprogramma zoals gzip.

    Verplaats de platte bestanden na extractie naar Azure Blob Storage. Microsoft biedt verschillende opties voor het verplaatsen van grote hoeveelheden gegevens, waaronder:

    • AzCopy voor het verplaatsen van bestanden in het netwerk naar Azure Storage.
    • Azure ExpressRoute voor het verplaatsen van bulkgegevens via een privénetwerkverbinding.
    • Azure Data Box voor het verplaatsen van bestanden naar een fysiek opslagapparaat dat u verzendt naar een Azure-datacenter voor het laden.

    Zie Gegevens overdragen naar en van Azure voor meer informatie.

  • Direct extraheren en laden via het netwerk: de Azure-doelomgeving verzendt een aanvraag voor gegevensextracten, normaal gesproken via een SQL-opdracht, naar het verouderde Oracle-systeem om de gegevens te extraheren. De resultaten worden via het netwerk verzonden en rechtstreeks in Azure Synapse geladen, zonder dat de gegevens in tussenliggende bestanden hoeven te worden geplaatst. De beperkende factor in dit scenario is normaal gesproken de bandbreedte van de netwerkverbinding tussen de Oracle-database en de Azure-omgeving. Voor uitzonderlijk grote gegevensvolumes is deze benadering mogelijk niet praktisch.

Tip

Meer informatie over de gegevensvolumes die moeten worden gemigreerd en de beschikbare netwerkbandbreedte, omdat deze factoren van invloed zijn op de beslissing van de migratiebenadering.

Er is ook een hybride benadering die beide methoden gebruikt. U kunt bijvoorbeeld de directe benadering voor netwerkextracten gebruiken voor kleinere dimensietabellen en voorbeelden van de grotere feitentabellen om snel een testomgeving in Azure Synapse te bieden. Voor historische feitentabellen met grote volumes kunt u de methode voor het extraheren en overdragen van bestanden gebruiken met behulp van Azure Data Box.

Organiseren vanuit Oracle of Azure?

De aanbevolen benadering bij het overstappen naar Azure Synapse is het organiseren van gegevensextractie en het laden vanuit de Azure-omgeving met behulp van SSMA of Data Factory. Gebruik de bijbehorende hulpprogramma's, zoals PolyBase of COPY INTO, voor het efficiëntste laden van gegevens. Deze aanpak profiteert van ingebouwde Azure-mogelijkheden en vermindert de moeite om herbruikbare pijplijnen voor het laden van gegevens te bouwen. U kunt pijplijnen voor het laden van metagegevens gebruiken om het migratieproces te automatiseren.

De aanbevolen benadering minimaliseert ook de prestaties van de bestaande Oracle-omgeving tijdens het laden van gegevens, omdat het beheer- en laadproces wordt uitgevoerd in Azure.

Bestaande hulpprogramma's voor gegevensmigratie

Gegevenstransformatie en -verplaatsing is de basisfunctie van alle ETL-producten. Als een hulpprogramma voor gegevensmigratie al in gebruik is in de bestaande Oracle-omgeving en Azure Synapse ondersteunt als doelomgeving, kunt u overwegen dat hulpprogramma te gebruiken om de gegevensmigratie te vereenvoudigen.

Zelfs als een bestaand ETL-hulpprogramma niet aanwezig is, bieden Azure Synapse Analytics-gegevensintegratiepartners ETL-hulpprogramma's om de taak van gegevensmigratie te vereenvoudigen.

Als u van plan bent om een ETL-hulpprogramma te gebruiken, kunt u overwegen dat hulpprogramma in de Azure-omgeving uit te voeren om te profiteren van de prestaties, schaalbaarheid en kosten van de Azure-cloud. Deze benadering maakt ook resources vrij in het Oracle-datacenter.

Samenvatting

Samenvattend zijn onze aanbevelingen voor het migreren van gegevens en bijbehorende ETL-processen van Oracle naar Azure Synapse:

  • Plan vooruit om een geslaagde migratieoefening te garanderen.

  • Bouw een gedetailleerde inventarisatie van gegevens en processen die zo snel mogelijk moeten worden gemigreerd.

  • Gebruik systeemmetagegevens en logboekbestanden om een nauwkeurig inzicht te krijgen in gegevens en het gebruik van processen. Vertrouw niet op documentatie omdat deze mogelijk verouderd is.

  • Informatie over de gegevensvolumes die moeten worden gemigreerd en de netwerkbandbreedte tussen het on-premises datacenter en Azure-cloudomgevingen.

  • Overweeg om een Oracle-exemplaar in een Azure-VM te gebruiken als een stap voor het offloaden van migratie vanuit de verouderde Oracle-omgeving.

  • Gebruik standaard ingebouwde Azure-functies om de migratieworkload te minimaliseren.

  • Identificeer en begrijp de meest efficiënte hulpprogramma's voor gegevensextractie en -belasting in zowel Oracle- als Azure-omgevingen. Gebruik de juiste hulpprogramma's in elke fase van het proces.

  • Gebruik Azure-faciliteiten, zoals Data Factory, om het migratieproces te organiseren en automatiseren, terwijl de impact op het Oracle-systeem wordt geminimaliseerd.

Bijlage: Voorbeelden van technieken voor het extraheren van Oracle-gegevens

U kunt verschillende technieken gebruiken om Oracle-gegevens te extraheren bij het migreren van Oracle naar Azure Synapse. In de volgende secties ziet u hoe u Oracle-gegevens extraheert met Oracle SQL Developer en de Oracle-connector in Data Factory.

Oracle SQL Developer gebruiken voor gegevensextractie

U kunt de Oracle SQL Developer-gebruikersinterface gebruiken om tabelgegevens te exporteren naar veel indelingen, waaronder CSV, zoals wordt weergegeven in de volgende schermopname:

Schermopname van de gebruikersinterface van de SQL Developer-exportwizard.

Andere exportopties zijn JSON en XML. U kunt de gebruikersinterface gebruiken om een set tabelnamen toe te voegen aan een 'winkelwagen', en vervolgens de export toe te passen op de hele set in de winkelwagen:

Schermopname van de gebruikersinterface van de SQL Developer-winkelwagen.

U kunt oracle SQL Developer-opdrachtregel (SQLcl) ook gebruiken om Oracle-gegevens te exporteren. Deze optie ondersteunt automatisering met behulp van een shellscript.

Voor relatief kleine tabellen kan deze techniek handig zijn als u problemen ondervindt bij het extraheren van gegevens via een directe verbinding.

De Oracle-connector in Azure Data Factory gebruiken voor parallelle kopie

U kunt de Oracle-connector in Data Factory gebruiken om grote Oracle-tabellen parallel te laden. De Oracle-connector biedt ingebouwde gegevenspartitionering om gegevens parallel van Oracle te kopiëren. U vindt de opties voor gegevenspartitionering op het tabblad Bron van de kopieeractiviteit.

Schermopname van Azure Data Factory Oracle-partitieopties op het tabblad Bron.

Zie Parallelle kopie van Oracle voor informatie over het configureren van de Oracle-connector voor parallelle kopie.

Zie Copy-activiteit handleiding voor prestaties en schaalbaarheid van data factory-kopieeractiviteiten voor meer informatie over de prestaties en schaalbaarheid van Data Factory.

Volgende stappen

Zie het volgende artikel in deze reeks: Beveiliging, toegang en bewerkingen voor Oracle-migraties voor meer informatie over bewerkingen voor beveiligingstoegang.