- Amazon Relational Database Service
Pagine non valideIncoerenza dell'indiceTasso di transazione eccezionalmente elevato

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Questa sezione esplora altri motivi che possono impedire che l'aspirapolvere compia progressi. Questi problemi non sono attualmente identificabili direttamente dalla funzione. postgres_get_av_diag()

Pagine non valide

Un errore di pagina non valida si verifica quando PostgreSQL rileva una mancata corrispondenza nel checksum di una pagina durante l'accesso a quella pagina. I contenuti sono illeggibili e impediscono all'autovacuum di congelare le tuple. Ciò interrompe efficacemente il processo di pulizia. Il seguente errore è scritto nel registro di PostgreSQL:

WARNING:  page verification failed, calculated checksum YYYYY but expected XXXX
ERROR:  invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT:  automatic vacuum of table myschema.mytable

Determina il tipo di oggetto

ERROR: invalid page in block 4305910 of relation base/16403/186752608 
WARNING: page verification failed, calculated checksum 50065 but expected 60033

Dal messaggio di errore, il percorso base/16403/186752608 fornisce le seguenti informazioni:

  • «base» è il nome della directory nella directory dei dati PostgreSQL.

  • «16403" è l'OID del database, che puoi cercare nel catalogo di sistema. pg_database

  • «186752608" è ilrelfilenode, che è possibile utilizzare per cercare lo schema e il nome dell'oggetto nel catalogo di sistema. pg_class

Controllando l'output della seguente query nel database interessato, è possibile determinare il tipo di oggetto. La seguente query recupera le informazioni sull'oggetto per oid: 186752608. Sostituisci l'OID con quello relativo all'errore riscontrato.

SELECT
    relname AS object_name,
    relkind AS object_type,
    nspname AS schema_name
FROM
    pg_class c
    JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
    c.oid = 186752608;

Per ulteriori informazioni, consulta la pg_classdocumentazione di PostgreSQL per tutti i tipi di oggetti supportati, indicata nella colonna in. relkind pg_class

Guida

La soluzione più efficace per questo problema dipende dalla configurazione dell'istanza Amazon RDS specifica e dal tipo di dati interessati dalla pagina incoerente.

Se il tipo di oggetto è un indice:

Si consiglia di ricostruire l'indice.

  • Utilizzo dell'CONCURRENTLYopzione: prima della versione 12 di PostgreSQL, la ricostruzione di un indice richiedeva un blocco tabella esclusivo, che limitava l'accesso alla tabella. Con PostgreSQL versione 12 e versioni successive, l'opzione consente CONCURRENTLY il blocco a livello di riga, migliorando significativamente la disponibilità della tabella. Di seguito è riportato il comando:

    REINDEX INDEX ix_name CONCURRENTLY;

    Sebbene CONCURRENTLY sia meno fastidioso, può essere più lento su tavoli occupati. Se possibile, valuta la possibilità di creare l'indice durante i periodi di traffico ridotto.

    Per ulteriori informazioni, consulta la documentazione di PostgreSQL REINDEX.

  • Utilizzo dell'INDEX_CLEANUP FALSEopzione: se gli indici sono grandi e si stima che richiedano molto tempo per essere completati, puoi sbloccare l'autovacuum eseguendo un manuale escludendo gli indici. VACUUM FREEZE Questa funzionalità è disponibile nella versione 12 di PostgreSQL e nelle versioni successive.

    Bypassare gli indici ti consentirà di saltare il processo di vacuità dell'indice incoerente e di mitigare il problema dell'involucro. Tuttavia, ciò non risolverà il problema sottostante relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricostruire l'indice.

Se il tipo di oggetto è una vista materializzata:

Se si verifica un errore di pagina non valida in una vista materializzata, accedi al database interessato e aggiornalo per risolvere la pagina non valida:

Aggiorna la vista materializzata:

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

Se l'aggiornamento fallisce, prova a ricreare:

DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

L'aggiornamento o la ricreazione della vista materializzata la ripristina senza influire sui dati della tabella sottostante.

