Best practices voor migraties van Oracle naar Azure Database for PostgreSQL
VAN TOEPASSING OP: 
Azure Database for PostgreSQL - Flexibele server
In de volgende scenario's worden enkele mogelijke uitdagingen beschreven die zijn opgetreden tijdens een Migratie van Oracle naar Azure Postgres. De aanbevolen oplossingen kunnen handig zijn bij het overwinnen van deze uitdagingen bij het plannen en uitvoeren van uw eigen migratie(s).
Scenario: Twee afzonderlijke, lage latentie, hoge doorvoer, clienttoepassingen zijn onafhankelijk van elkaar gedetecteerd op dezelfde database. Elke toepassing heeft per ongeluk de query's in de cache van de andere uit de buffers gestoten. De gedeelde belasting en gecombineerde resourceconflicten hebben een situatie gecreëerd waarbij de gedeelde buffers van de database te vaak werden leeggemaakt, wat leidt tot verminderde prestaties in beide systemen.
Aanbevolen oplossing: Zorg ervoor dat uw eerste evaluaties alle aspecten van uw databaseplatformomgeving vastleggen, inclusief de geheugenverbruiks- en gebruikspatronen van zowel SGA-geheugenstructuren (Global Area) als PGA-geheugenstructuren (Program Global Area). Selecteer de juiste rekenfamilie die overeenkomt met uw resourcevereisten en zorg ervoor dat de geplande Postgres-capaciteit naar wens wordt aangepast.
Tip
De pg_buffercache-extensie biedt een manier om het gebruik te onderzoeken en u kunt zien wat er in realtime gebeurt in de gedeelde buffercache.
Buffercachetrefferverhouding
Door trefferverhoudingen te onderzoeken, kunt u de effectiviteit van de cache evalueren en bepalen of de grootte van de gedeelde buffer geschikt is. Een goede cachetrefferverhouding is een teken dat de meeste gegevensaanvragen worden verwerkt vanuit het geheugen in plaats van schijf, wat optimale prestaties biedt:
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;
Meest gebruikte tabellen en indexen
Door te onderzoeken welke tabellen en indexen het vaakst worden geopend en/of de meeste ruimte in de buffercache wordt gebruikt, kunt u hotspots identificeren die in het geheugen in de cache worden opgeslagen:
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;
Buffercacheconflicten
Aanzienlijke conflicten in uw buffercache geven aan dat meerdere query's mogelijk vechten voor dezelfde bufferruimte, wat leidt tot knelpunten in de prestaties. Het onderzoeken van de locatie en frequentie van buffertoegang kan helpen bij het vaststellen van dergelijke problemen:
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: er is een migratie-inspanning geïnitieerd tussen de releases van het Postgres-platform en de releasecycli van het Postgres-platform. Ondanks de nieuwe functies en verbeteringen die beschikbaar zijn in de nieuwste versie, bleef de versie die bij het begin van de migratie werd geselecteerd, ongewijzigd. Volgende extra inspanning, tijd en kosten werden uitgeoefend om de Postgres-databaseversie te upgraden na de eerste migratie om optimale prestaties en nieuwe mogelijkheden te bereiken.
Aanbevolen oplossing: geef waar mogelijk prioriteit aan de acceptatie van de nieuwste releaseversie van Postgres bij de migratie. De Ontwikkelaarsteams van de Postgres-community werken ongelooflijk moeilijk om elk beetje prestaties en stabiliteit in elke nieuwe release te knijpen, en het vasthouden van de prestaties aan de zijlijnen. Profiteer bovendien optimaal van nieuwe Azure-functies. Nieuwe Functies van Azure Postgres zijn onder andere: SSDv2-opslag, de nieuwste serverfamilie van infrastructuur en geautomatiseerde afstemming van indexparameters en mogelijkheden voor het afstemmen van autonome serverparameters.
Scenario: organisaties die voor het eerst migreren naar Postgres, zijn mogelijk niet bekend met aanbevolen procedures en benaderingen bij het identificeren van trage query's. Speciale zorg en aandacht moet worden uitgeoefend bij het implementeren van op de juiste wijze nieuwe indextypen. Met name de Postgres-database-engine is ontworpen om de queryprestaties te optimaliseren zonder dat er queryhints hoeven te worden opgegeven.
Aanbevolen oplossing: Extensies vormen een integraal onderdeel van wat Postgres zo krachtig maakt. Er zijn verschillende extensies die belangrijke functies kunnen bieden waarmee u ervoor kunt zorgen dat uw database op piekprestaties werkt. Enkele belangrijke extensies om rekening mee te houden zijn:
auto_explain: registreert automatisch uitvoeringsplannen voor query's die worden uitgevoerd buiten een ingestelde drempelwaarde. Hiermee kunnen databasebeheerders prestatieproblemen vaststellen en queryprestaties optimaliseren zonder UITLEG handmatig uit te voeren voor elke query.
pg_trgm: biedt functies en operators voor het bepalen van overeenkomsten tussen tekstgegevens via trigramvergelijking. Deze extensie is handig voor taken met betrekking tot zoeken in tekst, fuzzy overeenkomsten en op overeenkomsten gebaseerde query's. Gecombineerd met GIN- of GIST-indexen op tekstkolommen bieden verbeterde prestaties voor LIKE-query's en overeenkomsten.
pg_cron: maakt het mogelijk om periodieke taken rechtstreeks in de database te plannen en te beheren. Integreert cron-achtige jobplanning in Postgres, waardoor routineonderhoudstaken, gegevensverwerking en soortgelijke terugkerende bewerkingen kunnen worden geautomatiseerd.
Tip
Als uw databasebewerkingen betrekking hebben op een aanzienlijke hoeveelheid herhaalde creatie en verwijdering van databaseobjecten, nemen oudere pg_catalog systeemtabel tuples toe, wat leidt tot tabel 'bloat'. Aangezien pg_catalog een systeemtabel is die betrokken is bij veel databasebewerkingen, kan ongemitteerd onderhoud in deze tabel leiden tot verminderde prestaties in de database. Ervoor zorgen dat pg_catalog adequaat wordt onderhouden en op de juiste wijze wordt leeggezogen, kan worden gegarandeerd door een terugkerend pg_cron schema te configureren.
- pg_hint_plan: Postgres streeft ernaar consistente en betrouwbare prestaties te bieden zonder handmatige tussenkomst, wat resulteert in de opzettelijke ontwerpbeslissing om geen queryhints op te nemen. Voor sommige scenario's waarin specifieke en nauwkeurige controle over ontwerp van queryplannen nodig is, biedt pg_hint_plan een manier om de beslissingen van de queryplanner te beïnvloeden met behulp van hints die zijn ingesloten in SQL-opmerkingen. Met deze hints kunnen databasebeheerders de queryplanner begeleiden bij het kiezen van specifieke plannen om complexe query's te optimaliseren of prestatieproblemen op te lossen die de planner mogelijk niet zelfstandig kan verwerken.
Notitie
Deze voorbeelden zijn alleen maar een krassen op het oppervlak van de ongelooflijk grote set extensies die beschikbaar zijn voor uw Postgres-database. We raden u aan deze extensies volledig te verkennen om uw Postgres-database te vervangen. U kunt ook rekening houden met de mogelijkheid om uw eigen extensies te ontwerpen, waar u het potentieel ziet om Postgres uit te breiden buiten de huidige mogelijkheden. De krachtige flexibele uitbreidingsarchitectuur zorgt ervoor dat Postgres zich altijd kan aanpassen en ontwikkelen met uw platformvereisten.
Scenario: In sommige gevallen hebben verouderde strategieën voor tabelpartitie geresulteerd in het maken van duizenden partities. Hoewel dit mogelijk effectief is bij gebruik eerder, kunnen deze strategieën de prestaties van query's in Postgres vertragen onder bepaalde omstandigheden. In zeer specifieke gevallen kan de queryplanner mogelijk niet de juiste partitiesleutel bepalen bij het parseren van de query. Het resulterende gedrag genereert een langere planningstijd en zorgt ervoor dat het plannen van query's langer duurt dan de werkelijke uitvoering van de query.
Aanbevolen oplossing: evalueer de noodzaak voor partitioneringsstrategieën die te veel partities genereren opnieuw. De Postgres-database-engine vereist mogelijk niet langer dezelfde segmentatie van gegevens en het verminderen van het aantal partities kan de prestaties waarschijnlijk verbeteren. Als een verouderd partitioneringsschema wordt beoordeeld en dit is vereist, kunt u overwegen om uw query in discrete bewerkingen te herstructureren om eerst dynamische partitiesleutels te identificeren en te extraheren en vervolgens de partitiesleutels in uw querybewerkingen te gebruiken.
Scenario: Soms kunnen externe afhankelijkheden en omgevingsomstandigheden hybride databasescenario's vereisen waarbij zowel Oracle- als Azure Postgres-databases naast elkaar moeten bestaan. Er kunnen zich bijvoorbeeld situaties voordoen waarbij gefaseerde migraties nodig zijn om rechtstreeks vanuit Azure Postgres toegang te krijgen tot Oracle-gegevens en er query's op uit te voeren zonder dat er overhead nodig is om gegevens te importeren of complexe ETL-processen te wijzigen. In andere gevallen kunt u parallelle gegevensvalidatie uitvoeren door equivalente gegevenssets in zowel Oracle- als Azure Postgres-omgevingen tegelijkertijd te vergelijken, zodat gegevensconsistentie en integriteit tijdens en/of na uw migratie kunnen worden gegarandeerd.
Aanbevolen oplossing: PostgreSQL Foreign Data Wrapper -extensies (FDW) zijn een belangrijke Postgres-functie waarmee u gegevens kunt openen en bewerken die zijn opgeslagen in externe systemen alsof die gegevens zich in de systeemeigen Azure Postgres-database bevinden. Met FDW's kan Azure Postgres functioneren als een federatieve database, waardoor integratie met een willekeurig aantal externe gegevensbronnen, waaronder Oracle-databases, mogelijk is. FDW's maken refererende tabeldefinities in uw Postgres-database en deze refererende tabellen fungeren als proxy voor uw gedefinieerde externe gegevensbron, zodat gebruikers query's kunnen uitvoeren op deze refererende tabellen met behulp van reguliere SQL-query's. Intern gebruikt de Postgres-engine de externe FDW-definitie om te communiceren met en gegevens op aanvraag te coördineren vanuit de externe gegevensbron.
oracle_fdw: (Foreign Data Wrapper voor Oracle) is een Postgres-extensie waarmee u toegang hebt tot Oracle-databases vanuit Azure Postgres. Bij het migreren van Oracle naar Azure Postgres kan oracle_fdw een cruciale rol spelen door gegevenstoegang, gegevensvalidatie, incrementele migratie en realtime gegevenssynchronisatie te bieden. Houd rekening met de volgende belangrijke overwegingen bij het gebruik van FDW's:
- Het uitvoeren van query's via oracle_fdw leidt tot overhead in de vorm van netwerkcommunicatie en verificatieonderhandeling terwijl de gegevens worden verwerkt en opgehaald van de externe Oracle-server
- Sommige gegevenstypen hebben mogelijk speciale verwerking of conversie nodig om ervoor te zorgen dat gegevenstypen correct zijn toegewezen tussen systemen.
Effectief gebruik van oracle_fdw kan helpen bij het vereenvoudigen van de databaseovergang en het waarborgen van de toegankelijkheid van gegevens door uw toepassingen en gegevens toegankelijk te maken gedurende het hele migratieproces.