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 bazy danych 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
Podczas migrowania danych, ETL i ładowania ze starszego magazynu danych i składnic danych Oracle do usługi Azure Synapse należy wziąć pod uwagę wiele czynników.
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 związane z danymi:
Czy nieużywane struktury tabel powinny być migrowane?
Jakie jest najlepsze podejście do migracji w celu zminimalizowania ryzyka i wpływu na użytkowników?
Podczas migrowania składnic danych: pozostawanie fizyczne lub wirtualne?
W następnych sekcjach omówiono te kwestie 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, mogą być zarchiwizowane, a nie migrowane, 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 została ostatnio użyta — 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 aktywnej sesji, której można użyć do określenia, kiedy tabela była ostatnio uzyskiwana.
Napiwek
W starszych systemach nie jest niczym niezwykłym, aby tabele stały się nadmiarowe w miarę upływu czasu — 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 zająć trochę czasu, jeśli uruchomiono wiele zapytań.
Jakie jest najlepsze podejście do migracji w celu zminimalizowania ryzyka i wpływu na użytkowników?
Często pojawia się to pytanie, 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 wiąże się z wyższym ryzykiem, ponieważ zmienia jednocześnie wiele czynników, co utrudnia porównywanie wyników starego systemu w porównaniu z nowym. Wprowadzenie tutaj zmian w modelu danych może również mieć wpływ na nadrzędne lub podrzędne zadania ETL do innych systemów. 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 jako do usługi Azure Synapse, a nie ponownej 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 na potrzeby jednorazowych zadań ponownej inżynierii.
Napiwek
Najpierw przeprowadź migrację istniejącego modelu, nawet jeśli w przyszłości zaplanowano zmianę modelu danych.
Migracja składnic danych: pozostać fizycznym lub wirtualnym?
W starszych środowiskach magazynu danych Oracle często opisano tworzenie wielu składnic danych, które mają strukturę zapewniającą dobrą wydajność dla zapytań samoobsługowych i raportów ad hoc dla danego działu lub funkcji biznesowej w organizacji. Składnica danych zwykle składa się z podzbioru 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 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 postaci użytecznej, nawet jeśli bazowy model danych magazynu jest czymś innym, takim jak magazyn danych.
Do implementowania niezawodnych systemów 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, oraz 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 martynie będą aktualne tylko jako ostatnia operacja odświeżania, dlatego mogą być nieodpowiednie dla wysoce niestabilnych pulpitów nawigacyjnych danych.
Napiwek
Wirtualizacja składnic danych może zaoszczędzić na magazynie i przetwarzaniu zasobów.
Dzięki pojawieniu się skalowalnych architektur MPP o niższych kosztach, takich jak usługa Azure Synapse i ich nieodłączne cechy 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 do głównego magazynu 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. Implementując logikę agregacji i sprzężenia w warstwie wirtualizacji oraz prezentując zewnętrzne narzędzia raportowania za pośrednictwem zwirtualizowanego widoku, przetwarzanie wymagane do utworzenia tych widoków jest wypychane 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 implementują teraz inteligentne techniki buforowania w celu ograniczenia tej różnicy.
Napiwek
Wydajność i skalowalność usługi Azure Synapse umożliwia wirtualizację bez poświęcania wydajności.
Migracja danych z bazy danych Oracle
Poznaj swoje dane
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.
Poniższe 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 skryptów spisu Oracle. Narzędzie Oracle Inventory Script Artifacts zawiera zapytanie PL/SQL, które uzyskuje dostęp do tabel systemowych Oracle i udostępnia 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 pobiera plik CSV jako dane wejściowe i udostępnia dane 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 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ć tabeli nieprzetworzone dane. 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ą mapowania bezpośrednio na typy danych w usłudze Azure Synapse. Podobnie można użyć zapytań, aby zliczyć liczbę wystąpień każdego typu danych Oracle, które nie są mapujące bezpośrednio na usługę 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 usługi Azure Synapse.
Aby znaleźć kolumny z typami danych, które nie są mapowe na typy danych w usłudze 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ę niemapowalnych typów danych, 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 firmy Oracle w celu zautomatyzowania migracji magazynów danych ze starszych środowisk Oracle, w tym mapowania typów danych. Usługi Azure Database Migration Services umożliwiają również planowanie i przeprowadzanie migracji ze środowisk takich jak Oracle. Zewnętrzni dostawcy oferują również narzędzia i usługi do automatyzacji migracji. Jeśli narzędzie ETL innej firmy jest już używane w środowisku Oracle, możesz użyć tego narzędzia do zaimplementowania wszelkich 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 metod, które ewoluowały wraz z upływem czasu. Podczas planowania migracji do usługi Azure Synapse określ najlepszy sposób wdrożenia wymaganego przetwarzania ETL/ELT w nowym środowisku, jednocześnie minimalizując koszt i ryzyko.
Napiwek
Zaplanuj z wyprzedzeniem podejście do migracji ETL i w razie potrzeby skorzystaj z obiektów platformy Azure.
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ć. Dzięki standardowym wbudowanym funkcjom platformy Azure niektóre istniejące procesy mogą nie wymagać przeniesienia. Dla celów planowania ważne jest, aby zrozumieć skalę migracji. Następnie zastanów się nad pytaniami 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 usługi 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 procesy przetwarzania ETL są wykonywane przez niestandardowe skrypty przy użyciu narzędzi specyficznych dla oracle, takich jak Oracle SQL Developer, Oracle SQL*Loader lub Oracle Data Pump. W tym przypadku należy ponownie zaprojektować usługę Azure Data Factory.
Czy inna firma obsługuje dedykowane pule SQL w usłudze 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, ustal, czy narzędzie może efektywnie obsługiwać usługę Azure Synapse jako środowisko docelowe. W idealnym przypadku narzędzie będzie zawierać łączniki natywne, 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 INTOi przekazywania odpowiednich parametrów. W takim przypadku użyj istniejących umiejętności i przepływów pracy z usługą Azure Synapse jako nowym środowiskiem docelowym.Jeśli używasz integratora danych Oracle (ODI) do przetwarzania ELT, potrzebujesz modułów wiedzy ODI dla usługi 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 usługi Azure Data Lake Storage w celu załadowania ich do usługi 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ą.
Napiwek
Rozważ uruchomienie narzędzi ETL na platformie Azure, aby wykorzystać korzyści związane z wydajnością, skalowalnością i 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 oracle, takich jak Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader lub Oracle Data Pump, należy ponownie zakodować te skrypty dla środowiska usługi 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 usługi Azure Synapse COPY INTO lub 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 na ponowne zaprojektowanie.
Napiwek
Spis zadań ETL do zmigrowania powinien obejmować skrypty i procedury składowane.
Jednym ze sposobów testowania bazy danych Oracle SQL pod kątem zgodności z usługą Azure Synapse jest przechwycenie kilku reprezentatywnych instrukcji SQL z przyłączenia do bazy danych Oracle v$active_session_history i v$sql pobranie sql_textprefiksu , a następnie prefiks tych zapytań za pomocą EXPLAINpolecenia . Przy założeniu, że model danych podobny do podobnego w usłudze Azure Synapse, uruchom te EXPLAIN instrukcje w usłudze Azure Synapse. Wszystkie niezgodne bazy danych SQL spowodują wystąpienie błędu. Te informacje umożliwiają określenie skali zadania recodowania.
Napiwek
Użyj EXPLAIN polecenia , 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, aby pomóc w ponownym inżynierii kodu specyficznego dla firmy Oracle.
Napiwek
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 zapoznać się z listą bieżących partnerów integracji danych firmy Microsoft dla usługi 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.
Napiwek
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 usługi Azure Synapse w chmurze i które narzędzia będą używane do przeprowadzania transferu 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 zaaranżujesz proces z systemu źródłowego, czy ze środowiska docelowego platformy Azure?
Które narzędzia będą używane 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 usłudze 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, aby umożliwić ładowanie danych według partycji.
- Użyj narzędzia ETL innej firmy.
Przykłady 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 wystarczająca ilość miejsca jest dostępna lub zdalna w usłudze Azure Blob Storage. Najlepszą wydajność można osiągnąć, gdy plik jest zapisywany lokalnie, ponieważ pozwala to uniknąć narzutów sieciowych.
Aby zminimalizować wymagania dotyczące magazynu i transferu sieciowego, należy skompresować wyodrębnione pliki danych przy użyciu narzędzia takiego jak gzip.
Po wyodrębnieniu przenieś pliki proste do usługi 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 sieciowego prywatnego.
- Usługa Azure Data Box umożliwia przenoszenie 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 między sieciami: docelowe środowisko platformy Azure wysyła żądanie wyodrębniania danych, zwykle za pomocą polecenia SQL, do starszego systemu Oracle w celu wyodrębnienia danych. Wyniki są wysyłane przez sieć i ładowane bezpośrednio do usługi Azure Synapse, bez konieczności przechodzenia 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.
Napiwek
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 usłudze 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 platformy Oracle lub platformy Azure?
Zalecane podejście podczas przechodzenia do usługi Azure Synapse polega na organizowaniu wyodrębniania i ładowania danych ze środowiska platformy Azure przy użyciu programu SSMA lub 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 możliwości platformy Azure i zmniejsza nakład pracy na tworzenie potoków ładowania danych wielokrotnego użytku. Potoki ładowania danych oparte na metadanych umożliwiają zautomatyzowanie procesu migracji.
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 usługę 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 istnieje, partnerzy integracji danych usługi Azure Synapse Analytics oferują narzędzia ETL, aby uprościć 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 bazy danych Oracle do usługi Azure Synapse są następujące:
Zaplanuj z wyprzedzeniem pomyślne ćwiczenie migracji.
Utwórz szczegółowy spis danych i procesów, które mają zostać zmigrowane tak szybko, jak to możliwe.
Użyj systemowych metadanych i plików dziennika, aby uzyskać dokładne informacje na temat danych i użycia procesów. Nie należy polegać na dokumentacji, ponieważ może być nieaktualna.
Poznaj woluminy danych, które mają zostać zmigrowane, oraz przepustowość sieci między lokalnym centrum danych i ś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.
Identyfikowanie i zrozumienie najbardziej wydajnych narzędzi do wyodrębniania i ładowania danych w środowiskach Oracle 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, aby wyodrębnić dane Oracle podczas migracji z bazy danych Oracle do usługi 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.
Wyodrębnianie danych za pomocą programu Oracle SQL Developer
Interfejs użytkownika programu Oracle SQL Developer umożliwia eksportowanie danych tabeli do wielu formatów, w tym csv, jak pokazano na poniższym zrzucie ekranu:
Inne opcje eksportu obejmują pliki 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:
Do eksportowania danych Oracle można również użyć wiersza polecenia programu Oracle SQL Developer (SQLcl). Ta opcja obsługuje automatyzację przy użyciu skryptu powłoki.
W przypadku stosunkowo małych tabel ta technika może być przydatna, jeśli wystąpią problemy z wyodrębnianiem danych za pośrednictwem połączenia bezpośredniego.
Używanie łącznika Oracle w usłudze Azure Data Factory do 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 Parallel copy from Oracle (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 na temat operacji dostępu do zabezpieczeń, zobacz następny artykuł z tej serii: Zabezpieczenia, dostęp i operacje migracji oracle.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla