Sdílet prostřednictvím

Osvědčené postupy pro migrace z Oracle do Azure Database for PostgreSQL

Následující scénáře popisují některé potenciální problémy, ke kterým došlo během migrace Oracle do Azure Postgres. Doporučená řešení mohou být užitečná při řešení těchto problémů při plánování a provádění vlastních migrací.

Scénář: Dvě samostatné, nízká latence, vysoká propustnost, klientské aplikace byly zjištěny nezávisle na stejné databázi. Každá aplikace neúmyslně narazila na dotazy v mezipaměti druhého z vyrovnávacích pamětí. Sdílená zátěž a kombinované soutěžení o prostředky vytvořily situaci, kdy byly sdílené vyrovnávací paměti databáze příliš často vyprázdňovány, což vedlo ke snížení výkonu obou systémů.

Doporučené řešení: Ujistěte se, že vaše počáteční posouzení zachytávají všechny aspekty prostředí databázové platformy, včetně vzorců spotřeby paměti a využití obou systémů globální oblasti (SGA) a struktur paměti globální oblasti programu (PGA). Vyberte odpovídající skupinu výpočetních prostředků, která odpovídá vašim požadavkům na prostředky, a podle potřeby se ujistěte, že se plánovaná kapacita Postgres upraví.

Tip

Rozšíření pg_buffercache poskytuje způsob pro zkoumání využití a umožňuje sledovat, co se děje v mezipaměti sdílené vyrovnávací paměti v reálném čase.

Poměr přístupů do mezipaměti vyrovnávací paměti

Zkoumání poměrů přístupů umožňuje vyhodnotit efektivitu mezipaměti a určit, jestli je velikost sdílené vyrovnávací paměti vhodná. Dobrým poměrem přístupů do mezipaměti je znaménko, že většina požadavků na data se obsluhuje z paměti místo disku a poskytuje optimální výkon:

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;

Nejčastěji používané tabulky a indexy

Zkoumání, ke kterým tabulkám a indexům se nejčastěji přistupuje nebo zabírá nejvíce místa v mezipaměti vyrovnávací paměti, může pomoct identifikovat hotspoty, které se ukládají do mezipaměti v paměti:

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;

Kolize mezipaměti vyrovnávací paměti

Významné kolize v mezipaměti vyrovnávací paměti značí, že několik dotazů může bojovat za stejný prostor vyrovnávací paměti, což vede k kritickým bodům výkonu. Zkoumání umístění a frekvence přístupu k vyrovnávací paměti může pomoct při diagnostice takových problémů:

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;

Scénář: Migrační úsilí bylo zahájeno mezi verzemi platformy Postgres a jejich rozšířením. Navzdory novým funkcím a vylepšením dostupným v nejnovější verzi zůstala verze vybraná na začátku migrace beze změny. Následné úsilí, čas a výdaje byly vynaloženy na upgrade verze databáze Postgres po počáteční migraci, aby bylo dosaženo optimálního výkonu a nových funkcí.

Doporučené řešení: Kdykoli je to možné, při migraci určete prioritu přijetí nejnovější verze Postgres. Týmy vývojářů komunity Postgres pracují neuvěřitelně tvrdě na tom, aby do každé nové verze vytáhly každou část výkonu a stability a v podstatě se drží zpět, což znamená, že výkon zůstává na bočních čarách. Kromě toho plně využijte nové funkce Azure. Nové funkce Azure Postgres zahrnují: úložiště SSDv2, nejnovější serverovou řadu infrastruktury a automatizované ladění indexů a možnosti ladění parametrů autonomního serveru.

Scénář: Organizace, které migrují na Postgres poprvé, můžou být při identifikaci pomalých dotazů neznalé osvědčených postupů a metod. Při implementaci nových typů indexů je třeba věnovat zvláštní pozornost a pozornost. Zejména je databázový stroj Postgres navržen tak, aby optimalizoval výkon dotazů bez nutnosti nebo schopnosti zadávat nápovědy k dotazům.

Doporučené řešení: Rozšíření jsou nedílnou součástí toho, co dělá Postgres tak výkonným. Existuje několik rozšíření, která poskytují důležité funkce, které vám umožní zajistit, aby vaše databáze fungovala ve špičce. Mezi klíčová rozšíření, která je potřeba zvážit, patří:

  • auto_explain: Automaticky zaznamená plány spouštění dotazů, které běží nad rámec nastavené prahové hodnoty. Umožňuje správcům databází diagnostikovat problémy s výkonem a optimalizovat výkon dotazů bez ručního spuštění příkazu EXPLAIN na každém dotazu.

  • pg_trgm: poskytuje funkce a operátory pro určení podobnosti textových dat pomocí porovnávání trigramů. Toto rozšíření je užitečné pro úlohy zahrnující vyhledávání textu, přibližné porovnávání a dotazy založené na podobnosti. V kombinaci s indexy GIN nebo GIST v textových sloupcích nabízí vylepšený výkon dotazů LIKE a vyhledávání podobností.

  • pg_cron: umožňuje plánování a správu pravidelných úloh přímo v databázi. Integruje plánování úloh podobných cron do Postgres, což umožňuje automatizaci úloh rutinní údržby, zpracování dat a podobných opakovaných operací.

Tip

