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.

Tip

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ść.

• Increased agility and shorter time to value.

• 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 narzędzia innych firm, które mają być używane.

• Przeszkól pracowników wcześnie w zakresie nowej platformy.

• Skonfiguruj platformę docelową 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.

• Migracja danych historycznych w celu ich utrzymania.

• Migrate or refactor stored procedures and business processes.

• Migrate or refactor ETL/ELT incremental load processes.

    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ę ze środowiska Oracle wspiera wcześniej wymienione elementy oraz:

• Implements a BI/Analytics workload rather than an online transaction processing (OLTP) workload.

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

Tip

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.

Lift and shift migration vs. Phased approach

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.

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. Lift and shift migration is a good fit for these scenarios:

• You have an existing Oracle environment with a single data mart to migrate, or
• Masz istniejące środowisko Oracle z danymi, które są już w dobrze zaprojektowanym schemacie gwiazdy lub płatka śniegu lub
• Jesteś pod presją czasu i kosztów, aby przejść do nowoczesnego środowiska chmury.

Tip

Lift and shift is a good starting point, even if subsequent phases implement changes to the data model.

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. Może być również konieczne przeprojektowanie 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 modelu Data Vault.

Microsoft zaleca przeniesienie istniejącego modelu danych w niezmienionej formie na platformę Azure oraz wykorzystanie wydajności i elastyczności środowiska Azure do wprowadzenia zmian wynikających z 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 wpływ na wydajność w istniejącym środowisku Oracle, które może już działać na granicy swoich możliwoś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 w projektowaniu między Oracle a 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 vs. pojedyncza baza danych i schematy

Środowisko Oracle często zawiera wiele oddzielnych baz danych. For instance, there could be separate databases for: data ingestion and staging tables, core warehouse tables, and data marts—sometimes referred to as the semantic layer. Processing in ETL or ELT pipelines can implement cross-database joins and move data between the separate databases.

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 Azure Synapse są tylko do odczytu, więc wszystkie aktualizacje danych muszą odbywać się w podstawowych tabelach.

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

Tip

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

Table considerations

Podczas migracji tabel między różnymi środowiskami zazwyczaj migrują tylko nieprzetworzone dane i metadane, które je fizycznie opisują. 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 być używany do przygotowywania zaleceń dotyczących migracji, dystrybucji i indeksowania tabel.

Tip

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 widoków dba_index_usage lub v$object_usage w czasie, gdy monitorowanie jest włączone. 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 będące 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. Clustered columnstore tables offer the highest level of data compression, best overall query performance, and generally outperform clustered index or heap tables. A clustered columnstore index is usually the best choice for large tables. Podczas tworzenia tabeli wybierz grupowany magazyn kolumn, jeśli nie masz pewności, jak indeksować tabelę. However, there are some scenarios where clustered columnstore indexes aren't the best option:

    • Tables with pre-sort data on a sort key(s) could benefit from the segment elimination enabled by ordered clustered columnstore indexes.
    • 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 stosu lub indeksu klastrowanego.
    • Tables with transient data, because columnstore tables might be less efficient than heap or temporary tables.
    • Small tables with less than 100 million rows. Instead, consider using heap tables.

  • Uporządkowane klastrowane indeksy magazynu kolumn: Poprzez umożliwienie wydajnej eliminacji segmentów, uporządkowane klastrowane indeksy magazynu kolumn w dedykowanych pulach SQL platformy Azure Synapse oferują znacznie lepszą wydajność, pomijając duże ilości uporządkowanych danych, które nie pasują do predykatu zapytania. Ładowanie danych do uporządkowanej tabeli CCI może trwać dłużej niż do nieuporządkowanej tabeli CCI ze względu na operację sortowania danych. Jednak późniejsze zapytania mogą działać szybciej z uporządkowaną tabelą CCI. For more information on ordered clustered columnstore indexes, see Performance tuning with ordered clustered columnstore index.

  • Indeksy klastrowane i nieklastrowane: indeksy klastrowane mogą przewyższać klastrowane indeksy magazynu kolumn, gdy trzeba szybko pobrać pojedynczy wiersz. W przypadku zapytań, gdzie wyszukiwanie pojedynczego wiersza lub tylko kilku wierszy musi działać z ekstremalną szybkością, rozważ użycie indeksu klastrowego lub nieklastrowego indeksu pomocniczego. The disadvantage of using a clustered index is that only queries with a highly selective filter on the clustered index column will benefit. 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.

  • Heap tables: when you're temporarily landing data on Azure Synapse, you might find that using a heap table makes the overall process faster. This is because loading data to heap tables is faster than loading data to index tables, and in some cases subsequent reads can be done from cache. If you're loading data only to stage it before running more transformations, it's much faster to load it to a heap table than a clustered columnstore table. Ponadto ładowanie danych do tabeli tymczasowej jest szybsze niż ładowanie tabeli do magazynu trwałego. For small lookup tables with less than 100 million rows, heap tables are usually the right choice. 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 also provides a hash-cluster option for individual tables, which applies a hash value to the cluster key and physically stores rows with the same hash value together. 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. Zdarzenia wyzwalające mogą obejmować:

  • 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 zapytanie do widoków ALL_TRIGGERS, DBA_TRIGGERS lub USER_TRIGGERS. Zrzut ekranu poniżej przedstawia zapytanie DBA_TRIGGERS 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 zapytanie dotyczące widoków ALL_TYPES, DBA_TYPES lub 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 zdefiniowane przez użytkownika, spłaszcz je do konwencjonalnej definicji tabeli lub, jeśli są tablicami danych, znormalizuj 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
