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 jest 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 korzystać z innowacji oferowanych przez nowoczesne środowiska w chmurze. Środowiska chmurowe 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 usług w chmurze.

Porada

Więcej niż tylko baza danych — środowisko platformy Azure zawiera kompleksowy zestaw możliwości i narzędzi.

Mimo że oracle i Azure Synapse Analytics to zarówno bazy danych SQL, które używają technik masowego przetwarzania równoległego (MPP), aby osiągnąć wysoką wydajność 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 Azure Synapse jest oparta na chmurze i korzysta z usługi Azure Storage i zasobów obliczeniowych.

• Uaktualnianie konfiguracji oracle jest głównym zadaniem obejmującym dodatkowy sprzęt fizyczny i potencjalnie długie ponowne konfigurowanie bazy danych lub zrzut i ponowne ładowanie. Ponieważ zasoby magazynu i zasobów obliczeniowych są oddzielne w środowisku platformy Azure i mają możliwość elastycznego skalowania, te zasoby można skalować w górę lub w dół niezależnie.

• Możesz wstrzymać lub zmienić rozmiar Azure Synapse zgodnie z potrzebami, aby zmniejszyć wykorzystanie zasobów i koszty.

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

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 ten uruchamiany niedawno przez GigaOm, który porównuje Azure Synapse z innymi popularnymi ofertami magazynu danych w chmurze. Klienci, którzy przeprowadzają migrację do środowiska 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łaci się tylko za rzeczywiste użycie.

• Ulepszone zabezpieczenia/zgodność.

• Zmniejszono koszty magazynowania i odzyskiwania po awarii.

• Niższe ogólne TCO, 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 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 na potrzeby migracji.

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

• Definiowanie mechanizmu wyodrębniania danych źródłowych.

• Zidentyfikuj odpowiednie narzędzia i funkcje platformy Azure i innych firm do użycia.

• Szkolić pracowników na początku nowej platformy.

• Skonfiguruj platformę docelową platformy Azure.

    Migracja ㋂

• Zacznij od małych i prostych.

• Automatyzuj wszędzie tam, gdzie jest 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.

    Zadania po migracji

• Monitoruj i dokumentuj wszystkie etapy procesu.

• Skorzystaj z zdobytego środowiska, aby utworzyć szablon na potrzeby przyszłych migracji.

• W razie potrzeby należy ponownie zaprojektować 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 migracji magazynu danych z istniejącego środowiska Oracle do Azure Synapse. Celem optymalizacji wydajności jest osiągnięcie tej samej lub lepszej wydajności magazynu danych w Azure Synapse po migracji.

Zagadnienia dotyczące projektowania

Zakres migracji

Podczas przygotowywania do migracji ze środowiska Oracle rozważ 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 podejmowania decyzji, gdzie rozpocząć pracę nad projektem migracji, wybierz obszar, w którym będzie można wykonywać następujące zadania:

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

• Zezwól pracownikom technicznym na uzyskanie odpowiedniego doświadczenia z procesami i narzędziami, których będą używać podczas migracji 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ę ze środowiska Oracle obsługuje poprzednie elementy i:

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

• Ma model danych, taki jak schemat star lub płatka śniegu, który można zmigrować z minimalną modyfikacją.

Porada

Utwórz spis obiektów, które należy zmigrować 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 Azure Synapse, ale nie zbyt duże, aby szybko zademonstrować wartość. Rozmiar w zakresie terabajtów 1–10 jest typowy.

Początkowym podejściem do projektu migracji jest zminimalizowanie 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 marty 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 mart danych zostanie wypełniona danymi i wymaganymi procesami kompilacji.

Podejście migracji metodą "lift and shift" a podejście etapowe

Ogólnie rzecz biorąc, istnieją dwa typy migracji niezależnie od przeznaczenia 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 star, jest migrowany bez zmian do nowej platformy Azure Synapse. Takie podejście minimalizuje ryzyko i czas migracji, zmniejszając pracę potrzebną do realizacji korzyści związanych z przejściem do środowiska chmury platformy Azure. Migracja metodą lift-and-shift jest dobrym rozwiązaniem dla następujących scenariuszy:

• 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 star lub schemacie płatka śniegu lub
• Jesteś w czasie i pod presją kosztów, aby przejść do nowoczesnego środowiska chmury.

Porada

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 utrzymania wymaganych poziomów wydajności. Konieczne może być również ponowne zaprojektowanie obsługi nowych danych, takich jak strumienie Internetu rzeczy (IoT). W ramach procesu ponownej inżynierii przeprowadź migrację do Azure Synapse, aby uzyskać korzyści ze skalowalnego środowiska chmury. Migracja może obejmować zmianę bazowego modelu danych, taką jak przejście z modelu Inmon do magazynu danych.

