Analyse des paramètres d'une base

Concernant les stats systèmes il faut les mettre à jour uniquement quand on connait des pb de perf ou bien faut il les mettre à jour régulièrement ?

Les statistiques systèmes doivent être à jour. Celà dit ce n'est pas la peine de les recalculer tous les jours. Normalement un calcul une fois durant une période de charge représentative suffit. Après s'il y a modification du hardware (disque, cpu ...) il faut les recalculer.

Citation:

---

Envoyé par sweeton

Enfin, d'une manière générale ça coûte toujours beaucoup moins cher de modifier un paramètre de l'instance ou de créer un outline que de modifier le code-source pour optimiser la requête.

---

Certes mais l'investissement à long terme est bien plus intéressant quand on adapte le code à la nouvelle version et pas le contraire ;)

Ouais ... ça c'est la théorie. ;) En pratique si à chaque changement de version d'un des composants d'une plate-forme il fallait refaire une passe sur tout le code-source, tous les informaticiens de France et de Navarre auraient du boulôt pour les prochains siècles ... On appelle ça le mouvement perpétuel :mouarf:
Bref, trève de plaisanterie, investir de l'argent pour modifier une application pour cause de changement de version de base Oracle ou autre composant quand la version précédente marchait bien est quelque chose de difficile à faire à passer à tout DSI qui se respecte. ;)

Certes mais tu ne le fais pas tous les 4 matins non plus (que les MAJ majeures, entre 8i et 9i il y avait peu ou pas de boulot, idem entre 10g et 11g :)) et ça permet de profiter pleinement de la nouvelle version.

C'est vrai que le plus dur là dedans c'est de convaincre le DSI qui doit convaincre l'équipe TMA :mouarf:

Citation:

---

Envoyé par sweeton

Si ton batch fait essentiellement du full scan, tu peut modifier les paramètres suivant :
- optimizer_mode : ALL_ROWS
- _optimizer_cost_based_transformation : OFF (attention c'est un undocumented parameter mais ça marche plutôt bien sur les problèmes de dégradation de perfs suite au passage en 10G).
- _optimizer_cost_model : io (ça c'est pour le cas ou ta base passe beaucoup de temps en "db file sequential read", si elle passe plus de temps en "CPU Time" ne touche pas à ce paramètre).

Si les requêtes lancée par ton batch sont censées passer par des indexes, modifie les paramètres suivants :
- optimizer_index_caching : 50, 90 voire 100 (il faut essayer plusieurs valeurs ...)
- optimizer_index_cost_adj : 1


Celà dit, commence d'abord par les actions suivantes :
1. Augmenter ton sga_target et ton pga_aggregate_target.
2. Vérifier les stats Oracle et si besoin les recalculer avec un taux d'échantillonage et une méthode histogramme plus complète
3. Calculer les statistisques système (dbms_stats.gather_system_stats)

---

je suis en train de lire le livre de Christopher LAWSON (The art and the science of Oracle Performance Tuning) et dans le chapitre "Analyzing SQL Joins" il préconise la MAJ du paramètre OPTIMIZER_INDEX_COST_ADJ selon la manière suivante:
- récupérer la valeur de AVERAGE_WAIT dans la table v$SYSTEm_EVENT pour les évenements: "db file sequential reads et db file scattered reads
-faire: AVERAGE_WAIT pour sequential reads / AVERAGE_WAIT pour scattered reads
- le pourcentage récupéré correspond à la valeur à mettre dans OPTIMIZER_INDEX_COST_ADJ

ex: si pour les lectures par index on : 0.4561 et pour les lectures disk on a 2.04121 alors la valeur du paramètre sera de 0.4561/2.04121= 0.223 = 22.3(%)

Don Burleson (dba-oracle.com) propose aussi une formule de calcul basée sur un script qui pioche les infos dans les tables d'event. C'est assez fiable mais la valeur dépend beaucoup de l'activité qu'il y a eu durant les dernières heures.
Toutes ces formules c'est assez empiriques. En général j'ai l'habitude de tester plusieurs valeurs en live via des "alter system set ..." jusqu'à tomber sur la valeur la plus cohérente.