PostgreSQL dimensioni del database (dimensione spazio tabelle) molto più grande quindi somma totale calcolato di rapporti

Question

Hallo tutto,

vedo una grande differenza tra la dimensione effettiva del database (sul disco fisso e visualizzato da pg_database_size() chiamata) e la dimensione, calcolato sommando le dimensioni delle relazioni totali recuperate da pg_total_relation_size().

Il primo è 62G e l'ultimo è 16G (a destra la differenza dei dati cancellati dal più grande tabella)

Ecco una query semplificata, che può dimostrare che la differenza sul mio sistema:

select current_database(), 
     pg_size_pretty(sum(total_relation_raw_size)::bigint) as calculated_database_size, 
     pg_size_pretty(pg_database_size(current_database())) as database_size 
    from (select pg_total_relation_size(relid) as total_relation_raw_size 
      from pg_stat_all_tables -- this includes also system tables shared between databases 
     where schemaname != 'pg_toast' 
     ) as stats; 

Sembra che ci siano alcuni dati penzoloni lì. All'apparire di questa situazione, dopo aver scaricato e riempito con un sacco di dati inutilizzati da quel DB.

PS: suppongo, che si trattava di un danneggiamento del database di qualche tipo ... L'unico modo per uscire da questa situazione è stato quello di passare al database di hot-standby ...

Answer 1

Avete LOB inutilizzati ?

Se hai qualcosa di simile:

CREATE TABLE bigobjects (
    id BIGINT NOT NULL PRIMARY KEY, 
    filename VARCHAR(255) NOT NULL, 
    filecontents OID NOT NULL 
); 

seguito da:

\lo_import '/tmp/bigfile' 
11357 
INSERT INTO bigobjects VALUES (1, 'bigfile', 11357); 
TRUNCATE TABLE bigobjects; 

Avrai ancora il LOB (id 11357) nel database.

È possibile controllare la tabella del catalogo di sistema pg_catalog.pg_largeobject per tutti gli oggetti di grandi dimensioni nel database (Raccomandare Scegliere loid DISTINTO DA pg_catalog.pg_largeobject a meno che non si desidera visualizzare tutti i dati LOB come ottale.)

Se pulisci tutti i tuoi LOB inutilizzati e fai un VACUOLO COMPLETO, dovresti vedere una forte riduzione di spazio. Ho appena provato questo su un database di dev personale che ho utilizzato e ho visto una riduzione delle dimensioni da 200 MB fino a 10 MB (come riportato da pg_database_size (current_database()).)

Answer 2

La query è specificamente di screening tabelle pg_toast, che può essere grande Vedi se sbarazzarsi di quello in cui schemaname != 'pg_toast' ottiene una risposta più accurata.

Answer 3

All'apparire di questa situazione, dopo aver scaricato e riempito con un sacco di dati inutilizzati da quel DB.

Ho avuto un'esperienza simile: 3 GB db con un sacco di dati dinamici che è andato a 20 GB per un mese circa. cancellando manualmente/aspirare le tabelle problematici non cuciture di avere effetto .. E poi abbiamo appena fatto una finale

VACUUM FULL ANALYZE 

su tutto il DB ... ed è caduto la metà delle dimensioni.

Sono occorse 4 ore, quindi fai attenzione.

Answer 4

I LOB sono una preoccupazione molto valida mentre BobG scrive, poiché non vengono eliminati quando vengono eliminate le righe della tabella delle applicazioni (contenente gli OID).

Questi NON verranno eliminati automaticamente dal processo VACUUM, solo che è stato eseguito VACUUMLO su di essi.

Vacuumlo eliminerà tutti i LOB non referenziati dal database.

Esempio chiamata:

vacuumlo -U postgres -W -v <database_name> 

(ho incluso solo il -v per fare vacuumlo un po 'prolisso, in modo che si vede il numero di LOB rimuove)

Dopo vacuumlo ha cancellato il LOB, è può eseguire VACUUM FULL (o lasciare che il processo di auto-vuoto venga eseguito).