Pokud vaše databázové operace zahrnují značné množství opakovaného vytváření a odstraňování databázových objektů, zvýší se starší kartézské záznamy (řádky) systémové tabulky pg_catalog, což vede k nafouknutí tabulky. Vzhledem k tomu, že pg_catalog je systémová tabulka zapojená do mnoha databázových operací, může nemitigovaná údržba této tabulky vést ke snížení výkonu databáze. Pokud chcete zajistit, aby pg_catalog byla dostatečně udržována a řádně vysátá, je možné nakonfigurovat opakovaný pg_cron plán.

  • pg_hint_plan: Postgres má za cíl poskytovat konzistentní a spolehlivý výkon bez nutnosti ručního zásahu, což vede k úmyslnému rozhodnutí o návrhu, které nezahrnuje rady dotazů. V některých scénářích, kdy jsou potřeba konkrétní a přesné kontroly nad návrhy plánů dotazů, pg_hint_plan nabízí způsob, jak ovlivnit rozhodování plánovače dotazů pomocí tipů vložených do komentářů SQL. Tyto rady umožňují správcům databází vést plánovač dotazů, aby zvolili konkrétní plány, aby optimalizovali složité dotazy nebo vyřešili problémy s výkonem, které plánovač nedokáže zpracovat sami.

Poznámka:

Tyto příklady jen poškrábají povrch neuvěřitelně rozsáhlé sady rozšíření dostupných pro vaši databázi Postgres. Doporučujeme, abyste tato rozšíření plně prozkoumali, abyste nadvýběrovali databázi Postgres. Kromě toho můžete zvážit možnost vytváření vlastních rozšíření, kde vidíte potenciál rozšíření Postgres nad rámec jeho aktuálních možností. Výkonná flexibilní architektura rozšíření zajišťuje, že Postgres se bude vždy moct přizpůsobit a vyvíjet s vašimi požadavky na platformu.

Scénář: V některých případech způsobily strategie starších oddílů tabulky vytvoření tisíců oddílů. I když to mohlo být efektivní při předchozím použití, tyto strategie můžou v Postgresu za určitých okolností zpomalit výkon dotazů. Ve velmi specifických případech nemusí plánovač dotazů při analýze dotazu určit odpovídající klíč oddílu. Výsledné chování generuje delší dobu plánování a způsobuje, že plánování dotazů trvá déle než skutečné spuštění dotazu.

Doporučené řešení: Znovu vyhodnotujte potřebu strategií dělení, které generují příliš velký počet oddílů. Databázový stroj Postgres už nemusí vyžadovat stejnou segmentaci dat a snížení počtu oddílů může pravděpodobně zvýšit výkon. Pokud se vyhodnotí starší schéma dělení a určí se, že je potřeba, zvažte restrukturalizaci dotazu na diskrétní operace, abyste nejprve identifikovali a extrahovali dynamické klíče oddílů a následně v operacích dotazu použili klíče oddílů.

Scénář: V některých případech můžou externí závislosti a okolnosti prostředí vyžadovat scénáře hybridní databáze, ve kterých musí existovat databáze Oracle i Azure Postgres. Existují například situace, kdy jsou fázované migrace nezbytné pro přístup k datům Oracle a jejich dotazování přímo z Azure Postgres bez režie při importu dat nebo úpravě složitých procesů ETL. V jiných případech může souběžné provádění paralelního ověřování dat porovnáním ekvivalentních datových sad v prostředíCh Oracle i Azure Postgres současně zajistit konzistenci a integritu dat během migrace nebo po migraci.

Doporučené řešení: Rozšíření FDW (Foreign Data Wrapper) PostgreSQL představují klíčovou funkci Postgres, která umožňuje přístup k datům uloženým v externích systémech a manipulaci s nimi, jako by se tato data nativně nacházejí v databázi Azure Postgres. FDWs umožňují službě Azure Postgres fungovat jako federovaná databáze, což umožňuje integraci s libovolným počtem externích zdrojů dat, včetně databází Oracle. Sady FDWs vytvářejí v databázi Postgres definice cizí tabulky a tyto cizí tabulky fungují jako proxy pro definovaný externí zdroj dat, který uživatelům umožňuje dotazovat se na tyto cizí tabulky pomocí běžných dotazů SQL. Modul Postgres interně používá externí definici FDW ke komunikaci a koordinaci dat na vyžádání ze vzdáleného zdroje dat.

oracle_fdw: (Foreign Data Wrapper for Oracle) je rozšíření Postgres, které umožňuje přístup k databázím Oracle z Azure Postgres. Při migraci z Oracle do Azure Postgres může oracle_fdw hrát zásadní roli tím, že poskytuje přístup k datům, ověřování dat, přírůstkovou migraci a synchronizaci dat v reálném čase. Při používání FDWs je důležité mít na paměti následující klíčové aspekty:

  • Spouštění dotazů prostřednictvím oracle_fdw bude při zpracování a načítání dat ze vzdáleného serveru Oracle účtují režijní náklady ve formě vyjednávání o síťové komunikaci a ověřování.
  • Některé datové typy můžou potřebovat speciální zpracování nebo převod, aby se zajistilo, že jsou datové typy správně namapované mezi systémy.

Efektivní používání oracle_fdw může potenciálně pomoct zjednodušit přechod databáze a zajistit přístupnost dat tím, že vašim aplikacím a datům umožní zůstat dostupné v průběhu celého procesu migrace.

Související obsah

  • Last updated on