Firma Microsoft zaleca przeniesienie istniejącego modelu danych zgodnie z oczekiwaniami na platformę Azure oraz wykorzystanie wydajności i elastyczności środowiska platformy Azure w celu zastosowania zmian inżynierii ponownie. 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 przy użyciu obiektów firmy Microsoft

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

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

Program SSMA for Oracle może pomóc w migracji magazynu danych Oracle lub martu do Azure Synapse. Usługa SSMA została zaprojektowana 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 przepływów pracy opartych na danych 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 pozyskiwają 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 Azure SQL celu. Ten ruch danych w trybie offline pomaga znacznie zmniejszyć przestoje migracji.

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

Gdy planujesz używać obiektów platformy Azure do zarządzania procesem migracji, utwórz metadane zawierające listę wszystkich tabel danych do migracji i ich lokalizacji.

Różnice projektowe między rozwiązaniem 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 for Oracle nie tylko pomaga wypełnić te luki, ale także zautomatyzować migrację. Chociaż SSMA nie jest najbardziej wydajnym podejściem do bardzo dużych ilości danych, jest to przydatne 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 marty 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.

Natomiast środowisko Azure Synapse zawiera jedną bazę danych i używa schematów do rozdzielania tabel w logiczne oddzielne grupy. Zalecamy użycie serii schematów w docelowej bazie danych Azure Synapse do 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żna na przykład połączyć istniejące nazwy schematów i tabel Oracle z nową nazwą tabeli 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 Azure Synapse są tylko do odczytu, więc wszystkie aktualizacje danych muszą odbywać się w podstawowych tabelach podstawowych.

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

Porada

Połącz wiele baz danych w pojedynczą bazę danych w 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 korzystają z indeksów mapowanych na bity, sugeruje to, że w Azure Synapse powinien zostać utworzony nieklasowany indeks. Inne natywne techniki optymalizacji wydajności, takie jak replikacja tabel, mogą być bardziej odpowiednie niż proste tworzenie indeksów podobnych do podobnych. Narzędzie SSMA for Oracle może służyć do udostępniania zaleceń dotyczących migracji dla dystrybucji i indeksowania tabel.

Porada

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

Nieobsługiwane typy obiektów bazy danych Oracle

Funkcje specyficzne dla oracle mogą być często zastępowane przez funkcje Azure Synapse. Jednak niektóre obiekty bazy danych Oracle nie są bezpośrednio obsługiwane w Azure Synapse. Poniższa lista nieobsługiwanych obiektów bazy danych Oracle opisuje, jak można osiągnąć równoważną funkcjonalność w 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 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 widoków lub v$object_usage po włączeniu dba_index_usage 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 Azure Synapse. Zalecamy, aby najpierw przeprowadzić migrację danych, a następnie w Azure Synapse uruchamiać zapytania Oracle korzystające z indeksów opartych na funkcjach w celu pomiaru wydajności. Jeśli wydajność tych zapytań w Azure Synapse nie jest akceptowalna, rozważ utworzenie kolumny zawierającej wstępnie obliczoną wartość, a następnie indeksowanie tej kolumny.

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

  

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

  • Indeksy magazynu kolumn klastrowanych: jeśli dla tabeli nie określono żadnych opcji indeksu, Azure Synapse domyślnie tworzy indeks klastrowanego magazynu kolumn. Tabele magazynu kolumn klastrowanych 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 klasterowany 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 z danymi wstępnego sortowania dla kluczy sortowania mogą korzystać z eliminacji segmentów włączonej przez uporządkowane indeksy magazynu kolumn klastrowanych.
    • 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 stert lub indeksu klastrowanego.
    • Tabele z danymi przejściowymi, ponieważ tabele magazynu kolumn mogą być mniej wydajne niż sterty lub tabele tymczasowe.
    • Małe tabele z mniej niż 100 milionami wierszy. Zamiast tego rozważ użycie tabel stert.

  • Uporządkowane indeksy magazynu kolumn klastrowanych: dzięki włączeniu wydajnej eliminacji segmentów uporządkowane indeksy magazynu kolumn klastrowanych w Azure Synapse dedykowanych pul SQL zapewniają znacznie szybciej 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ż nieskonsortowa tabela CCI ze względu na operację sortowania danych, jednak zapytania mogą działać szybciej później przy użyciu uporządkowanego CCI. Aby uzyskać więcej informacji na temat uporządkowanych indeksów magazynu kolumn klastrowanych, zobacz Dostrajanie wydajności z uporządkowanym indeksem magazynu kolumn klastrowanych.

  • 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życia indeksu klastrowanego jest to, że korzyści będą korzystać tylko zapytania z wysoce selektywnym filtrem w kolumnie indeksu klastrowanego. Aby poprawić 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: w przypadku tymczasowego lądowania danych na Azure Synapse można zauważyć, ż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 można załadować je do tabeli sterty niż tabela magazynu kolumn klastrowanych. 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ą więcej niż 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 w celu zmniejszenia liczby operacji we/wy dysku podczas pobierania danych. Oracle udostępnia również opcję klastra skrótów dla poszczególnych tabel, która stosuje wartość skrótu do klucza klastra i fizycznie przechowuje wiersze o tej samej wartości skrótu razem. 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 Azure Synapse można osiągnąć podobne wyniki przy użyciu zmaterializowanych i/lub replikowanych tabel, ponieważ te typy tabel minimalizują wymagane operacje we/wy 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 Azure Synapse będzie obsługiwać zmaterializowane widoki z tą samą funkcjonalnością co w oracle. Zmaterializowane widoki są teraz funkcją w wersji zapoznawczej w 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 zostanie wyzwolony 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ć, wysyłając ALL_TRIGGERSzapytanie do widoków , lub USER_TRIGGERS . DBA_TRIGGERS Poniższy zrzut ekranu przedstawia DBA_TRIGGERS zapytanie w programie Oracle SQL Developer.

  

  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 korzystających z wyzwalaczy.

