Metodtips för migreringar från Oracle till Azure Database for PostgreSQL
GÄLLER FÖR: 
Azure Database for PostgreSQL – flexibel server
Följande scenarier beskriver några av de potentiella utmaningar som har påträffats under en Oracle till Azure Postgres-migrering. De rekommenderade lösningarna kan vara till hjälp för att övervinna dessa utmaningar när du planerar och kör dina egna migreringar.
Scenario: Två separata klientprogram med låg svarstid och högt dataflöde identifierades oberoende av varandra som arbetar på samma databas. Varje program stötte oavsiktligt ut den andras cachelagrade frågor från buffertarna. Den delade belastningen och den kombinerade resurskonkurrationen skapade en situation där databasens delade buffertar tömdes för ofta, vilket resulterade i försämrade prestanda i båda systemen.
Rekommenderad lösning: Se till att dina första utvärderingar samlar in ALLA aspekter av databasens plattformsmiljö, inklusive minnesförbrukning och användningsmönster för båda systemens globala områdesstrukturer (SGA) och program globalt område (PGA). Välj lämplig beräkningsfamilj som matchar dina resurskrav och se till att din planerade Postgres-kapacitet justeras efter behov.
Dricks
Tillägget pg_buffercache ger ett sätt att undersöka användningen och gör att du kan se vad som händer i den delade buffertcachen i realtid.
Kvot för buffertcacheträff
Genom att undersöka träffkvoter kan du utvärdera cacheeffektiviteten och avgöra om den delade buffertstorleken är lämplig. Ett bra cacheträffförhållande är ett tecken på att de flesta databegäranden hanteras från minnet i stället för disken, vilket ger optimala prestanda:
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;
Tabeller och index som används oftast
Att undersöka vilka tabeller och index som används oftast och/eller som upptar mest utrymme i buffertcachen kan hjälpa dig att identifiera hotspots som cachelagras i minnet:
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;
Konkurrens om buffertcache
Betydande konkurrens i buffertcachen indikerar att flera frågor kan kämpa för samma buffertutrymme, vilket leder till flaskhalsar i prestanda. Att undersöka platsen och frekvensen för buffertåtkomst kan hjälpa dig att diagnostisera sådana problem:
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;
Scenario: En migreringsinsats initierades mellan och sträckte sig över versioner av Postgres-plattformens lanseringscykler. Trots att nya funktioner och förbättringar är tillgängliga i den senaste versionen var den version som valdes i början av migreringen oförändrad. Efterföljande ytterligare ansträngning, tid och kostnad utövades för att uppgradera Postgres-databasversionen efter den första migreringen för att uppnå optimal prestanda och nya funktioner.
Rekommenderad lösning: Prioritera när det är möjligt införandet av den senaste versionen av Postgres när du migrerar. Postgres community dev teams arbetar otroligt hårt för att pressa varje bit av prestanda och stabilitet i varje ny version, och att hålla tillbaka innebär i huvudsak att lämna prestanda vid sidlinjen. Dessutom kan du dra full nytta av nya Azure-funktioner. Nya Funktioner i Azure Postgres är: SSDv2-lagring, den senaste serverfamiljen med infrastruktur och automatiserad indexjustering och funktioner för justering av autonoma serverparametrar.
Scenario: Organisationer som migrerar till Postgres för första gången kanske inte känner till metodtips och metoder när de identifierar långsamma frågor. Särskild försiktighet och uppmärksamhet bör utövas när lämpliga nya indextyper implementeras. I synnerhet är Postgres-databasmotorn utformad för att optimera frågeprestanda utan behov eller möjlighet att ange frågetips.
Rekommenderad lösning: Tillägg är en integrerad del av det som gör Postgres så kraftfullt. Det finns flera tillägg som kan ge viktiga funktioner som gör att du kan se till att databasen fungerar med hög prestanda. Några viktiga tillägg att överväga är:
auto_explain: loggar automatiskt körningsplaner för frågor som körs utanför ett angivet tröskelvärde. Gör att databasadministratörer kan diagnostisera prestandaproblem och optimera frågeprestanda utan att köra EXPLAIN manuellt på varje fråga.
pg_trgm: tillhandahåller funktioner och operatorer för att fastställa likheten mellan textbaserade data genom trigrammatchning. Det här tillägget är användbart för uppgifter som rör textsökning, fuzzy-matchning och likhetsbaserade frågor. Kombinerat med GIN- eller GIST-index i textkolumner ger bättre prestanda för LIKE-frågor och likhetssökningar.
pg_cron: möjliggör schemaläggning och hantering av periodiska uppgifter direkt i databasen. Integrerar cron-liknande jobbschemaläggning i Postgres som möjliggör automatisering av rutinmässiga underhållsaktiviteter, databearbetning och liknande repetitiva åtgärder.
Dricks
Om databasåtgärderna omfattar en betydande mängd upprepade skapande och borttagning av databasobjekt ökar äldre pg_catalog systemtabelltupplar, vilket leder till att tabellen "svälls upp". Eftersom pg_catalog är en systemtabell som ingår i många databasåtgärder kan obekrävt underhåll på den här tabellen leda till försämrade prestanda i databasen. Genom att konfigurera ett återkommande pg_cron schema kan du säkerställa att pg_catalog underhålls och dammsugs på rätt sätt.
- pg_hint_plan: Postgres syftar till att tillhandahålla konsekventa och tillförlitliga prestanda utan att behöva manuella åtgärder, vilket resulterar i ett avsiktligt designbeslut att inte inkludera frågetips. För vissa scenarier där specifik och exakt kontroll över frågeplansdesign behövs pg_hint_plan ger ett sätt att påverka frågehanterarens beslut med hjälp av tips som är inbäddade i SQL-kommentarer. Med de här tipsen kan databasadministratörer vägleda frågehanteraren att välja specifika planer för att optimera komplexa frågor eller åtgärda prestandaproblem som planeraren kanske inte kan hantera på egen hand.
Kommentar
De här exemplen skrapar bara ytan på den otroligt stora uppsättning tillägg som är tillgängliga för din Postgres-databas. Vi rekommenderar att du utforskar dessa tillägg fullt ut för att superdebitera din Postgres-databas. Du kan också överväga möjligheten att skapa egna tillägg där du ser potentialen att expandera Postgres utöver dess nuvarande funktioner. Den kraftfullt flexibla tilläggsarkitekturen säkerställer att Postgres alltid kommer att kunna anpassa sig och utvecklas med dina plattformskrav.
Scenario: I vissa fall har strategier för äldre tabellpartitioner resulterat i att tusentals partitioner har skapats. Även om detta kan ha varit effektivt när de användes tidigare, kan dessa strategier sänka frågeprestandan i Postgres under vissa omständigheter. I mycket specifika fall kanske frågehanteraren inte kan fastställa lämplig partitionsnyckel när frågan parsas. Det resulterande beteendet genererar längre planeringstid och gör att frågeplaneringen tar längre tid än den faktiska frågekörningen.
Rekommenderad lösning: Utvärdera behovet av partitioneringsstrategier som genererar ett alltför stort antal partitioner. Postgres-databasmotorn kanske inte längre kräver samma segmentering av data och att minska antalet partitioner kan sannolikt förbättra prestandan. Om ett äldre partitioneringsschema utvärderas och det bedöms vara nödvändigt bör du överväga att omstrukturera frågan till diskreta åtgärder för att först identifiera och extrahera dynamiska partitionsnycklar och sedan använda partitionsnycklarna i dina frågeåtgärder.
Scenario: Ibland kan externa beroenden och miljöförhållanden kräva hybriddatabasscenarier där både Oracle- och Azure Postgres-databaser måste samexistera. Det kan till exempel finnas tillfällen då stegvisa migreringar krävs för att komma åt och köra frågor mot Oracle-data direkt från Azure Postgres utan att behöva importera data eller ändra komplexa ETL-processer. I andra fall kan parallell dataverifiering genom att jämföra motsvarande datauppsättningar i både Oracle- och Azure Postgres-miljöer samtidigt bidra till att säkerställa datakonsekvens och integritet under och/eller efter migreringen.
Rekommenderad lösning: PostgreSQL FDW-tillägg (Foreign Data Wrapper) är en viktig Postgres-funktion som gör att du kan komma åt och manipulera data som lagras i externa system som om dessa data finns i Azure Postgres-databasen internt. Med FDW:er kan Azure Postgres fungera som en federerad databas, vilket möjliggör integrering med valfritt antal externa datakällor, inklusive Oracle-databaser. FDW:er skapar definitioner av sekundärtabeller i Postgres-databasen och dessa sekundärtabeller fungerar som proxy för din definierade externa datakälla så att användarna kan köra frågor mot dessa sekundärtabeller med vanliga SQL-frågor. Internt använder Postgres-motorn den externa FDW-definitionen för att kommunicera med och samordna data på begäran från fjärrdatakällan.
oracle_fdw: (Foreign Data Wrapper for Oracle) är ett Postgres-tillägg som gör att du kan komma åt Oracle-databaser från Azure Postgres. När du migrerar från Oracle till Azure Postgres kan oracle_fdw spela en avgörande roll genom att tillhandahålla dataåtkomst, dataverifiering, inkrementell migrering och datasynkronisering i realtid. Det är viktigt att tänka på följande viktiga överväganden när du använder FDW:n:
- Att köra frågor via oracle_fdw medför kostnader i form av nätverkskommunikation och autentiseringsförhandling medan data bearbetas och hämtas från den fjärranslutna Oracle-servern
- Vissa datatyper kan behöva särskild hantering eller konvertering för att säkerställa att datatyper mappas korrekt mellan system.
Att effektivt använda oracle_fdw kan bidra till att förenkla databasövergången och säkerställa datatillgänglighet genom att göra dina program och data tillgängliga under hela migreringsprocessen.