Choix de db_block_size

[totoche]

Bonjour,

Je dois créer une table à laquelle les utilisateurs vont avoir accès par requête mono table(pas de jointure).
Chaque tuple de la table pèse entre 25 et 35 octets (4 attributs).
Plusieurs milliers de lignes vont alimentées cette tables.
Je pense donc créer un tablespace pour cette table, avec des block size de 32ko (DB_32K_CACHE_SIZE)
Cette table sera en IOT.

Qu'en pensez vous

Merci

[Pomalaix]

De ce que vous dites, rien à mon sens ne justifie l'usage de blocs de grande taille, sauf si vous comptez faire des lectures intégrales de cette table, sans passer par index.

De plus, Oracle ne recommande pas d'utiliser des tablespaces ayant des tailles de bloc différentes ; cette commodité est officiellement réservée à l'accueil des tablespaces transportables venant d'une base utilisant une taille de bloc différente.

[pachot]

Bonjour,
Je suppose que l'idée est d'avoir des blocs très larges dans le but de diminuer la hauteur de l'index (IOT). Il faudrait être sûr que le gain en performance soit important pour justifier le fait d'avoir des tailles de bloc différents dans la base.
Cordialement,
Franck.

[Rei Ichido]

Envoyé par pachot

Bonjour,
Je suppose que l'idée est d'avoir des blocs très larges dans le but de diminuer la hauteur de l'index (IOT). Il faudrait être sûr que le gain en performance soit important pour justifier le fait d'avoir des tailles de bloc différents dans la base.
Cordialement,
Franck.

Le but doit plutôt être de ne pas avoir de l'overflow, effectivement pour ne faire que du parcours de l'index ...
J'aurais tendance à penser que si une table a besoin de ça, c'est qu'elle n'est pas idéale pour une IOT.

[pachot]

Bonjour,

Envoyé par Rei Ichido

Le but doit plutôt être de ne pas avoir de l'overflow

J'en doute. Avec une clause INCLUDING ça devrait être facile de ne pas avoir d'overflow pour des lignes de 35 octets...
Cordialement,
Franck.

[Waldar]

Envoyé par totoche

Chaque tuple de la table pèse entre 25 et 35 octets (4 attributs).
Plusieurs milliers de lignes vont alimentées cette tables.

Avec un million de lignes, votre table pèsera autour 50 Mo, c'est à dire presque rien du tout.

Quant au choix de l'IOT, si vos appels à cette table passe toujours par la clef primaire, pourquoi pas. Si vous n'en êtes pas certain, restez en organisation heap.

[Rei Ichido]

Envoyé par pachot

Bonjour,

J'en doute. Avec une clause INCLUDING ça devrait être facile de ne pas avoir d'overflow pour des lignes de 35 octets...
Cordialement,
Franck.

Au temps pour moi, j'avais zappé la partie descriptive des tuples ...

[totoche]

Bonjour,

Merci de vos réponses, en effet l'objectif est de diminuer le nombre d'E/S.

Cependant il me manque une spec... les requêtes auront-elles comme unique prédicat la clé primaire... Si tel est le cas je pars pour faire une IOT.

Si au final ma Table n'est pas en IO (predicat qui met en oeuvre les index secondaires), je pensais judicieux de créer un tablespace index de taille DB_4K_CACHE_SIZE, or vos réserves sur

tailles de bloc différentes

me laisse penser que ce n'est pas la cas, quitte a ce que le bloc ne soit que partiellement rempli. (db_block_size 8ko)