Condividi tramite

Procedure consigliate per le migrazioni da Oracle a Database di Azure per PostgreSQL

I seguenti scenari illustrano alcune delle potenziali sfide riscontrate durante una migrazione da Oracle ad Azure Postgres. Le soluzioni consigliate possono essere utili per superare queste sfide durante la pianificazione e l'esecuzione delle migrazioni.

Scenario: sono state individuate due applicazioni client separate, a bassa latenza e ad alta velocità effettiva, che operavano in modo indipendente sullo stesso database. Ogni applicazione eliminava inavvertitamente dai buffer le query memorizzate nella cache dell'altra applicazione. Il caricamento condiviso e la contesa combinata delle risorse hanno creato una situazione in cui i buffer condivisi del database sono stati scaricati troppo frequentemente, con conseguente riduzione delle prestazioni in entrambi i sistemi.

Soluzione consigliata: assicurarsi che le valutazioni iniziali tengano conto di TUTTI gli aspetti dell'ambiente della piattaforma di database, compresi il consumo di memoria e i modelli di utilizzo delle strutture di memoria dell'area globale del sistema (SGA) e dell'area globale del programma (PGA). Selezionare la famiglia di calcolo appropriata per i propri requisiti di risorse e assicurarsi che la capacità pianificata di Postgres venga regolata come richiesto.

Suggerimento

L'estensione pg_buffercache fornisce un mezzo per esaminare l'utilizzo e consente di osservare ciò che accade nella cache del buffer condiviso in tempo reale.

Percentuale riscontri cache buffer

L'analisi delle percentuali di riscontri consente di valutare l'efficacia della cache e determinare se le dimensioni del buffer condiviso sono adeguate. Una buona percentuale di riscontro nella cache è un segno che la maggior parte delle richieste di dati viene servita dalla memoria anziché dal disco, offrendo prestazioni ottimali:

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;

Tabelle e indici a cui si accede più frequentemente

Esaminare le tabelle e gli indici a cui si accede più frequentemente e/o che occupano più spazio nella cache del buffer può aiutare a identificare gli hotspot memorizzati nella cache:

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;

Contesa a livello di pool di buffer

Una contesa significativa nel pool di buffer indica che più query potrebbero competere per lo stesso spazio nel buffer, determinando colli di bottiglia nelle prestazioni. L'analisi della posizione e della frequenza di accesso al buffer può aiutare a diagnosticare questi problemi:

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: è stata avviata un'operazione di migrazione tra le versioni dei cicli di rilascio della piattaforma Postgres. Nonostante le nuove funzionalità e i miglioramenti disponibili nella versione più recente, la versione selezionata all'inizio della migrazione è rimasta invariata. Successivamente, sono stati impiegati ulteriori sforzi, tempo e risorse per aggiornare la versione del database Postgres dopo la migrazione iniziale, al fine di ottenere prestazioni ottimali e nuove funzionalità.

Soluzione consigliata: quando è possibile, durante la migrazione assegnare la priorità all'adozione dell’ultima versione rilasciata di Postgres. I team di sviluppo della comunità Postgres lavorano duramente per ottenere il massimo in termini di prestazioni e stabilità in ogni nuova versione, e frenare significa essenzialmente lasciare le prestazioni in secondo piano. In questo modo, inoltre, è possibile sfruttare appieno le nuove funzionalità di Azure. Le nuove funzionalità di Azure Postgres includono: archiviazione SSDv2, l'ultima famiglia di server dell'infrastruttura e funzionalità di ottimizzazione automatica degli indici e dei parametri del server.

Scenario: Le organizzazioni che eseguono la migrazione a Postgres per la prima volta potrebbero non conoscere le procedure consigliate e gli approcci quando si identificano query a esecuzione lenta. È necessario prestare particolare attenzione e cura nell'implementazione dei nuovi tipi di indici. In particolare, il motore di database Postgres è progettato per ottimizzare le prestazioni delle query senza la necessità o la possibilità di specificare suggerimenti per le query.

Soluzione consigliata: le estensioni sono parte integrante di ciò che rende Postgres così potente. Esistono diverse estensioni che possono fornire importanti funzionalità che consentono di garantire il funzionamento ottimale del database. Alcune estensioni chiave da considerare includono:

  • auto_explain: registra automaticamente i piani di esecuzione per le query che superano una soglia prestabilita. Consente agli amministratori di database di diagnosticare i problemi di prestazioni e ottimizzare le prestazioni delle query senza eseguire manualmente EXPLAIN su ogni query.

  • pg_trgm: fornisce funzioni e operatori per determinare la somiglianza dei dati testuali tramite la corrispondenza dei trigrammi. Questa estensione è utile per attività che prevedono la ricerca di testo, la corrispondenza fuzzy e le query basate sulla somiglianza. In combinazione con gli indici GIN o GIST sulle colonne di testo, offre prestazioni migliorate nelle query LIKE e nelle ricerche di similarità.

  • pg_cron: consente la pianificazione e la gestione di attività periodiche direttamente all'interno del database. Integra la pianificazione di processi di tipo cron in Postgres, consentendo l'automazione delle attività di manutenzione ordinaria, dell'elaborazione dei dati e di operazioni ripetitive simili.

Suggerimento

