suppression / mise à jour de données médico-légales

15

J'ai besoin de supprimer les données médico-légales d'Oracle. Si je le supprime simplement, je crois comprendre que les données seront toujours réellement dans le fichier de données jusqu'à ce que cet espace soit réutilisé. Je ne suis pas préoccupé par l'espace redo / archive / undo, ceux-ci vieilliront rapidement.

Existe-t-il des méthodes pour garantir que les données sont réellement supprimées d'un fichier de données?

oracle security

— Matthew Watson
source

15

C'est une question intéressante: quand Oracle supprime-t-il vraiment les données physiquement?

L'unité de données dans Oracle est un bloc. Voyons ce qui se passe lorsque nous supprimons une ligne.

Voici un exemple avec un tableau simple sur 11gR2 (voir " Comment vider 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;

Vous devriez obtenir quelque chose comme ça à la fin du fichier créé dans votre user_dump_destrépertoire:

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

Si je supprime la deuxième ligne, valide et sauvegarde le même bloc, j'obtiendrai quelque chose comme ceci:

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

Le record est toujours là (avec un Ddrapeau établi). Si nous regardons les données binaires réelles (juste avant la block header dumpsection, nous voyons que les données n'ont pas encore été écrasées:

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]

Une façon de forcer les données à être réellement écrasées serait de les mettre à jour à une valeur vide de sens avant de supprimer la ligne. Cela ne fonctionnerait pas avec les index car les mises à jour sont traduites pour supprimer + insérer dans un index d'arborescence ab *.

— Vincent Malgrat
source

+1 "Une façon de forcer l'écrasement des données serait de les mettre à jour à une valeur vide de sens avant de supprimer la ligne."

Très bonne réponse! Je voudrais ajouter que vous pouvez implémenter la "mise à jour avant suppression" avec un au lieu d'un déclencheur .

— ora-600

Si vous voulez vous assurer que les données d'index sont également écrasées, vous pouvez réduire la table, reconstruire tous les index (de cette table), créer une nouvelle table avec PCT_FREE = 99 que vous étendez jusqu'à ce qu'elle consomme tout l'espace libre, puis remplissez cette table avec lignes factices. Enfin, vous pouvez déposer la table pour libérer de l'espace. Ce n'est certainement pas une tâche que vous devez effectuer automatiquement après chaque suppression. N'oubliez pas non plus de désactiver l'extension automatique avant d'effectuer cette opération.

— ora-600

0

Je ne pense pas que les données persistent après une suppression, mais vous avez raison de dire que l'espace sera conservé par cette table jusqu'à ce qu'il soit rempli. L'utilisation d'espace supérieure dans une table est connue comme la ligne des hautes eaux. Tom Kyte a un très bon (sans surprise) après à ce sujet.

Vous réduisez la ligne des hautes eaux en reconstruisant la table:

alter table my_table_name move

ou en la tronquant; bien que dans une table active ce ne soit évidemment pas une option.

— Ben
source

ISTBC, mais je m'attendrais à ce que les données existent toujours (sous forme "brute") après une suppression. Ce sera là, c'est juste que la ligne a été "dissociée" de la table et l'espace marqué comme libre. Tom Kyte dit ceci "Donc, lorsque vous supprimez les informations, le bloc est toujours" un bloc ", c'est juste un bloc qui avait une fois des lignes actives - mais qui n'en a plus." Je ne suis pas sûr à 100% de cela, donc pas de downvote. :)

@cagcowboy, il dit également "nous pourrions avoir de nombreux blocs qui ne contiennent plus de données ". J'ai toujours considéré cela comme signifiant que l'espace est conservé pour une utilisation future mais que les données ont disparu. Je suis prêt à être prouvé cependant :-).

— Ben

3

Je vois ce que tu veux dire. Cependant, je suppose qu'il aurait pu écrire «nous pourrions avoir de nombreux blocs qui ne contiennent plus de données actives ». Fondamentalement, je ne m'attendrais pas à ce qu'Oracle écrase les données supprimées - je pense que cela ne fait que des références.