Discussion :

[elkamaro]

Bonjour A tous,

Mon client vient de me demander de faire une proposition (script ...) pour purger une base de données qui commence a grossir.

Il voudrait que je garde uniquement ses informations sur les deux dernières années (par exemple supprimer tous les contrats qui ont plus de deux ans)

Ceci nous permettra de réduire l'espace disque occupé par la base de données

Pouvez vous me conseiller sur par quoi commencer ?
Quelles serait les erreurs a éviter ?

d'autres part, je ne maitrise pas le schema de la base et donc comment eviter des erreurs (genre si je fais une suppression cascade sur un projet créé en 2005 et que cela me supprime des contrats 2010 qui appartiennent à ce projet )

Merci pour toute aide apportée

[olivanto]

j'aurai tendance à dire que la taille de la base ne provient pas uniquement des données, mais de la façon dont la base est concue...(liste chainées, etc..)

après je sais pas....et je vois pas top l'intérêt de gagner de la place à moins d'avoir une base gigantesque...

par ailleurs, suivant le modèle de données relationnel, tu risques d'avoir des surprises.....genre la compta par exemple (comment tu pointes avec un virement sur un dossier qui n'existe plus)

[agdid04]

Bonjour,

J'ai une demande de purge identique une fois et quand j'ai demandé la confirmation de purge par écrit c'est silence total plus personne.

[elkamaro]

j'aurai tendance à dire que la taille de la base ne provient pas uniquement des données, mais de la façon dont la base est concue...(liste chainées, etc..)

après je sais pas....et je vois pas top l'intérêt de gagner de la place à moins d'avoir une base gigantesque...

par ailleurs, suivant le modèle de données relationnel, tu risques d'avoir des surprises.....genre la compta par exemple (comment tu pointes avec un virement sur un dossier qui n'existe plus)

En fait, ce n'est pas une super grosse base, elle fait tout juste 60G
mais qd le client vous dit de diminuer la taille, vous allez pas lui repondre non

c'est une base qui contient des données brut, la plus grosse table fait 13G et une autre de 5Go

l'interet de gagne de la place c est juste la fleme d ajouter un disque à la bécane, et aussi parceque la base est censé augmenté de volume dans les prochains mois

[elkamaro]

Bonjour,

J'ai une demande de purge identique une fois et quand j'ai demandé la confirmation de purge par écrit c'est silence total plus personne.

effectivement, c est ce que je me suis dit aussi car je n'ai pas encore eu de demande formalisé à l ecrit.

Mais avant de demandé cela, je voulais dabord enumérer les risques d'une telle action, ensuite faire un mail à la personne avec ces risques et lui demander de confirmer sa demande.

Mais d 'autre part, pour ma formation personnelle, je voulais votre aide

[13thFloor]

Bonjour,
le delete ne fera que gagner de la place dans les tablespaces, pas au niveau système.
Pour ce la, il faudra compacter les données à l'aide notamment de la commande shrink.

Code :

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

1
2
3
 
alter table ma_table enable row movement;
alter table ma_table shrink space cascade;

Quelques restrictions (en 10g r2) :
impossible de shrinker une table avec une colonne de type LONG
idem pour une table avec un index bitmap ou function based
pas d'effet sur une IOT ou une table compressée

Autre astuce pour gagner de l'espace : reconstruire les objets qui ne grandissent pas lors des mises à jour avec un PCTFREE à 0, pour éviter qu'oracle ne se réserve 10% de l'espace d'un bloc pour les futurs updates.

Règle n°1 : valider la procédure dans un autre environnement
Règle n°2 : avant de se lancer, s'assurer qu'un backup est disponible.

Il se peut qu'un index soit nécessaire pour accélérer la purge d'une table.
De même, la mise en mode nologging des tables concernées peut légèrement accélérer le processus (moins de switchs de log).

Si plus de la moitié d'une table doit être purgée, il peut être plus pertinent de créer une nouvelle table contenant les données à préserver, de supprimer l'ancienne et de renommer la nouvelle. En créant ses index (sauf la primary key) après l'insertion, on gagne encore du temps.
Il faut dans ce cas disposer d'une période d'indisponibilité applicative.
Le processus est le suivant :
1) créer une table à l'identique de la table à purger mais ne contenant que les données à conserver => critère à déterminer
2) renommer la table à purger (et ses index)
3) renommer la table créée (et ses index) avec le nom de la table purgée
4) supprimer la table purgée qui a été renommée
Avantage : disponibilité beaucoup plus rapide des données de la table purgée

