Projektowanie i wydajność migracji oracle

Ten artykuł jest jedną z siedmiu części 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 projektowania i wydajności.

Omówienie

Ze względu na koszt i złożoność konserwacji i uaktualniania starszych lokalnych środowisk Oracle wielu istniejących użytkowników Oracle chce skorzystać z innowacji oferowanych przez nowoczesne środowiska chmurowe. Środowiska chmury typu infrastruktura jako usługa (IaaS) i platforma jako usługa (PaaS) umożliwiają delegowanie zadań, takich jak konserwacja infrastruktury i programowanie platformy dla dostawcy chmury.

Napiwek

Nie tylko baza danych — środowisko platformy Azure zawiera kompleksowy zestaw funkcji i narzędzi.

Mimo że bazy danych Oracle i Azure Synapse Analytics to bazy danych SQL, które używają technik masowego przetwarzania równoległego (MPP) w celu osiągnięcia wysokiej wydajności zapytań na wyjątkowo dużych woluminach danych, istnieją pewne podstawowe różnice w podejściu:

• Starsze systemy Oracle są często instalowane lokalnie i używają stosunkowo kosztownego sprzętu, podczas gdy usługa Azure Synapse jest oparta na chmurze i korzysta z usługi Azure Storage i zasobów obliczeniowych.

• Uaktualnianie konfiguracji oracle to główne zadanie obejmujące dodatkowy sprzęt fizyczny i potencjalnie długotrwałą ponowną konfigurację bazy danych lub zrzut i ponowne ładowanie. Ponieważ zasoby magazynu i zasobów obliczeniowych są oddzielne w środowisku platformy Azure i mają elastyczne możliwości skalowania, te zasoby można skalować w górę lub w dół niezależnie.

• W razie potrzeby możesz wstrzymać lub zmienić rozmiar usługi Azure Synapse, aby zmniejszyć wykorzystanie zasobów i koszty.

Platforma Microsoft Azure to globalnie dostępne, wysoce bezpieczne, skalowalne środowisko w chmurze, które obejmuje usługę Azure Synapse i ekosystem pomocniczych narzędzi i możliwości. Następny diagram zawiera podsumowanie ekosystemu usługi Azure Synapse.

Usługa Azure Synapse zapewnia najlepszą wydajność relacyjnej bazy danych przy użyciu technik, takich jak MPP i automatyczne buforowanie w pamięci. Wyniki tych technik można zobaczyć w niezależnych testach porównawczych, takich jak ostatnio uruchamiany przez GigaOm, który porównuje usługę Azure Synapse z innymi popularnymi ofertami magazynu danych w chmurze. Klienci migrujący do środowiska usługi Azure Synapse widzą wiele korzyści, w tym:

• Zwiększona wydajność i cena/wydajność.

• Zwiększona elastyczność i krótszy czas na wartość.

• Szybsze wdrażanie serwera i tworzenie aplikacji.

• Elastyczna skalowalność — płacisz tylko za rzeczywiste użycie.

• Ulepszone zabezpieczenia/zgodność.

• Zmniejszono koszty magazynowania i odzyskiwania po awarii.

• Niższy ogólny koszt posiadania, lepsza kontrola kosztów i usprawnione wydatki operacyjne (OPEX).

Aby zmaksymalizować te korzyści, zmigruj nowe lub istniejące dane i aplikacje do platformy Azure Synapse. W wielu organizacjach migracja obejmuje przeniesienie istniejącego magazynu danych ze starszej platformy lokalnej, takiej jak Oracle, do usługi Azure Synapse. Na wysokim poziomie proces migracji obejmuje następujące kroki:

    Przygotowanie 🡆

• Zdefiniuj zakres — co ma zostać zmigrowane.

• Tworzenie spisu danych i procesów migracji.

• Zdefiniuj zmiany modelu danych (jeśli istnieją).

• Zdefiniuj mechanizm wyodrębniania danych źródłowych.

• Zidentyfikuj odpowiednie narzędzia i funkcje platformy Azure oraz inne firmy, które mają być używane.

• Szkolenie pracowników na początku nowej platformy.

• Skonfiguruj platformę docelową platformy Azure.

    Migracja 🡆

• Zacznij od małych i prostych.

• Automatyzuj wszędzie tam, gdzie to możliwe.

• Skorzystaj z wbudowanych narzędzi i funkcji platformy Azure, aby zmniejszyć nakład pracy nad migracją.

• Migrowanie metadanych dla tabel i widoków.

• Migrowanie danych historycznych do utrzymania.

• Migrowanie lub refaktoryzacja procedur składowanych i procesów biznesowych.

• Migrowanie lub refaktoryzacja procesów ładowania przyrostowego ETL/ELT.

    Po migracji

• Monitoruj i dokumentuj wszystkie etapy procesu.

• Użyj zdobytego doświadczenia, aby utworzyć szablon na potrzeby przyszłych migracji.

• W razie potrzeby przeprojektuj ponownie model danych (przy użyciu nowej wydajności i skalowalności platformy).

• Testowanie aplikacji i narzędzi do wykonywania zapytań.

• Testowanie porównawcze i optymalizowanie wydajności zapytań.

Ten artykuł zawiera ogólne informacje i wytyczne dotyczące optymalizacji wydajności podczas migrowania magazynu danych z istniejącego środowiska Oracle do usługi Azure Synapse. Celem optymalizacji wydajności jest osiągnięcie takiej samej lub lepszej wydajności magazynu danych w usłudze Azure Synapse po migracji.

Uwagi dotyczące projektowania

Zakres migracji

Podczas przygotowywania do migracji ze środowiska Oracle należy wziąć pod uwagę następujące opcje migracji.

Wybieranie obciążenia na potrzeby migracji początkowej

Zazwyczaj starsze środowiska Oracle ewoluowały wraz z upływem czasu, aby obejmować wiele obszarów tematycznych i mieszanych obciążeń. Podczas wybierania miejsca rozpoczęcia projektu migracji wybierz obszar, w którym będzie można wykonywać następujące zadania:

