Discussion :

[msomso]

Bonjour
Sans vraiment connaître Sybase, je dois intervenir sur une BD pour supprimer certaines données et rendre impossible toute leur récupération.
Pouviez-vous m'indiquer les actions à faire après exécution de la purge via Transact SQL ?

Suffit-il de purger le journal des transactions ?
Peut-on garantir alors que, même pour le plus chevronné de DBA, toute récupération est devenue impossible ?
Cette intervention sur le journal, peut-elle représenter un risque pour la consistance de la base ?

Merci
mso

[mpeppler]

Effacer les données dans une table revient en général à marquer des-allouer la ligne, mais ne va pas physiquement changer les données sur le disque tant qu'une autre ligne ne prend pas sa place. Si tu veux que les données soient effectivement illisibles même avec une lecture physique des pages (via dbcc page, par example) alors je suggère de faire la purge en deux fois: d'abord tu fais un update des lignes à purger avec des données bidons, et ensuite tu effaces.

Pour ce qui du transaction log - c'est une queue circulaire qui est tronquée de temps en temps (soit automatiquement si l'option "truncate log on checkpoint" est positionnée pour la base, soit via une opération manuelle ou scriptée de "dump transaction", ou encore via une proc de type sp_thresholdaction).
Donc après suffisamment d'activité d'update dans la base la queue circulaire a été complètement utilisée, et les données précédantes ne sont plus lisibles.

(reste ensuite évidemment les sauvegardes qui contiennent encore les anciennes données, mais je suppose que celle-là doivent rester dispo...)

Michael

[msomso]

je suggère de faire la purge en deux fois: d'abord tu fais un update des lignes à purger avec des données bidons, et ensuite tu effaces.

Michael

D'après mes premières lectures sur Sybase, un update = delete + insert.
Mais alors :

1. ce premier delete (lors de update) n'est pas forcement remplacé par d'autres écritures, non? Le données d'origines peuvent donc "survivre", je me trompe ?
2. le deuxième et "vrai" delete de la ligne venant d'être insérée (donc réecrite plus loin) est-il vrai=physique ou juste marqué/flagé comme ligne supprimée ?