Si la suppression est trop lourde pour être effectuée en une seule fois, il peut être utile de le faire en plusieurs fois en découpant le delete par tranche. Exemple : 1/4 du travail le jour J, un autre 1/4 le jour J+1 etc.

[ducho]

Bonjour,

elle est originale votre question .
Moi , c'est l'inverse, nous sommes clients et avons demandé à plusieurs éditeurs de purger des vieilles années de nos bases .
Le client ne connait pas le MCD de la base, normalement c'est l'éditeur
qui gére ce genre de purge .
une société a bien répondu à notre demande et j'ai purgé par scripts
leur base , en regardant de pres leurs scripts :
- bonne connaissane des références étrangéres
- archivage systématique dans d'autres tables non accedées par l'application
des données supprimées (par exemple préfixer les tables par ARC_,DEL_, etc).
- purge par delete des données ( je l'ai fait mois par mois pour ne pas engendrer trop de rollback)
- garder l'intégrité des données ( effectivement , attention aux vieux dossiers
ayant une ramification avec le présent)
- pouvoir en cas d'erreur réintégrer les données sans trop galérer
(pas évident avec des numéros de dossiers ou contrat qui sont des clés primaires )

nous avions demandé ces purges car même si les traitements oltp ont des tps de réponse satisfaisants, il en est autrement des batchs qui parcourent
les tables d'historiques (j'imagine le temps sur votre table de 13G° ).
et effectivement, ce n'était pas pour gagner de la place !

cordialement


ps : dans tous les cas , c'est à vous d'assurer les risques et non au client !
de toute façon , un export des tables avant purge est obligatoir

[remi4444]

Personnellement si on me demandait de faire des purges sur un schéma que je ne connais pas, et en l'absence de document de description clair sur ce dernier, ma réponse serait toute simple :NON.

Parce qu'évidement vous avez toutes les chances de casser fonctionnellement des trucs, et on vous fera porter le chapeau.

Un processus de purge est quelque chose qui doit être prévu dans le logiciel, c'est au concepteur de ce dernier, ou au responsable fonctionnel de dire ce qu'il faut faire. Pour gagner de la place en tant que DBA, vous ne pouvez vous en tenir qu'à des procédures techniques telles que des rebuild d'index, des move ou autre shrink mais ce n'est pas à vous de prendre la responsabilité de choisir quelles données vont disparaitre

En tout cas, je vous conseille d'ouvrir bien grand le parapluie en proposant un script et en ne l'exécutant qu'avec la signature de vos responsables hierarchiques

[Invité]

En tout cas, je vous conseille d'ouvrir bien grand le parapluie en proposant un script et en ne l'exécutant qu'avec la signature de vos responsables hierarchiques