• Udowodnij rentowność migracji do usługi Azure Synapse, szybko zapewniając korzyści wynikające z nowego środowiska.

• Zezwól swoim pracownikom technicznym na uzyskanie odpowiedniego doświadczenia z procesami i narzędziami, których będą używać podczas migrowania innych obszarów.

• Utwórz szablon do dalszych migracji specyficznych dla źródłowego środowiska Oracle oraz bieżących narzędzi i procesów, które już istnieją.

Dobry kandydat na początkową migrację z bazy danych Oracle wsparcie środowiska poprzednich elementów i:

• Implementuje obciążenie analizy biznesowej/analizy, a nie obciążenie przetwarzania transakcji online (OLTP).

• Ma model danych, taki jak schemat gwiazdy lub płatka śniegu, który można migrować z minimalnymi modyfikacjami.

Napiwek

Utwórz spis obiektów, które muszą zostać zmigrowane, i udokumentować proces migracji.

Ilość migrowanych danych w początkowej migracji powinna być wystarczająco duża, aby zademonstrować możliwości i zalety środowiska usługi Azure Synapse, ale nie zbyt duże, aby szybko zademonstrować wartość. Typowy jest rozmiar zakresu 1–10 terabajtów.

Wstępne podejście do projektu migracji polega na zminimalizowaniu ryzyka, nakładu pracy i czasu potrzebnego, aby szybko zobaczyć korzyści środowiska chmury platformy Azure. Poniższe podejścia ograniczają zakres początkowej migracji tylko do składnic danych i nie dotyczą szerszych aspektów migracji, takich jak migracja ETL i migracja danych historycznych. Można jednak rozwiązać te aspekty w późniejszych fazach projektu, gdy zmigrowana warstwa składnicy danych jest wypełniana z danymi i wymaganymi procesami kompilacji.

Migracja metodą "lift and shift" a podejście etapowe

Ogólnie rzecz biorąc, istnieją dwa typy migracji niezależnie od celu i zakresu planowanej migracji: lift and shift as-is i podejście etapowe, które obejmuje zmiany.

Migrowanie metodą „lift-and-shift”

W przypadku migracji metodą "lift and shift" istniejący model danych, taki jak schemat gwiazdy, jest migrowany bez zmian do nowej platformy Azure Synapse. Takie podejście minimalizuje ryzyko i czas migracji, skracając pracę wymaganą do realizacji korzyści związanych z przejściem do środowiska chmury platformy Azure. Migracja metodą "lift and shift" jest dobrym rozwiązaniem w następujących scenariuszach:

• Masz istniejące środowisko Oracle z pojedynczą składnicą danych do migracji lub
• Masz istniejące środowisko Oracle z danymi, które są już w dobrze zaprojektowanym schemacie gwiazdy lub płatka śniegu lub
• Czas i presja kosztów jest niewystarczająca, aby przejść do nowoczesnego środowiska chmury.

Napiwek

Lift and shift to dobry punkt wyjścia, nawet jeśli kolejne fazy implementują zmiany w modelu danych.

Podejście etapowe, które obejmuje zmiany

Jeśli starszy magazyn danych ewoluował przez długi czas, może być konieczne ponowne zaprojektowanie go w celu zachowania wymaganych poziomów wydajności. Konieczne może być również ponowne tworzenie inżynierów w celu obsługi nowych danych, takich jak strumienie Internetu rzeczy (IoT). W ramach procesu ponownej inżynierii przeprowadź migrację do usługi Azure Synapse, aby uzyskać korzyści ze skalowalnego środowiska w chmurze. Migracja może obejmować zmianę bazowego modelu danych, na przykład przejście z modelu Inmon do magazynu danych.

Firma Microsoft zaleca przeniesienie istniejącego modelu danych zgodnie z oczekiwaniami na platformę Azure oraz użycie wydajności i elastyczności środowiska platformy Azure w celu zastosowania zmian ponownej inżynierii. Dzięki temu możesz użyć możliwości platformy Azure, aby wprowadzić zmiany bez wpływu na istniejący system źródłowy.

Implementowanie migracji opartej na metadanych za pomocą obiektów firmy Microsoft

Proces migracji można zautomatyzować i zorganizować przy użyciu możliwości środowiska platformy Azure. Takie podejście minimalizuje osiągnięcie wydajności w istniejącym środowisku Oracle, które może już działać blisko pojemności.

Asystent migracji do programu SQL Server (SSMA) dla oracle może zautomatyzować wiele części procesu migracji, w tym w niektórych przypadkach funkcje i kod proceduralny. Usługa SSMA obsługuje usługę Azure Synapse jako środowisko docelowe.

Program SSMA for Oracle może pomóc w migracji magazynu danych Oracle lub składnicy danych do usługi Azure Synapse. Program SSMA został zaprojektowany w celu zautomatyzowania procesu migrowania tabel, widoków i danych z istniejącego środowiska Oracle.

Azure Data Factory to oparta na chmurze usługa integracji danych, która obsługuje tworzenie opartych na danych przepływów pracy w chmurze, które organizują i automatyzują przenoszenie danych i przekształcanie danych. Za pomocą usługi Data Factory można tworzyć i planować oparte na danych przepływy pracy (potoki), które pozyskują dane z różnych magazynów danych. Usługa Data Factory może przetwarzać i przekształcać dane przy użyciu usług obliczeniowych, takich jak Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics i Azure Machine Learning.

Usługa Data Factory może służyć do migrowania danych w źródle do miejsca docelowego usługi Azure SQL. To przenoszenie danych w trybie offline pomaga znacznie zmniejszyć czas przestoju migracji.

Usługi Azure Database Migration Services mogą ułatwić planowanie i przeprowadzanie migracji ze środowisk, takich jak Oracle.

Podczas planowania używania obiektów platformy Azure do zarządzania procesem migracji utwórz metadane zawierające listę wszystkich tabel danych, które mają zostać zmigrowane i ich lokalizację.

Różnice między projektami Oracle i Azure Synapse

