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à.

Recupero dello spazio di archiviazione mediante aspirazione

Postgre SQL Multiversion Concurrency Control (MVCC) aiuta a preservare l'integrità dei dati salvando una copia interna delle righe aggiornate o eliminate fino al completamento o al rollback di una transazione. Queste copie, chiamate anche tuple, possono causare il sovraccarico della tabella se non vengono pulite regolarmente. SQLLe istanze Postgre ordinano le transazioni in base alla transazione IDs e Postgre SQL utilizza la tecnologia basata sull'ID delle transazioni per controllare la visibilità delle tuple e garantire l'isolamento MVCC delle transazioni. Ogni transazione stabilisce un'istantanea dei dati e ogni tupla ha una versione. Sia l'istantanea che la versione sono basate sull'ID della transazione.

Per ripulire i dati, l'VACUUMutilità svolge quattro funzioni chiave in Postgre: SQL

Allo stesso modoMVCC, l'aspirapolvere in Aurora SQL Postgre è basato sull'ID della transazione. Se c'è una transazione in corso quando inizia l'operazione di vacuuming, le righe che sono ancora visibili in quella transazione non vengono rimosse.

Per ulteriori informazioni sull'VACUUMutilità, consulta VACUUMla documentazione di SQL Postgre. Per ulteriori informazioni sul VACUUM supporto in Aurora Postgre SQL Limitless Database, vedere. VACUUM

AUTOVACUUM

Aurora Postgre SQL utilizza le AUTOVACUUM utilità VACUUM and per rimuovere le tuple non necessarie. Il meccanismo alla base di un AUTOVACUUM manuale VACUUM è lo stesso; l'unica differenza è l'automazione.

AUTOVACUUMin Aurora Postgre e Aurora SQL SQL Postgre Limitless Database è una combinazione delle utilità e. VACUUM ANALYZE AUTOVACUUMdetermina quali database e tabelle pulire, in base a una regola predefinita, come la percentuale di tuple morte e il numero di inserti.

Ad esempio, AUTOVACUUM «si riattiva» periodicamente per eseguire la pulizia. L'intervallo è controllato dal parametro. autovacuum_naptime Il valore predefinito è 1 minuto. I valori predefiniti AUTOVACUUM e i parametri di VACUUM configurazione sono gli stessi per Aurora Postgre SQL Limitless Database e per Aurora Postgre. SQL

Il AUTOVACUUM demone, se abilitato, emette automaticamente i ANALYZE comandi ogni volta che il contenuto di una tabella è sufficientemente modificato. In Aurora Postgre SQL Limitless Database, AUTOVACUUM problemi sia sui router che ANALYZE sugli shard.

Per ulteriori informazioni sui parametri di archiviazione dei AUTOVACUUM daemon e delle tabelle associati aAUTOVACUUM, consulta Il demone autovacuum e i parametri di archiviazione nella documentazione di Postgre. SQL

Aspirazione basata sul tempo nel database Aurora Postgre Limitless SQL

Aurora Postgre SQL Limitless Database è un sistema distribuito, il che significa che più istanze possono essere coinvolte in una transazione. Pertanto, la visibilità basata sull'ID della transazione non si applica. Al contrario, Aurora Postgre SQL Limitless Database utilizza la visibilità basata sul tempo, poiché le transazioni IDs non sono «unificate» tra le istanze, ma il tempo può essere «unificato» tra le istanze. Ogni snapshot della transazione e ogni versione della tupla obbediscono all'ora anziché all'ID della transazione. Per essere più specifici, un'istantanea della transazione ha un'ora di inizio dell'istantanea e una tupla ha un'ora di creazione (quando si verifica un INSERT o) e un'ora di cancellazione (quando UPDATE accade un). DELETE

Per mantenere la coerenza dei dati tra le istanze del gruppo di shard DB, Aurora Postgre SQL Limitless Database deve assicurarsi che l'vacuuming non rimuova le tuple ancora visibili a qualsiasi transazione attiva nel gruppo di shard DB. Pertanto, anche l'aspirazione in Aurora Postgre SQL Limitless Database è basata sul tempo. Altri aspetti VACUUM rimangono invariati, incluso il fatto che per essere eseguito VACUUM su una particolare tabella, un utente deve avere accesso a quella tabella.

L'esempio seguente illustra come funziona l'aspirazione basata sul tempo.

L'ultimo passaggio viene eseguito tramite la sincronizzazione, in modo che tutti gli shard siano a conoscenza della transazione 1, anche se la transazione 1 non li riguarda tutti.

Utilizzo delle statistiche del database per l'aspirazione

Per ottenere informazioni sulle tuple che potresti dover ripulire, usa la vista limitless_stat_all_tables, che funziona in modo simile a pg_stat_all_tables. L'esempio seguente interroga la vista.

SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%';

Allo stesso modo, per le statistiche del database usa limitless_stat_database invece di pg_stat_database e limitless_stat_activity invece di pg_stat_activity.

Per controllare l'utilizzo del disco della tabella, usa la funzione limitless_stat_relation_sizes, che funziona in modo simile a pg_relation_size. L'esempio seguente interroga la funzione.

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer');

Per tenere traccia dell'avanzamento di un'VACUUMoperazione su Aurora Postgre SQL Limitless Database, usa la vista limitless_stat_progress_vacuum invece di pg_stat_progress_vacuum. L'esempio seguente interroga la vista.

SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;

Per ulteriori informazioni, consulta Visualizzazioni del database Aurora PostgreSQL Limitless e Funzioni del database Aurora SQL Postgre Limitless.

Differenze nel comportamento di aspirazione tra Aurora Postgre e Aurora Postgre Limitless Database SQL SQL

Alcune altre differenze tra Aurora Postgre e Aurora SQL SQL Postgre Limitless Database nel funzionamento dell'aspirazione sono le seguenti:

Per informazioni sul supporto per VACUUM Aurora Postgre SQL Limitless Database, vedere in. VACUUM Riferimento al database Aurora SQL Postgre Limitless