Paramétrage optimal pour PCTFREE, PCTUSED et INITRANS, par Tom Kyte

Publié le par

Cet article est la traduction d’une réponse Tom Kyte à une question sur le paramétrage idéal de PCTFREE, PCTUSED et INITRANS (L’article original en anglais se trouve ici).

PCTFREE

Si vous avez une table qui ne subit que des inserts, mettez PCTFREE à 0, parce que vous n’avez rien à réserver pour les updates.

si vous savez une table dont les lignes doublent de taille, c’est une bonne idée de mettre PCTFREE à 50, pour réserver de la place pour les updates.

Vous devez comprendre comment les données grossissent dans le temps. Si vous faites des inserts, puis sur 10% de ces lignes vous faites des updates qui augmentent leur taille de 20%, alors vous devez:

  • savoir combien de lignes par bloc vous avez en moyenne
  • calculer ce que les 20% d’une ligne représentent en pourcentage de bloc.
  • utiliser ce pourcentage de bloc comme PCTFREE

PCTUSED

Et utilisez ASSM (automatic segment space management), la gestion automatique de l’espace libre des segments, et vous n’avez pas à vous soucier de PCTUSED, FREELISTS, FREELIST GROUPS.

INITRANS

Pour INITRANS, vous devez vous baser sur le nombre maximum de modifications concurrentes qu’il peut y avoir sur un bloc. Si vous avez une table qui ne reçoit que des inserts, et que vous êtes en ASSM, ne vous inquiétez pas et laissez la valeur par défaut. Si vous avez plutôt une petite table que vous updatez comme un fou, alors vous devez y réfléchir.

Question supplémentaire sur PCTFREE

Je ne comprends pas bien la raison du nombre de ligne par bloc ici. Je pensais que si 10% des lignes augmentent de 20% alors – en moyenne – l’espace utilisé dans le bloc augment de 2%.

Réponse:

2% d’un bloc n’est pas vraiment de sens ici. Vous devez comprendre combien de lignes par bloc vous pouvez avoir. Par exemple, je peux avoir 7 lignes de 1024 octets, dans un bloc de 8k. Si je dois en updater 10% pour qu’elles soient 20% plus larges, ce n’est pas les 2% qui comptent, mais le calcul suivant:

  • Environ 1 ligne par bloc va augmenter
  • Si elle s’accroît de 20%, je ne peut avoir que 6 lignes par bloc
  • Je ferais mieux de mettre un PCTFREE qui fait qu’il n’y aura que 6 lignes en moyenne.

2% serait trompeur, car la granularité des lignes est assez « large »

Une précision: Ces explications concernent les tables (heap tables) mais pas les index (ni les Index Organized tables)
Un index a une gestion différente de l’espace libre: chaque ligne y a sa place, puisqu’il est trié: un bloc n’a pas le choix d’accepter des lignes ou non. Les blocs sont remplis jusqu’au bout, et lorsque ils sont pleins à 100%, ils peuvent être coupés (split) en deux blocs qui auront chacun leur part d’espace libre.
Ce qui veut dire que pour les index, PCTUSED n’a pas de sens, PCTFREE ne concerne que l’espace libre laissé à la création de l’index (ou au rebuild ou coalsece) pour qu’il n’y ait pas trop de block splits dès les premières mises à jour. INITRANS est ignoré, il suffit qu’il y ait toujours une entrée possible pour la transaction qui aura à faire le bloc split et on pourra toujours faire de la place. Au fur et à mesure des mises à jour, l’index s’ajustera en fonction du besoin d’espace libre et d’entrées ITL.

Laisser un commentaire