Jak wspomniano wcześniej, istnieją pewne podstawowe różnice w podejściu między bazami danych Oracle i Azure Synapse Analytics. Program SSMA dla oracle nie tylko pomaga wypełnić te luki, ale także automatyzować migrację. Chociaż funkcja SSMA nie jest najbardziej wydajnym podejściem do bardzo dużych ilości danych, jest przydatna w przypadku mniejszych tabel.

Wiele baz danych a pojedynczych baz danych i schematów

Środowisko Oracle często zawiera wiele oddzielnych baz danych. Na przykład mogą istnieć oddzielne bazy danych: pozyskiwanie danych i tabele przejściowe, podstawowe tabele magazynu i składnice danych — czasami nazywane warstwą semantyczną. Przetwarzanie w potokach ETL lub ELT może implementować sprzężenia między bazami danych i przenosić dane między oddzielnymi bazami danych.

Z kolei środowisko usługi Azure Synapse zawiera pojedynczą bazę danych i używa schematów do oddzielania tabel w logicznie oddzielne grupy. Zalecamy użycie serii schematów w docelowej bazie danych usługi Azure Synapse w celu naśladowania oddzielnych baz danych migrowanych ze środowiska Oracle. Jeśli środowisko Oracle używa już schematów, może być konieczne użycie nowej konwencji nazewnictwa podczas przenoszenia istniejących tabel i widoków Oracle do nowego środowiska. Możesz na przykład połączyć istniejące nazwy schematów i tabel Oracle z nową nazwą tabeli usługi Azure Synapse i użyć nazw schematów w nowym środowisku, aby zachować oryginalne oddzielne nazwy baz danych. Mimo że można używać widoków SQL na podstawie bazowych tabel do obsługi struktur logicznych, istnieją potencjalne wady tego podejścia:

• Widoki w usłudze Azure Synapse są tylko do odczytu, więc wszystkie aktualizacje danych muszą odbywać się w podstawowych tabelach podstawowych.

• Może już istnieć co najmniej jedna warstwa widoków i dodanie dodatkowej warstwy widoków może mieć wpływ na wydajność.

Napiwek

Połącz wiele baz danych w jedną bazę danych w usłudze Azure Synapse i użyj nazw schematów, aby logicznie oddzielić tabele.

Zagadnienia dotyczące tabeli

Podczas migracji tabel między różnymi środowiskami zazwyczaj tylko nieprzetworzone dane i metadane, które opisują je fizycznie. Inne elementy bazy danych z systemu źródłowego, takie jak indeksy, zwykle nie są migrowane, ponieważ mogą być niepotrzebne lub zaimplementowane inaczej w nowym środowisku.

Optymalizacje wydajności w środowisku źródłowym, takie jak indeksy, wskazują, gdzie można dodać optymalizację wydajności w nowym środowisku. Jeśli na przykład zapytania w źródłowym środowisku Oracle często używają indeksów mapowanych bitowo, sugeruje to, że indeks nieklasowany powinien zostać utworzony w usłudze Azure Synapse. Inne natywne techniki optymalizacji wydajności, takie jak replikacja tabel, mogą być bardziej odpowiednie niż proste tworzenie indeksów podobnych do podobnych. Program SSMA for Oracle może służyć do udostępniania zaleceń dotyczących migracji dotyczących dystrybucji i indeksowania tabel.

Napiwek

Istniejące indeksy wskazują kandydatów do indeksowania w zmigrowanym magazynie.

Nieobsługiwane typy obiektów bazy danych Oracle

Funkcje specyficzne dla programu Oracle mogą być często zastępowane przez funkcje usługi Azure Synapse. Jednak niektóre obiekty bazy danych Oracle nie są bezpośrednio obsługiwane w usłudze Azure Synapse. Poniższa lista nieobsługiwanych obiektów bazy danych Oracle zawiera opis sposobu osiągnięcia równoważnych funkcji w usłudze Azure Synapse.