• Synonimy: 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.

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

• Typy zdefiniowane przez użytkownika: 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 .

  Azure Synapse obecnie nie obsługuje typów zdefiniowanych przez użytkownika. Jeśli dane potrzebne do migracji obejmują typy danych zdefiniowane 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 Azure Synapse. W poniższej tabeli przedstawiono zalecane podejście do mapowania typów danych Oracle na Azure Synapse.

Typ danych Oracle	typ danych Azure Synapse
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 element VARBINARY(MAX).
CHAR	CHAR
CLOB	Nieobsługiwane bezpośrednio. Zastąp element VARCHAR(MAX).
DATE	Data w programie Oracle może również zawierać informacje o godzinie. W zależności od mapy użycia na wartość DATE lub TIMESTAMP.
DZIESIĘTNYCH	DZIESIĘTNYCH
PODWÓJNE	PRECYZJA PODWÓJNA
FLOAT	FLOAT
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, na potrzeby 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, na potrzeby obliczeń daty.
DŁUGI	Nieobsługiwane. Mapuj na VARCHAR(MAX).
DŁUGI RAW	Nieobsługiwane. Mapuj na VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMER	FLOAT
NCLOB	Nieobsługiwane bezpośrednio. Zastąp ciąg NVARCHAR(MAX).
LICZBOWE	LICZBOWE
Typy danych nośnika ORD	Nieobsługiwane
RAW	Nieobsługiwane. Mapuj na VARBINARY.
LICZBA RZECZYWISTA	LICZBA RZECZYWISTA
ROWID	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 CZAS jest przechowywany przy użyciu zegara ściany bez przesunięcia strefy czasowej.
Typ identyfikatora URI	Nieobsługiwane. Przechowywanie w zmiennej VARCHAR.
UROWID	Nieobsługiwane. Mapuj na identyfikator GUID, który jest podobny.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
Xmltype	Nieobsługiwane. Przechowywanie danych XML w zmiennej 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. Azure Synapse obecnie nie obsługuje typów zdefiniowanych przez użytkownika. Jeśli dane potrzebne do migracji obejmują typy danych zdefiniowane przez użytkownika, "spłaszczają" je do konwencjonalnej definicji tabeli lub jeśli są tablicami danych, normalizuj je w oddzielnej tabeli.

Porada

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 do zaimplementowania wszelkich wymaganych przekształceń danych.

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

Różnice składni języka DML sql istnieją między bazą danych Oracle SQL i Azure Synapse języka 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 dla 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ć funkcjonalność funkcji, procedur składowanych i sekwencji, ponieważ zwykle bardziej wydajne jest używanie wbudowanych narzędzi platformy Azure niż ponowne kodowanie ich dla 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 SQL. Podczas migracji starszej platformy bazy danych do Azure Synapse typowe funkcje systemowe można zwykle migrować 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 przy użyciu odpowiedniej WHERE klauzuli. 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 Azure Synapse, zakoduj je ponownie przy użyciu języka środowiska docelowego. Funkcje zdefiniowane przez użytkownika oracle są kodowane w języku PL/SQL, Java lub C. 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 z odpowiednią WHERE klauzulą. Aby uzyskać listę procedur składowanych, jak pokazano na następnym zrzucie ekranu, możesz użyć programu Oracle SQL Developer.

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 . Wygenerowanych unikatowych liczb można użyć jako wartości klucza zastępczego dla kluczy podstawowych.

