Reorg / Rebuild : optimisation

Bonjour,

Je souhaite optimiser mes Reorg / Rebuild car mes bases grossissant, je ne dispose plus d'assez de temps pour effectuer ces maintenances hebdomadairement. Par ailleurs, je ne suis pas convaincu qu'un Reorg / Rebuild systématique soit judicieux.

Je souhaite m'appuyer sur les valeurs ci-dessous qui me sont retournées par OPTDIAG après avoir lancer un UPDATE STATISTICS MA_TABLE :

Code:

---

1 2 3 4 5 6

Empty data page count: 0 Forwarded row count: 0.0000000000000000 Deleted row count: 0.0000000000000000 First extent data pages: 0 Unused page count: 0

---

Pouvez-vous m'indiquer si c'est la meilleurs méthode et quels sont les seuils par rapport au nombre de ligne d'une table ou un Reorg / Rebuild s'impose ?
Y-a-t'il une manière plus adaptée pour déterminer quand un Reorg / Rebuild doit être effectué sur une table ?

Personellement j'utilise le petit script perl joint pour determiner quand faire des reorg. C'est basé sur la fonction "derived_stats" qui permet de calculer les ratios (data pages cluster ratio, etc) pour chaque table/index.

De façon très empirique j'utilise 0.95 comme seuil pour le datapages cluster ratio et le index pages cluster ratio, et 0.75 pour le space utilisation. Ce ne sont pas forcément les bons seuils....

Michael

Michael,
Merci pour le script. Est-il nécessaire de lancer un update statistics avant de lancer ce script perl ?
:roll:

Je ne sais pas si c'est nécessaire - si on le fait on a une plus grande chance que les champs des statistiques dérivées seront correct.

Michael

Merci Michael,
Je vais le mettre en oeuvre dans un environnement de test.
:ccool:

Michael,

Je n'arrive pas à trouver le module DBAutil qui est utilisé le script que tu m'as fourni. Peux-tu m'indiquer où tu te l'es procuré ?

Merci d'avance.

:oops:

DBAutil ne sert qu'a trouver le password du user 'sa' pour le dataserver.

Donc il est facile de s'en passer - il faut mettre en commentaire le "use DBAutil" et toujours passer le password en parametre au script.

Michael

Ok, merci.
Par contre, est il possible de réduire le temps de certains Reorg/Rebuild ?
J'en ai certains qui prennent plus de 6 heures les plus grosses tables.

reorg rebuild (et reorg compact, reorg rebuild index) font évidemment beaucoups d'IO physiques - d'où la lenteur.

Pour optimiser, on peut bénéficier d'un pool 16k de taille raisonnable (il peut être agrandi dynamiquement avant le reorg, et re-taillé plus petit ensuite).

Il y a peut-être d'autres paramètres qui peuvent un peu influer sur la durée du reorg (p.ex. number of sort buffers)

Michael

Merci Michael,
Je vais tester différentes config afin d'optimiser la durée de mes traitements.
:ccool:

Par contre, le pool de 16K doit il être créé dans le pool de Default Data Cache ?
;)

Le pool doit être créé dans la cache qui est utilisée pour la table qui est réorganisée.

Donc si cette table utilise la "default data cache" alors oui, c'est là qu'il faut mettre le pool 16k.

Michael

Bonsoir Michael,
Juste une petite info : je suis curieux et cherche à savoir d'où vient la méthode get_tabinfo. J'ai cherché sur les sites Perl, CPAN, dans le code du DBI.pm, mais rien n'y fait, je ne la trouve nulle part et pourtant ça fonctionne.
Merci et @ +
:ccool:

Désolé, je viens de voir qu'il s'agit d'une fonction interne à votre code.