• Różne opcje indeksowania: w programie Oracle kilka opcji indeksowania, takich jak indeksy mapowane bitowo, indeksy oparte na funkcjach i indeksy domeny, nie mają bezpośredniego odpowiednika w usłudze Azure Synapse.

  Możesz dowiedzieć się, które kolumny są indeksowane, a typ indeksu według:

  • Wykonywanie zapytań dotyczących tabel i widoków wykazu systemu, takich jak ALL_INDEXES, DBA_INDEXES, USER_INDEXESi DBA_IND_COL. Możesz użyć wbudowanych zapytań w programie Oracle SQL Developer, jak pokazano na poniższym zrzucie ekranu.

    

    Możesz też uruchomić następujące zapytanie, aby znaleźć wszystkie indeksy danego typu:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Wykonywanie zapytań względem dba_index_usage widoków lub v$object_usage podczas włączania monitorowania. Możesz wykonywać zapytania dotyczące tych widoków w programie Oracle SQL Developer, jak pokazano na poniższym zrzucie ekranu.

    

  Indeksy oparte na funkcjach, w których indeks zawiera wynik funkcji w kolumnach danych bazowych, nie mają bezpośredniego odpowiednika w usłudze Azure Synapse. Zalecamy, aby najpierw przeprowadzić migrację danych, a następnie w usłudze Azure Synapse uruchamiać zapytania Oracle, które używają indeksów opartych na funkcjach, aby ocenić wydajność. Jeśli wydajność tych zapytań w usłudze Azure Synapse nie jest akceptowalna, rozważ utworzenie kolumny zawierającej wstępnie obliczoną wartość, a następnie zaindeksuj ją.

  Podczas konfigurowania środowiska usługi Azure Synapse warto zaimplementować tylko indeksy w użyciu. Usługa Azure Synapse obecnie obsługuje typy indeksów pokazane tutaj:

  

  Funkcje usługi Azure Synapse, takie jak równoległe przetwarzanie zapytań i buforowanie danych i wyników w pamięci, sprawiają, że w celu osiągnięcia celów wydajności prawdopodobnie jest wymagana mniejsza liczba indeksów. Zalecamy użycie następujących typów indeksów w usłudze Azure Synapse:

  • Klastrowane indeksy magazynu kolumn: jeśli nie określono żadnych opcji indeksu dla tabeli, usługa Azure Synapse domyślnie tworzy indeks klastrowanego magazynu kolumn. Tabele klastrowanego magazynu kolumn oferują najwyższy poziom kompresji danych, najlepszą ogólną wydajność zapytań i ogólnie przewyższają indeks klastrowany lub tabele stert. Indeks klastrowanego magazynu kolumn jest zwykle najlepszym wyborem dla dużych tabel. Podczas tworzenia tabeli wybierz grupowany magazyn kolumn, jeśli nie masz pewności, jak indeksować tabelę. Istnieją jednak pewne scenariusze, w których klastrowane indeksy magazynu kolumn nie są najlepszą opcją:

    • Tabele ze wstępnie posortowanymi danymi dla kluczy sortowania mogą korzystać z eliminacji segmentu włączonej przez uporządkowane indeksy klastrowanego magazynu kolumn.
    • Tabele z typami danych varchar(max), nvarchar(max) lub varbinary(max), ponieważ indeks klastrowanego magazynu kolumn nie obsługuje tych typów danych. Zamiast tego rozważ użycie sterta lub indeksu klastrowanego.
    • Tabele z danymi przejściowymi, ponieważ tabele magazynu kolumn mogą być mniej wydajne niż sterta lub tabele tymczasowe.
    • Małe tabele z mniej niż 100 milionami wierszy. Zamiast tego rozważ użycie tabel stert.

  • Uporządkowane indeksy klastrowanego magazynu kolumn: dzięki włączeniu wydajnej eliminacji segmentów uporządkowane indeksy magazynu kolumn klastrowanych w dedykowanych pulach SQL usługi Azure Synapse zapewniają znacznie szybszą wydajność, pomijając duże ilości uporządkowanych danych, które nie są zgodne z predykatem zapytania. Ładowanie danych do uporządkowanej tabeli CCI może trwać dłużej niż nie uporządkowana tabela CCI ze względu na operację sortowania danych, jednak zapytania mogą działać szybciej później przy użyciu uporządkowanego interfejsu CCI. Aby uzyskać więcej informacji na temat uporządkowanych klastrowanych indeksów magazynu kolumn, zobacz Performance tuning with ordered clustered columnstore index (Dostrajanie wydajności z uporządkowanym indeksem klastrowanego magazynu kolumn).

  • Indeksy klastrowane i nieklastrowane: indeksy klastrowane mogą przewyższać klastrowane indeksy magazynu kolumn, gdy trzeba szybko pobrać pojedynczy wiersz. W przypadku zapytań, w których wyszukiwanie pojedynczego wiersza lub tylko kilka odnośników wierszy, musi działać z ekstremalną szybkością, rozważ użycie indeksu klastra lub indeksu pomocniczego nieklastrowanego. Wadą używania indeksu klastrowanego jest to, że korzyści będą korzystać tylko zapytania z wysoce selektywnym filtrem w kolumnie indeksu klastrowanego. Aby ulepszyć filtrowanie innych kolumn, możesz dodać indeks nieklastrowany do innych kolumn. Jednak każdy indeks dodany do tabeli używa więcej miejsca i zwiększa czas przetwarzania do załadowania.

  • Tabele stert: gdy tymczasowo lądujesz dane w usłudze Azure Synapse, możesz stwierdzić, że użycie tabeli stert sprawia, że ogólny proces jest szybszy. Dzieje się tak, ponieważ ładowanie danych do tabel sterty jest szybsze niż ładowanie danych do tabel indeksowania, a w niektórych przypadkach kolejne operacje odczytu można wykonać z pamięci podręcznej. Jeśli ładujesz dane tylko do etapu przed uruchomieniem większej liczby przekształceń, znacznie szybciej załaduj je do tabeli sterty niż tabela klastrowanego magazynu kolumn. Ponadto ładowanie danych do tabeli tymczasowej jest szybsze niż ładowanie tabeli do magazynu trwałego. W przypadku małych tabel odnośników z mniej niż 100 milionami wierszy tabele stert są zwykle właściwym wyborem. Tabele magazynu kolumn klastra zaczynają osiągać optymalną kompresję, gdy zawierają ponad 100 milionów wierszy.

• Tabele klastrowane: tabele Oracle można organizować tak, aby wiersze tabeli, do których często uzyskiwano dostęp (na podstawie wspólnej wartości), są fizycznie przechowywane razem w celu zmniejszenia liczby operacji we/wy dysku podczas pobierania danych. Oracle udostępnia również opcję skrótu klastra dla poszczególnych tabel, która stosuje wartość skrótu do klucza klastra i fizycznie przechowuje wiersze z tą samą wartością skrótu. Aby wyświetlić listę klastrów w bazie danych Oracle, użyj SELECT * FROM DBA_CLUSTERS; zapytania. Aby określić, czy tabela znajduje się w klastrze, użyj SELECT * FROM TAB; zapytania, które pokazuje nazwę tabeli i identyfikator klastra dla każdej tabeli.

  W usłudze Azure Synapse można osiągnąć podobne wyniki przy użyciu zmaterializowanych i/lub replikowanych tabel, ponieważ te typy tabel minimalizują operacje we/wy wymagane w czasie wykonywania zapytania.

• Zmaterializowane widoki: Oracle obsługuje zmaterializowane widoki i zaleca używanie co najmniej jednego dla dużych tabel z wieloma kolumnami, w których tylko kilka kolumn jest regularnie używanych w zapytaniach. Zmaterializowane widoki są automatycznie odświeżane przez system po zaktualizowaniu danych w tabeli podstawowej.

  W 2019 r. firma Microsoft ogłosiła, że usługa Azure Synapse będzie obsługiwać zmaterializowane widoki z taką samą funkcjonalnością jak w programie Oracle. Zmaterializowane widoki są teraz funkcją w wersji zapoznawczej w usłudze Azure Synapse.

