Discussion :

[fred_04510]

Bonjour,
J'ai un tablespace en extent management = auto,allocation type = system, block size 8k, initial extent = 64M, next extent = null
Dans ce tablespace, j'ai affaire à une table de 1321M ayant un initial extent à 1280M.
Déjà comment se fait il que dans cette configuration j'ai une table avec un initial extent aussi gros ?
Quand je regarde dba_extents je ne vois que des extents à 64M, pourquoi mon extent de 1280M n'apparait pas?

Cordialement,

[Pomalaix]

Bonjour,
J'ai un tablespace en extent management = auto,allocation type = system, block size 8k, initial extent = 64M, next extent = null
Dans ce tablespace, j'ai affaire à une table de 1321M ayant un initial extent à 1280M.
Déjà comment se fait il que dans cette configuration j'ai une table avec un initial extent aussi gros ?
Quand je regarde dba_extents je ne vois que des extents à 64M, pourquoi mon extent de 1280M n'apparait pas?

Cordialement,

Bonjour

Ces chiffres sont en effet surprenants...
A tout hasard, cette table est-elle le résultat d'un import effectué par IMP classique ?

[fred_04510]

Bonjour

Ces chiffres sont en effet surprenants...
A tout hasard, cette table est-elle le résultat d'un import ?

Bien vu, oui c'est le cas.

Frédéric

[Pomalaix]

Bien vu, oui c'est le cas.

Frédéric

Alors mon hypothèse c'est que l'export a été fait avec COMPRESS=YES (c'est la valeur par défaut), ce qui conduit, à l'import, à une table qui tient en une seule extension énorme.

[fred_04510]

Alors mon hypothèse c'est que l'export a été fait avec COMPRESS=YES (c'est la valeur par défaut), ce qui conduit, à l'import, à une table qui tient en une seule extension énorme.

Exact, et c'est le cas pour toutes les tables de la base.
C'est pas terrible du point de vue de la réutilisation de l'espace libre non?
Etonnant que ce soit la valeur par défaut d'ailleurs.

Et pour ce qui est de la table dba_extents?

Merci encore.

[pachot]

Bonjour,

allocation type = system

ce qui veut dire que tu laisse oracle gérer la taille des extents. C'est très bien. Et donc ne t'ettends pas à pouvoir préciser toi-même la taille des extents

Quand je regarde dba_extents je ne vois que des extents à 64M, pourquoi mon extent de 1280M n'apparait pas?

Donc tu as demandé d'allouer 1280M à la création de la table, et oracle a donc choisi 20 extents de 64MB.

Initial permet de définir la taille des extentds à créer au départ, mais pas obligatoirement en un seul extent.

Donc le seul pb posé par un initial si grand, c'est que ta table prendra toujours au moins 1280M, même vide, même après un deallocate extent.
Mais il est normal qu'en Locally Managed Tablespaces l'initial soit sur plusieurs extents, et soit arrondi en fonction de la taille d'extent.
Mais si tu auras toujours plus de 1280M dedans, tout va bien.

Cordialement,
Franck.

[fred_04510]

Bonjour,

Donc tu as demandé d'allouer 1280M à la création de la table, et oracle a donc choisi 20 extents de 64MB.

C'est plutôt l'import qui a demandé ça.

Initial permet de définir la taille des extents à créer au départ, mais pas obligatoirement en un seul extent.

Désolé, je ne suis pas sûr d'avoir compris

l'initial soit sur plusieurs extents

Idem

dans dba_segments, on a une colonne initial_extent qui donne une taille, pour moi c'est la taille du premier extent (en Ko au fait?).
D'après ce que je comprends dba_extents ne donnerait pas l'état réel des choses, mais un état théorique des choses basé sur le mode d'allocation?
Ex : un initial de 1280M = d'après le mode d'allocation 64MX20 extents

Merci d'avance,
Frédéric

[pachot]

En fait c'est le contraire, dba_extents montre la vérité: tu as 20 extents de 64M.

INITIAL_EXTENT a été nommée ainsi du temps des Dictionnary Managed Tablespaces, où une table pouvait avoir des extents de n'importe quelle taille et où avoir des extents trop nombreux était mauvais pour les performances. Et donc, l'allocation initiale se faisait en un seul extent et c'est pour ça que la colonne de la vue a été nommée ainsi.

Mais ici, tu es en Locally Managed Tablespaces où il est préférable d'avoir des extents de taille identiques (ou sinon les bons multiples qui ne laissent pas de trous de taille inégale) et où ce n'est pa gênant d'avoir de très nombreux extents. Donc dans ce cas l'allocation initiale se fait en plusieurs extents.

INITIAL_EXTENT est en octet, et n'est pas obligatoirement alloué en un seul extent - malgrè son nom.

[fred_04510]

Bonjour,
Déjà merci de faire des heures sup pour moi

En fait c'est le contraire, dba_extents montre la vérité: tu as 20 extents de 64M.

Dans ce cas, pourquoi le truncate ne laisse t'il pas un extent de 64M pour la table. Le truncate se base sur dba_segments et non pas sur dba_extents?

Ah oui, j'aurais une question de plus.
J'ai le même problème avec un index volumineux lié à cette table.
Le truncate de la table ne libère pas l'espace alloué pour ce premier extent.
Pour la table, j'ai fait un alter table move storage (initial 64M)
Quelle est la commande équivalente pour un index.

Frédéric

[pachot]

Bonjour,

Dans ce cas, pourquoi le truncate ne laisse t'il pas un extent de 64M pour la table.

Parce que le tuncate redescend la atble à sa taille initiale, même si celà fait plusieurs extents. Si tu fais 'alter table deallocate unused' tu verra que le nb d'extent ne réduit pas non plus.

Pour un index, c'est 'alter index ... rebuild' qui reconstruit l'index éventuellement avec d'autres options de storage.

Cordialement,
Franck.

[fred_04510]

Bonjour,
Pour un index, c'est 'alter index ... rebuild' qui reconstruit l'index éventuellement avec d'autres options de storage.

Oui mais s'il y a un premier extent volumineux, le alter index rebuild suffira t'il?
Sinon, quelle est l'option à utiliser avec la clause de storage pour un index ?

Merci.

Frédéric

[fred_04510]

Bonjour,
J'ai trouvé la réponse à ma question :
alter index ... rebuild storage (initial ...);

Merci pour tout.

Frédéric