[9i] Connaitre le pourcentage de fragmentation des tablespaces

Version imprimable

Bonjour à tous,

Après de multiples recherches, je n'arrive pas à comprendre comment faire pour calculer la fragmentation des tablespaces d'une base de données.

J'ai suivi la note métalink 1020182.6, j'ai regardé sur ce superbe forum mais je reste perplexe...

J'ai ressorti à partir du script trouvé dans la note le nombre d'extent ainsi que la taille de chaque tablespace. Mais je ne vois pas comment à partir de ces résultats, ressortir un pourcentage de fragmentation...

Exemple pour un tablespace :
Code:

1 2 3 4 TABLESPACE_NAME # OF EXTENTS TOTAL BYTES ------------------------------ ------------ ---------------- MY_INDX 2388 1,938,915,328 MY_DATA 5 11,274,289,152
Donc MY_INDX est composé de 2388 extents pour 1,938,915,328 bytes et MY_DATA de 5 extents pour 11,274,289,152 bytes...

Première analyse, je dirai que MY_INDX est fragmenté mais à quel niveau ??? Comment ressortir un pourcentage de fragmentation ? A partir de quel niveau faudrait-il penser à réorganiser le tablespace ?

Pour info les tablespaces sont en Locally Managed Uniform.
Version Oracle : 9.2.0.8

Merci.

Cordialement,
Milo.

21/08/2009, 12h02
fatsora

Bonjour,

effectivment ca peut laisser perplexe :
en LMT il ne faut plus se soucier de la fragmentation des tablespaces car c'est techniquement pas possible !

Le nombre d'extents n'est pas un probleme non plus !

How to stop defragmentatin and start living

Jonathan LEWIS

http://www.jlcomp.demon.co.uk/faq/table_frag.html

Sur les extents TOM KYTES
http://asktom.oracle.com/pls/asktom/...:1667293495336
21/08/2009, 14h40
Pomalaix

Citation:

Envoyé par Milo59000

...je n'arrive pas à comprendre comment faire pour calculer la fragmentation des tablespaces d'une base de données.

Bonjour

Je ne peux que rejoindre Fatsora sur les saines lectures qu'il propose.

Néanmoins, comme à chaque fois que ce genre de question revient : quel sens donnez-vous à "fragmentation de tablespace" ?
21/08/2009, 14h44
Milo59000

Merci pour les liens, je vais les consulter.

"Fragmentation de tablespace", pour moi, concerne l'espace libre (chunk ?) qu'il y a dans un tablespace. C'est-à-dire l'espace devenu libre après des opérations DML par exemple.
21/08/2009, 15h29
Pomalaix

Citation:

Envoyé par Milo59000

Merci pour les liens, je vais les consulter.

"Fragmentation de tablespace", pour moi, concerne l'espace libre (chunk ?) qu'il y a dans un tablespace. C'est-à-dire l'espace devenu libre après des opérations DML par exemple.

On peut avoir avoir de l'espace libre à différentes échelles :
1) à l'intérieur d'un bloc (des "lignes" vides suite à DELETE ciblé ou PCTFREE/PCTUSED inadaptés)
2) à l'intérieur d'une extension (des blocs vides suite à DELETE massif)
3) à l'intérieur d'un tablespace (des fragments d'espace qui ne sont pas alloués à des extensions, suite à TRUNCATE / DROP)

A noter que les opérations DML ne provoquent pas de fragmentation de type 3, mais de type 1 et 2.

Si c'est à la fragmentation de type 3 que vous vous intéressez, vous trouverez les informations dans DBA_FREE_SPACE, et la note Metalink que vous citez fait référence principalement à cette vue.
Mais je ne vois pas ce que signifierait un "pourcentage de fragmentation" (alors que pourcentage d'espace libre est tout à fait clair).
21/08/2009, 15h51
Milo59000

Merci pour les précisions.

Effectivement, la demande que j'ai reçue concerne la fragmentation à l'intérieur d'un tablespace et donc bien le pourcentage d'espace libre dans chaque tablespace afin de voir si une réorganisation au niveau tablespaces est nécessaire.

Les informations d'un tablespace que j'ai donné au tout début proviennent justement de DBA_FREE_SPACE. Si j'ai bien compris, le tablespace MY_INDX comprends 5 espaces libres (chunk) qui font en total 11Go.

Est-ce bien cela ?

Maintenant, comment définir si un tablespace possède "trop" d'espaces libres et doit donc être défragmentés ?

en LMT pas besoi de reornaiser , il faul le dire aux directions informatique de tot l'univers !!!!

Les vielles habitudes de oracle 6 que les générations actuelles perpetuent !

regarde ici Tom Kytes

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
 
Tom,
 
If I am having LMT with uniform size so there will be no fragmentation of data.But does this LMT 
requires reorganisation for performance reason ? 
 
( Reorganisation I mean my some method arrange table data in continuous extents by methods such as 
exp/imp, alter table ..etc )
 
thanks & regards 
 
 
 
Followup   June 1, 2004 - 9am US/Eastern:
 
No.  Not it does not.
 
 
extents are never ever contigous -- even if you put them right next to eachother "logically" (we 
are on a file system, file systems are not contigous, you have raid striping and other stuff in 
addition to the fact that file systems are not contigous.  Even if they were, you achieve nothing 
by having the data contigous from a performance perspective)

ou plus encore
http://asktom.oracle.com/pls/asktom/...:1295801859138

21/08/2009, 17h35
Milo59000

Ok, ben écoute, je te remercie pour tes réponses.

Je vais faire le point avec le demandeur compte tenu de toutes ces informations.

Merci.

Cordialement,
Milo.
24/08/2009, 11h54
farenheiit

Citation:

Envoyé par fatsora

Bonjour,

effectivment ca peut laisser perplexe :
en LMT il ne faut plus se soucier de la fragmentation des tablespaces car c'est techniquement pas possible !

peux tu expliquer pourquoi ce n'est pas possible STP?