Migrace dat, ETL a načítání pro migrace Oracle
Tento článek je druhou částí sedmidílné série, která poskytuje pokyny k migraci z Oracle na Azure Synapse Analytics. Tento článek se zaměřuje na osvědčené postupy pro etl a migraci zatížení.
Aspekty migrace dat
Při migraci dat, ETL a načítání ze staršího datového skladu Oracle a datových tržiští na Azure Synapse je potřeba vzít v úvahu mnoho faktorů.
Počáteční rozhodnutí o migraci dat ze společnosti Oracle
Při plánování migrace z existujícího prostředí Oracle zvažte následující otázky související s daty:
Mají se migrovat nepoužívané struktury tabulek?
Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?
Při migraci datových tržítků: Zůstat fyzicky nebo virtuální?
Následující části popisují tyto body v kontextu migrace z Oracle.
Migrovat nepoužívané tabulky?
Je vhodné migrovat jenom tabulky, které se používají. Tabulky, které nejsou aktivní, je možné místo migrace archivovat, aby data byla v budoucnu v případě potřeby k dispozici. K určení, které tabulky se používají, je nejlepší místo dokumentace použít systémová metadata a soubory protokolů, protože dokumentace může být za aktuální.
Tabulky a protokoly katalogu systémů Oracle obsahují informace, které lze použít k určení, kdy byla daná tabulka naposledy přístupná– které se pak dají použít k rozhodnutí, jestli je tabulka kandidátem na migraci.
Pokud jste licencovali sadu Oracle Diagnostic Pack, máte přístup k historii aktivních relací, pomocí které můžete určit, kdy byla tabulka naposledy přístupná.
Tip
Ve starších systémech není neobvyklé, že tabulky budou v průběhu času redundantní – ve většině případů se nemusí migrovat.
Tady je příklad dotazu, který hledá použití konkrétní tabulky v daném časovém intervalu:
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;
Spuštění tohoto dotazu může nějakou dobu trvat, pokud jste spustili mnoho dotazů.
Jaký je nejlepší přístup k migraci, aby se minimalizovalo riziko a dopad na uživatele?
Tato otázka přichází často, protože společnosti mohou chtít snížit dopad změn na datový model datového skladu, aby se zlepšila flexibilita. Společnosti často vidí příležitost k další modernizaci nebo transformaci dat během migrace ETL. Tento přístup s sebou nese vyšší riziko, protože současně mění více faktorů, což ztěžuje porovnání výsledků starého systému s novým. Změny datového modelu v této části by také mohly ovlivnit nadřazené nebo podřízené úlohy ETL do jiných systémů. Vzhledem k tomuto riziku je lepší po migraci datového skladu tento rozsah přepracovat.
I když se datový model v rámci celkové migrace záměrně změní, je vhodné stávající model migrovat tak, jak je, a Azure Synapse, místo aby se na nové platformě přepracovávat. Tento přístup minimalizuje dopad na stávající produkční systémy a zároveň těží z výkonu a elastické škálovatelnosti platformy Azure pro jednorázové přepracování úloh.
Tip
Migrace stávajícího modelu tak, jak je, i když se v budoucnu plánuje změna datového modelu.
Migrace datového tržiště: Zůstat fyzicky nebo virtuální?
Ve starších prostředích datového skladu Oracle je běžným zvykem vytvořit mnoho datových tržiští, která jsou strukturovaná tak, aby poskytovala dobrý výkon pro ad hoc samoobslužné dotazy a sestavy pro dané oddělení nebo obchodní funkce v rámci organizace. Datové tržiště se obvykle skládá z podmnožina datového skladu, která obsahuje agregované verze dat ve formě, která uživatelům umožňuje snadno se na tato data dotazovat s rychlou dobou odezvy. Uživatelé můžou používat uživatelsky přívětivé dotazovací nástroje, jako je Microsoft Power BI, který podporuje interakce podnikových uživatelů s datovými tržištěmi. Forma dat v datovém tržiště je obecně dimenzionální datový model. Jedním z použití datových tržítků je zveřejnění dat v použitelné podobě, i když je podkladový datový model skladu něco jiného, například trezor dat.
K implementaci robustních režimů zabezpečení dat můžete použít samostatná datová tržiště pro jednotlivé obchodní jednotky v rámci organizace. Omezte přístup ke konkrétním datovým tržinám, která jsou pro uživatele relevantní, a eliminujte, obfuscate nebo anonymizujte citlivá data.
Pokud jsou tato datová tržiště implementovaná jako fyzické tabulky, budou k jejich pravidelnému sestavování a aktualizaci vyžadovat další prostředky úložiště a jejich zpracování. Data v tržině budou také pouze aktuální jako poslední operace aktualizace, a proto mohou být nevhodná pro vysoce nestálé řídicí panely dat.
Tip
Virtualizace datových tržítků může ušetřit prostředky úložiště a zpracování.
S nástupem škálovatelných architektur MPP s nižšími náklady, jako je Azure Synapse, a jejich inherentních charakteristik výkonu můžete poskytovat funkce datového tržiště bez vytvoření instance tržiště jako sady fyzických tabulek. Jednou z metod je efektivní virtualizace datových tržítků prostřednictvím zobrazení SQL do hlavního datového skladu. Dalším způsobem je virtualizovat datová tržiště prostřednictvím vrstvy virtualizace pomocí funkcí, jako jsou zobrazení v Azure nebo virtualizační produkty třetích stran . Tento přístup zjednodušuje nebo eliminuje potřebu dalšího zpracování úložiště a agregace a snižuje celkový počet databázových objektů, které se mají migrovat.
Tento přístup má další potenciální výhodu. Díky implementaci agregace a logiky spojení v rámci vrstvy virtualizace a prezentování externích nástrojů pro vytváření sestav prostřednictvím virtualizovaného zobrazení se zpracování potřebné k vytvoření těchto zobrazení přesune do datového skladu. Datový sklad je obecně nejlepším místem pro spouštění spojení, agregací a dalších souvisejících operací na velkých objemech dat.
Primárními ovladači pro implementaci virtuálního datového tržiště přes fyzické datové tržiště jsou:
Větší flexibilita: Virtuální datové tržiště se snadněji mění než fyzické tabulky a přidružené procesy ETL.
Nižší celkové náklady na vlastnictví: Virtualizovaná implementace vyžaduje méně úložišť dat a kopií dat.
Odstranění úloh ETL za účelem migrace a zjednodušení architektury datového skladu ve virtualizovaném prostředí
Výkon: Přestože fyzická datová tržiště v minulosti fungovala lépe, virtualizační produkty teď implementují techniky inteligentního ukládání do mezipaměti, které tento rozdíl zmírnit.
Tip
Výkon a škálovatelnost Azure Synapse umožňují virtualizaci bez obětování výkonu.
Migrace dat z Oracle
Vysvětlení dat
V rámci plánování migrace byste měli podrobně porozumět objemu migrovaných dat, protože to může mít vliv na rozhodování o přístupu k migraci. Pomocí systémových metadat můžete určit fyzický prostor, který zabírají nezpracovaná data v tabulkách, které se mají migrovat. Nezpracovaná data v tomto kontextu znamenají velikost místa využitého řádky dat v tabulce, s výjimkou režijních nákladů, jako jsou indexy a komprese. Největší tabulky faktů obvykle tvoří více než 95 % dat.
Tento dotaz vám poskytne celkovou velikost databáze v 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
Velikost databáze se rovná velikosti (data files + temp files + online/offline redo log files + control files). Celková velikost databáze zahrnuje využité místo a volné místo.
Následující příklad dotazu obsahuje rozpis místa na disku, které využívají data tabulky a indexy:
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;
Kromě toho tým pro migraci databází Microsoftu poskytuje mnoho prostředků, včetně artefaktů skriptů inventáře Oracle. Nástroj Oracle Inventory Script Artifacts obsahuje dotaz PL/SQL, který přistupuje k systémovým tabulkám Oracle a poskytuje počet objektů podle typu schématu, typu objektu a stavu. Nástroj také poskytuje hrubý odhad nezpracovaných dat v každém schématu a velikost tabulek v každém schématu s výsledky uloženými ve formátu CSV. Zahrnutá tabulka kalkulačky přebírá csv jako vstup a poskytuje data o velikosti.
U jakékoli tabulky můžete přesně odhadnout objem dat, která je potřeba migrovat, extrahováním reprezentativního vzorku dat, například jednoho milionu řádků, do nekomprimovaného datového souboru ASCII s oddělovači. Pak pomocí velikosti tohoto souboru získáte průměrnou nezpracovanou velikost dat na řádek. Nakonec vynásobte průměrnou velikost celkovým počtem řádků v celé tabulce, abyste získali nezpracovanou velikost dat pro tabulku. Tuto nezpracovanou velikost dat použijte při plánování.
Použití dotazů SQL k vyhledání datových typů
Dotazováním zobrazení statického slovníku DBA_TAB_COLUMNS dat Oracle můžete určit, které datové typy se ve schématu používají a jestli je potřeba některý z těchto datových typů změnit. Pomocí dotazů SQL vyhledejte sloupce v libovolném schématu Oracle s datovými typy, které se nemapují přímo na datové typy v Azure Synapse. Podobně můžete pomocí dotazů spočítat počet výskytů jednotlivých datových typů Oracle, které se nemapují přímo na Azure Synapse. Pomocí výsledků z těchto dotazů v kombinaci s srovnávací tabulkou datových typů můžete určit, které datové typy je potřeba změnit v Azure Synapse prostředí.
Pokud chcete najít sloupce s datovými typy, které se nemapují na datové typy v Azure Synapse, spusťte po nahrazení <owner_name> příslušným vlastníkem schématu následující dotaz:
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;
Pokud chcete spočítat počet nemapovatelných datových typů, použijte následující dotaz:
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 nabízí Pomocník s migrací SQL Serveru (SSMA) pro Oracle k automatizaci migrace datových skladů ze starších prostředí Oracle, včetně mapování datových typů. Službu Azure Database Migration Services můžete také použít k plánování a provedení migrace z prostředí, jako je Oracle. Externí dodavatelé také nabízejí nástroje a služby pro automatizaci migrace. Pokud se v prostředí Oracle již používá nástroj ETL třetí strany , můžete ho použít k implementaci všech požadovaných transformací dat. V další části se podíváme na migraci existujících procesů ETL.
Aspekty migrace ETL
Počáteční rozhodnutí o migraci Oracle ETL
Pro zpracování ETL/ELT používají starší datové sklady Oracle často vlastní skripty, nástroje ETL třetích stran nebo kombinaci přístupů, které se v průběhu času vyvinuly. Při plánování migrace do Azure Synapse určete nejlepší způsob, jak v novém prostředí implementovat požadované zpracování ETL/ELT a zároveň minimalizovat náklady a rizika.
Tip
Naplánujte přístup k migraci ETL předem a v případě potřeby využijte zařízení Azure.
Následující vývojový diagram shrnuje jeden přístup:
Jak je znázorněno ve vývojovém diagramu, počátečním krokem je vždy vytvoření inventáře procesů ETL/ELT, které je potřeba migrovat. Díky standardním integrovaným funkcím Azure nemusí být některé stávající procesy nutné přesouvat. Pro účely plánování je důležité, abyste rozuměli rozsahu migrace. Dále se zamyslete nad otázkami v rozhodovacím stromu vývojového diagramu:
Přejít na nativní Azure? Vaše odpověď závisí na tom, jestli migrujete do zcela nativního prostředí Azure. Pokud ano, doporučujeme přepracovat zpracování ETL pomocí kanálů a aktivit v kanálech Azure Data Factory nebo Azure Synapse.
Používáte nástroj ETL třetí strany? Pokud nepřesouváte do zcela nativního prostředí Azure, zkontrolujte, jestli se už používá existující nástroj ETL třetí strany . V prostředí Oracle můžete zjistit, že některé nebo veškeré zpracování ETL provádí vlastní skripty pomocí nástrojů specifických pro Oracle, jako jsou Oracle SQL Developer, Oracle SQL*Loader nebo Oracle Data Pump. Přístup v tomto případě spočívá v přepracování pomocí Azure Data Factory.
Podporuje třetí strana vyhrazené fondy SQL v rámci Azure Synapse? Zvažte, jestli nástroj ETL třetí strany investuje velké investice do dovedností, nebo jestli tento nástroj využívají stávající pracovní postupy a plány. Pokud ano, určete, jestli nástroj dokáže efektivně podporovat Azure Synapse jako cílové prostředí. V ideálním případě bude tento nástroj obsahovat nativní konektory, které můžou k co nejefektivnějšímu načítání dat používat zařízení Azure, jako je PolyBase nebo COPY INTO . Ale i bez nativních konektorů existuje obecně způsob, jak můžete volat externí procesy, jako je PolyBase nebo
COPY INTO, a předávat příslušné parametry. V tomto případě použijte existující dovednosti a pracovní postupy, přičemž Azure Synapse jako nové cílové prostředí.Pokud ke zpracování ELT používáte Oracle Data Integrator (ODI), budete potřebovat znalostní moduly ODI pro Azure Synapse. Pokud tyto moduly nejsou ve vaší organizaci dostupné, ale máte ODI, můžete k vygenerování plochých souborů použít ODI. Tyto ploché soubory se pak dají přesunout do Azure a ingestovat do Azure Data Lake Storage pro načtení do Azure Synapse.
Spustit nástroje ETL v Azure? Pokud se rozhodnete zachovat existující nástroj ETL třetí strany, můžete tento nástroj spustit v prostředí Azure (nikoli na existujícím místním serveru ETL) a nechat službu Data Factory, aby zpracoval celkovou orchestraci stávajících pracovních postupů. Proto se rozhodněte, jestli chcete stávající nástroj nechat spuštěný tak, jak je, nebo ho přesunout do prostředí Azure, abyste dosáhli výhod nákladů, výkonu a škálovatelnosti.
Tip
Zvažte spuštění nástrojů ETL v Azure, abyste mohli využívat výkon, škálovatelnost a nákladové výhody.
Přepracování existujících skriptů specifických pro Oracle
Pokud některé nebo všechny stávající zpracování ETL/ELT ve skladu Oracle zpracovávají vlastní skripty, které používají nástroje specifické pro Oracle, například Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader nebo Oracle Data Pump, budete muset tyto skripty překódovat pro Azure Synapse prostředí. Podobně platí, že pokud byly procesy ETL implementované pomocí uložených procedur v Oracle, musíte tyto procesy překódovat.
Některé prvky procesu ETL se snadno migrují, například jednoduchým hromadným načtením dat do pracovní tabulky z externího souboru. Může být dokonce možné automatizovat tyto části procesu, například pomocí Azure Synapse COPY INTO nebo PolyBase místo SQL*Loaderu. Další části procesu, které obsahují libovolně složité sql a/nebo uložené procedury, bude trvat delší dobu, než se přepracují.
Tip
Inventář úloh ETL, které se mají migrovat, by měl zahrnovat skripty a uložené procedury.
Jedním ze způsobů, jak otestovat kompatibilitu Oracle SQL s Azure Synapse, je zachytit některé reprezentativní příkazy SQL ze spojení Oracle v$active_session_history a v$sql získat sql_textpředponu pro tyto dotazy pomocí EXPLAIN. Za předpokladu migrovaného datového modelu podobného typu v Azure Synapse spusťte tyto EXPLAIN příkazy v Azure Synapse. Jakýkoli nekompatibilní SQL zobrazí chybu. Tyto informace můžete použít k určení měřítka úlohy přepočítávání.
Tip
Slouží EXPLAIN k vyhledání nekompatibility SQL.
V nejhorším případě může být nutné provést ruční překódování. Existují však produkty a služby od partnerů Microsoftu , které pomáhají při přepracování kódu specifického pro Oracle.
Tip
Partneři nabízejí produkty a dovednosti, které vám pomůžou při přepracování kódu specifického pro Oracle.
Použití existujících nástrojů ETL třetích stran
V mnoha případech bude stávající starší systém datového skladu již naplněn a udržován produktem ETL třetí strany. Seznam aktuálních partnerů microsoftu pro integraci dat pro Azure Synapse najdete v tématu partneři pro integraci dat Azure Synapse Analytics.
Komunita Oracle často používá několik oblíbených produktů ETL. Následující odstavce popisují nejoblíbenější nástroje ETL pro sklady Oracle. Všechny tyto produkty můžete spouštět na virtuálním počítači v Azure a používat je ke čtení a zápisu databází a souborů Azure.
Tip
Využijte investice do stávajících nástrojů třetích stran ke snížení nákladů a rizika.
Načítání dat z Oracle
Volby dostupné při načítání dat z Oracle
Když se připravujete na migraci dat z datového skladu Oracle, rozhodněte se, jak se data fyzicky přesunou z existujícího místního prostředí do Azure Synapse v cloudu a jaké nástroje se použijí k přenosu a načtení. Zvažte následující otázky, které jsou popsány v následujících částech.
Budete extrahovat data do souborů nebo je přesunout přímo přes síťové připojení?
Budete orchestrovat proces ze zdrojového systému nebo z cílového prostředí Azure?
Které nástroje použijete k automatizaci a správě procesu migrace?
Přenášet data přes soubory nebo síťové připojení?
Jakmile se v Azure Synapse vytvoří databázové tabulky, které se mají migrovat, můžete data, která tyto tabulky naplní, přesunout ze staršího systému Oracle do nového prostředí. Existují dva základní přístupy:
Extrakce souboru: Extrahujte data z tabulek Oracle do plochých souborů s oddělovači, obvykle ve formátu CSV. Data tabulky můžete extrahovat několika způsoby:
- Používejte standardní nástroje Oracle, jako jsou SQL*Plus, SQL Developer a SQLcl.
- K vygenerování plochých souborů použijte Oracle Data Integrator (ODI).
- Pomocí konektoru Oracle ve službě Data Factory můžete paralelně uvolnit tabulky Oracle, aby bylo možné načítat data podle oddílů.
- Použijte nástroj ETL třetí strany .
Příklady extrahování dat tabulky Oracle najdete v příloze článku.
Tento přístup vyžaduje místo pro získání extrahovaných datových souborů. Pokud je k dispozici dostatečné úložiště, může být místo pro zdrojovou databázi Oracle místní nebo vzdálené v Azure Blob Storage. Nejlepšího výkonu dosáhnete, když je soubor zapsán místně, protože se tím vyhnete síťovým režijním nákladům.
Pokud chcete minimalizovat požadavky na úložiště a síťový přenos, komprimujte extrahované datové soubory pomocí nástroje, jako je gzip.
Po extrakci přesuňte ploché soubory do Azure Blob Storage. Microsoft nabízí různé možnosti pro přesun velkých objemů dat, včetně těchto:
- AzCopy pro přesun souborů v síti do Služby Azure Storage.
- Azure ExpressRoute pro přesun hromadných dat přes připojení k privátní síti.
- Azure Data Box pro přesun souborů do fyzického úložného zařízení, které odesíláte do datacentra Azure pro načtení.
Další informace najdete v tématu Přenos dat do a z Azure.
Přímé extrakce a načítání napříč sítí: Cílové prostředí Azure odešle požadavek na extrakci dat, obvykle prostřednictvím příkazu SQL, do staršího systému Oracle za účelem extrahování dat. Výsledky se odesílají přes síť a načtou se přímo do Azure Synapse, aniž by bylo nutné data převést do zprostředkujících souborů. Omezujícím faktorem v tomto scénáři je obvykle šířka pásma síťového připojení mezi databází Oracle a prostředím Azure. U mimořádně velkých objemů dat nemusí být tento přístup praktický.
Tip
Seznamte se s objemy dat, které se mají migrovat, a dostupnou šířku pásma sítě, protože tyto faktory ovlivňují rozhodnutí o přístupu k migraci.
Existuje také hybridní přístup, který používá obě metody. Pro menší tabulky dimenzí a ukázky větších tabulek faktů můžete například použít přístup k přímému extrakci sítě, abyste rychle poskytli testovací prostředí v Azure Synapse. U rozsáhlých historických tabulek faktů můžete použít přístup k extrakci a přenosu souborů pomocí Azure Data Boxu.
Chcete orchestrovat z Oracle nebo Azure?
Doporučeným postupem při přechodu na Azure Synapse je orchestrace extrakce a načítání dat z prostředí Azure pomocí SSMA nebo Data Factory. K co nejefektivnějšímu načítání dat použijte přidružené nástroje, například PolyBase nebo COPY INTO. Tento přístup těží z integrovaných funkcí Azure a snižuje úsilí při vytváření opakovaně použitelných kanálů načítání dat. K automatizaci procesu migrace můžete použít kanály načítání dat řízené metadaty.
Doporučený přístup také minimalizuje výkon ve stávajícím prostředí Oracle během procesu načítání dat, protože proces správy a načítání běží v Azure.
Existující nástroje pro migraci dat
Transformace a přesun dat je základní funkcí všech produktů ETL. Pokud se nástroj pro migraci dat už používá v existujícím prostředí Oracle a podporuje Azure Synapse jako cílové prostředí, zvažte použití nástroje ke zjednodušení migrace dat.
I v případě, že stávající nástroj ETL neexistuje, nabízejí partneři pro integraci dat Azure Synapse Analytics nástroje ETL, které zjednodušují migraci dat.
A konečně, pokud plánujete používat nástroj ETL, zvažte jeho spuštění v prostředí Azure, abyste mohli využít výkon, škálovatelnost a náklady v cloudu Azure. Tento přístup také uvolní prostředky v datacentru Oracle.
Souhrn
Abychom to shrnuli, naše doporučení pro migraci dat a souvisejících procesů ETL z Oracle do Azure Synapse jsou:
Naplánujte předem, abyste zajistili úspěšné cvičení migrace.
Vytvořte podrobný inventář dat a procesů, které se mají migrovat co nejdříve.
Pomocí systémových metadat a souborů protokolů získáte přesné informace o využití dat a procesů. Nespoléhejte se na dokumentaci, protože může být za aktuální.
Seznamte se s migrovanými datovými svazky a šířkou pásma sítě mezi místním datacentrem a cloudovými prostředími Azure.
Zvažte použití instance Oracle na virtuálním počítači Azure jako odrazového můstku pro přesměrování migrace ze starší verze prostředí Oracle.
Použití standardních integrovaných funkcí Azure k minimalizaci úloh migrace
Identifikujte a porozumíte nejúčinnějším nástrojům pro extrakci a načítání dat v prostředíCh Oracle i Azure. V každé fázi procesu používejte příslušné nástroje.
Pomocí zařízení Azure, jako je Data Factory, můžete orchestrovat a automatizovat proces migrace a zároveň minimalizovat dopad na systém Oracle.
Příloha: Příklady technik pro extrakci dat Oracle
K extrakci dat Oracle při migraci z Oracle do Azure Synapse můžete použít několik technik. Další části ukazují, jak extrahovat data Oracle pomocí Oracle SQL Developer a konektoru Oracle ve službě Data Factory.
Použití Oracle SQL Developer k extrakci dat
Pomocí uživatelského rozhraní Oracle SQL Developer UI můžete exportovat data tabulky do mnoha formátů, včetně csv, jak je znázorněno na následujícím snímku obrazovky:
Mezi další možnosti exportu patří JSON a XML. Pomocí uživatelského rozhraní můžete do košíku přidat sadu názvů tabulek a pak použít export na celou sadu v košíku:
K exportu dat Oracle můžete použít také příkazový řádek Oracle SQL Developer Command Line (SQLcl). Tato možnost podporuje automatizaci pomocí skriptu prostředí.
U relativně malých tabulek může být tato technika užitečná, pokud narazíte na problémy s extrahováním dat prostřednictvím přímého připojení.
Použití konektoru Oracle v Azure Data Factory pro paralelní kopírování
Konektor Oracle ve službě Data Factory můžete použít k paralelnímu uvolnění velkých tabulek Oracle. Konektor Oracle poskytuje integrované dělení dat pro paralelní kopírování dat z Oracle. Možnosti dělení dat najdete na kartě Zdroj aktivity kopírování.
Informace o tom, jak nakonfigurovat konektor Oracle pro paralelní kopírování, najdete v tématu Paralelní kopírování z Oracle.
Další informace o výkonu a škálovatelnosti aktivity kopírování služby Data Factory najdete v průvodci aktivita Copy výkonem a škálovatelností.
Další kroky
Další informace o operacích přístupu zabezpečení najdete v dalším článku této série: Zabezpečení, přístup a operace pro migrace Oracle.