La lecture d'un rapport AWR (Automatic Workload Repository)

Regroupement avec GROUP BY

Substr et opérations sur les chînes.

Insérer un CLOB par sql*Loader

Les directories : manipulation de fichiers

Le bind peeking

Les histogrammes associés aux statistiques

Les secrets de la fonction DECODE

Les triggers

Plans d'exécution stockés

Aperçu des transactions autonomes

CBO : les plans d'exécution selon la volumétrie cible

Reprise de données : exemples simples

Clés primaires et étrangères : mettre en place ses contraintes d'intégrité

L'instruction MERGE ou l'insertion choisie

DBlink : interroger une base distante

Pourquoi mon index n'est pas utilisé ?

Les index bitmap

Les bind variables pour les requêtes courantes

Injection et traitements de masse

Créer un index de fonction

Vidage de cache

Utilisation de rownum et rowid

Les exceptions SQL oracle

Des lignes aux colonnes, un PIVOT suffit pour la 11g ; DECODE en attendant

Migration de modèles avec vues et synonymes

La clause WITH à la rescousse des sous requêtes

Comparer l'exécution d'une requête avec 2 index différents

La table DUAL pour développer

Tablespaces, datafiles et filesystem, comprendre le stockage

Modifier des paramètres, arrêter et redémarrer une base oracle.

Comprendre à quoi sert le listener et test avec tnsping

Interaction shell Unix / sqlplus Oracle

Gérer l'auto-increment sous Oracle

Le dictionnaire de données : premiers pas

Les LOB pour contourner les limites de LONG

Hint oracle et choix du plan d'exécution

Les types SQL et les types PL

Migration des LOB dans un tablespace dédié

SQL générant du SQL

Industrialisation des scripts SQL

CREATE OR REPLACE ... oui mais pour les tables ?

Les vues

Migration des index dans un tablespace dédié

Les colonnes virtuelles en 11g

Monter des données dans le cache Oracle

Index

La jointure : sélection sur plusieurs tables

XML et Oracle

Les statistiques Oracle

Import avec les contraintes : ordonner les insert

Les tables partitionnées

Fonction Oracle à partir d'une procédure java

Exporter la structure d'une base

Améliorer les performances d'une vue

Les index B-tree

La lecture d'un rapport AWR (Automatic Workload Repository)

La période de rapport :
- OLTP en journée / batch la nuit
- Spécifique à une action logicielle
- Tests de charge représentatifs

La participation d’Oracle sur la CPU utilisée :
- DB time vs elapsed time => Dbtime / elapsed time = sessions actives moyennes

Instance Efficiency Percentages

- Comprendre les ratios en fonction de l’activité :
- En OLTP : Expliquer les ratios < 98 ; s’attarder sur les ratios < 95

Buffer hit ratio

C’est le ratio entre les requêtes satisfaites à partir du cache et les requêtes nécessitant un accès disque. Ce ratio sera très déterminant pour des applications web ou visualisations « temps réelles ».

S’il est trop bas sur des traitements OLTP, il faut s’attarder à sur le db_cache_size

Buffer Nowait ratio

C’est le ratio de disponibilité d’un buffer (100% signifie qu’aucun lock de buffer n’a été rencontré) ; si ce ratio est faible (< 95%), il faut se rendre à la section Buffer Wait Statistics du présent AWR pour déterminer quels types de buffer provoquent des contentions (appelés Hot blocks).

Library Hit ratio

C’est le ratio entre les requêtes envoyées au serveur et les requêtes dont le plan d’exécution est en cache.

Ce ratio est primordial pour les traitement OLTP. S’il est trop bas, il faudra agir soit sur la taille de la library cache soit revoir les accès aux données (cursor sharing), éviter la construction des requêtes dynamiques tous azimuts.

Execute to Parse %

Ce ratio est un peu plus compliqué à calculer : sa formule est : 100 * (1 – nb Parses/nb Executions) ; il indique donc le pourcentage de requête ne nécessitant pas d’être parsées ; c'est-à-dire dont le plan d’exécution précédemment calculé est disponible et utilisé.

Si la valeur de ce ratio est basse, il faut alors regarder le ratio soft parse ; si celui-ci révèle un taux faible également pour un système OLTP, il s’agit de revoir l’accès aux données (cursor sharing, requêtes dynamiques, ...) car Oracle doit recalculer le plan d’exécution pour une grande partie des requêtes.



