Najlepsze rozwiązania dotyczące migracji z bazy danych Oracle do usługi Azure Database for PostgreSQL
DOTYCZY: 
Azure Database for PostgreSQL — serwer elastyczny
W poniższych scenariuszach przedstawiono niektóre potencjalne wyzwania, które napotkano podczas migracji oracle do usługi Azure Postgres. Zalecane rozwiązania mogą być przydatne podczas planowania i wykonywania własnych migracji.
Scenariusz: Dwa oddzielne, małe opóźnienia, wysoka przepływność, aplikacje klienckie zostały odnalezione niezależnie działające na tej samej bazie danych. Każda aplikacja przypadkowo podbijała buforowane zapytania innych z. Współdzielone obciążenie i połączone rywalizacje o zasoby stworzyły sytuację, w której udostępnione bazy danych były zbyt często opróżniane, co spowodowało obniżenie wydajności w obu systemach.
Zalecane rozwiązanie: Upewnij się, że początkowe oceny przechwytują wszystkie aspekty środowiska platformy bazy danych, w tym wzorce zużycia pamięci i wykorzystania obu systemów globalnego obszaru (SGA) i struktury pamięci globalnego obszaru programowego (PGA). Wybierz odpowiednią rodzinę zasobów obliczeniowych, która spełnia wymagania dotyczące zasobów, i upewnij się, że planowana pojemność usługi Postgres jest dostosowywana zgodnie z potrzebami.
Napiwek
Rozszerzenie pg_buffercache zapewnia środki do badania wykorzystania i umożliwia obserwowanie, co dzieje się w pamięci podręcznej buforu udostępnionego w czasie rzeczywistym.
Współczynnik trafień pamięci podręcznej buforu
Badanie współczynników trafień pozwala ocenić skuteczność pamięci podręcznej i określić, czy rozmiar udostępnionego buforu jest odpowiedni. Dobry współczynnik trafień pamięci podręcznej to znak, że większość żądań danych jest obsługiwana z pamięci, a nie z dysku, zapewniając optymalną wydajność:
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
Najczęściej używane tabele i indeksy
Sprawdzenie, które tabele i indeksy są najczęściej używane i/lub zajmują najwięcej miejsca w pamięci podręcznej buforu, mogą pomóc w zidentyfikowaniu buforowanych hotspotów w pamięci:
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
Rywalizacja o pamięć podręczną buforu
Znaczna rywalizacja w pamięci podręcznej buforu wskazuje, że wiele zapytań może walczyć o to samo miejsce w buforze, co prowadzi do wąskich gardeł wydajności. Badanie lokalizacji i częstotliwości dostępu buforu może pomóc w diagnozowaniu takich problemów:
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
Scenariusz: Zainicjowano nakład pracy nad migracją między wersjami i obejmującymi wydania platformy Postgres. Pomimo dostępności nowych funkcji i ulepszeń w najnowszej wersji, wersja wybrana na początku migracji pozostała niezmieniona. Kolejne dodatkowe nakłady pracy, czas i wydatki zostały wywłaszczone w celu uaktualnienia wersji bazy danych Postgres po początkowej migracji w celu osiągnięcia optymalnej wydajności i nowych możliwości.
Zalecane rozwiązanie: jeśli to możliwe, należy określić priorytety wdrażania najnowszej wersji bazy danych Postgres podczas migracji. Zespoły deweloperskie społeczności Postgres pracują niezwykle ciężko, aby wycisnąć każdy kawałek wydajności i stabilności w każdej nowej wersji, i powstrzymując się zasadniczo przekłada się na pozostawienie wydajności na linii bocznej. Ponadto możesz w pełni korzystać z nowych funkcji platformy Azure. Nowe funkcje usługi Azure Postgres obejmują: magazyn SSDv2, najnowszą rodzinę serwerów infrastruktury oraz automatyczne dostrajanie indeksów i możliwości dostosowywania parametrów serwera autonomicznego.
Scenariusz: Organizacje migrujące do bazy danych Postgres po raz pierwszy mogą nie być zgodne z najlepszymi rozwiązaniami i podejściami podczas identyfikowania wolno działających zapytań. Należy zachować szczególną ostrożność i zwrócić szczególną uwagę podczas implementowania odpowiednio nowych typów indeksów. W szczególności aparat bazy danych Postgres został zaprojektowany tak, aby optymalizować wydajność zapytań bez konieczności określania wskazówek dotyczących zapytań.
Zalecane rozwiązanie: Rozszerzenia są integralną częścią tego, co sprawia, że usługa Postgres jest tak zaawansowana. Istnieje kilka rozszerzeń, które mogą zapewnić ważne funkcje umożliwiające zapewnienie, że baza danych działa w szczytowej wydajności. Niektóre rozszerzenia klucza, które należy wziąć pod uwagę, obejmują:
auto_explain: automatycznie rejestruje plany wykonywania zapytań, które wykraczają poza ustawiony próg. Umożliwia administratorom bazy danych diagnozowanie problemów z wydajnością i optymalizowanie wydajności zapytań bez ręcznego uruchamiania funkcji WYJAŚNIJ dla każdego zapytania.
pg_trgm: udostępnia funkcje i operatory służące do określania podobieństwa danych opartych na tekście przy użyciu dopasowywania trigramów. To rozszerzenie jest przydatne w przypadku zadań obejmujących wyszukiwanie tekstu, dopasowywanie rozmyte i zapytania oparte na podobieństwie. W połączeniu z indeksami GIN lub GIST w kolumnach tekstowych zapewnia lepszą wydajność zapytań LIKE i wyszukiwania podobieństwa.
pg_cron: umożliwia planowanie i zarządzanie okresowymi zadaniami bezpośrednio w bazie danych. Integruje planowanie zadań przypominających cron z bazą danych Postgres, umożliwiając automatyzację rutynowych zadań konserwacji, przetwarzania danych i podobnych powtarzających się operacji.
Napiwek
Jeśli operacje bazy danych obejmują znaczną liczbę powtarzających się operacji tworzenia i usuwania obiektów bazy danych, starsze pg_catalog krotki tabeli systemu zwiększą się, co prowadzi do "wzdęć". Ponieważ pg_catalog jest tabelą systemową związaną z wieloma operacjami bazy danych, nieskręcona konserwacja tej tabeli może spowodować obniżenie wydajności bazy danych. Zapewnienie, że pg_catalog jest odpowiednio utrzymywane i odpowiednio opróżniane, można zapewnić przez skonfigurowanie cyklicznego harmonogramu pg_cron.
- pg_hint_plan: Usługa Postgres ma na celu zapewnienie spójnej i niezawodnej wydajności bez konieczności ręcznej interwencji, co skutkuje celową decyzją projektową, aby nie uwzględniać wskazówek dotyczących zapytań. W niektórych scenariuszach, w których potrzebna jest konkretna i precyzyjna kontrola nad projektami planów zapytań, pg_hint_plan zapewnia sposób wpływania na decyzje planisty zapytań przy użyciu wskazówek osadzonych w komentarzach SQL. Te wskazówki pozwalają administratorom baz danych kierować planistą zapytań do wybierania określonych planów w celu optymalizacji złożonych zapytań lub rozwiązywania problemów z wydajnością, które planista może nie być w stanie obsłużyć samodzielnie.
Uwaga
Te przykłady to po prostu drapanie powierzchni niezwykle rozległego zestawu rozszerzeń dostępnych dla bazy danych Postgres. Zachęcamy do pełnego zapoznania się z tymi rozszerzeniami, aby uzupełnić bazę danych Postgres. Ponadto możesz rozważyć możliwość tworzenia własnych rozszerzeń, w których można rozszerzyć usługę Postgres poza jej bieżące możliwości. Wydajnie elastyczna architektura rozszerzenia gwarantuje, że usługa Postgres będzie zawsze w stanie dostosować się i rozwijać zgodnie z wymaganiami dotyczącymi platformy.
Scenariusz: W niektórych przypadkach starsze strategie partycji tabeli spowodowały utworzenie tysięcy partycji. Chociaż może to być skuteczne w przypadku użycia wcześniej, te strategie mogą spowolnić wydajność zapytań w usłudze Postgres w pewnych okolicznościach. W bardzo konkretnych przypadkach planista zapytań może nie być w stanie określić odpowiedniego klucza partycji podczas analizowania zapytania. Wynikowe zachowanie generuje dłuższy czas planowania i powoduje, że planowanie zapytań trwa dłużej niż rzeczywiste wykonanie zapytania.
Zalecane rozwiązanie: przeszacuj potrzebę partycjonowania strategii generujących zbyt dużą liczbę partycji. Aparat bazy danych Postgres może już nie wymagać tej samej segmentacji danych i zmniejszenie liczby partycji może prawdopodobnie poprawić wydajność. Jeśli starszy schemat partycjonowania jest oceniany i jest określany jako wymagany, rozważ restrukturyzację zapytania w dyskretnych operacjach, aby najpierw zidentyfikować i wyodrębnić dynamiczne klucze partycji, a następnie użyć kluczy partycji w operacjach zapytań.
Scenariusz: Czasami zależności zewnętrzne i okoliczności środowiskowe mogą wymagać scenariuszy hybrydowych baz danych, w których bazy danych Oracle i Azure Postgres muszą współistnieć. Na przykład mogą wystąpić sytuacje, w których migracje etapowe są niezbędne do uzyskiwania dostępu do danych Oracle i wykonywania zapytań dotyczących ich bezpośrednio z usługi Azure Postgres bez konieczności importowania danych lub modyfikowania złożonych procesów ETL. W innych przypadkach przeprowadzanie równoległej weryfikacji danych przez porównanie równoważnych zestawów danych w środowiskach Oracle i Azure Postgres jednocześnie może pomóc zapewnić spójność i integralność danych podczas migracji i/lub po migracji.
Zalecane rozwiązanie: Rozszerzenia postgreSQL Foreign Data Wrapper (FDW) to kluczowa funkcja Postgres umożliwiająca uzyskiwanie dostępu do danych przechowywanych w systemach zewnętrznych i manipulowanie nimi, tak jakby te dane znajdowały się natywnie w bazie danych Azure Postgres. FDWs umożliwiają usłudze Azure Postgres działanie jako federacyjną bazę danych, umożliwiając integrację z dowolną liczbą zewnętrznych źródeł danych, w tym bazami danych Oracle. FDWs tworzą obce definicje tabel w bazie danych Postgres, a te obce tabele działają jako serwer proxy zdefiniowanego zewnętrznego źródła danych, co umożliwia użytkownikom wykonywanie zapytań dotyczących tych obcych tabel przy użyciu zwykłych zapytań SQL. Wewnętrznie aparat Postgres używa zewnętrznej definicji FDW do komunikowania się i koordynowania danych na żądanie ze zdalnego źródła danych.
oracle_fdw: (Foreign Data Wrapper for Oracle) to rozszerzenie Postgres, które umożliwia dostęp do baz danych Oracle z poziomu usługi Azure Postgres. Podczas migracji z bazy danych Oracle do usługi Azure Postgres oracle_fdw mogą odgrywać kluczową rolę, zapewniając dostęp do danych, walidację danych, migrację przyrostową i synchronizację danych w czasie rzeczywistym. Podczas korzystania z FDWs należy pamiętać o następujących kluczowych kwestiach:
- Uruchamianie zapytań za pośrednictwem oracle_fdw wiąże się z narzutami w postaci komunikacji sieciowej i negocjacji uwierzytelniania podczas przetwarzania i pobierania danych ze zdalnego serwera Oracle
- Niektóre typy danych mogą wymagać specjalnej obsługi lub konwersji, aby upewnić się, że typy danych są poprawnie mapowane między systemami.
Efektywne korzystanie z oracle_fdw może pomóc w uproszczeniu przejścia bazy danych i zapewnieniu ułatwień dostępu do danych, umożliwiając aplikacjom i danym pozostanie dostępnym w całym procesie migracji.