tables avec option AUTOALLOCATE

[pat29]

Bonjour, et bonne année !

J'ai créé mes tables (partitionnées) en Oracle 9i avec l'option AUTOALLOCATE et j'ai taillé l'INITEXTENT avec un seuil un peu inférieur à la taille de la partition minimum pour économiser l'espace.
Après l'import les tailles ont donc augmenté mais je me retrouve avec pas mal d'extents. Je ne sais pas comment il les alloue au niveau taille mais est-ce pénalisant pour les performances ?

Merci.

[orafrance]

Oui ça peut être pénalisant si tu attends énormément de volume dans chaque partition : http://oracle.developpez.com/guide/a...lespaces/#L4.1

La régle d'allocation est du genre (de mémoire) : 100° extent de 8k, du 101° au 1000° de 16k, du 1001 au 10000° de 32k... etc. C'est probablement pas la régle exacte mais c'est l'esprit

[pat29]

Merci, je viens de voir sur le lien que les 16 premiers extents font 64k, les 64 suivant 1024k.
Je pense donc que pour mon cas (certaines partitions dépassent 1 Go) il vaudrait mieux prendre UNIFORM SIZE pour pouvoir paramétrer un NEXT EXTENT proportionnel, non ?

[orafrance]

en effet ça peut être une solution

[LeoAnderson]

l'uniform est surtout intérêssant dans un tablespace où l'on crée/droppe beaucoup.
je ne vois pas en quoi l'auto vous pose soucis...

avec un uniform, vous risquez d'avoir encore plus d'extents, ou alors avoir une taillle d'uniforme très grande vous faisant perdre de la place...

quand à la règle, elle n'est pas documentée alors on ne peut que constater certains fonctionnement, mais il n'est pas possible de dire que c'est ce qui se produira avec certitude.

Si on ne fait pas beaucoup de drop/create, je préfère auto à uniform.

[pat29]

J'ai des drop/create uniquement pour les partitions.
Sinon le pb est que les partitions sont liées au mois et que le nombre de lignes augmente inexorablement avec le temps. Donc si je fixe l'INITIAL EXTENT au niveau de la 1ère partition, et sachant que l'on peut monter jusqu'à un écart de 100 Mo avec la dernière, nous aurons beaucoup d'extents, vu la taille attribuée par l'AUTOALLOCATE...

[Michel SALAIS]

J'ai des drop/create uniquement pour les partitions.
Sinon le pb est que les partitions sont liées au mois et que le nombre de lignes augmente inexorablement avec le temps. Donc si je fixe l'INITIAL EXTENT au niveau de la 1ère partition, et sachant que l'on peut monter jusqu'à un écart de 100 Mo avec la dernière, nous aurons beaucoup d'extents, vu la taille attribuée par l'AUTOALLOCATE...

J'ai l'impression qu'il y a plusieurs sous-entendus et plusieurs confusions:

AUTOALLOCATE et UNIFORM sont désignés au niveau des tablespaces et non au niveau des tables.
Les paramètres de stockage comme NEXT et PCTINCREASE sont définis par segment et non par table

Il faut également savoir que les paramètres de stockage de la table (du segment plus correctement) ne sont plus considérés après la création si le segment est sur un tablespace géré localement et ceci contrairement à ce que laissent enrendre certaines phrases

[orafrance]

Envoyé par Michel SALAIS

Il faut également savoir que les paramètres de stockage de la table (du segment plus correctement) ne sont plus considérés après la création si le segment est sur un tablespace géré localement et ceci contrairement à ce que laissent enrendre certaines phrases

j'ai pas compris se passage... ça laisserait entendre que les paramètres du tablespace "écrasent" les paramètres des segments

[pifor]

Pour les tablespaces gérés localement, oui. C'est ce qui dit la documentation parfois clairement et parfois moins clairement en ne faisant pas la distinction entre les tablespaces à gestion d'espace locale (LMT) et les tablespaces à gestion d'espace dans le dictionnaire (DMT).

[orafrance]

En effet, j'avais pas percuté... la gestion des extents est effectivement complétement gérés par le tablespace et plus par les segments... mais faut pas confondre avec les clauses de stockage qui inclus PCTFREE, PCTUSED, etc... et reste paramètrable au niveau du segment.

Ce qui est géré localement c'est "uniquement" les extents

[pat29]

Il faut également savoir que les paramètres de stockage de la table (du segment plus correctement) ne sont plus considérés après la création si le segment est sur un tablespace géré localement et ceci contrairement à ce que laissent enrendre certaines phrases

Je confirme que si la valeur INITIAL de l'ordre de création de la table est bien utilisée pour chaque partition, la valeur NEXT n'est pas prise en compte.

Sinon quand je dis

si je fixe l'INITIAL EXTENT au niveau de la 1ère partition

je voulais dire "au niveau de la taille de la 1ère partition"

Donc si je veux rester en AUTOALLOCATE et limiter le nombre d'extents pour les plus grosses partitions il faudrait que j'augmente l'INITIAL au fur et à mesure des partitions, ce qui est gênant car je génère tous les scripts de création/destruction de partition à partir d'une table de paramètrage avec un script PL*SQL...

[Michel SALAIS]

Envoyé par pat29

Je confirme que si la valeur INITIAL de l'ordre de création de la table est bien utilisée pour chaque partition, la valeur NEXT n'est pas prise en compte.

C'est à moitié vrai
En effet, si minextents est supérieur à 1 alors NEXT est pris en considération! En réalité, Oracle calcule la taille initiale nécessaire d'après les paramètres de stockage : INITIAL, NEXT, PCTINCREASE et MINEXTENTS et crée le segment avec la taille demandée mais sans respecter ni le nombre ni les tailles des extents. D'un autre côté, Oracle ne va pas "respecter" non plus sa stratégie d'origine pour les tablespaces en AUTOALLOCATE. Ainsi, nous pouvons voir que Oracle va démarrer avec des extents de taille 1M par exemple à la place de 64K.

Par la suite les paramètres de stockage : INITIAL, NEXT, PCTINCREASE, MINEXTENTS et MAXEXTENTS ne sont plus regardés.

[ édité pour rendre plus claire, du moins je l'espère ... ]