Top 5 wait events - Les attentes les plus courantes

  • wait class
  • %DB time

DB CPU

DB CPU est généralement indicateur de bonnes performances ; en effet, les temps de réponses dépendent directement du CPU.
Cependant, il faut nuancer cette affirmation dans le cas où l’applicatif est mal conçue ; par exemple en faisant de multiple accès et en utilisant des fonctions complexes qui pourraient être factorisées :

select label from matable where decode(to_date(monchampdate, ‘YYYY-MM-DD’), sysdate, ‘aujourd hui’, to_date(monchampdate, ‘YYYY-MM-DD’), sysdate-1, ‘hier’, to_date(monchampdate, ‘YYYY-MM-DD’), sysdate+1, ‘demain’) = ‘demain’ ;
devient

select label from matable where trunc(monchampdate) = trunc(sysdate)+1;

db file sequential read

C’est une des attentes que l’on retrouve très régulièrement dans le TOP 5 ; hormis une base de données dont la taille totale des index peut être en RAM ou un stockage dédié sur SSD, si ce n’est pas le cas, c’est qu’il y a de gros problèmes sur les attentes du TOP 5 (notamment pas d’index de créés). Il s’agit d’attentes de bloc de données lus dans les index.

db file scattered read

Il s’agit d’attentes due à la lecture de blocs de données multiple (généralement full table scan) cette attente est à considérer en même temps que la précédente.

hard parse time elapsed

En mode OLTP, cette attente rejoins généralement le problème décrit au § Execute to Parse %.

log file parallel write & log file sync

Généralement constaté sur des systèmes fortement mis à jour, ces attentes correspondent à l’écriture dans les redo log (uniquement en cas d’insert/update)

buffer busy waits

rejoint l’indicateur Buffer Nowait ratio : le système est fortement multi-process et certains blocs (et les données associées) sont fréquemment utilisés ; il faut dans ce cas améliorer les accès disques à ces blocs (indexer, mettre sur des disques plus performants, ALTER matable MINIMIZE RECORDS_PER_BLOCK, améliorer PCTUSED et PCTFREE, utiliser ASSM) ; allez voir à la section Segments by Physical Reads pour voir les segments potentiellement en cause.

Wait Event Histogram

Cette partie permet de savoir si les attentes relevées précédemment sont représentatives.
En effet, une moyenne très élevés pour une attente est un bon indicateur, cependant la distribution des valeurs est plus intéressant encore : si par exemple on relève une moyenne forte sur l’attente SQL*Net message to client mais qu’en réalité 98% des attentes sont inférieures à 1ms et 2% supérieures à 1s, il s’agit probablement d’un problème avec un client en particulier qui a un problème réseau.

La liste des requêtes selon différents critères

Enfin les parties listant les requêtes SQL suivant la CPU, le temps de réponse, le nombre d’IO, ... permettent d’identifier les requêtes problématiques.
Parmi les choses à regarder :
  • Une requête est exécutée très souvent : 10000 fois alors qu’il n’y a qu’un seul client qui a fait 3 clics dans l’application => symptôme d’une requête dans une boucle => Vérifier l’applicatif
  • Une requête contient un très grand nombre de variables (notamment dans un IN) => vérifier côté applicatif si ces paramètres ne sont pas issus du résultat d’une première requête, si tel est le cas, préférer une jointure)
  • Une requête n’est exécutée qu’une seule fois et est très longue => batch ou observateur (voir SQL Module)
  • Certaines requêtes sont consommatrices de lecture physique ou en attente IO => Vérifier les index
  • Une requête sans paramètre est exécutée très souvent => vérifier s’il ne s’agit pas de données de configuration, selon le cas, il peut être intéressant de les mettre en cache du côté applicatif
  • Requête INSERT exécutée très souvent => en cas d’insert de mass, il est parfois plus intéressant de supprimer les index le temps de l’opération pour le recréer juste après + vérifier s’il est pas possible d’écrire sous forme de d’insert multiple
  • Un job dbms_stats très long => il s’agit de la mise à jour des statistiques ; sur d’ancienne version (jusque 9i), vérifier si le calcul complet et la fréquence sont pertinents ; activer le monitoring de table

[ ... ] Lire la suite



Vous n'avez pas trouver réponse à votre question ? Préciser votre recherche :

Catégories