BFILE	Not supported. Map to VARBINARY (MAX).
BINARY_FLOAT	Not supported. Map to FLOAT.
BINARY_DOUBLE	Not supported. Map to DOUBLE.
BLOB	Not directly supported. Replace with VARBINARY(MAX).
CHAR	CHAR
CLOB	Not directly supported. Replace with VARCHAR(MAX).
DATE	Data w programie Oracle może również zawierać informacje o godzinie. Depending on usage map to DATE or TIMESTAMP.
DECIMAL	DECIMAL
DOUBLE	PRECISION DOUBLE
FLOAT	FLOAT
INTEGER	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.
LONG	Not supported. Map to VARCHAR(MAX).
LONG RAW	Not supported. Map to VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMBER	FLOAT
NCLOB	Not directly supported. Replace with NVARCHAR(MAX).
NUMERIC	NUMERIC
Typy danych nośnika ORD	Not supported
RAW	Not supported. Map to VARBINARY.
REAL	REAL
ROWID	Not supported. Map to GUID, which is similar.
Typy danych geoprzestrzennych SDO	Not supported
SMALLINT	SMALLINT
TIMESTAMP	DATETIME2 lub funkcja CURRENT_TIMESTAMP()
TIMESTAMP WITH LOCAL TIME ZONE	Not supported. Map to DATETIMEOFFSET.
TIMESTAMP WITH TIME ZONE	Not supported because TIME is stored using wall-clock time without a time zone offset.
Typ identyfikatora URI	Not supported. Store in a VARCHAR.
UROWID	Not supported. Map to GUID, which is similar.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Not supported. Przechowuj dane 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 zdefiniowane przez użytkownika, spłaszcz je do konwencjonalnej definicji tabeli lub, jeśli są tablicami danych, znormalizuj je w oddzielnej tabeli.

Tip

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 Minimalizuj problemy SQL przy migracjach 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ć. You can get a list of functions within an Oracle database by querying the ALL_OBJECTS view with the appropriate WHERE clause. 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.

Stored procedures

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 zapytanie względem widoku ALL_OBJECTS przy użyciu odpowiedniej klauzuli WHERE. 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.

Sequences

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ą metod CURRVAL 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 SEQUENCE, ale można zaimplementować sekwencje przy użyciu kolumn IDENTITY lub kodu SQL generującego kolejny 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 Oracle CREATE TABLE i CREATE VIEW 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.

Extract table data as efficiently as possible—especially when migrating large fact tables. W przypadku tabel Oracle użyj przetwarzania równoległego, aby zmaksymalizować wydajność 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.

Tip

Użyj parallelizmu 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 zewnętrznych produktów do migracji danych lub ETL.

Extracted data files should contain delimited text in CSV, Optimized Row Columnar (ORC), or Parquet format.

pl-PL: Aby uzyskać więcej informacji na temat migrowania danych i ETL ze środowiska Oracle, zobacz Migracja danych, ETL i ładowanie dla 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 zastosowanie w przypadku baz danych Azure Synapse. Na przykład:

• Use data distribution to collocate data-to-be-joined onto the same processing node.

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

• Upewnij się, że kolumny do łączenia mają ten sam typ danych, aby zoptymalizować przetwarzanie łączenia i zredukować konieczność 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.

Tip

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 . For example, you can specify a hash-distributed table, which distributes table rows across compute nodes by using a deterministic hash function. 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. Azure Synapse can replicate the smaller dimension table across all nodes to ensure that the value of any join key for the large table has a matching, locally available dimension row. Obciążenie replikacji tabeli wymiarów jest stosunkowo niskie dla małej tabeli wymiarów. For large dimension tables, a hash distribution approach is more appropriate. 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.

Tip

Hash distribution improves query performance on large fact tables. Dystrybucja okrężna jest przydatna do poprawy szybkości ładowania.

Hash distribution can be applied on multiple columns for a more even distribution of the base table. 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 wielokolumnowej przy użyciu 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. For more information about the different indexing options in Azure Synapse, see Indexes on dedicated SQL pool tables.

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 i zestawów wyników w pamięci.

• 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 CREATE TABLE AS (CTAS), aby ponownie utworzyć tabelę z nową dystrybucją. 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ż przetwarzanie danych o wysokiej przepustowości i:

• Pobieranie danych ze wszystkich plików w folderze i podfolderach.
• Pobieranie danych z wielu lokalizacji w tym samym koncie magazynowym. 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.

Tip

Zalecaną metodą ładowania danych jest użycie COPY INTO wraz z formatem pliku PARQUET.

Zarządzanie obciążeniami

Uruchamianie mieszanych obciążeń może stanowić wyzwanie dla zasobów w systemach obciążonych. 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 portalu Azure i zapytań T-SQL w widokach dynamicznego zarządzania (DMV), aby monitorować obciążenie i zapewnić efektywne wykorzystanie odpowiednich zasobów.

Następne kroki

Aby dowiedzieć się więcej o ETL i ładowaniu dla migracji Oracle, zobacz następny artykuł z tej serii: Migracja danych, ETL i ładowanie dla migracji Oracle.