Fragmentation du datafile

Salut a tous,

J'ai une base de données oracle 9.2i d'environ 15Go qui grossie depuis 2 ans maintenant. Le datafile principale est configuré en autogrow de 1M.

Depuis quelques temps, les temps de traitement devienennt de plus en plus long et je pense que (vu le autogrow de 1M) j'ai un datafile fragmenté et donc des tables toutes fragmentées et que ca peux causer les problèmes lenteur ?

Est-ce une piste et avec quelles requetes je peux identifier la fragmentation des tables, index...

Je pensais aussi arréter l'instance Oracle un week end et faire un defrag du disque sous Windows 2003 pour défragmenter le datafile.
Ca peut être une solution ou non ?

Merci de votre aide.

je me pencherais plutôt sur un defrag du tablespace
pour faire simple et sans entrer dans les détails du pourquoi du comment, tu réduiras la place utilisé dans le tablespace et potentiellement du gain en perf.

mais pourquoi faire un autogrow de 1M si tu sais que ca va grossit sans arrêt ? fais-en un gros tout de suite et on en parle plus, ca t'évitera de faire trop d'allocations sur le disque qui sont forcément coûteuse

En fait j'ai constaté le autogrow de 1M, c'est le fournisseur de l'applicatif qui avait installé Oracle et qui l'avait configuré ainsi, il y a deux ans.

Quand tu parles de "defrag du tablespace", c'est une commande SQL ou le defrag de Windows ?

Bonjour

Avant de s'interroger sur une hypothétique "fragmentation" (ce terme bien vague sert de fourrre-tout à pas mal de fantasmes), il est prioritaire de vérifier si les statistiques sont régulièrement rafraîchies sur les tables et les index, et si les index nécessaires aux principales requêtes effectuées par l'application existent bien.
La volumétrie augmentant, de nouveaux index peuvent se révéler nécessaires.

comment dois-je faire pour vérifier si les statistiques des tables et des index sont à jour et surtout comment les mettre à jour ?

Oracle ne fait pas ce travail tout seul en 9.2i ?

Merci de votre aide en tout cas.

C'est à partir de la version 10g que les statistiques sont mises à jour automatiquement (s'il y a un changement significatif du nombre de lignes).
Si les traitements sont de plus en plus long, je pencherais pour des accès en full table scan.
La défragmentation sous windows des datafiles peut aider mais ne garantit pas que tes problèmes seront résolus.

Pour vérifier la date des statistiques : colonne last_analyzed des vues DBA_INDEXES et DBA_TABLES.

Pour calculer les stats :

Code:

---

1 2 3

exec dbms_stats.gather_schema_stats(ownname=>'TON_SCHEMA', granularity=>ALL, cascade=>TRUE);

---

Voir les notes metalink 114671.1 et 102334.1

la colonne last_analyzed des vues DBA_INDEXES et DBA_TABLES est NULL pour tous les enregistrements des 2 tables.
Je pense que les stats n'ont donc jamais été calculées.... ca c'est une bonne piste pour mes problèmes de performances.

Maintenant, quels sont les risques pour moi de lancer la requete ci-dessous
exec dbms_stats.gather_schema_stats(ownname=>'MON_SCHEMA',
granularity=>ALL, cascade=>TRUE);

Si j'ai bien compris, la requete mets seulement à jour les tables DBA_INDEXES et DBA_TABLES qu'Oracle utilise pour optimiser ces traitements ?

Y'a-t-il un risque pour mes données, de dégradation des perfs ou autres problèmes... désolé pour ces questions mais je débute...

Enfin, j'ai trouvé que cascade=>true permettais de mettre à jour les stats des indexes relatifs aux tables. Mais à quoi sert granularity=>ALL ?

Merci pour votre aide, je crois qu'on s'approche de la solution ?

granularity=>ALL permettra de calculer les statistiques des partitions et sous-partitions.
Si last_analyzed est nul, l'optimiseur fonctionne en mode RBO (rule based optimizer) => basé sur les règles syntaxiques des requêtes (exemple : choix des index en fonction des champs de la clause where, de l'ordre alphabétique des index...). Le calcul des stats peut te faire gagner beaucoup mais peut aussi dégrader certaines requêtes.
Les risques :
- consommation cpu et disque durant le calcul des stats (c'est normal, tu vas lire toutes les datas et faire des calculs : longueur moyenne des lignes, nb de blocks utilisés etc.)
- consommation d'espace temporaire supplémentaire
- dégradation de perf possible pour certaines requêtes

la plupart de ces risques sont levées si les stats etaient efeectuées au moment ou ca gene moins les users : week end , demain (11 nov) , le soir ....

Vous pensez qu'il est aussi necessaire de calculer les stats pour les schémas SYS et SYSTEM

exec dbms_stats.gather_schema_stats(ownname=>'SYS', granularity=>ALL, cascade=>TRUE);

exec dbms_stats.gather_schema_stats(ownname=>'SYSTEM', granularity=>ALL, cascade=>TRUE);

FYI

Subject: Gathering Data Dictionary Statistics
Doc ID: NOTE:245051.1 Type: FAQ
Last Revision Date: 16-APR-2004 Status: PUBLISHED


Il dit notamment que ce n'est pas nécessaire de lancer les stats
sur les objets SYS.

Citation:

---

Le calcul des stats peut te faire gagner beaucoup mais peut aussi dégrader certaines requêtes.

---

Je comprend pas comment des requêtes peuvent etre plus longues quand l'optimiseur à toutes les stats à jours.
Quelles genres de requêtes sont plus longues en RBO (rule based optimizer) qu'en CBO (cost based optimizer)

Citation:

---

Envoyé par devplanete

Vous pensez qu'il est aussi necessaire de calculer les stats pour les schémas SYS et SYSTEM

exec dbms_stats.gather_schema_stats(ownname=>'SYS', granularity=>ALL, cascade=>TRUE);

exec dbms_stats.gather_schema_stats(ownname=>'SYSTEM', granularity=>ALL, cascade=>TRUE);

---

Bonjour à tous,

J'ai +fois que calculer les statistiques pour sys ou system est risqué (risque de deadlook sur les tables sys ...)
Est ce vrai ?
Meci.

Quelle version Oracle ??

FYI

Subject: Gathering Data Dictionary Statistics
Doc ID: NOTE:245051.1 Type: FAQ
Last Revision Date: 16-APR-2004 Status: PUBLISHED


Il dit notamment que ce n'est pas nécessaire de lancer les stats
sur les objets SYS.

Citation:

---

Envoyé par fatsora

Quelle version Oracle ??

FYI

Subject: Gathering Data Dictionary Statistics
Doc ID: NOTE:245051.1 Type: FAQ
Last Revision Date: 16-APR-2004 Status: PUBLISHED


Il dit notamment que ce n'est pas nécessaire de lancer les stats
sur les objets SYS.

---

Bonjour,

En 9i (9205, 9207).

Cordialment,
SDR

Bonjour,

personnellement , je déconseillerai complétement un defrag d' un
disque windows contenant des datafiles .

Sous dba-studio, clique droit sur le tbs : show tablespace map
un outil ou on voit la fragmentation du tbs,
on peut aussi lancer un outil qui donnera des infos sur
la nécessité de réorganiser le tbs .

l' idéal est un export-import pour défragmenter le tbs .

Mais comme l' a dit pomalaix, peu de chance que le souci vienne de là

la piste des stats semble meilleure ..

cdlt