• Wyzwalacze w bazie danych: w programie Oracle wyzwalacz można skonfigurować tak, aby był uruchamiany automatycznie po wystąpieniu zdarzenia wyzwalającego. Wyzwalanie zdarzeń może być następujące:

  • Instrukcja języka manipulowania danymi (DML), taka jak INSERT, UPDATElub DELETE, jest uruchamiana w tabeli. Jeśli zdefiniowano wyzwalacz, który jest uruchamiany przed instrukcją INSERT w tabeli klienta, wyzwalacz zostanie wyzwolony raz, zanim nowy wiersz zostanie wstawiony do tabeli klienta.

  • Instrukcja DDL, taka jak CREATE lub ALTER, jest uruchamiana. Ten wyzwalacz jest często używany do celów inspekcji w celu rejestrowania zmian schematu.

  • Zdarzenie systemowe, takie jak uruchamianie lub zamykanie bazy danych Oracle.

  • Zdarzenie użytkownika, takie jak logowanie lub wylogowanie.

  Listę wyzwalaczy zdefiniowanych w bazie danych Oracle można uzyskać, wykonując ALL_TRIGGERSzapytanie dotyczące widoków , DBA_TRIGGERSlub USER_TRIGGERS . Poniższy zrzut ekranu przedstawia DBA_TRIGGERS zapytanie w programie Oracle SQL Developer.

  

  Usługa Azure Synapse nie obsługuje wyzwalaczy bazy danych Oracle. Można jednak dodać równoważną funkcjonalność przy użyciu usługi Data Factory, chociaż wymaga to refaktoryzacji procesów, które używają wyzwalaczy.

• Synonimy: Firma Oracle obsługuje definiowanie synonimów jako alternatywnych nazw dla kilku typów obiektów bazy danych. Te typy obiektów obejmują: tabele, widoki, sekwencje, procedury, funkcje składowane, pakiety, zmaterializowane widoki, obiekty schematu klasy Java, obiekty zdefiniowane przez użytkownika lub inny synonim.

  Usługa Azure Synapse obecnie nie obsługuje definiowania synonimów, chociaż jeśli synonim w programie Oracle odwołuje się do tabeli lub widoku, możesz zdefiniować widok w usłudze Azure Synapse tak, aby był zgodny z alternatywną nazwą. Jeśli synonim w programie Oracle odwołuje się do funkcji lub procedury składowanej, w usłudze Azure Synapse możesz utworzyć inną funkcję lub procedurę składowaną z nazwą zgodną z synonimem, która wywołuje obiekt docelowy.

• Typy zdefiniowane przez użytkownika: Firma Oracle obsługuje obiekty zdefiniowane przez użytkownika, które mogą zawierać serię poszczególnych pól, z których każda ma własną definicję i wartości domyślne. Do tych obiektów można odwoływać się w definicji tabeli w taki sam sposób, jak wbudowane typy danych, takie jak NUMBER lub VARCHAR. Listę typów zdefiniowanych przez użytkownika można uzyskać w bazie danych Oracle, wykonując ALL_TYPESzapytanie dotyczące widoków , DBA_TYPESlub USER_TYPES .

  Usługa Azure Synapse obecnie nie obsługuje typów zdefiniowanych przez użytkownika. Jeśli dane potrzebne do migracji zawierają typy danych zdefiniowanych przez użytkownika, "spłaszczają" je do konwencjonalnej definicji tabeli lub jeśli są tablicami danych, normalizuj je w oddzielnej tabeli.

Mapowanie typu danych Oracle

Większość typów danych Oracle ma bezpośredni odpowiednik w usłudze Azure Synapse. W poniższej tabeli przedstawiono zalecane podejście do mapowania typów danych Oracle na usługę Azure Synapse.

Typ danych Oracle	Typ danych usługi Azure Synapse
PLIK BFILE	Nieobsługiwane. Mapuj na VARBINARY (MAX).
BINARY_FLOAT	Nieobsługiwane. Mapuj na zmiennoprzecinkowe.
BINARY_DOUBLE	Nieobsługiwane. Mapuj na PODWÓJNE.
BLOB	Nieobsługiwane bezpośrednio. Zastąp ciąg VARBINARY(MAX).
CHAR	CHAR
CLOB	Nieobsługiwane bezpośrednio. Zastąp ciąg VARCHAR(MAX).
DATE	Data w programie Oracle może również zawierać informacje o godzinie. W zależności od mapy użycia na DATĘ lub ZNACZNIK CZASU.
DZIESIĘTNY	DZIESIĘTNY
PODWÓJNY	PRECYZJA PODWÓJNA
SPŁAWIK	SPŁAWIK
LICZBA CAŁKOWITA	INT
INTERWAŁ OD ROKU DO MIESIĄCA	Typy danych INTERVAL nie są obsługiwane. Użyj funkcji porównania dat, takich jak DATEDIFF lub DATEADD, dla obliczeń daty.
INTERWAŁ OD DNIA DO SEKUNDY	Typy danych INTERVAL nie są obsługiwane. Użyj funkcji porównania dat, takich jak DATEDIFF lub DATEADD, dla obliczeń daty.
DŁUGI	Nieobsługiwane. Mapuj na VARCHAR(MAX).
DŁUGI NIEPRZETWORZONE	Nieobsługiwane. Mapuj na VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMER	SPŁAWIK
NCLOB	Nieobsługiwane bezpośrednio. Zastąp ciąg NVARCHAR(MAX).
NUMERYCZNY	NUMERYCZNY
Typy danych nośnika ORD	Nieobsługiwane
SUROWY	Nieobsługiwane. Mapuj na VARBINARY.
PRAWDZIWY	PRAWDZIWY
IDENTYFIKATOR WIERSZA	Nieobsługiwane. Mapuj na identyfikator GUID, który jest podobny.
Typy danych geoprzestrzennych SDO	Nieobsługiwane
SMALLINT	SMALLINT
TIMESTAMP	DATETIME2 lub funkcja CURRENT_TIMESTAMP()
SYGNATURA CZASOWA Z LOKALNĄ STREFĄ CZASOWĄ	Nieobsługiwane. Mapuj na DATETIMEOFFSET.
SYGNATURA CZASOWA ZE STREFĄ CZASOWĄ	Nieobsługiwane, ponieważ czas TIME jest przechowywany przy użyciu zegara ściany bez przesunięcia strefy czasowej.
Typ identyfikatora URI	Nieobsługiwane. Przechowywanie w varCHAR.
IDENTYFIKATOR UROWID	Nieobsługiwane. Mapuj na identyfikator GUID, który jest podobny.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
Typ XML	Nieobsługiwane. Przechowywanie danych XML w varCHAR.