Per tutti gli altri tipi di oggetti:

Per tutti gli altri tipi di oggetti, contatta l' AWS assistenza.

Incoerenza dell'indice

Un indice logicamente incoerente può impedire che l'autovacuum compia progressi. I seguenti errori o errori simili vengono registrati durante la fase di vuoto dell'indice o quando si accede all'indice tramite istruzioni SQL.

ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT:  while vacuuming index index_name of relation schema.table

Guida

Ricostruisci l'indice o salta gli indici utilizzando il manuale. INDEX_CLEANUP VACUUM FREEZE Per informazioni su come ricostruire l'indice, consulta Se il tipo di oggetto è un indice.

  • Utilizzo dell'opzione CONCURRENTLY — Prima della versione 12 di PostgreSQL, la ricostruzione di un indice richiedeva un blocco tabella esclusivo, che limitava l'accesso alla tabella. Con PostgreSQL versione 12 e versioni successive, l'opzione CONCURRENTLY consente il blocco a livello di riga, migliorando significativamente la disponibilità della tabella. Di seguito è riportato il comando:

    REINDEX INDEX ix_name CONCURRENTLY;

    Anche se CONCURRENTLY comporta meno interruzioni, può essere più lenta sui tavoli occupati. Se possibile, valuta la possibilità di creare l'indice durante i periodi di traffico ridotto. Per ulteriori informazioni, vedere REINDEX nella documentazione di PostgreSQL.

  • Utilizzo dell'opzione INDEX_CLEANUP FALSE: se gli indici sono grandi e si stima che richiedano molto tempo per essere completati, puoi sbloccare l'autovacuum eseguendo un VACUUM FREEZE manuale escludendo gli indici. Questa funzionalità è disponibile nella versione 12 di PostgreSQL e nelle versioni successive.

    Bypassare gli indici ti consentirà di saltare il processo di vacuità dell'indice incoerente e di mitigare il problema dell'involucro. Tuttavia, ciò non risolverà il problema sottostante relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricostruire l'indice.

Tasso di transazione eccezionalmente elevato

In PostgreSQL, tassi di transazione elevati possono influire in modo significativo sulle prestazioni di autovacuum, portando a una pulizia più lenta delle tuple morte e a un aumento del rischio di avvolgimento dell'ID delle transazioni. È possibile monitorare il tasso di transazione misurando la differenza tra due periodi di tempo, in genere al secondo. max(age(datfrozenxid)) Inoltre, puoi utilizzare le seguenti metriche dei contatori di RDS Performance Insights per misurare il tasso di transazione (la somma di xact_commit e xact_rollback) che è il numero totale di transazioni.

Contatore Tipo Unità Parametro

xact_commit

Transazioni

Commit al secondo

db.Transactions.xact_commit

xact_rollback

Transazioni

Rollback al secondo

db.Transactions.xact_rollback

Un aumento rapido indica un carico di transazioni elevato, che può sovraccaricare l'autovacuum, con conseguenti ingrossamenti, conflitti tra blocchi e potenziali problemi di prestazioni. Ciò può influire negativamente sul processo di autovacuum in un paio di modi:

  • Attività delle tabelle: la tabella specifica oggetto di cancellazione potrebbe registrare un volume elevato di transazioni, con conseguenti ritardi.

  • Risorse di sistema L'intero sistema potrebbe essere sovraccarico, rendendo difficile per Autovacuum l'accesso alle risorse necessarie per funzionare in modo efficiente.

Considerate le seguenti strategie per consentire all'autovacuum di funzionare in modo più efficace e di tenere il passo con le sue attività:

  1. Se possibile, riduci il tasso di transazione. Prendi in considerazione la possibilità di raggruppare o raggruppare transazioni simili, ove possibile.

  2. Scegli come target le tabelle aggiornate di frequente con VACUUM FREEZE operazioni manuali ogni notte, settimanalmente o bisettimanalmente durante le ore non di punta.

  3. Valuta la possibilità di ampliare la classe di istanza per allocare più risorse di sistema per gestire l'elevato volume di transazioni e l'autovacuum.