Perché DELETE + REORG non libera spazio su disco (DB2)?

18

In DB2 ho una tabella contenente grandi dati binari. Ora ho eliminato l'intera tabella ed eseguito runstats, reorg, runstats, ma la quantità di spazio su disco occupata non cambia. Cosa potrebbe essere sbagliato qui?

La tabella risiede nel proprio tablespace che ho creato come segue:

CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096;
CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING;

Ho cancellato / rinnovato come segue:

DELETE FROM MY_TBL
RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED INDEXES ALL
REORG TABLE MY_TBL
RUNSTATS ON TABLE MY_TABLE WITH DISTRIBUTION AND DETAILED INDEXES ALL
ALTER TABLESPACE MY_TBS REDUCE

La tabella MY_TBL ha occupato 2,5 GB prima di tutto e dopo aver eliminato / riprogrammato utilizza solo 3 MB in meno.

FWIW: sto eseguendo DB2 / NT v9.5.2.

— Alexander Tobias Bockstaller
fonte

Funziona con sistemi su db2 v8?

— Tony,

22

Ho intenzione di indovinare che stai utilizzando l'archiviazione automatica. (Non che ciò possa accadere altrimenti ... è facile accedervi con l'archiviazione automatica.)

Molto probabilmente il problema è che il database ha recuperato lo spazio per se stesso ma non ha rilasciato il disco sul sistema operativo. Questo può essere mostrato molto facilmente controllando l'High Water Mark per il tablespace.

Procedi come segue

db2 list tablespaces show detail

Questo ti mostrerà ogni tablespace e cosa sta usando sul disco. Used pagesindica quante pagine del disco sta utilizzando il database. Confrontandolo con total pages(il totale richiesto su disco) e il High water mark (pages)ti mostrerà se stai "rivendicando" più del necessario. (vale a dire pagine a basso consumo, pagine totali molto alte e un contrassegno di livello elevato vicino alle pagine totali).

Per sbarazzarsi di questo spazio inutilizzato e restituirlo al sistema operativo che si rilascia il seguente (sotto memorizzazione automatica): db2 alter tablespace <tablespace name> reduce max. esempio

db2 alter tablespace ts1 reduce max;

Ciò farà sì che DB2 riduca il segno di livello alto e rilasci il disco inutilizzato al sistema operativo. (Nota che puoi farlo solo per tablespace regolari e di grandi dimensioni, non per tablespace temporanei di sistema o temporanei dell'utente).

Se si utilizza DMS senza archiviazione automatica, è necessario utilizzare un set leggermente diverso di comandi:

db2 alter tablespace <tablespace name> lower high water mark;
db2 alter tablespace reduce (<containter name> or [all containers] integer K|M|G or integer PERCENT);

esempio

db2 alter tablespace ts1 lower high water mark;
db2 alter tablespace reduce (all containers 500 M);

Laddove lavoriamo, inseriamo questo in alcuni dei nostri script di manutenzione in modo da eseguirlo automaticamente dopo aver effettuato nuovamente il rimontaggio per assicurarci di recuperare spazio su disco. Nel nostro caso utilizziamo DB2 LUW 9.7 FP 4, quindi non fa male ricontrollare il Centro informazioni per 9.5 per assicurarsi di avere accesso alle informazioni giuste per la tua versione.

EDIT: se i tuoi tablespace provengono da un database aggiornato a DB2 9.7, probabilmente non avrai impostato l'attributo di archiviazione recuperabile. Questo vale anche se si aggiorna da DMS all'archiviazione automatica. Ad ogni modo morde poiché non è possibile effettivamente abbassare il livello massimo dell'acqua. Devi scaricare la tabella e i dati, eliminare i tablespace. Quindi ricreare il tablespace utilizzando l'archiviazione automatica e importare i dati per le tabelle.

— Chris Aldrich
fonte

+1: bello vedere un esperto di DB2 che contribuisce al sito. Siamo stati deboli in quel dominio in passato.

— Philᵀᴹ

1

Solo un breve commento, in DB2 9.5, non è possibile utilizzare la sintassi alter tablespace <tbsp> lower high watermarko alter tablespace <tbsp> reduce max- questi non sono stati introdotti fino a DB2 9.7.

— Ian Bjorhovde,

Come ho già detto nel mio post iniziale, ho già provato gran parte di questo e non ha funzionato. Ormai ho trovato la soluzione da solo: lo spazio su disco non è stato recuperato perché non ho specificato l'opzione LONGLOBDATA, che sembra essere necessaria se si desidera recuperare spazio su disco da BLOB o CLOB. Si prega di vedere la mia risposta alla mia domanda qui. Comunque apprezzo lo sforzo che hai messo nella tua risposta, +1!

— Alexander Tobias Bockstaller

9

La tabella MY_TBLcontiene grandi dati binari in una BLOBcolonna. La documentazione del REORGcomando dice che DB2 evita di riorganizzare tali oggetti perché richiede tempo e non migliora il clustering. Tuttavia, DB2 può essere forzato a riorganizzare i dati LOB se l' LONGLOBDATAopzione è specificata. Lo spazio inutilizzato può essere riutilizzato da DB2, quindi l'inserimento di nuovi dati riempirà prima le pagine esistenti e inutilizzate prima di allocare nuove.

In esecuzione

REORG TABLE MY_TBL LONGLOBDATA

ha recuperato con successo i 2,5 GB di spazio su disco utilizzati dalla tabella vuota.

Non sapevo di questa opzione e l'ho supervisionata la prima volta che ho letto la documentazione.

— Alexander Tobias Bockstaller
fonte

Buon punto. Tuttavia, da quello che ho appena appreso in un episodio di DB2NightShow "Attack of the Blob" non si desidera eseguire l'opzione LONGLOBDATA troppo spesso poiché impiega più tempo e / o causa problemi di prestazioni (se si sta tentando di eseguire REORG online) .

— Chris Aldrich,

I database di cui ci occupiamo contengono dati di registro di macchine industriali. Le query su tali database non sono critiche in termini di tempo, quindi se le prestazioni diminuiscono durante un rimbalzo, questo non è un problema.

— Alexander Tobias Bockstaller