Oracle obsługuje również definiowanie obiektów zdefiniowanych przez użytkownika, które mogą zawierać serię poszczególnych pól, z których każda ma własną definicję i wartości domyślne. Te obiekty można następnie przywoływać w definicji tabeli w taki sam sposób, jak wbudowane typy danych, takie jak NUMBER lub VARCHAR. Usługa Azure Synapse obecnie nie obsługuje typów zdefiniowanych przez użytkownika. Jeśli dane potrzebne do migracji zawierają typy danych zdefiniowanych przez użytkownika, "spłaszczają" je do konwencjonalnej definicji tabeli lub jeśli są tablicami danych, normalizuj je w oddzielnej tabeli.

Napiwek

Oceń liczbę i typ nieobsługiwanych typów danych w fazie przygotowywania migracji.

Zewnętrzni dostawcy oferują narzędzia i usługi do automatyzacji migracji, w tym mapowanie typów danych. Jeśli narzędzie ETL innej firmy jest już używane w środowisku Oracle, użyj tego narzędzia, aby zaimplementować wszelkie wymagane przekształcenia danych.

Różnice składni języka SQL DML

Różnice składni języka SQL DML istnieją między językami Oracle SQL i Azure Synapse T-SQL. Te różnice zostały szczegółowo omówione w temacie Minimalizuj problemy z bazą danych SQL na potrzeby migracji oracle. W niektórych przypadkach można zautomatyzować migrację DML przy użyciu narzędzi firmy Microsoft, takich jak SSMA for Oracle i Azure Database Migration Services, lub produktów i usług migracji innych firm .

Funkcje, procedury składowane i sekwencje

Podczas migracji magazynu danych ze środowiska dojrzałego, takiego jak Oracle, prawdopodobnie trzeba migrować elementy inne niż proste tabele i widoki. Sprawdź, czy narzędzia w środowisku platformy Azure mogą zastąpić funkcje, procedury składowane i sekwencje, ponieważ zwykle bardziej wydajne jest używanie wbudowanych narzędzi platformy Azure niż ponowne kodowanie ich dla usługi Azure Synapse.

W ramach fazy przygotowania utwórz spis obiektów, które muszą zostać zmigrowane, zdefiniuj metodę ich obsługi i przydziel odpowiednie zasoby w planie migracji.

Narzędzia firmy Microsoft, takie jak SSMA dla oracle i Azure Database Migration Services, lub produkty i usługi migracji innych firm , mogą zautomatyzować migrację funkcji, procedur składowanych i sekwencji.

W poniższych sekcjach szczegółowo omówiono migrację funkcji, procedur składowanych i sekwencji.

Funkcje

Podobnie jak w przypadku większości produktów baz danych, oracle obsługuje funkcje systemowe i zdefiniowane przez użytkownika w ramach implementacji JĘZYKA SQL. Podczas migracji starszej platformy bazy danych do usługi Azure Synapse typowe funkcje systemowe mogą być zwykle migrowane bez zmian. Niektóre funkcje systemowe mogą mieć nieco inną składnię, ale wszelkie wymagane zmiany można zautomatyzować. Listę funkcji w bazie danych Oracle można uzyskać, wykonując ALL_OBJECTS zapytanie względem widoku z odpowiednią WHERE klauzulą. Aby uzyskać listę funkcji, jak pokazano na poniższym zrzucie ekranu, możesz użyć programu Oracle SQL Developer.

W przypadku funkcji systemowych Oracle lub dowolnych funkcji zdefiniowanych przez użytkownika, które nie mają odpowiedników w usłudze Azure Synapse, zakoduj ponownie te funkcje przy użyciu docelowego języka środowiska. Funkcje zdefiniowane przez użytkownika oracle są kodowane w języku PL/SQL, Java lub C. Usługa Azure Synapse używa języka Transact-SQL do implementowania funkcji zdefiniowanych przez użytkownika.

Procedury składowane

Większość nowoczesnych produktów baz danych obsługuje procedury przechowywania w bazie danych. Firma Oracle udostępnia język PL/SQL w tym celu. Procedura składowana zwykle zawiera zarówno instrukcje SQL, jak i logikę proceduralną oraz zwraca dane lub stan. Listę procedur składowanych w bazie danych Oracle można uzyskać, wykonując ALL_OBJECTS zapytanie względem widoku przy użyciu odpowiedniej WHERE klauzuli. Aby uzyskać listę procedur składowanych, jak pokazano na następnym zrzucie ekranu, możesz użyć programu Oracle SQL Developer.

Usługa Azure Synapse obsługuje procedury składowane przy użyciu języka T-SQL, dlatego należy ponownie zakodować wszystkie zmigrowane procedury składowane w tym języku.

Sekwencje

W programie Oracle sekwencja jest nazwanym obiektem bazy danych utworzonym przy użyciu polecenia CREATE SEQUENCE. Sekwencja udostępnia unikatowe wartości liczbowe za pomocą CURRVAL metod i NEXTVAL . Wygenerowane unikatowe liczby można użyć jako wartości klucza zastępczego dla kluczy podstawowych.

Usługa Azure Synapse nie implementuje CREATE SEQUENCEmetody , ale można zaimplementować sekwencje przy użyciu kolumn IDENTITY lub kodu SQL, który generuje następny numer sekwencji w serii.

Wyodrębnianie metadanych i danych ze środowiska Oracle

Generowanie języka definicji danych

Standard ANSI SQL definiuje podstawową składnię poleceń języka Data Definition Language (DDL). Niektóre polecenia DDL, takie jak CREATE TABLE i CREATE VIEW, są wspólne dla systemów Oracle i Azure Synapse, ale także udostępniają funkcje specyficzne dla implementacji, takie jak indeksowanie, dystrybucja tabel i opcje partycjonowania.

