Discussion :

[farenheiit]

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 ?

[fatsora]

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 ...

[farenheiit]

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.

[fatsora]

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 ?

[farenheiit]

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?

[fatsora]

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