Discussion :

[rvfranck]

Salut,

Je voudrais savoir

1)
a) Si j'ai une ligne de données qui se trouve sur deux (2)
blocs de données différents b1 et b2 chainés. Aprés un update, si la
ligne peut maintenant tenir dans un bloc est ce que les données vont
remonter au bloc b1, et b2 restera vide?
b) Si oui, lors d'une prochaine insertion, le bloc b2 pourra t'il être
utilisé ou alors l'insertion va se faire au niveau du high-water mark?

3)
a) Est ce que deallocate me permet d'organiser mon segment de telle sorte que j'ai d'abord des
extents occupés puis des extents non occupés?
b) si oui, les extents non occupés sont ils supprimés? et que devient le niveau de flottaison?

Merci

[orafrance]

1.a : à ma connaissance, seul un rebuild d'index ou une recréation de table permet de "déchainer" une ligne
b. quand un bloc est vidé, il est réutilisable... (en fait, déplacer les données )

3 (il n'y a pas 2 )a : non, deallocate permet seulement de libérer les extents vides en vue de réduire le tablespace par exemple
En aucun cas, les données sont déplacées dans les blocs
b. Comme le dit Tom Kyte : quand il y a une inondation, le niveau de l'eau est marqué sur le mur... à moins de casser le mur jusqu'au niveau de l'eau ou reconstruire la maison, la marque sera toujours au même niveau

Donc, seul TRUNCATE, MOVE ou DROP/CREATE permet d'abaisser la HWM

J'espère ne pas avoir raconté de bétise

Merci de me corriger si c'est le cas

[orafrance]

une précision importante : http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/optimops.htm#44948

La HWM ne sert que d'indicateur à Oracle pour savoir quand arrêter un FULL SCAN. Ca n'a donc aucun rapport avec des problèmatiques physiques de stockage

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/b_deprec.htm#635291

[rvfranck]

Merci,
Je crois que c'est clair maintenant. J'en profite, si je comprends bien la différence entre DEALLOCATE et COALESCE est que deallocate supprime les extents vides mais le second fusionne juste les extents vides contigus mais les extents restent?

[orafrance]

c'est exactement ça, le COALESCE n'a d'ailleurs plus d'intérêt quand DICTIONNARY MANAGED où le nombre d'extents pouvait dégrader les performances alors qu'en LOCALLY MANAGED ça n'a plus aucune importance

[rvfranck]

Salut,
Orafrance a dit:

c'est exactement ça, le COALESCE n'a d'ailleurs plus d'intérêt quand DICTIONNARY MANAGED où le nombre d'extents pouvait dégrader les performances alors qu'en LOCALLY MANAGED ça n'a plus aucune importance

Je m'excuse mais j'ai pas bien compris ce que vous vouliez me dire.

Merci

[orafrance]

simplement que COALESCE réduit le nombre d'extents (10 extents de 10ko libres contigus 1 extent de 100 ko) ce qui n'a d'intérêt que si le table space est géré par le dictionnaire

[rvfranck]

Merci,
Mon problème est résolu.

[orafrance]

quel était le problème ? Et la solution choisie ?

[rvfranck]

Salut,

En fait mon problème était de savoir comment réorganiser ma table pour qu'il n'y ait plus de trous (après trop de delete par exemple), comment faire pour que les blocs qui constituent une même ligne soient contigus. Pour cela j'ai d'abord voulu savoir comment les blocs sont chaînés et s'il se déchainaient tous seuls.

Dans votre article (le stockage de données) vous avez parlé de coalesce mais pas de deallocate (si je ne trompe pas). coalesce fusionne les extends contigus vides et je me demandais pourquoi ils restaient dans le tablespace alors qu'ils étaient vides, heureusement vous m'avez dit que deallocate libère les extends vides.

Maintenant je cherche la syntaxe d'un rebuild index si vous avez un lien se serait cool.
Dites, Move et truncate quelle est la différence?
Merci

[orafrance]

MOVE déplace la table et son contenu dans un autre tablespace alors que TRUNCATE vide la table... les deux commandes permettent de réorganiser les extents

Pour le rebuild : http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_18a.htm#2086990

Quand à la question des blocs contigus... c'est quasiment impossible d'avoir tous les blocs contigus puisque la fragmentation du disque est une problèmatique systéme et non Oracle et dans une baie SAN en particulier en STRIPPING les chances que les blocs soient contigus sont très proche de 0

Il faut arrêter de se casser la tête avec la fragmentation , cela ne pose quasiment plus de problème de performance et l'espace disque économisé ne couvre peut-être même pas le coup d'une réorganisation

[rvfranck]

Est ce que vous essayez de me dire que si j'ai par exemple une table dans laquelle j'ai éffectué trop de suppressions c'est pas bien grave?

[LeoAnderson]

A priori, non !
Parce que même si vous arrivez à limiter la fragmentation Oracle (en termes d'extents alloués), rien ne vous dit qu'au niveau OS, les quelques extents qui resteront (ou le seul, on peut toujours rêver) seront physiquement implémentés de façon contigües....

Par contre, un chainage de bloc important peut révèler un bloc trop petit, et ça, c'est plus gênant car là, c'est le fonctionnement même de l'optimizer qui est mis à mal...

D'un autre côté, si votre table a eu une période de croissance frénétique et que maintenant, c'est non seulement terminé mais qu'en plus vous avez fait beaucoup de ménage, oui, il peut être utile de vouloir faire de la place.

[rvfranck]

Merci