Istniejące skrypty i CREATE VIEW oracle CREATE TABLE można edytować, aby uzyskać równoważne definicje w usłudze Azure Synapse. W tym celu może być konieczne użycie zmodyfikowanych typów danych i usunięcie lub zmodyfikowanie klauzul specyficznych dla oracle, takich jak TABLESPACE.

W środowisku Oracle tabele wykazu systemu określają bieżącą tabelę i definicję widoku. W przeciwieństwie do dokumentacji obsługiwanej przez użytkownika informacje o katalogu systemowym są zawsze kompletne i zsynchronizowane z bieżącymi definicjami tabeli. Dostęp do informacji katalogu systemu można uzyskać przy użyciu narzędzi, takich jak Oracle SQL Developer. Program Oracle SQL Developer może wygenerować CREATE TABLE instrukcje DDL, które można edytować w celu utworzenia równoważnych tabel w usłudze Azure Synapse.

Możesz też użyć programu SSMA for Oracle do migrowania tabel z istniejącego środowiska Oracle do usługi Azure Synapse. Program SSMA for Oracle zastosuje odpowiednie mapowania typów danych oraz zalecane typy tabel i dystrybucji, jak pokazano na poniższym zrzucie ekranu.

Aby uzyskać podobne wyniki, można również użyć narzędzi do migracji innych firm i narzędzi ETL, które przetwarzają informacje o katalogu systemu.

Wyodrębnianie danych z bazy danych Oracle

Nieprzetworzone dane tabeli można wyodrębnić z tabel Oracle do prostych plików rozdzielonych, takich jak pliki CSV, przy użyciu standardowych narzędzi Oracle, takich jak Oracle SQL Developer, SQL*Plus i SCLcl. Następnie możesz skompresować płaskie pliki rozdzielane przy użyciu narzędzia gzip i przekazać skompresowane pliki do usługi Azure Blob Storage przy użyciu narzędzia AzCopy lub narzędzi transportu danych platformy Azure, takich jak Azure Data Box.

Wyodrębnianie danych tabeli tak wydajnie, jak to możliwe — szczególnie podczas migrowania dużych tabel faktów. W przypadku tabel Oracle użyj równoległości, aby zmaksymalizować przepływność wyodrębniania. Równoległość można osiągnąć, uruchamiając wiele procesów, które pojedynczo wyodrębniają odrębne segmenty danych lub za pomocą narzędzi umożliwiających automatyzację wyodrębniania równoległego za pomocą partycjonowania.

Napiwek

Użyj równoległości w celu najbardziej wydajnego wyodrębniania danych.

Jeśli dostępna jest wystarczająca przepustowość sieci, możesz wyodrębnić dane z lokalnego systemu Oracle bezpośrednio do tabel usługi Azure Synapse lub usługi Azure Blob Data Storage. W tym celu należy użyć procesów usługi Data Factory, usługi Azure Database Migration Service lub innych firm migracji danych lub produktów ETL.

Wyodrębnione pliki danych powinny zawierać rozdzielany tekst w formacie CSV, zoptymalizowanym kolumnie wierszy (ORC) lub Parquet.

Aby uzyskać więcej informacji na temat migrowania danych i etL ze środowiska Oracle, zobacz Migracja danych, ETL i ładowanie migracji Oracle.

Zalecenia dotyczące wydajności migracji oracle

Celem optymalizacji wydajności jest taka sama lub lepsza wydajność magazynu danych po migracji do usługi Azure Synapse.

Podobieństwa w pojęciach dotyczących podejścia do dostrajania wydajności

Wiele pojęć dotyczących dostrajania wydajności baz danych Oracle ma wartość true dla baz danych usługi Azure Synapse. Na przykład:

• Użyj dystrybucji danych, aby połączyć dane do przyłączenia do tego samego węzła przetwarzania.

• Użyj najmniejszego typu danych dla danej kolumny, aby zaoszczędzić miejsce do magazynowania i przyspieszyć przetwarzanie zapytań.

• Upewnij się, że kolumny do sprzężenia mają ten sam typ danych, aby zoptymalizować przetwarzanie sprzężenia i zmniejszyć potrzebę przekształcania danych.

• Aby pomóc optymalizatorowi utworzyć najlepszy plan wykonania, upewnij się, że statystyki są aktualne.

• Monitorowanie wydajności przy użyciu wbudowanych funkcji bazy danych w celu zapewnienia wydajnego używania zasobów.

Napiwek

Określ priorytety opcji dostrajania usługi Azure Synapse na początku migracji.

Różnice w podejściu dostrajania wydajności

W tej sekcji przedstawiono różnice implementacji dostrajania wydajności niskiego poziomu między rozwiązaniami Oracle i Azure Synapse.

Opcje dystrybucji danych

W celu uzyskania wydajności usługa Azure Synapse została zaprojektowana z architekturą z wieloma węzłami i korzysta z przetwarzania równoległego. Aby zoptymalizować wydajność tabel w usłudze Azure Synapse, możesz zdefiniować opcję dystrybucji danych w CREATE TABLE instrukcjach przy użyciu instrukcji DISTRIBUTION . Można na przykład określić tabelę rozproszoną przy użyciu skrótu, która dystrybuuje wiersze tabeli między węzłami obliczeniowymi przy użyciu funkcji wyznaczania wartości skrótu deterministycznego. Wiele implementacji Oracle, zwłaszcza starszych systemów lokalnych, nie obsługuje tej funkcji.

W przeciwieństwie do bazy danych Oracle usługa Azure Synapse obsługuje sprzężenia lokalne między małą tabelą a dużą tabelą przez małą replikację tabel. Rozważmy na przykład małą tabelę wymiarów i dużą tabelę faktów w modelu schematu gwiazdy. Usługa Azure Synapse może replikować mniejszą tabelę wymiarów we wszystkich węzłach, aby upewnić się, że wartość dowolnego klucza sprzężenia dla dużej tabeli ma pasujący, lokalnie dostępny wiersz wymiaru. Obciążenie replikacji tabeli wymiarów jest stosunkowo niskie dla małej tabeli wymiarów. W przypadku tabel dużych wymiarów bardziej odpowiednie jest podejście dystrybucji skrótów. Aby uzyskać więcej informacji na temat opcji dystrybucji danych, zobacz Wskazówki dotyczące projektowania dotyczące używania replikowanych tabel i Wskazówki dotyczące projektowania tabel rozproszonych.

