Comment locker une partition au moment d'un truncate

Bonjour,

J'ai une table partitonnée. Au cours de mon traitement je souhaiterais faire un truncate de ma partition pour faire redescendre la HWM. avant de faire un truncate je lock la partition puis je fais un insert select de ma partition dans une table temporaire et après je peux truncater la partition. A la fin de mon truncate je peux réinsérer les lignes sauvegardées dans la partition.

le problème est le suivant : si juste après avoir locké la partition une autre session fais une insertion dans la partition mon truncate va commencer par un commit implicite qui va libérer le lock et du coup l'insert de l'autre session va pouvoir se faire et le truncate lui va planter avec le message "ressource busy with no wait".

je suis en 10G mais pour des raisons politiques je ne peux pas utiliser le shrink. y' a t'il une solution à ce problème ? Comment être sur qu' entre le moment où je sauvegarde des données et au moment où je truncate la partition une autre session n'aura pas mis à jour des lignes dans la partition ?

Bonjour,


Que veux tu dire par probleme politique avec le shrink .....

Parce qu'il y a d'autres sautions tel que move mais s'il rencontre le meme probleme politique ca va etre dur de t'aider ...

en fait je travaille pour un éditeur de logiciels.
Un de nos très gros clients se plaint que leurs tables soient fragmentées à cause de notre appli car on fait beaucoup d'insert et beaucoup de deletes.
On peut se retrouver dans des cas où la partition est défini sur 4000 blocks alors que les lignes occupent réellement 50 blocks.

puisqu'il s'agit de tables avec bcp d'accès concurrents on ne peut pas faire de truncate facilement. Les DBA de notre client ne veulent pas de shrink ou de move au niveau applicatif. par contre ils ne veulent pas faire leur travail en réorganisant les tables aux moment où la base est arrêtée par exemple. Voilà les raisons POLITIQUES.

Le beurre ,l'argent du beurre et les majorettes en prime...


Les solutions les plus simples et les plus soft sont shrink et online redefinition

Il y a un moyen graphique avec dbms_advisor OEM , mais se basant de ces solutions et possibilité de le faire par schedule

http://download.oracle.com/docs/cd/B.../schema003.htm

Les autres (move, truncate ) bloquent avec risque de "busy ..."

avec plus de risque de perte de donnée avec truncate

De l'autre coté , tu ne dervais faire de reorganisation que si le bénéfice obtenu est supérieur a l'effort,risque encouru pour le faire .

Est ce le cas ici ?

Gain en temps de réponse vraiment chiffrable , gain en espace disque reéllement important ?

En fait on a constaté ce problème de fragmentation des partitions par le fait qu'on fait du dynamic sampling niveau 2 sur ces tables. le problème est que sur une partition hyper fragmentée (ex: 4000 blocks mais 50 blocks réellement occupées) au moment du sampling il est arrivé que l'optimizer en ne prenant que 2*32 blocks comme échantillon ne tombait que sur des blocks vides donc pour lui la partition contenait 0 lignes => du coup il nous a sortit un plan d'execution foireux avec un merge join cartesian car les cardinalités étaient pas bonnes.

le client a gueulé en disant que c'était la faute de notre application et qu'il fallait qu'on fasse des truncates et pas des deletes. le problème c'est qu'on ne peut pas faire des truncates facilement.

Quand tu parles de shrink et online redefinition ce n'est pas un pléonasme ? le shrink par defaut se fait on line non?

Non, c'est pas la meme chose

definition de online redefinition


http://download.oracle.com/docs/cd/B...s.htm#i1006790

http://www.oracle.com/technology/dep..._reorg_twp.pdf

Le alter table shrink space compact devrait abaisser le HWM. (précédé de alter table enable row movement).
Voir la note metalink 242090.1.

Citation:

---

Envoyé par 13thFloor

Le alter table shrink space compact devrait abaisser le HWM. (précédé de alter table enable row movement).
Voir la note metalink 242090.1.

---

Attention, vous avez mal lu !
L'option COMPACT est à comprendre comme "COMPACT ONLY".
SHRINK SPACE tout court défragmente le segment et redescend le HWM, alors que SHRINK SPACE COMPACT ne fait que la défragmentation, sans redescendre le HWM.

Bonjour,

Effectivement la solution truncate n'est pas une bonne solution à faire online:
- pour le pb de lock que tu as rencontré
- et parce que tu ne peut pas faire le insert + truncate dans la même transaction. Donc s'il y a des inserts pendant l'opération ils seront perdus.

Shrink et dbms_redefinition se font online, mais ce sont quand même des opérations de maintenance, celà de devrrait pas faire partie des process applicatifs normaux.

Quel est le rythme des insert/delete qui rendendent cette table si vide de temps en temps ? Il y a peut être d'autres solutions (partition ou IOT). Parce que passer son temps à allouer et désallouer des extents, ce n'est peut être pas la bonne solution, même si c'est possible online.
Et peut être que le dynamic sampling n'est pas judicieux dans ce cas. Un autre moyen de fixer le plan d'exécution peut-être.

Mais bon, quand les choix politiques prennent le dessus sur raisons techniques et le bon sens :roll:

Cordialement,
Franck.