Discussion :

[user_oracle]

Il est vrai qu'il est difficile de réorganiser automatiquement les tables.
Q c q tu appelles les rows migrées :

[orafrance]

ça peut quand même être fait si on ne s'attache qu'à vérifier l'existence de lignes dans chained_rows qui ne liste QUE les lignes migrées

En revanche, l'utilité d'une réorg quotidienne me parait absurde :

1°) la table est peu volumineuse : la réorg sera relativement rapide mais le volume est si petit que les lignes migrées ne représentent pas une perte de perf significative

2°) le table est énorme : là la migration de lignes coutent très cher mais la réorg sera tellement lourde que dans une journée tu passeras plus de temps à réorganiser tables et indexes qu'à reconstituer les chaines

Il faut bien comprendre que la migration ne peut se produire SURTOUT en update puisque c'est le cas d'une ligne contenu dans un bloc qui est agrandit de telle sorte que la colonne agrandit oblige Oracle à la mettre dans un autre bloc

Bref... à mon avis, tu fais une erreur de vouloir programmer la réorg trop souvent. En revanche, ça peut effectivement être interessant de monitorer les lignes chainées pour savoir quand intervenir

[user_oracle]

La procédure sera rattacher à un job qui tournera une fois par semaine vers 02h00 (dimanche), ça ne perturbera personne. Il y a réorganisation de la table si cela est nécessaire ( chain_cnt >0 ) sinon il n'y aura pas de réorganisation.

[orafrance]

NOOOOONNNN

pas si chnt_count > 0 mais si il existe des lignes dans chained rows suite à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ANALYZE TABLE <nom de table> 
LIST CHAINED ROWS INTO chained_rows;

chnt_count permet de voir si tu as des lignes chainées mais ne fait pas la différence en une ligne chainée sur des blocs contigus (taille de ligne > taille de bloc) et une ligne migrée (i.e. fractionnée en n blocs non contigus)

[thomasjcj]

A propos des vraies chained Rows et essayer de resoudre le probleme. Mettons qu'une table contienne une grande quantite de chained rows et que cela ait un effet notable sur la performance, es ce qu'une possibilité serait de reorganiser la table dans un Tablespace avec une taille de bloc supérieure (a partir de 9i)?
Je n'ai cependant pas une grande experience des tablespaces de taille diferentes dans une base, ca complique la gestion du buffer cache....

vos avis ?

[user_oracle]

Orafrance,

Si j'ai bien compris ce que tu viens d'écrire, il faudrait que je fasse un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ANALYZE

de mes tables, ensuite, je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select distinct owner_name,table_name from system.CHAINED_ROWS;

.
Donc, si cette requête me retourne des tables qui ont des lignes chaînées alors je fais une réorganisation des tables concernées.
8)

[orafrance]

pas systématiquement mais dans l'idée c'est ça

En fait, la réorg vaut le coup quand les perfs se dégradent et/ou lorsque le taux de lignes migrées devient conséquent

[orafrance]

A propos des vraies chained Rows et essayer de resoudre le probleme. Mettons qu'une table contienne une grande quantite de chained rows et que cela ait un effet notable sur la performance, es ce qu'une possibilité serait de reorganiser la table dans un Tablespace avec une taille de bloc supérieure (a partir de 9i)?
Je n'ai cependant pas une grande experience des tablespaces de taille diferentes dans une base, ca complique la gestion du buffer cache....
vos avis ?

C'est effectivement une idée intéressante, on peut aussi jouer avec le PCTFREE pour garder de l'espace libre suffisant pour les updates à venir

Apparemment les tablespaces avec des blocs de taille différente au DB_BLOCK_SIZE fonctionnent bien, pas de probléme à déplorer

[Marc Musette]

pour conclure :
- effectivement c'est le para PCTFREE qui va permettre d'éviter les migrated rows

- la colonne CHAIN_CNT contient les vraies chained rows + les migrated

cf la doc (Oracle Reference) :

CHAIN_CNT* : Number of rows in the table that are chained from one data block to another, or which have migrated to a new block, requiring a link to preserve the old ROWID

--> comment voir si on a des migrated rows :
1 - faire un SELECT COUNT de la dernière colonne de la table : cela oblige Oracle à construire la row entière en cas de vraies chained row et non en cas de migrated row (car full scan)
2- vérifier le nombre de TFCR (Table Fetch Continued Rows) via :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
select a.name, b.value
from v$statname a, v$mystat b
where a.statistic# = b.statistic#
and lower(a.name) like '%' || lower('&1')||'%' ;
 
NAME                                VALUE
------------------------------ ----------
table fetch continued row            10

10 indique que 10 rows sont réellement des chained rows --> si CHAIN_CNT > à 10, alors il y a également des migrated rows.

et une réorg est nécessaire

General Management of Schema Objects


pour la marche à suivre "officielle"

[user_oracle]

MERCI à vous tous [/b]

[Débéa]

Je relance le débat...

Vous ne parlez que des chained rows mais n'y a t-il pas d'autre raisons de réorganiser une table ?

1- Nombre de EMPTY_BLOCKS importants --> pour récupérer de la place
2- Fragmentation ! Vaste sujet !
Qu'est-ce que la FRAGMENTATION ?
Est-ce toujours d'actualité avec les tablespace locally managed (LMT) ?
Beaucoup imagine que l'ideal est d'avoir tous les segments/extents/blocks d'une table contigus dans le tablespace...
Qu'en est-il ? Est-ce vraiment important pour les perfs ? Surtout dans le cas d'un full scan avec db_file_multiblock_read_count ?

Merci par avance pour vos réponses,