Se le operazioni sul database comportano un numero significativo di creazioni e cancellazioni ripetute di oggetti del database, le tuple della tabella di sistema pg_catalog più vecchie aumenteranno, causando un “gonfiamento” della tabella. Poiché pg_catalog è una tabella di sistema coinvolta in molte operazioni del database, una manutenzione non mitigata su questa tabella può comportare un calo delle prestazioni dell'intero database. È possibile garantire che pg_catalog sia adeguatamente mantenuto e opportunamente pulito configurando una pianificazione pg_cron ricorrente.

  • pg_hint_plan: Postgres mira a fornire prestazioni costanti e affidabili senza la necessità di interventi manuali, che ha portato alla decisione di progettazione intenzionale di non includere suggerimenti per le query. Per alcuni scenari in cui è necessario un controllo specifico e preciso sulle progettazioni dei piani di query, pg_hint_plan consente di influenzare le decisioni di Query Planner usando hint incorporati nei commenti SQL. Questi hint consentono agli amministratori di database di guidare query planner a scegliere piani specifici per ottimizzare query complesse o risolvere i problemi di prestazioni che potrebbero non essere in grado di gestire autonomamente.

Note

Questi esempi sono solo una piccola parte dell'incredibile quantità di estensioni disponibili per il database Postgres. Per potenziare il database Postgres, si consiglia di esplorare appieno queste estensioni. È inoltre possibile valutare la possibilità di creare estensioni personalizzate laddove si intraveda il potenziale per espandere Postgres oltre le sue attuali capacità. L'architettura di estensione estremamente flessibile garantisce che Postgres sarà sempre in grado di adattarsi ed evolversi in base ai requisiti della propria piattaforma.

Scenario: in alcuni casi, le strategie di partizionamento delle tabelle legacy hanno portato alla creazione di migliaia di partizioni. Anche se questo potrebbe essere stato efficace se usato in precedenza, queste strategie possono rallentare le prestazioni delle query in Postgres in determinate circostanze. In istanze molto specifiche, Query Planner potrebbe non essere in grado di determinare la chiave di partizione appropriata durante l'analisi della query. Il comportamento risultante genera tempi di pianificazione prolungati e fa sì che la pianificazione delle query richieda più tempo rispetto all'effettiva esecuzione delle query.

Soluzione consigliata: rivalutare la necessità di strategie di partizionamento che generano un numero eccessivo di partizioni. Il motore di database Postgres potrebbe non richiedere più la stessa segmentazione dei dati e ridurre il numero di partizioni potrebbe probabilmente migliorare le prestazioni. Se viene valutato uno schema di partizionamento legacy e se ne determina la necessità, prendere in considerazione la possibilità di ristrutturare la query in operazioni discrete per identificare ed estrarre prima le chiavi di partizione dinamiche e quindi usare successiamente le chiavi di partizione nelle operazioni di query.

Scenario: A volte, le dipendenze esterne e le circostanze ambientali potrebbero richiedere scenari di database ibridi in cui i database Oracle e Postgres di Azure devono coesistere. Ad esempio, potrebbero esserci occasioni in cui le migrazioni in più fasi sono necessarie per accedere ai dati Oracle ed eseguire query direttamente da Postgres di Azure senza sovraccaricare l'importazione di dati o la modifica di processi ETL complessi. In altri casi, eseguire una convalida parallela dei dati confrontando contemporaneamente set di dati equivalenti sia nell'ambiente Oracle che in Azure Postgres può aiutare a garantire la coerenza e l'integrità dei dati durante e/o dopo la migrazione.

Soluzione consigliata: le estensioni FDW (Foreign Data Wrapper) di PostgreSQL sono una funzionalità chiave di Postgres che consente di accedere e manipolare i dati archiviati in sistemi esterni come se tali dati risiedessero nativamente nel database Azure Postgres. FDW consente ad Azure Postgres di funzionare come database federato, consentendo l'integrazione con un numero illimitato di origini dati esterne, inclusi i database Oracle. Gli FDW creano definizioni di tabelle esterne all'interno del database Postgres e queste tabelle esterne svolgono la funzione di proxy per l'origine dati esterna definita, consentendo agli utenti di eseguire query su queste tabelle esterne usando normali query SQL. Internamente, il motore Postgres usa la definizione FDW esterna per comunicare e coordinare i dati su richiesta dall’origine dati remota.

oracle_fdw: (Foreign Data Wrapper per Oracle) è un'estensione Postgres che consente di accedere ai database Oracle da Azure Postgres. Durante la migrazione da Oracle ad Azure Postgres, oracle_fdw può svolgere un ruolo cruciale fornendo accesso ai dati, convalida dei dati, migrazione incrementale e sincronizzazione dei dati in tempo reale. È importante tenere presenti le seguenti considerazioni fondamentali quando si utilizzano gli FDW:

  • L'esecuzione di query tramite oracle_fdw comporterà un sovraccarico sotto forma di comunicazioni di rete e negoziazione dell'autenticazione mentre i dati vengono elaborati e recuperati dal server Oracle remoto
  • Alcuni tipi di dati potrebbero richiedere una gestione o una conversione speciali per garantire che i tipi di dati siano mappati correttamente tra i sistemi.

Un uso efficace di oracle_fdw può contribuire a semplificare la transizione del database e garantire l'accessibilità dei dati, consentendo alle applicazioni e ai dati di rimanere accessibili durante l'intero processo di migrazione.

Contenuti correlati

  • Last updated on