Napiwek

Dystrybucja skrótów zwiększa wydajność zapytań w dużych tabelach faktów. Dystrybucja okrężna jest przydatna do poprawy szybkości ładowania.

Rozkład skrótów można stosować w wielu kolumnach w celu bardziej równomiernego rozkładu tabeli podstawowej. Dystrybucja wielokolumna umożliwia wybranie maksymalnie ośmiu kolumn do dystrybucji. Zmniejsza to nie tylko niesymetryczność danych w czasie, ale także poprawia wydajność zapytań.

Uwaga

Dystrybucja wielokolumnowa jest obecnie dostępna w wersji zapoznawczej dla usługi Azure Synapse Analytics. Możesz użyć dystrybucji wielokolumna z funkcją CREATE MATERIALIZED VIEW, CREATE TABLE i CREATE TABLE AS SELECT.

Doradca dystrybucji

W usłudze Azure Synapse SQL można dostosować sposób dystrybucji każdej tabeli. Strategia dystrybucji tabel ma znaczący wpływ na wydajność zapytań.

Doradca dystrybucji to nowa funkcja w usłudze Synapse SQL, która analizuje zapytania i zaleca najlepsze strategie dystrybucji tabel w celu zwiększenia wydajności zapytań. Zapytania, które mają być brane pod uwagę przez doradcę, mogą być dostarczane przez Ciebie lub pobierane z historycznych zapytań dostępnych w widoku DMV.

Aby uzyskać szczegółowe informacje i przykłady dotyczące korzystania z doradcy dystrybucji, odwiedź stronę Distribution Advisor w usłudze Azure Synapse SQL.

Indeksowanie danych

Usługa Azure Synapse obsługuje kilka opcji indeksowania z możliwością definiowania użytkownika, które mają inną operację i użycie w porównaniu z mapami stref zarządzanych przez system w programie Oracle. Aby uzyskać więcej informacji na temat różnych opcji indeksowania w usłudze Azure Synapse, zobacz Indeksy w dedykowanych tabelach puli SQL.

Definicje indeksów w środowisku źródłowym Oracle zapewniają przydatne wskazanie użycia danych i kolumn kandydatów do indeksowania w środowisku usługi Azure Synapse. Zazwyczaj nie trzeba migrować każdego indeksu ze starszego środowiska Oracle, ponieważ usługa Azure Synapse nie nadmiernie polega na indeksach i implementuje następujące funkcje, aby osiągnąć wyjątkową wydajność:

• Równoległe przetwarzanie zapytań.

• Buforowanie danych w pamięci i zestawu wyników.

• Dystrybucja danych, taka jak replikacja małych tabel wymiarów, w celu zmniejszenia liczby operacji we/wy.

Data partitioning (Partycjonowanie danych)

W magazynie danych przedsiębiorstwa tabele faktów mogą zawierać miliardy wierszy. Partycjonowanie optymalizuje konserwację i wykonywanie zapytań dotyczących tych tabel przez podzielenie ich na oddzielne części w celu zmniejszenia ilości przetwarzanych danych. W usłudze Azure Synapse CREATE TABLE instrukcja definiuje specyfikację partycjonowania dla tabeli.

Do partycjonowania można używać tylko jednego pola na tabelę. To pole jest często polem daty, ponieważ wiele zapytań jest filtrowanych według daty lub zakresu dat. Po początkowym załadowaniu można zmienić partycjonowanie tabeli przy użyciu instrukcji (CTAS), aby ponownie utworzyć tabelę przy użyciu CREATE TABLE AS nowej dystrybucji. Aby zapoznać się ze szczegółowym omówieniem partycjonowania w usłudze Azure Synapse, zobacz Partycjonowanie tabel w dedykowanej puli SQL.

Program PolyBase lub COPY INTO na potrzeby ładowania danych

Technologia PolyBase obsługuje wydajne ładowanie dużych ilości danych do magazynu danych przy użyciu strumieni ładowania równoległego. Aby uzyskać więcej informacji, zobacz Strategia ładowania danych polyBase.

FUNKCJA COPY INTO obsługuje również pozyskiwanie danych o wysokiej przepływności i:

• Pobieranie danych ze wszystkich plików w folderze i podfolderach.
• Pobieranie danych z wielu lokalizacji na tym samym koncie magazynu. Można określić wiele lokalizacji przy użyciu ścieżek rozdzielanych przecinkami.
• Usługi Azure Data Lake Storage (ADLS) i Azure Blob Storage.
• Formaty plików CSV, PARQUET i ORC.

Napiwek

Zalecaną metodą ładowania danych jest użycie COPY INTO formatu pliku PARQUET.

Zarządzanie obciążeniami

Uruchamianie mieszanych obciążeń może stanowić wyzwanie dla zasobów w systemach zajętych. Pomyślny schemat zarządzania obciążeniami skutecznie zarządza zasobami, zapewnia wysoce wydajne wykorzystanie zasobów i maksymalizuje zwrot z inwestycji (ROI). Klasyfikacja obciążeń, ważność obciążenia i izolacja obciążenia zapewniają większą kontrolę nad sposobem korzystania z zasobów systemowych przez obciążenie.

W przewodniku zarządzania obciążeniami opisano techniki analizowania obciążenia, zarządzania i monitorowania ważności obciążenia oraz kroków konwertowania klasy zasobów na grupę obciążeń. Użyj witryny Azure Portal i zapytań T-SQL w widokach DMV, aby monitorować obciążenie w celu zapewnienia efektywnego wykorzystania odpowiednich zasobów.

Następne kroki

Aby dowiedzieć się więcej o etL i obciążeniu migracji oracle, zobacz następny artykuł z tej serii: Migracja danych, ETL i ładowanie migracji oracle.