. En fait, je vais avoir du mal à masquer par update toutes les données (il me faudrait alors updater toutes les colonnes et puis il y a des triggeurs pour gérer l'intégrité - nous voulons les garder tout au long du traitement, je ne peux donc pas mettre facilement des données bidons)

Une autre idée:
pensez-vous que faire un dump suivi aussitôt d'un load dans la même base, peut résoudre le problème en supprimant définitivement les traces des données d'origine ?
Je crois que même là on ne peut pas le garantir ...

Merci

[mpeppler]

Un dump + load ne devrait rien changer vu que le dump est une copie physique des pages allouées, et le load fait un rechargement de ces pages. Peut-être que les pages non-allouées sont ré-initialisées lors du load, mais j'en doute.

Pour le reste - un update n'est pas nécessairement un delete+insert. Si c'est possible ASE va faire un update "in place", mais c'est vrai que dans bon nombre de cas (existence de trigger, en particulier) ASE va faire un "deferred" update.

Je ne vois pas vraiment d'autre moyen de réellement effacer les données - sauf peut-être écrire une routine qui crée des records bidons dans une table bidon utilisant le même segment (même device physique) et remplir la database de cette façon, puis faire un truncate de la table bidon... qqch du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
create table bidon(c char(255) not null) -- char, comme cela on écrit toujour 255 octets
go
while 1
begin
     insert into bidon values("toto")
     if @@error != 0
         break
end
truncate table bidon
go

(attention - code non testé).

C'est pas très joli, mais cela devrait avoir l'effet voulu.

Michael

[msomso]

Bonjour Michael
Je suis intéressée par ton idée, mais j'ai une petite crainte:

Dans ma future base (copie exacte d'une bd de prod existante) j'aurai 2 devices:

1. un pour le journal de transaction (1Go) et
2. un autre pour les données (4Go).
   Dans ce dernier, 2 segments:
   
   • system et
   • default contenant toutes mes données.

En consultant la base de production avec Sybase Central, je vois que chaque segment possède un espace avec des valeurs (maxi, alloué, libre restant) identiques pour ces 2 segments. Donc j'ai l'impression qu'il s'agît d'un même et commun espace !

Ma question donc:
En exécutant les insertions bidon pour forcer l'écriture/écrasement des données supprimées dans le segment default, ne risque-t-on pas de consommer l'espace du segment system et bloquer ainsi la base ?

Comment Sybase peut s'arrêter au segment default, alors qu'il semble "partager" espace disponible du device avec celui de system ?
Comment est gérée l'affectation/la distribution d'espace entre ces 2 segments au sein d'un même device?

Merci
P.S.
Je suis en phase d'étude, la base n'existe pas encore et je ne peux pas le tester.

[gcouvez]

Oui par défault les egments system et default partage le meme espace physique (même device)

si ce comportement ne convient pas il faut "corriger" la répartition des segments sur les devices avec les procedures

sp_extendsegment et sp_dropsegment

[mpeppler]

Ma question donc:
En exécutant les insertions bidon pour forcer l'écriture/écrasement des données supprimées dans le segment default, ne risque-t-on pas de consommer l'espace du segment system et bloquer ainsi la base ?

Le segment pour Sybase ASE est un concept peut-être un peu particulier...
Dans le cas particulier la base va se remplir à 100% avec tes inserts, et la table sera ensuite tronquée (libérant ainsi la place). Il y aura un court instant où les tables système ne pourrons pas grandir, mais cela ne devrait pas porter à conséquence puisque ces tables sont en général assez statiques.

Donc je ne vois pas de problème fondamental à cet exercice - sauf que la transaction log va se remplir avec tous les inserts. Donc je te suggère de mettre ta base de test en mode "truncate log on checkpoint" pour que la gestion du transaction log soit automatique.

Michael

[msomso]

Bonjour
D'abord merci à parsonnes m'ayant répondu.

Selon le support Sybase l'action du serveur lors du DELETE dépend du type de lock attribué à la table.

1. Pour une table avec LOCK ALL PAGE toute la page est recalculée et les données sont compactées en debut de page avec la mise à jour de setoff table.
   Je crois par contre que rien n'est supprimé à l'emplacement d'origine des lignes recopiées à la place des données supprimées (cela reste à confirmer).
   La lecture des données dupprimées ne doit pas être possible via bcp, pensez-vous qu'avec une commande systeme (Sun Solaris) on peut y arriver ?
2. Pour une table avec LOCK ROW DATA le delete consiste à flaguer l'enregistrement supprimé et l'espace n'est pas realloué tant que la réorganisation de la table ne soit pas effectuée. Avant le Reorg, la relecture via bcp des données sensible doit être possible (d'après le support).

Je vais tester ces 2 cas avec bcp demain et vous tiendrais au courant. Toutes mes tables ont l'attribut "lock all page". Mais par précaution, je pense que je vais forcer l'écrasemnt par insert comme Michael l'a suggéré.

Merci de votre attention.
mso

[mpeppler]

Pour le cas 1 (table en mode APL), les données peuvent probablement être lues si la ligne éffacée était la dernière sur la page (dans ce cas la compaction des données sur la page ne va pas écrire par dessus la ligne). Ces données peuvent être lues avec un outil OS (od, strings, etc. pour autant qu'on ait le droit en lecture sur le device physique). Et ces données peuvent être lues depuis ASE via dbcc page().

Pour le cas 2 (table en mode DOL) les données ne seront (potentiellement) éffacée que lors d'un reorg rebuild ou reorg compact, ou alors si ASE a besoin de la place pour mettre autre chose.

Ceci étant je ne sais pas (et je n'ai jamais fais de tests) à quel point ASE "casse" les données éffacées lors d'un REORG ou d'une opération de delete dans une table APL - donc si on veut être sur je pense qu'une opération de "blanchissage" du style de ce que j'ai suggéré plus haut est recommandée.

Michael

[msomso]

Bonjour
Voici le résultat de mes tests fait avec dbcc page:

1. LDR: pour lock data row la lecture est possible
2. LAP: pour lock all page les données supprimées ne sont plus lisibles (même celle situées à la fin de page)

Ceci étant, le support Sybase précise que même en mode LAP, ne sont recalculées que les pages n'ayant pas été entièrement vidées. Elle peuvent eventuellement être réinitialisées par un dump et load (si fait une nouvelle base vierge). La solution de Michael reste donc incontournable. C'est malheureusement extrèment long dans mon cas, car j'ai beaucoup d'espace libre dans la base.

Merci pour vos précieuses idées
mso