J'ai un exemple en ce moment.
On a une application Oracle.
La bd grossit vraiment vite.
Je regarde dedans: deux tables occupent 60% du volume.
Visiblement (après recherche dans le code et traçage) ce sont des tables d'historisation qui semblent fonctionnellement dispensables.
Je fais quoi? Je laisse ma bd grossir de façon disproportionnée pour stocker de la scrap? Je contacte Oracle qui va me facturer pour me dire vraisemblablement : Ok vous pouvez faire une purge quotidienne dans ces tables?
Et grâce à Google, j'ai quand même pu découvrir qu'il y avait une procédure stockée qui doit être lancée au moins tous les jours pour faire une purge partielle. Ok mais ce n'est indiqué nulle part dans la documentation officielle fournie...
Tout ça pour dire que dans le meilleur des mondes, on devrait agir avec beaucoup de précaution, mais dans le réel, on agira bien plus prosaïquement...
Et puis, je suis en Amérique du Nord, alors l'action est toujours préférée à l'attentisme (ce qui a du bon et du mauvais, j'en suis bien conscient!)

[remi4444]

Et puis, je suis en Amérique du Nord, alors l'action est toujours préférée à l'attentisme (ce qui a du bon et du mauvais, j'en suis bien conscient!)

Ah oui mais ça change tout! ce n'est pas la même culture dans les grosses entreprises françaises ou, à partir d'un certain niveau, le problème n'est pas de savoir si ça va marcher ou pas, mais "à qui c'est la faute" et malheur à celui qui a oublié d'ouvrir son parapluie en prenant une initiative de lui même qui a outrepassé ses prérogatives.

Je me souviens d'un matin tot dans une des plus grosses boites française, ou en l'absence des chefs, on avait pris la décision d'activer une standby pour assurer la continuité de service d'une appli sensible.

Que n'avait-on pas fait là, on était légèrement sorti de la procédure prévue en matière de validation hierarchique, l'équipe a failli se faire virer, alors que techniquement tout s'était déroulé parfaitement et les utilisateurs n'y avaient vu que du feu...

En France on ne se méfie jamais assez de la mauvaise foi des chefs qui flippent tellement pour leur propre situation qu'ils sont prets à tout pour se dédouaner sur les autres. C'est bien triste mais c'est comme ça...

Et pour répondre à votre cas concret. Si ça se produit dans une grosse entreprise française, une fois identifié le problème, proposé la solution avec une analyse des risques, moi j'envoie un mail à un responsable hierarchique présent doublé d'un coup de fil pour m'assurer qu'il a compris le truc et ça sera à lui de donner sa décision ou bien de se référer lui même à sa hierarchie. Parceque perso, les remontrances pour avoir essayé de régler les soucis techniques au plus vite, j'en ai eu ma dose.

[Invité]

Ah oui mais ça change tout! ce n'est pas la même culture dans les grosses entreprises françaises ou, à partir d'un certain niveau, le problème n'est pas de savoir si ça va marcher ou pas, mais "à qui c'est la faute" et malheur à celui qui a oublié d'ouvrir son parapluie en prenant une initiative de lui même qui a outrepassé ses prérogatives.

Oui, ici c'est plus simple, si t'as vraiment merdé, tu peux ranger ton bureau et rentré chez toi en 15 minutes. Et si le boss est particulièrement fâché, tu es viré et sorti tout de suite ! On t'enverra ton carton par Fedex...
C'est une autre philosophie du travail, le CDI n'est pas roi ici, et c'est valable pour l'employeur et l'employé!

[ducho]

tout à fait d'accord,
une regle d'or en informatique, ne rien entreprendre sans un courrier
ou mail de la hiérarchie validant l'action ,
ce qui est logique apres tout (surtout lorsqu'on touche à des applis sensibles).

dans le cas cité, c'est toujours le client qui décide de purger les données
par contre, c'est bien l'éditeur (ou concepteur) qui assure les risques
(bien qu'on sache tous que le risque 0 n'existe pas )

[ducho]

ps je répondais à remy, en france on ne vire pas les gens comme ça !!!

[remi4444]

ps je répondais à remy, en france on ne vire pas les gens comme ça !!!

Et si...

Je ne parlais pas de licenciement direct, mais la grosse entreprise vire des sous traitants par un simple coup de fil au responsable commercial de la boite sous-traitante (qui dit amen à tout puisque c'est un gros client.)

Personnellement je suis indépendant, donc en contrat avec la boite sous-traitante et si je fait facher un client tout rouge, ben je rentre chez moi avec mes cliques et mes claques et je me bat pendant des semaines pour me faire payer mes factures.

Et même si vous êtes en CDI dans la boite sous-traitante, que vos chefs ne vous connaissent par particulièrement parceque toujours en clientèle, que par votre "faute" un client est mécontent, vous êtes mal, très mal et vous serez poussé vers la sortie de manière très efficace.

En encore, on a eu du bol que le CPE ne soit pas passé! mais il y a une nouvelle méthode avec ces boites qui transforment tous leurs colaborateurs en auto-entrepreneurs...

Enfin bon, tout ça pour dire qu'il ne faut jamais oublier d'ouvrir son parapluie, c'est toujours assez facile à faire, et ça évite bien des soucis, croyez en ma vielle expérience

[ducho]

ah , j'étais prestataire là ou je suis actuellement (pendant 10ans)
je viens de me faire embaucher,
je connais bien le monde des ssii et leur façon de gérer leur personnel
heureusement, toutes les entreprises ne sont pas comme ça, dans mon
ancienne boite, si le client est mécontent et que tu n'es pas complétement
responsable, on te change de client (bon , en discutant avec les rh, j'ai appris
qu' il ne fallait pas que ça arrive trop souvent )

je connais des gens comme toi sur ce forum, c'est vrai que ce n'est pas facile,
entre le marteau et l'enclume !!

bonne soirée