Datamigrering, ETL och inläsning för Oracle-migreringar
Den här artikeln är del två 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 ETL- och belastningsmigrering.
Överväganden för datamigrering
Det finns många faktorer att tänka på när du migrerar data, ETL och läser in från ett äldre Oracle-informationslager och data marts till Azure Synapse.
Inledande beslut om datamigrering från Oracle
När du planerar en migrering från en befintlig Oracle-miljö bör du överväga följande datarelaterade frågor:
Ska oanvända tabellstrukturer migreras?
Vilken är den bästa migreringsmetoden för att minimera risker och påverkan för användare?
När du migrerar data marts: förblir fysisk eller virtuell?
I nästa avsnitt beskrivs dessa punkter inom ramen för en migrering från Oracle.
Migrera oanvända tabeller?
Det är klokt att bara migrera tabeller som används. Tabeller som inte är aktiva kan arkiveras i stället för att migreras, så att data är tillgängliga om det behövs i framtiden. Det är bäst att använda systemmetadata och loggfiler i stället för dokumentation för att avgöra vilka tabeller som används, eftersom dokumentationen kan vara inaktuell.
Oracle-systemkatalogtabeller och -loggar innehåller information som kan användas för att avgöra när en viss tabell senast användes, vilket i sin tur kan användas för att avgöra om en tabell är en kandidat för migrering eller inte.
Om du har licensierat Oracle Diagnostic Pack har du åtkomst till Aktiv sessionshistorik som du kan använda för att avgöra när en tabell senast användes.
Dricks
I äldre system är det inte ovanligt att tabeller blir redundanta över tid – de behöver inte migreras i de flesta fall.
Här är en exempelfråga som söker efter användningen av en specifik tabell inom ett angivet tidsfönster:
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;
Den här frågan kan ta en stund att köra om du har kört flera frågor.
Vilken är den bästa migreringsmetoden för att minimera risker och påverkan på användare?
Den här frågan uppstår ofta eftersom företag kanske vill minska effekten av ändringar på datalagrets datamodell för att förbättra flexibiliteten. Företag ser ofta en möjlighet att ytterligare modernisera eller transformera sina data under en ETL-migrering. Den här metoden medför en högre risk eftersom den ändrar flera faktorer samtidigt, vilket gör det svårt att jämföra resultatet av det gamla systemet jämfört med det nya. Att göra ändringar i datamodellen här kan också påverka uppströms- eller nedströms ETL-jobb till andra system. På grund av den risken är det bättre att designa om på den här skalan efter migreringen av informationslagret.
Även om en datamodell avsiktligt ändras som en del av den övergripande migreringen är det bra att migrera den befintliga modellen som den är till Azure Synapse i stället för att göra någon omkonstruktion på den nya plattformen. Den här metoden minimerar effekten på befintliga produktionssystem, samtidigt som du drar nytta av prestanda och elastisk skalbarhet för Azure-plattformen för enstaka omkonstruktionsuppgifter.
Dricks
Migrera den befintliga modellen som den är från början, även om en ändring av datamodellen planeras i framtiden.
Data mart-migrering: förblir fysisk eller virtuell?
I äldre Oracle-informationslagermiljöer är det vanligt att skapa många data marts som är strukturerade för att ge bra prestanda för ad hoc-självbetjäningsfrågor och rapporter för en viss avdelning eller affärsfunktion inom en organisation. En data mart består vanligtvis av en delmängd av informationslagret som innehåller aggregerade versioner av data i ett formulär som gör det möjligt för användare att enkelt köra frågor mot dessa data med snabba svarstider. Användare kan använda användarvänliga frågeverktyg som Microsoft Power BI, som stöder interaktion med företagsanvändare med data marts. Dataformen i en data mart är i allmänhet en dimensionsdatamodell. En användning av data marts är att exponera data i en användbar form även om den underliggande lagerdatamodellen är något annat, till exempel ett datavalv.
Du kan använda separata data marts för enskilda affärsenheter i en organisation för att implementera robusta datasäkerhetsregimer. Begränsa åtkomsten till specifika data marts som är relevanta för användare och eliminera, dölja eller anonymisera känsliga data.
Om dessa data marts implementeras som fysiska tabeller behöver de extra lagringsresurser och bearbetning för att skapa och uppdatera dem regelbundet. Dessutom är data i mars bara lika uppdaterade som den senaste uppdateringsåtgärden, och kan därför vara olämpliga för mycket flyktiga datainstrumentpaneler.
Dricks
Virtualisering av data marts kan spara på lagrings- och bearbetningsresurser.
Med tillkomsten av billigare skalbara MPP-arkitekturer, till exempel Azure Synapse och deras inneboende prestandaegenskaper, kan du tillhandahålla data mart-funktioner utan att instansiera mart som en uppsättning fysiska tabeller. En metod är att effektivt virtualisera data marts via SQL-vyer till huvudinformationslagret. Ett annat sätt är att virtualisera data marts via ett virtualiseringslager med hjälp av funktioner som vyer i Azure eller virtualiseringsprodukter från tredje part . Den här metoden förenklar eller eliminerar behovet av extra lagrings- och aggregeringsbearbetning och minskar det totala antalet databasobjekt som ska migreras.
Det finns en annan potentiell fördel med den här metoden. Genom att implementera aggregerings- och kopplingslogik i ett virtualiseringslager och presentera externa rapporteringsverktyg via en virtualiserad vy, skickas den bearbetning som krävs för att skapa dessa vyer ned till informationslagret. Informationslagret är vanligtvis det bästa stället att köra kopplingar, aggregeringar och andra relaterade åtgärder på stora datavolymer.
De främsta drivkrafterna för att implementera en virtuell data mart över en fysisk data mart är:
Mer smidighet: en virtuell data mart är enklare att ändra än fysiska tabeller och associerade ETL-processer.
Lägre total ägandekostnad: en virtualiserad implementering kräver färre datalager och kopior av data.
Eliminering av ETL-jobb för att migrera och förenkla informationslagerarkitekturen i en virtualiserad miljö.
Prestanda: Även om fysiska data marts historiskt sett har presterat bättre, implementerar virtualiseringsprodukter nu intelligenta cachelagringstekniker för att minska den här skillnaden.
Dricks
Prestanda och skalbarhet för Azure Synapse möjliggör virtualisering utan att offra prestanda.
Datamigrering från Oracle
Förstå dina data
Som en del av migreringsplaneringen bör du i detalj förstå mängden data som ska migreras eftersom det kan påverka beslut om migreringsmetoden. Använd systemmetadata för att fastställa det fysiska utrymme som tas upp av rådata i tabellerna som ska migreras. I det här sammanhanget innebär rådata mängden utrymme som används av dataraderna i en tabell, exklusive omkostnader som index och komprimering. De största faktatabellerna består vanligtvis av mer än 95 % av data.
Den här frågan ger dig den totala databasstorleken i 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
Databasstorleken är lika med storleken på (data files + temp files + online/offline redo log files + control files). Den totala databasstorleken omfattar använt utrymme och ledigt utrymme.
Följande exempelfråga ger en uppdelning av diskutrymmet som används av tabelldata och index:
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;
Dessutom tillhandahåller Microsofts databasmigreringsteam många resurser, inklusive Oracle Inventory Script Artifacts. Verktyget Oracle Inventory Script Artifacts innehåller en PL/SQL-fråga som har åtkomst till Oracle-systemtabeller och ger ett antal objekt efter schematyp, objekttyp och status. Verktyget ger också en grov uppskattning av rådata i varje schema och storleksändringen av tabeller i varje schema, med resultat som lagras i ett CSV-format. Ett inkluderat kalkylatorkalkylblad tar CSV som indata och tillhandahåller storleksdata.
För alla tabeller kan du exakt uppskatta mängden data som måste migreras genom att extrahera ett representativt urval av data, till exempel en miljon rader, till en okomprimerad avgränsad platt ASCII-datafil. Använd sedan filens storlek för att få en genomsnittlig rådatastorlek per rad. Multiplicera slutligen den genomsnittliga storleken med det totala antalet rader i den fullständiga tabellen för att ge en rådatastorlek för tabellen. Använd den rådatastorleken i planeringen.
Använda SQL-frågor för att hitta datatyper
Genom att fråga oracles statiska dataordlistevy DBA_TAB_COLUMNS kan du avgöra vilka datatyper som används i ett schema och om någon av dessa datatyper behöver ändras. Använd SQL-frågor för att hitta kolumnerna i ett Oracle-schema med datatyper som inte mappas direkt till datatyper i Azure Synapse. På samma sätt kan du använda frågor för att räkna antalet förekomster av varje Oracle-datatyp som inte mappas direkt till Azure Synapse. Genom att använda resultaten från dessa frågor i kombination med jämförelsetabellen för datatyp kan du avgöra vilka datatyper som behöver ändras i en Azure Synapse-miljö.
Om du vill hitta kolumnerna med datatyper som inte mappas till datatyper i Azure Synapse kör du följande fråga när du har ersatt <owner_name> med relevant ägare av schemat:
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;
Om du vill räkna antalet datatyper som inte kan mappas använder du följande fråga:
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 erbjuder SQL Server Migration Assistant (SSMA) för Oracle för att automatisera migreringen av informationslager från äldre Oracle-miljöer, inklusive mappning av datatyper. Du kan också använda Azure Database Migration Services för att planera och utföra en migrering från miljöer som Oracle. Tredjepartsleverantörer erbjuder även verktyg och tjänster för att automatisera migreringen. Om ett ETL-verktyg från tredje part redan används i Oracle-miljön kan du använda verktyget för att implementera nödvändiga datatransformeringar. I nästa avsnitt beskrivs migrering av befintliga ETL-processer.
Överväganden för ETL-migrering
Inledande beslut om Oracle ETL-migrering
För ETL/ELT-bearbetning använder äldre Oracle-informationslager ofta anpassade skript, ETL-verktyg från tredje part eller en kombination av metoder som har utvecklats över tid. När du planerar en migrering till Azure Synapse ska du bestämma det bästa sättet att implementera den nödvändiga ETL/ELT-bearbetningen i den nya miljön samtidigt som du minimerar kostnader och risker.
Dricks
Planera metoden för ETL-migrering i förväg och utnyttja Azure-anläggningar där det är lämpligt.
Följande flödesschema sammanfattar en metod:
Som du ser i flödesschemat är det första steget alltid att skapa en inventering av ETL/ELT-processer som måste migreras. Med de inbyggda Azure-standardfunktionerna kanske vissa befintliga processer inte behöver flyttas. I planeringssyfte är det viktigt att du förstår migreringens skala. Tänk sedan på frågorna i beslutsträdet för flödesschemat:
Vill du flytta till den interna Azure? Ditt svar beror på om du migrerar till en helt Azure-intern miljö. I så fall rekommenderar vi att du återskapar ETL-bearbetningen med hjälp av pipelines och aktiviteter i Azure Data Factory eller Azure Synapse-pipelines.
Använder du ett ETL-verktyg från tredje part? Om du inte flyttar till en helt Azure-intern miljö kontrollerar du om ett befintligt ETL-verktyg från tredje part redan används. I Oracle-miljön kan du upptäcka att en del eller hela ETL-bearbetningen utförs av anpassade skript med hjälp av Oracle-specifika verktyg som Oracle SQL Developer, Oracle SQL*Loader eller Oracle Data Pump. Metoden i det här fallet är att omkonstruera med Hjälp av Azure Data Factory.
Stöder tredje part dedikerade SQL-pooler i Azure Synapse? Fundera på om det finns en stor investering i kunskaper i ETL-verktyget från tredje part, eller om befintliga arbetsflöden och scheman använder det verktyget. I så fall kan du avgöra om verktyget effektivt kan stödja Azure Synapse som en målmiljö. Helst innehåller verktyget inbyggda anslutningsappar som kan använda Azure-anläggningar som PolyBase eller COPY INTO för den mest effektiva datainläsningen. Men även utan interna anslutningsappar finns det vanligtvis ett sätt att anropa externa processer, till exempel PolyBase eller
COPY INTO, och skicka in tillämpliga parametrar. I det här fallet använder du befintliga kunskaper och arbetsflöden med Azure Synapse som ny målmiljö.Om du använder Oracle Data Integrator (ODI) för ELT-bearbetning behöver du ODI-kunskapsmoduler för Azure Synapse. Om dessa moduler inte är tillgängliga för dig i din organisation, men du har ODI, kan du använda ODI för att generera flata filer. Dessa flata filer kan sedan flyttas till Azure och matas in i Azure Data Lake Storage för inläsning till Azure Synapse.
Kör du ETL-verktyg i Azure? Om du bestämmer dig för att behålla ett befintligt ETL-verktyg från tredje part kan du köra verktyget i Azure-miljön (i stället för på en befintlig lokal ETL-server) och låta Data Factory hantera den övergripande orkestreringen av befintliga arbetsflöden. Så bestäm om du vill låta det befintliga verktyget köras som det är eller flytta det till Azure-miljön för att uppnå kostnads-, prestanda- och skalbarhetsfördelar.
Dricks
Överväg att köra ETL-verktyg i Azure för att dra nytta av prestanda, skalbarhet och kostnadsfördelar.
Återskapa befintliga Oracle-specifika skript
Om en del eller hela den befintliga Oracle Warehouse ETL/ELT-bearbetningen hanteras av anpassade skript som använder Oracle-specifika verktyg, till exempel Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader eller Oracle Data Pump, måste du koda om skripten för Azure Synapse-miljön. Om ETL-processer har implementerats med lagrade procedurer i Oracle måste du på samma sätt koda om dessa processer.
Vissa element i ETL-processen är enkla att migrera, till exempel genom enkel massinläsning av data till en mellanlagringstabell från en extern fil. Det kan till och med vara möjligt att automatisera dessa delar av processen, till exempel genom att använda Azure Synapse COPY INTO eller PolyBase i stället för SQL*Loader. Andra delar av processen som innehåller godtyckliga komplexa SQL- och/eller lagrade procedurer tar längre tid att återskapa.
Dricks
Inventeringen av ETL-uppgifter som ska migreras bör innehålla skript och lagrade procedurer.
Ett sätt att testa Oracle SQL för kompatibilitet med Azure Synapse är att samla in några representativa SQL-instruktioner från en anslutning till Oracle v$active_session_history och v$sql hämta sql_textoch sedan prefixa dessa frågor med EXPLAIN. Om du antar att en liknande migrerad datamodell i Azure Synapse kör du dessa EXPLAIN instruktioner i Azure Synapse. Alla inkompatibla SQL-filer ger ett fel. Du kan använda den här informationen för att fastställa omoderingsaktivitetens skala.
Dricks
Använd EXPLAIN för att hitta SQL-inkompatibiliteter.
I värsta fall kan manuell omodering vara nödvändigt. Det finns dock produkter och tjänster som är tillgängliga från Microsoft-partner för att hjälpa till med omframställning av Oracle-specifik kod.
Dricks
Partner erbjuder produkter och färdigheter för att hjälpa till med att omkonstruera Oracle-specifik kod.
Använda befintliga ETL-verktyg från tredje part
I många fall kommer det befintliga äldre informationslagersystemet redan att fyllas i och underhållas av en ETL-produkt från tredje part. Se Azure Synapse Analytics-dataintegreringspartners för en lista över aktuella Microsoft-dataintegreringspartner för Azure Synapse.
Oracle-communityn använder ofta flera populära ETL-produkter. I följande stycken beskrivs de mest populära ETL-verktygen för Oracle-lager. Du kan köra alla dessa produkter på en virtuell dator i Azure och använda dem för att läsa och skriva Azure-databaser och -filer.
Dricks
Dra nytta av investeringar i befintliga verktyg från tredje part för att minska kostnader och risker.
Datainläsning från Oracle
Tillgängliga alternativ vid inläsning av data från Oracle
När du förbereder migreringen av data från ett Oracle-informationslager bestämmer du hur data ska flyttas fysiskt från den befintliga lokala miljön till Azure Synapse i molnet och vilka verktyg som ska användas för att utföra överföringen och belastningen. Tänk på följande frågor som beskrivs i följande avsnitt.
Kommer du att extrahera data till filer eller flytta dem direkt via en nätverksanslutning?
Kommer du att samordna processen från källsystemet eller från Azure-målmiljön?
Vilka verktyg använder du för att automatisera och hantera migreringsprocessen?
Vill du överföra data via filer eller nätverksanslutningar?
När databastabellerna som ska migreras har skapats i Azure Synapse kan du flytta data som fyller dessa tabeller från det äldre Oracle-systemet och till den nya miljön. Det finns två grundläggande metoder:
Filextrakt: extrahera data från Oracle-tabellerna till platta avgränsade filer, vanligtvis i CSV-format. Du kan extrahera tabelldata på flera sätt:
- Använd Oracle-standardverktyg som SQL*Plus, SQL Developer och SQLcl.
- Använd Oracle Data Integrator (ODI) för att generera flata filer.
- Använd Oracle-anslutningsappen i Data Factory för att ta bort Oracle-tabeller parallellt för att aktivera datainläsning av partitioner.
- Använd ett ETL-verktyg från tredje part .
Exempel på hur du extraherar Oracle-tabelldata finns i artikelns bilaga.
Den här metoden kräver utrymme för att landa de extraherade datafilerna. Utrymmet kan vara lokalt för Oracle-källdatabasen om tillräckligt med lagringsutrymme är tillgängligt eller fjärranslutet i Azure Blob Storage. Bästa prestanda uppnås när en fil skrivs lokalt eftersom det undviker nätverksbelastning.
För att minimera kraven på lagring och nätverksöverföring komprimerar du de extraherade datafilerna med hjälp av ett verktyg som gzip.
Efter extrahering flyttar du de platta filerna till Azure Blob Storage. Microsoft erbjuder olika alternativ för att flytta stora mängder data, inklusive:
- AzCopy för att flytta filer över nätverket till Azure Storage.
- Azure ExpressRoute för att flytta massdata via en privat nätverksanslutning.
- Azure Data Box för att flytta filer till en fysisk lagringsenhet som du skickar till ett Azure-datacenter för inläsning.
Mer information finns i Överföra data till och från Azure.
Direkt extrahering och inläsning över nätverket: Azure-målmiljön skickar en begäran om dataextrakt, vanligtvis via ett SQL-kommando, till det äldre Oracle-systemet för att extrahera data. Resultaten skickas över nätverket och läses in direkt i Azure Synapse, utan att data behöver landas i mellanliggande filer. Den begränsande faktorn i det här scenariot är normalt bandbredden för nätverksanslutningen mellan Oracle-databasen och Azure-miljön. För exceptionellt stora datavolymer är den här metoden kanske inte praktisk.
Dricks
Förstå de datavolymer som ska migreras och den tillgängliga nätverksbandbredden, eftersom dessa faktorer påverkar migreringsmetodens beslut.
Det finns också en hybridmetod som använder båda metoderna. Du kan till exempel använda metoden för direkt nätverksextrakt för mindre dimensionstabeller och exempel på de större faktatabellerna för att snabbt tillhandahålla en testmiljö i Azure Synapse. För historiska faktatabeller med stora volymer kan du använda metoden för att extrahera och överföra filer med hjälp av Azure Data Box.
Orkestrera från Oracle eller Azure?
Den rekommenderade metoden när du flyttar till Azure Synapse är att samordna extrahering och inläsning av data från Azure-miljön med hjälp av SSMA eller Data Factory. Använd de associerade verktygen, till exempel PolyBase eller COPY INTO, för den mest effektiva datainläsningen. Den här metoden drar nytta av inbyggda Azure-funktioner och minskar arbetet med att skapa återanvändbara datainläsningspipelines. Du kan använda metadatadrivna datainläsningspipelines för att automatisera migreringsprocessen.
Den rekommenderade metoden minimerar också prestandan för den befintliga Oracle-miljön under datainläsningsprocessen, eftersom hanterings- och inläsningsprocessen körs i Azure.
Befintliga datamigreringsverktyg
Datatransformering och förflyttning är den grundläggande funktionen för alla ETL-produkter. Om ett datamigreringsverktyg redan används i den befintliga Oracle-miljön och det stöder Azure Synapse som målmiljö kan du överväga att använda det verktyget för att förenkla datamigreringen.
Även om det inte finns något befintligt ETL-verktyg erbjuder Azure Synapse Analytics-dataintegreringspartner ETL-verktyg för att förenkla datamigreringen.
Om du planerar att använda ett ETL-verktyg bör du överväga att köra verktyget i Azure-miljön för att dra nytta av Azures molnprestanda, skalbarhet och kostnad. Den här metoden frigör även resurser i Oracle-datacentret.
Sammanfattning
För att sammanfatta är våra rekommendationer för migrering av data och associerade ETL-processer från Oracle till Azure Synapse:
Planera framåt för att säkerställa en lyckad migreringsövning.
Skapa en detaljerad inventering av data och processer som ska migreras så snart som möjligt.
Använd systemmetadata och loggfiler för att få en korrekt förståelse för data- och processanvändning. Förlita dig inte på dokumentation eftersom den kan vara inaktuell.
Förstå de datavolymer som ska migreras och nätverksbandbredden mellan det lokala datacentret och Azure-molnmiljöerna.
Överväg att använda en Oracle-instans på en virtuell Azure-dator som en språngbräda för att avlasta migreringen från den äldre Oracle-miljön.
Använd inbyggda Azure-standardfunktioner för att minimera migreringsarbetsbelastningen.
Identifiera och förstå de mest effektiva verktygen för extrahering och inläsning av data i både Oracle- och Azure-miljöer. Använd lämpliga verktyg i varje fas av processen.
Använd Azure-anläggningar, till exempel Data Factory, för att samordna och automatisera migreringsprocessen samtidigt som påverkan på Oracle-systemet minimeras.
Bilaga: Exempel på tekniker för att extrahera Oracle-data
Du kan använda flera tekniker för att extrahera Oracle-data när du migrerar från Oracle till Azure Synapse. I nästa avsnitt visas hur du extraherar Oracle-data med Oracle SQL Developer och Oracle-anslutningsappen i Data Factory.
Använda Oracle SQL Developer för extrahering av data
Du kan använda Oracle SQL Developer-användargränssnittet för att exportera tabelldata till många format, inklusive CSV, enligt följande skärmbild:
Andra exportalternativ är JSON och XML. Du kan använda användargränssnittet för att lägga till en uppsättning tabellnamn i en "kundvagn" och sedan tillämpa exporten på hela uppsättningen i kundvagnen:
Du kan också använda Oracle SQL Developer Command Line (SQLcl) för att exportera Oracle-data. Det här alternativet stöder automatisering med hjälp av ett gränssnittsskript.
För relativt små tabeller kan den här tekniken vara användbar om du stöter på problem med att extrahera data via en direktanslutning.
Använda Oracle-anslutningsappen i Azure Data Factory för parallell kopiering
Du kan använda Oracle-anslutningsappen i Data Factory för att ta bort stora Oracle-tabeller parallellt. Oracle-anslutningsappen tillhandahåller inbyggd datapartitionering för att kopiera data från Oracle parallellt. Du hittar alternativen för datapartitionering på fliken Källa i kopieringsaktiviteten.
Information om hur du konfigurerar Oracle-anslutningsappen för parallell kopiering finns i Parallell kopiering från Oracle.
Mer information om datafabrikens kopieringsaktivitetsprestanda och skalbarhet finns i guiden Kopiera aktivitetsprestanda och skalbarhet.
Nästa steg
Mer information om säkerhetsåtkomståtgärder finns i nästa artikel i den här serien: Säkerhet, åtkomst och åtgärder för Oracle-migreringar.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för