eliminazione / aggiornamento forensi dei dati


15

Ho bisogno di rimuovere i dati in modo forense dall'oracolo. Se lo elimino, la mia comprensione è che i dati rimarranno effettivamente nel file di dati fino a quando lo spazio non viene riutilizzato. Non sono preoccupato per lo spazio di ripetizione / archiviazione / annullamento, quelli invecchieranno ragionevolmente rapidamente.

Esistono metodi per garantire che i dati vengano effettivamente rimossi da un file di dati?

Risposte:


15

Questa è una domanda interessante: quando Oracle elimina davvero i dati fisicamente?

L'unità di dati in Oracle è un blocco. Vediamo cosa succede quando cancelliamo una riga.

Ecco un esempio con una semplice tabella su 11gR2 (vedi " Come scaricare Oracle Data Block? "):

CREATE TABLE test_delete_data(id NUMBER,data VARCHAR2(100));
INSERT INTO test_delete_data VALUES (1, rpad('1', 100, '1'));
INSERT INTO test_delete_data VALUES (2, rpad('2', 100, '2'));
INSERT INTO test_delete_data VALUES (3, rpad('3', 100, '3'));
COMMIT;

SELECT dbms_rowid.rowid_to_absolute_fno(rowid, user, 'TEST_DELETE_DATA') fileno,
       dbms_rowid.rowid_block_number(rowid) blockno
  FROM test_delete_data;

-- replace with values from query
alter system dump datafile 4 block 16573;

Dovresti ottenere qualcosa del genere alla fine del file creato nella tua user_dump_destdirectory:

data_block_dump,data header at 0x8b02264
===============
[...]
block_row_dump:
tab 0, row 0, @0x1f2d
tl: 107 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 02
col  1: [100]
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
tab 0, row 1, @0x1ec2
tl: 107 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 03
col  1: [100]
 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
tab 0, row 2, @0x1e57
tl: 107 fb: --H-FL-- lb: 0x1  cc: 2
col  0: [ 2]  c1 04
col  1: [100]
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
end_of_block_dump

Se elimino la seconda riga, eseguo il commit e dump dello stesso blocco, otterrò qualcosa del genere:

block_row_dump:
tab 0, row 0, @0x1f2d
tl: 107 fb: --H-FL-- lb: 0x0  cc: 2
col  0: [ 2]  c1 02
col  1: [100]
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
tab 0, row 1, @0x1ec2
tl: 2 fb: --HDFL-- lb: 0x2 
tab 0, row 2, @0x1e57
tl: 107 fb: --H-FL-- lb: 0x0  cc: 2
col  0: [ 2]  c1 04
col  1: [100]
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
end_of_block_dump

Il record è ancora lì (con un Dflag impostato). Se guardiamo i dati binari effettivi (appena prima della block header dumpsezione, vediamo che i dati non sono stati ancora sovrascritti:

8B040C0 33336404 33333333 33333333 33333333  [.d33333333333333]
8B040D0 33333333 33333333 33333333 33333333  [3333333333333333]
        Repeat 4 times
8B04120 33333333 023C3333 03C10202 32323264  [333333<.....d222]
8B04130 32323232 32323232 32323232 32323232  [2222222222222222]
        Repeat 5 times
8B04190 02002C32 6402C102 31313131 31313131  [2,.....d11111111]
8B041A0 31313131 31313131 31313131 31313131  [1111111111111111]
        Repeat 4 times
8B041F0 31313131 31313131 31313131 30A30602  [111111111111...0]

Un modo per forzare la sovrascrittura dei dati sarebbe quello di aggiornarli a un valore insignificante prima di eliminare la riga. Ciò non funzionerebbe con gli indici poiché gli aggiornamenti vengono tradotti in delete + insert in ab * tree index.


+1 "Un modo per forzare la sovrascrittura dei dati sarebbe quello di aggiornarli a un valore insignificante prima di eliminare la riga."

Bella risposta! Vorrei aggiungere che è possibile implementare l '"aggiornamento prima di eliminare" con un trigger anziché .
ora-600,

Se vuoi assicurarti che anche i dati dell'indice vengano sovrascritti, puoi ridurre la tabella, ricostruire tutti gli indici (di quella tabella), creare una nuova tabella con PCT_FREE = 99 che estendi fino a quando non consuma tutto lo spazio libero e quindi riempire questa tabella con file fittizie. Finalmente puoi rilasciare la tabella per liberare spazio. Questa non è sicuramente un'attività che dovresti fare automaticamente dopo ogni eliminazione. Ricordare inoltre di disabilitare l'auto-estensione prima di eseguire questa operazione.
ora-600,

0

Non credo che i dati persistano dopo un'eliminazione, ma hai ragione sul fatto che lo spazio sarà mantenuto in uso da quella tabella fino a quando non sarà stato riempito. L'utilizzo dello spazio superiore in una tabella è noto come marchio di livello elevato. Tom Kyte ha un post davvero buono (non sorprende) riguardo.

Riduci il punteggio massimo dell'acqua ricostruendo la tabella:

alter table my_table_name move

o troncandolo; sebbene in una tabella attiva questa non sia ovviamente un'opzione.


ISTBC, ma mi aspetto che i dati esistano ancora (in forma "grezza") dopo un'eliminazione. Sarà lì, è solo che la riga è stata "scollegata" dalla tabella e lo spazio contrassegnato come libero. Tom Kyte dice questo "Quindi, quando si eliminano le informazioni, il blocco è ancora" un blocco ", è solo un blocco che una volta aveva righe attive - ma non lo fa più". Non ne sono sicuro al 100%, quindi nessun voto negativo. :)

@cagcowboy, dice anche "potremmo avere molti blocchi che non contengono più dati ". Ho sempre preso questo per significare che lo spazio è conservato per un uso futuro ma i dati sono spariti. Sono disposto a essere dimostrato errato però :-).
Ben

3
Vedo il tuo punto. Tuttavia, suppongo che avrebbe potuto scrivere "potremmo avere molti blocchi che non contengono più dati attivi ". Fondamentalmente, non mi aspetterei che Oracle sovrascriva i dati cancellati - penso che non li rimandi.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.