Migracja danych, etL i ładowanie migracji oracle
Ten artykuł jest drugą częścią siedmioczęściowej serii, która zawiera wskazówki dotyczące migracji z programu Oracle do usługi Azure Synapse Analytics. Celem tego artykułu są najlepsze rozwiązania dotyczące migracji ETL i ładowania.
Zagadnienia dotyczące migracji danych
Istnieje wiele czynników, które należy wziąć pod uwagę podczas migrowania danych, etL i ładowania ze starszego magazynu danych Oracle i składnic danych do Azure Synapse.
Wstępne decyzje dotyczące migracji danych z programu Oracle
Podczas planowania migracji z istniejącego środowiska Oracle należy wziąć pod uwagę następujące pytania dotyczące danych:
Czy nieużywane struktury tabel powinny być migrowane?
Jakie jest najlepsze podejście do migracji, aby zminimalizować ryzyko i wpływ na użytkowników?
Podczas migrowania składnic danych: pozostać fizycznym lub wirtualnym?
W następnych sekcjach omówiono te punkty w kontekście migracji z programu Oracle.
Czy przeprowadzić migrację nieużywanych tabel?
Warto migrować tylko tabele, które są używane. Tabele, które nie są aktywne, można zarchiwizować, a nie zmigrować, dzięki czemu dane będą dostępne w razie potrzeby w przyszłości. Najlepiej użyć systemowych metadanych i plików dziennika, a nie dokumentacji, aby określić, które tabele są używane, ponieważ dokumentacja może być nieaktualna.
Tabele i dzienniki wykazu systemu Oracle zawierają informacje, których można użyć do określenia, kiedy dana tabela była ostatnio uzyskiwana — co z kolei może służyć do decydowania, czy tabela jest kandydatem do migracji.
Jeśli masz licencję pakietu diagnostycznego Oracle, masz dostęp do historii sesji aktywnej, której można użyć do określenia, kiedy tabela była ostatnio dostępna.
Porada
W starszych systemach nie jest niczym niezwykłym, aby tabele stały się nadmiarowe w czasie — w większości przypadków nie trzeba ich migrować.
Oto przykładowe zapytanie, które wyszukuje użycie określonej tabeli w danym przedziale czasu:
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;
Uruchomienie tego zapytania może trochę potrwać, jeśli uruchomiono wiele zapytań.
Jakie jest najlepsze podejście do migracji w celu zminimalizowania ryzyka i wpływu na użytkowników?
To pytanie pojawia się często, ponieważ firmy mogą chcieć zmniejszyć wpływ zmian w modelu danych magazynu danych w celu zwiększenia elastyczności. Firmy często widzą możliwość dalszej modernizacji lub przekształcania danych podczas migracji ETL. Takie podejście niesie ze sobą większe ryzyko, ponieważ zmienia jednocześnie wiele czynników, co utrudnia porównywanie wyników starego systemu z nowym. Wprowadzanie tutaj zmian w modelu danych może również mieć wpływ na zadania ETL nadrzędne lub podrzędne w innych systemach. Ze względu na to ryzyko lepiej jest przeprojektować tę skalę po migracji magazynu danych.
Nawet jeśli model danych został celowo zmieniony w ramach ogólnej migracji, dobrym rozwiązaniem jest migrowanie istniejącego modelu zgodnie z założeniami do Azure Synapse, zamiast ponownego inżynierii na nowej platformie. Takie podejście minimalizuje wpływ na istniejące systemy produkcyjne, a jednocześnie korzysta z wydajności i elastycznej skalowalności platformy Azure w przypadku jednorazowych zadań ponownej inżynierii.
Porada
Najpierw przeprowadź migrację istniejącego modelu, nawet jeśli w przyszłości zaplanowano zmianę modelu danych.
Migracja składnic danych: czy pozostać w trybie fizycznym, czy wirtualnym?
W starszych środowiskach magazynu danych Oracle powszechną praktyką jest tworzenie wielu składnic danych, które mają strukturę zapewniającą dobrą wydajność dla zapytań samoobsługowych ad hoc i raportów dla danego działu lub funkcji biznesowej w organizacji. Składninica danych zwykle składa się z podzestawu magazynu danych, który zawiera zagregowane wersje danych w postaci, która umożliwia użytkownikom łatwe wykonywanie zapytań o te dane z szybkim czasem odpowiedzi. Użytkownicy mogą używać przyjaznych dla użytkownika narzędzi do zapytań, takich jak Microsoft Power BI, które obsługują interakcje użytkowników biznesowych ze składnicami danych. Forma danych w składnic danych jest zazwyczaj modelem danych wymiarowych. Jednym z zastosowań składnic danych jest uwidocznienie danych w formie użytecznej, nawet jeśli bazowy model danych magazynu jest czymś innym, takim jak magazyn danych.
Aby zaimplementować niezawodne systemy zabezpieczeń danych, można użyć oddzielnych składnic danych dla poszczególnych jednostek biznesowych w organizacji. Ogranicz dostęp do określonych składnic danych, które są istotne dla użytkowników, i eliminuj, zaciemniaj lub anonimizuj poufne dane.
Jeśli te składnice danych są implementowane jako tabele fizyczne, będą wymagały dodatkowych zasobów magazynu i przetwarzania w celu ich regularnego kompilowania i odświeżania. Ponadto dane w składnicy będą aktualne tylko jako ostatnia operacja odświeżania i dlatego mogą być nieodpowiednie dla wysoce niestabilnych pulpitów nawigacyjnych danych.
Porada
Wirtualizacja składnic danych może zaoszczędzić na magazynie i przetwarzaniu zasobów.
Wraz z pojawieniem się mniej kosztowych skalowalnych architektur MPP, takich jak Azure Synapse i ich nieodłącznych cech wydajności, można zapewnić funkcjonalność składnicy danych bez tworzenia wystąpienia składnicy jako zestawu tabel fizycznych. Jedną z metod jest efektywne wirtualizacja składnic danych za pośrednictwem widoków SQL w głównym magazynie danych. Innym sposobem jest wirtualizacja składnic danych za pośrednictwem warstwy wirtualizacji przy użyciu funkcji, takich jak widoki na platformie Azure lub produkty wirtualizacji innych firm . Takie podejście upraszcza lub eliminuje konieczność dodatkowego przetwarzania magazynu i agregacji oraz zmniejsza ogólną liczbę obiektów bazy danych do zmigrowania.
Istnieje kolejna potencjalna korzyść z tego podejścia. Zaimplementowanie logiki agregacji i sprzężenia w warstwie wirtualizacji oraz przedstawienie zewnętrznych narzędzi raportowania za pośrednictwem zwirtualizowanego widoku umożliwia wypchnięcie przetwarzania wymaganego do utworzenia tych widoków do magazynu danych. Magazyn danych jest zazwyczaj najlepszym miejscem do uruchamiania sprzężeń, agregacji i innych powiązanych operacji na dużych woluminach danych.
Podstawowe sterowniki do implementowania wirtualnego składnic danych za pośrednictwem składnic danych fizycznych to:
Większa elastyczność: wirtualna składninica danych jest łatwiejsza do zmiany niż tabele fizyczne i skojarzone procesy ETL.
Niższy całkowity koszt posiadania: zwirtualizowana implementacja wymaga mniejszej liczby magazynów danych i kopii danych.
Eliminacja zadań ETL w celu migracji i uproszczenia architektury magazynu danych w środowisku zwirtualizowanym.
Wydajność: chociaż fizyczne składnice danych w przeszłości działały lepiej, produkty wirtualizacji wdrażają teraz inteligentne techniki buforowania, aby wyeliminować tę różnicę.
Porada
Wydajność i skalowalność Azure Synapse umożliwia wirtualizację bez poświęcania wydajności.
Migracja danych z bazy danych Oracle
Informacje o danych
W ramach planowania migracji należy szczegółowo zrozumieć ilość danych do zmigrowania, ponieważ może to mieć wpływ na decyzje dotyczące podejścia do migracji. Użyj metadanych systemowych, aby określić miejsce fizyczne zajęte przez nieprzetworzone dane w tabelach do zmigrowania. W tym kontekście dane pierwotne oznaczają ilość miejsca używanego przez wiersze danych w tabeli, z wyłączeniem narzutów, takich jak indeksy i kompresja. Największe tabele faktów zwykle składają się z ponad 95% danych.
To zapytanie daje łączny rozmiar bazy danych w programie 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
Rozmiar bazy danych jest równy rozmiarowi (data files + temp files + online/offline redo log files + control files). Ogólny rozmiar bazy danych obejmuje używane miejsce i wolne miejsce.
Następujące przykładowe zapytanie zawiera podział miejsca na dysku używanego przez dane tabeli i indeksy:
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;
Ponadto zespół ds. migracji bazy danych firmy Microsoft udostępnia wiele zasobów, w tym artefakty skryptu spisu Oracle. Narzędzie Oracle Inventory Script Artifacts zawiera zapytanie PL/SQL, które uzyskuje dostęp do tabel systemowych Oracle i zapewnia liczbę obiektów według typu schematu, typu obiektu i stanu. Narzędzie udostępnia również przybliżone oszacowanie nieprzetworzonych danych w każdym schemacie i rozmiar tabel w każdym schemacie z wynikami przechowywanymi w formacie CSV. Dołączony arkusz kalkulacyjny kalkulatora przyjmuje wolumin CSV jako dane wejściowe i udostępnia dane ustalania rozmiaru.
W przypadku dowolnej tabeli można dokładnie oszacować ilość danych, które należy zmigrować, wyodrębniając reprezentatywną próbkę danych, taką jak milion wierszy, do nieskompresowanego pliku danych z płaskim zestawem danych ASCII. Następnie użyj rozmiaru tego pliku, aby uzyskać średni rozmiar danych pierwotnych na wiersz. Na koniec pomnóż ten średni rozmiar przez łączną liczbę wierszy w pełnej tabeli, aby nadać nieprzetworzonemu rozmiarowi danych dla tabeli. Użyj tego nieprzetworzonego rozmiaru danych w planowaniu.
Znajdowanie typów danych przy użyciu zapytań SQL
Wykonując zapytanie względem widoku słownika DBA_TAB_COLUMNS danych statycznych Oracle, można określić, które typy danych są używane w schemacie i czy należy zmienić dowolny z tych typów danych. Użyj zapytań SQL, aby znaleźć kolumny w dowolnym schemacie Oracle z typami danych, które nie są mapowe bezpośrednio na typy danych w Azure Synapse. Podobnie można użyć zapytań, aby zliczyć liczbę wystąpień każdego typu danych Oracle, które nie są mapowe bezpośrednio na Azure Synapse. Korzystając z wyników tych zapytań w połączeniu z tabelą porównania typów danych, można określić, które typy danych należy zmienić w środowisku Azure Synapse.
Aby znaleźć kolumny z typami danych, które nie są mapowe na typy danych w Azure Synapse, uruchom następujące zapytanie po zastąpieniu <owner_name> odpowiednim właścicielem schematu:
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;
Aby zliczyć liczbę typów danych, które nie są mapowalne, użyj następującego zapytania:
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;
Firma Microsoft oferuje Asystent migracji do programu SQL Server (SSMA) dla oracle w celu zautomatyzowania migracji magazynów danych ze starszych środowisk Oracle, w tym mapowania typów danych. Usługi Azure Database Migration Services można również używać do planowania i przeprowadzania migracji ze środowisk takich jak Oracle. Zewnętrzni dostawcy oferują również narzędzia i usługi do automatyzacji migracji. Jeśli w środowisku Oracle jest już używane narzędzie ETL innej firmy , możesz użyć tego narzędzia do zaimplementowania dowolnych wymaganych przekształceń danych. W następnej sekcji omówiono migrację istniejących procesów ETL.
Zagadnienia dotyczące migracji ETL
Wstępne decyzje dotyczące migracji programu Oracle ETL
W przypadku przetwarzania ETL/ELT starsze magazyny danych Oracle często używają niestandardowych skryptów, narzędzi ETL innych firm lub kombinacji podejść, które ewoluowały w czasie. Podczas planowania migracji do Azure Synapse określ najlepszy sposób wdrożenia wymaganego przetwarzania ETL/ELT w nowym środowisku, jednocześnie minimalizując koszty i ryzyko.
Porada
Zaplanuj z wyprzedzeniem podejście do migracji ETL i korzystaj z obiektów platformy Azure tam, gdzie jest to konieczne.
Poniższy schemat blokowy zawiera podsumowanie jednego podejścia:
Jak pokazano w schemacie blokowym, pierwszym krokiem jest zawsze utworzenie spisu procesów ETL/ELT, które należy migrować. W przypadku standardowych wbudowanych funkcji platformy Azure niektóre istniejące procesy mogą nie wymagać przeniesienia. Dla celów planowania ważne jest, aby zrozumieć skalę migracji. Następnie rozważ pytania w drzewie decyzyjnym schematu blokowego:
Czy przenieść się na natywną platformę Azure? Twoja odpowiedź zależy od tego, czy przeprowadzasz migrację do całkowicie natywnego środowiska platformy Azure. Jeśli tak, zalecamy ponowne zaprojektowanie przetwarzania ETL przy użyciu potoków i działań w potokach Azure Data Factory lub Azure Synapse.
Za pomocą narzędzia ETL innej firmy? Jeśli nie przenosisz się do całkowicie natywnego środowiska platformy Azure, sprawdź, czy istniejące narzędzie ETL innej firmy jest już używane. W środowisku Oracle może się okazać, że niektóre lub wszystkie operacje przetwarzania ETL są wykonywane przez niestandardowe skrypty przy użyciu narzędzi specyficznych dla firmy Oracle, takich jak Oracle SQL Developer, Oracle SQL*Loader lub Oracle Data Pump. W tym przypadku podejście polega na ponownym zaprojektowaniu przy użyciu Azure Data Factory.
Czy inne firmy obsługują dedykowane pule SQL w ramach Azure Synapse? Zastanów się, czy istnieje duża inwestycja w umiejętności w narzędziu ETL innej firmy, czy też istniejące przepływy pracy i harmonogramy używają tego narzędzia. Jeśli tak, określ, czy narzędzie może efektywnie obsługiwać Azure Synapse jako środowisko docelowe. W idealnym przypadku narzędzie będzie zawierać natywne łączniki, które mogą używać obiektów platformy Azure, takich jak PolyBase lub COPY INTO w celu najbardziej wydajnego ładowania danych. Jednak nawet bez łączników natywnych istnieje ogólnie sposób wywoływania procesów zewnętrznych, takich jak PolyBase lub
COPY INTO, i przekazywania odpowiednich parametrów. W takim przypadku użyj istniejących umiejętności i przepływów pracy z Azure Synapse jako nowe środowisko docelowe.Jeśli używasz integratora danych Oracle (ODI) do przetwarzania ELT, potrzebujesz modułów wiedzy ODI do Azure Synapse. Jeśli te moduły nie są dostępne w organizacji, ale masz interfejs ODI, możesz użyć funkcji ODI do generowania plików prostych. Te pliki proste można następnie przenieść na platformę Azure i pozyskać do Azure Data Lake Storage w celu załadowania ich do Azure Synapse.
Czy uruchamiać narzędzia ETL na platformie Azure? Jeśli zdecydujesz się zachować istniejące narzędzie ETL innej firmy, możesz uruchomić to narzędzie w środowisku platformy Azure (zamiast na istniejącym lokalnym serwerze ETL) i zapewnić usłudze Data Factory obsługę ogólnej aranżacji istniejących przepływów pracy. Dlatego zdecyduj, czy istniejące narzędzie działa zgodnie z rzeczywistym działaniem, czy przenieść je do środowiska platformy Azure, aby uzyskać korzyści związane z kosztami, wydajnością i skalowalnością.
Porada
Rozważ uruchomienie narzędzi ETL na platformie Azure, aby wykorzystać wydajność, skalowalność i korzyści związane z kosztami.
Ponowne inżynieryj istniejące skrypty specyficzne dla firmy Oracle
Jeśli niektóre lub wszystkie istniejące przetwarzanie ETL/ELT magazynu Oracle są obsługiwane przez niestandardowe skrypty korzystające z narzędzi specyficznych dla firmy Oracle, takich jak Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader lub Oracle Data Pump, należy ponownie zakodować te skrypty dla środowiska Azure Synapse. Podobnie, jeśli procesy ETL zostały zaimplementowane przy użyciu procedur składowanych w programie Oracle, należy ponownie zakodować te procesy.
Niektóre elementy procesu ETL można łatwo migrować, na przykład przez proste zbiorcze ładowanie danych do tabeli przejściowej z pliku zewnętrznego. Może być nawet możliwe zautomatyzowanie tych części procesu, na przykład przy użyciu Azure Synapse COPY INTO lub technologii PolyBase zamiast programu SQL*Loader. Inne części procesu, które zawierają dowolne złożone procedury SQL i/lub składowane, zajmie więcej czasu, aby ponownie wykonać inżyniera.
Porada
Spis zadań ETL do zmigrowania powinien zawierać skrypty i procedury składowane.
Jednym ze sposobów testowania bazy danych Oracle SQL pod kątem zgodności z Azure Synapse jest przechwycenie kilku reprezentatywnych instrukcji SQL z sprzężenia bazy danych Oracle v$active_session_history i v$sql uzyskanie sql_textprefiksu tych zapytań za pomocą EXPLAINpolecenia . Zakładając, że w Azure Synapse jest migrowany model danych podobny do podobnych, uruchom te EXPLAIN instrukcje w Azure Synapse. Wszystkie niezgodne bazy danych SQL spowodują wystąpienie błędu. Te informacje umożliwiają określenie skali zadania odzyskiwania.
Porada
Użyj polecenia EXPLAIN , aby znaleźć niezgodności SQL.
W najgorszym przypadku może być konieczne ręczne odtwarzanie. Istnieją jednak produkty i usługi dostępne od partnerów firmy Microsoft , które ułatwiają ponowne projektowanie kodu specyficznego dla firmy Oracle.
Porada
Partnerzy oferują produkty i umiejętności pomagające w ponownym inżynierii kodu specyficznego dla oracle.
Korzystanie z istniejących narzędzi ETL innych firm
W wielu przypadkach istniejący starszy system magazynu danych zostanie już wypełniony i obsługiwany przez produkt ETL innej firmy. Zobacz Azure Synapse Analytics data integration partners (Partnerzy integracji danych usługi Azure Synapse Analytics), aby uzyskać listę bieżących partnerów integracji danych firmy Microsoft dla Azure Synapse.
Społeczność Oracle często używa kilku popularnych produktów ETL. W poniższych akapitach omówiono najpopularniejsze narzędzia ETL dla magazynów Oracle. Wszystkie te produkty można uruchamiać na maszynie wirtualnej na platformie Azure i używać ich do odczytywania i zapisywania baz danych i plików platformy Azure.
Porada
Wykorzystanie inwestycji w istniejące narzędzia innych firm w celu zmniejszenia kosztów i ryzyka.
Ładowanie danych z bazy danych Oracle
Opcje dostępne podczas ładowania danych z bazy danych Oracle
Podczas przygotowywania do migracji danych z magazynu danych Oracle zdecyduj, w jaki sposób dane zostaną fizycznie przeniesione z istniejącego środowiska lokalnego do Azure Synapse w chmurze oraz które narzędzia będą używane do przenoszenia i ładowania. Rozważ następujące pytania, które zostały omówione w poniższych sekcjach.
Czy wyodrębnisz dane do plików, czy przeniesiesz je bezpośrednio za pośrednictwem połączenia sieciowego?
Czy będziesz organizować proces z systemu źródłowego, czy ze środowiska docelowego platformy Azure?
Jakich narzędzi użyjesz do automatyzacji procesu migracji i zarządzania nim?
Transfer danych za pośrednictwem plików lub połączenia sieciowego?
Po utworzeniu tabel baz danych do zmigrowania w Azure Synapse można przenieść dane, które wypełniają te tabele ze starszego systemu Oracle i do nowego środowiska. Istnieją dwa podstawowe podejścia:
Wyodrębnianie pliku: wyodrębnianie danych z tabel Oracle do prostych plików rozdzielanych, zwykle w formacie CSV. Dane tabeli można wyodrębnić na kilka sposobów:
- Użyj standardowych narzędzi Oracle, takich jak SQL*Plus, SQL Developer i SQLcl.
- Użyj integratora danych Oracle (ODI), aby wygenerować pliki proste.
- Użyj łącznika Oracle w usłudze Data Factory, aby równolegle zwolnić tabele Oracle w celu umożliwienia ładowania danych według partycji.
- Użyj narzędzia ETL innej firmy .
Przykłady sposobu wyodrębniania danych tabeli Oracle można znaleźć w dodatku do artykułu.
Takie podejście wymaga miejsca, aby wylądować wyodrębnione pliki danych. Miejsce może być lokalne dla źródłowej bazy danych Oracle, jeśli dostępna jest wystarczająca ilość miejsca do magazynowania lub zdalne w Azure Blob Storage. Najlepszą wydajność jest osiągana, gdy plik jest zapisywany lokalnie, ponieważ pozwala to uniknąć narzutów sieciowych.
Aby zminimalizować wymagania dotyczące magazynu i transferu sieciowego, skompresuj wyodrębnione pliki danych przy użyciu narzędzia takiego jak gzip.
Po wyodrębnieniu przenieś pliki proste do Azure Blob Storage. Firma Microsoft oferuje różne opcje przenoszenia dużych ilości danych, w tym:
- Narzędzie AzCopy do przenoszenia plików między siecią do usługi Azure Storage.
- Usługa Azure ExpressRoute do przenoszenia danych zbiorczych za pośrednictwem połączenia z siecią prywatną.
- Usługa Azure Data Box do przenoszenia plików na fizyczne urządzenie magazynujące, które jest dostarczane do centrum danych platformy Azure na potrzeby ładowania.
Aby uzyskać więcej informacji, zobacz Transfer danych do i z platformy Azure.
Bezpośrednie wyodrębnianie i ładowanie w sieci: docelowe środowisko platformy Azure wysyła żądanie wyodrębniania danych, zwykle za pośrednictwem polecenia SQL, do starszego systemu Oracle w celu wyodrębnienia danych. Wyniki są wysyłane przez sieć i ładowane bezpośrednio do Azure Synapse, bez konieczności rozmieszczania danych do plików pośrednich. Czynnikiem ograniczającym w tym scenariuszu jest zwykle przepustowość połączenia sieciowego między bazą danych Oracle a środowiskiem platformy Azure. W przypadku wyjątkowo dużych ilości danych takie podejście może nie być praktyczne.
Porada
Zapoznaj się z woluminami danych, które mają zostać zmigrowane, i dostępną przepustowością sieci, ponieważ te czynniki wpływają na decyzję dotyczącą podejścia do migracji.
Istnieje również podejście hybrydowe, które korzysta z obu metod. Na przykład można użyć metody wyodrębniania sieci bezpośredniej dla mniejszych tabel wymiarów i przykładów większych tabel faktów, aby szybko zapewnić środowisko testowe w Azure Synapse. W przypadku dużych tabel faktów historycznych można użyć metody wyodrębniania i transferu plików przy użyciu usługi Azure Data Box.
Orkiestruj z bazy danych Oracle lub platformy Azure?
Zalecanym podejściem podczas przechodzenia do Azure Synapse jest organizowanie wyodrębniania i ładowania danych ze środowiska platformy Azure przy użyciu protokołu SSMA lub usługi Data Factory. Użyj skojarzonych narzędzi, takich jak PolyBase lub COPY INTO, w celu najbardziej wydajnego ładowania danych. Takie podejście korzysta z wbudowanych funkcji platformy Azure i zmniejsza nakład pracy na tworzenie potoków ładowania danych wielokrotnego użytku. Do zautomatyzowania procesu migracji można użyć potoków ładowania danych opartych na metadanych.
Zalecane podejście minimalizuje również wydajność w istniejącym środowisku Oracle podczas procesu ładowania danych, ponieważ proces zarządzania i ładowania działa na platformie Azure.
Istniejące narzędzia do migracji danych
Przekształcanie i przenoszenie danych to podstawowa funkcja wszystkich produktów ETL. Jeśli narzędzie do migracji danych jest już używane w istniejącym środowisku Oracle i obsługuje Azure Synapse jako środowisko docelowe, rozważ użycie tego narzędzia w celu uproszczenia migracji danych.
Nawet jeśli istniejące narzędzie ETL nie jest dostępne, partnerzy integracji danych usługi Azure Synapse Analytics oferują narzędzia ETL upraszczające zadanie migracji danych.
Jeśli na koniec planujesz użyć narzędzia ETL, rozważ uruchomienie tego narzędzia w środowisku platformy Azure, aby skorzystać z wydajności, skalowalności i kosztów chmury platformy Azure. Takie podejście zwalnia również zasoby w centrum danych Oracle.
Podsumowanie
Podsumowując, nasze zalecenia dotyczące migrowania danych i skojarzonych procesów ETL z oracle do Azure Synapse są następujące:
Zaplanuj z wyprzedzeniem, aby zapewnić pomyślne ćwiczenie dotyczące migracji.
Utwórz szczegółowy spis danych i procesów, które mają być migrowane tak szybko, jak to możliwe.
Użyj systemowych metadanych i plików dziennika, aby uzyskać dokładną wiedzę na temat danych i użycia procesów. Nie polegaj na dokumentacji, ponieważ może być nieaktualna.
Zapoznaj się z woluminami danych, które mają być migrowane, oraz przepustowością sieci między lokalnym centrum danych a środowiskami chmury platformy Azure.
Rozważ użycie wystąpienia Oracle na maszynie wirtualnej platformy Azure jako kamienia krokowego w celu odciążania migracji ze starszego środowiska Oracle.
Użyj standardowych wbudowanych funkcji platformy Azure, aby zminimalizować obciążenie migracji.
Zidentyfikuj i poznaj najbardziej wydajne narzędzia do wyodrębniania i ładowania danych zarówno w środowiskach Oracle, jak i Azure. Użyj odpowiednich narzędzi w każdej fazie procesu.
Użyj obiektów platformy Azure, takich jak Data Factory, aby zorganizować i zautomatyzować proces migracji, jednocześnie minimalizując wpływ na system Oracle.
Dodatek: Przykłady technik wyodrębniania danych Oracle
Możesz użyć kilku technik wyodrębniania danych Oracle podczas migracji z bazy danych Oracle do Azure Synapse. W następnych sekcjach pokazano, jak wyodrębnić dane Oracle przy użyciu programu Oracle SQL Developer i łącznika Oracle w usłudze Data Factory.
Korzystanie z programu Oracle SQL Developer do wyodrębniania danych
Interfejs użytkownika programu Oracle SQL Developer umożliwia eksportowanie danych tabeli do wielu formatów, w tym plików CSV, jak pokazano na poniższym zrzucie ekranu:
Inne opcje eksportu obejmują dane JSON i XML. Możesz użyć interfejsu użytkownika, aby dodać zestaw nazw tabel do "koszyka", a następnie zastosować eksport do całego zestawu w koszyku:
Możesz również użyć wiersza polecenia oracle SQL Developer (SQLcl) do wyeksportowania danych Oracle. Ta opcja obsługuje automatyzację przy użyciu skryptu powłoki.
W przypadku stosunkowo małych tabel można znaleźć tę technikę przydatną, jeśli wystąpią problemy z wyodrębnianiem danych za pośrednictwem bezpośredniego połączenia.
Używanie łącznika Oracle w Azure Data Factory na potrzeby kopiowania równoległego
Łącznik Oracle w usłudze Data Factory umożliwia równoległe zwalnianie dużych tabel Oracle. Łącznik Oracle zapewnia wbudowane partycjonowanie danych w celu równoległego kopiowania danych z bazy danych Oracle. Opcje partycjonowania danych można znaleźć na karcie Źródło działania kopiowania.
Aby uzyskać informacje na temat konfigurowania łącznika Oracle na potrzeby kopiowania równoległego, zobacz Kopiowanie równoległe z bazy danych Oracle.
Aby uzyskać więcej informacji na temat wydajności i skalowalności działania kopiowania w usłudze Data Factory, zobacz działanie Kopiuj przewodnik dotyczący wydajności i skalowalności.
Następne kroki
Aby dowiedzieć się więcej o operacjach dostępu do zabezpieczeń, zobacz następny artykuł z tej serii: Zabezpieczenia, dostęp i operacje migracji Oracle.