Discussion :

[dauphin34000]

Bonjour, à toutes et à tous

Voilà, je ne sais plus qui croîre sur le sujet de la réorganisation d'une base oracle en 9i.

Lors d'une formation "administration oracle", j'ai demandé au formateur "expérimenté" si il était toujours nécessaire en 9I avec une base en production de 12 gigas, qui n'augmente pas en taille (delete chaque jour des données qui dépassent 183 jours).

Il m'a répondu que depuis la 9i la fragmentation était négligable et par conséquent cela n'était plus utile.

Mais, lors de ma reprise de poste, j'ai constaté, qu'il y avait un script qui se lancé chaque semaine. Il fait une réorganisation (table et index) OFFLINE.

J'ai décidé de l'utiliser d'une fois par mois. Depuis, j'ai ma hiérarchie qui m'indique que cela va ralentir les temps de réponse et que ce processus a été décidé par un Expert DBA, donc il a forcément raison. Pour votre information nous n'avons pas d'augmentation de temps de réponse au niveau de l'application.

Si une bonne âme peu me dire si j'ai fait une bétise ? Si oui pourquoi et si non aussi. Y a-t-il un document "de référence" en la matière.

Merci encore pour vos explications et pour vos conseils.

Très cordialement.

[orafrance]

Bonjour,

Aller... je me lance au risque de m'attirer l'ire de certains puisque ce genre de questions on se l'est tous posé un jour... sans jamais vraiment pouvoir trancher Je vous remercie donc à l'avance de modérer vos réponses si vous devez me corriger

Personnellement, j'ai tendance à croire que la nécessité de réorganisation résulte d'un mauvais design des tablespaces. En effet, avec un PCT_FREE, un PCT_USED et une taille de bloc adéquat, une réorganisation doit être rare voir inutile. Néanmoins, il est évident qu'il est difficile à la création de la base de définir correctement ces paramètres.

Commençons donc à comprendre ce qui peux poser problème lors de l'accès aux données et entre autre, qu'est ce que la fragmentation.
Si nous parlons de fragmentation des disques, alors là c'est clair, la technologie utilisé par les OS ne permet pas d'éviter la fragmentation. Dés lors, il faut vivre avec et cesser de se faire des noeuds avec celle-ci sachant qu'on ne peux pas y faire grand chose. Néanmois, au cours des mes expériences, j'ai pu voir des gains considérables de performance en améliorant l'organisation des disques (je tempère tout de même ces propos : je ne l'ai vu qu'une fois et dans le cadre d'un datawarehouse de plusieurs To avec des recalculs complets de cubes quotidiens). Je ne suis pas un expert en la matière mais de ce que j'en ai compris, il s'agit d'optimiser l'emplacement des datafiles sur les disques pour réduire le stress du controleur et les I/O intempestifs (je parle ici d'une baie de disques type SAN). Le mieux étant encore de s'adresser au support matériel qui saura agir en conséquence. Bref... les disques, c'est l'affaire des admins systèmes, partons du principe qu'ils connaissent leur métier et qu'on a pas à leur apprendre Notez que les chances d'avoir toutes les données sur le même disque, voir le même plateau... voir même la même partie du disque doit être du même ordre que gagner 3 fois au loto la même semaine
Si nous parlons de fragmentation de données dans les datafiles, là il faut distinguer le chainage de la migration de données. La migration de données est symptomatique de paramètres de stockage inadéquat et là il faut essayer de profiter d'une réorganisation pour le revoir. J'en profite pour vous rappeler cette "règle" des 1024 extents : http://oracle.developpez.com/guide/a...lespaces/#L4.3 (si je n'ai moi-même jamais pu mettre en place cette "règle" un gourou de chez Oracle très calé sur les traces, m'a assuré que le kernel n'est pas spécialement prévu pour des tablespaces de plus de 1024 extents... ça fonctionne mais au coup d'un traitement particulier... selon lui )

Ma conclusion : On ne devrait faire une réorganisation des données que TRES rarement : une fois après que la base a suffisamment vécu pour pouvoir corriger les erreurs de paramétrage et éventuellement, de temps en temps (genre 2-3 ans) pour s'adapter au changement effectués dans la base au cours de sa "vie". Et on devrait toujours l'accompagner du changement des paramètres de stockages des tablespaces.

PS : Si quelqu'un a un retour d'expérience sur l'ASM concernant les perfs, ça peut aussi être intéressant puisqu'Oracle a promis des gains assez exceptionnel grâce à cette techno (et si le gain sur le terrain n'est pas aussi remarquable qu'annoncé par le service marketing, les retours que j'ai eu de mon coté sont plutôt positif). La question initiale concerne Oracle 9i mais rien n'interdit d'élargir le débat

[orafrance]

c'est dommage que personne n'a donné son avis sur ce sujet qui me semble pourtant intéressant