Azure Synapse nie implementuje CREATE SEQUENCEinstrukcji , 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 DDL (Data Definition Language). Niektóre polecenia DDL, takie jak i CREATE VIEW, są wspólne zarówno dla oracle, jak i Azure Synapse, ale także udostępniają funkcje specyficzne dla implementacji, takie jak CREATE TABLE indeksowanie, dystrybucja tabel i opcje partycjonowania.

Istniejące środowisko Oracle CREATE TABLE i CREATE VIEW skrypty można edytować, aby uzyskać równoważne definicje w Azure Synapse. W tym celu może być konieczne użycie zmodyfikowanych typów danych i usunięcie lub zmodyfikowanie klauzul specyficznych dla programu 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 wykazie systemu są zawsze kompletne i zsynchronizowane z bieżącymi definicjami tabel. Dostęp do informacji o katalogu systemu można uzyskać za pomocą 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 Azure Synapse.

Możesz też użyć programu SSMA for Oracle do migrowania tabel z istniejącego środowiska Oracle do 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.

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

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żna skompresować proste pliki rozdzielane przy użyciu narzędzia gzip i przekazać skompresowane pliki do Azure Blob Storage przy użyciu narzędzia AzCopy lub narzędzi do 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.

Porada

Korzystaj z 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 Azure Synapse lub usługi Azure Blob Data Storage. W tym celu należy użyć procesów usługi Data Factory, Azure Database Migration Service lub migracji danych innych firm lub produktów ETL.

Wyodrębnione pliki danych powinny zawierać tekst rozdzielany 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 Azure Synapse.

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

Wiele pojęć dotyczących dostrajania wydajności baz danych Oracle ma wartość true dla baz danych 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.

Porada

Określanie priorytetów przy użyciu opcji dostrajania Azure Synapse na początku migracji.

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

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

Opcje dystrybucji danych

Aby uzyskać wydajność, Azure Synapse została zaprojektowana z architekturą z wieloma węzłami i korzysta z przetwarzania równoległego. Aby zoptymalizować wydajność tabel w Azure Synapse, można zdefiniować opcję dystrybucji danych w instrukcjach CREATE TABLE 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 skrótu deterministycznego. Wiele implementacji Oracle, zwłaszcza starszych systemów lokalnych, nie obsługuje tej funkcji.

W przeciwieństwie do programu Oracle Azure Synapse obsługuje sprzężenia lokalne między małą tabelą a dużą tabelą za pośrednictwem replikacji małej tabeli. Rozważmy na przykład małą tabelę wymiarów i dużą tabelę faktów w modelu schematu star. 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, dostępny lokalnie wiersz wymiaru. Obciążenie replikacji tabeli wymiarów jest stosunkowo niskie dla małej tabeli wymiarów. W przypadku dużych tabel 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 przy użyciu tabel replikowanych i Wskazówki dotyczące projektowania tabel rozproszonych.

Porada

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

Dystrybucja skrótów może być stosowana na wielu kolumnach w celu bardziej równomiernego rozkładu tabeli podstawowej. Dystrybucja wielokolumna pozwala wybrać maksymalnie osiem kolumn do dystrybucji. Zmniejsza to nie tylko niesymetryczność danych w czasie, ale także poprawia wydajność zapytań.

Uwaga

Dystrybucja wielokolumna 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 Azure Synapse SQL można dostosować sposób, w jaki każda tabela jest dystrybuowana. 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

Azure Synapse obsługuje kilka opcji indeksowania, które można definiować przez 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 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 Azure Synapse. Zazwyczaj nie trzeba migrować każdego indeksu ze starszego środowiska Oracle, ponieważ Azure Synapse nie 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.

Partycjonowanie danych

W magazynie danych przedsiębiorstwa tabele faktów mogą zawierać miliardy wierszy. Partycjonowanie optymalizuje konserwację i wykonywanie zapytań względem tych tabel przez podzielenie ich na oddzielne części w celu zmniejszenia ilości przetwarzanych danych. W 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 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 równoległych strumieni ładowania. Aby uzyskać więcej informacji, zobacz Strategia ładowania danych polyBase.

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

• 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.
• Azure Data Lake Storage (ADLS) i Azure Blob Storage.
• Formaty plików CSV, PARQUET i ORC.

Porada

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

Zarządzanie obciążeniem

Uruchamianie mieszanych obciążeń może stanowić wyzwania związane z zasobami 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ń, znaczenie obciążenia i izolacja obciążenia zapewniają większą kontrolę nad sposobem wykorzystania 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 zapytań Azure Portal i T-SQL na widokach DMV, aby monitorować obciążenie, aby upewnić się, że odpowiednie zasoby są efektywnie wykorzystywane.

Następne kroki

Aby dowiedzieć się więcej na temat procesu ETL i ładowania migracji oracle, zobacz następny artykuł z tej serii: Migracja danych, ETL i ładowanie migracji Oracle.