Catégorie: Franck Pachot

Il n'a a pas eu beaucoup d'articles traduits ces derniers mois. Pour patienter, voici un lien sur une présentation:
Interpreting AWR Report - Straight to the Goal en anglais, mais très visuel...

C'est parfois difficile d'aborder un rapport AWR ou Statspack qui comprends 50 pages de statistiques, dont seulement quelques unes sont utiles dans un contexte donné. J'ai vu plusieurs personnes qui ne savent pas vraiment par où commencer. Et sans une approche méthodique, c'est facile de perdre du temps sur des choses qui ne feront pas gagner un un temps significatif dans l'amélioration du temps de réponse.

Cette présentation montre une approche méthodique: en partant du temps passé en base de données (DB time) pour voir si le rapport est pertinent ou pas, puis en prenant les éléments du 'Top 5 events' en montrant où aller chercher les détails qui permettent de comprendre la raison d'un problème de performance, comment le résoudre, et estimer le gain en temps de réponse que peut apporter la résolution.

Historiquement, les vues V$ collectent les durées en centisecondes (100ème de secondes).
Cependant, certaines vues utilisent une autre unité:

microsecondes (1000000ème de seconde):

TIME_WAITED_MICRO, WAIT_TIME dans V$SESSION_WAIT, V$SYSTEM_EVENT, V$SESSION_EVENT, V$ACTIVE_SESSION_HISTORY
CPU_TIME, ELAPSED_TIME dans V$SQL, V$SQLAREA
WAIT_TIME dans V$LATCH, V$LATCH_PARENT, V$LATCH_CHILDREN
ACTIVE_TIME dans V$SQL_WORKAREA, V$SQL_WORKAREA_ACTIVE

millisecondes (1000ème de seconde):

CPU_WAIT_TIME dans V$ENQUEUE_STAT

secondes:

CTIME dans V$LOCK

La liste est non exhaustive, et les commentaires sont bienvenus pour la mettre à jour

La version anglaise de cet article se trouve sur knol

Le vérouillage (Locking) sous Oracle paraît simple au premier abord. La plupart du temps, on n'a pas à utiliser de vérouillage explicite (LOCK TABLE). Le vérouillage implicite des ordres DML (insert, update, delete, select for update) est transparent et souvent efficace. Un select (sans le for update) ne pose aucun verrou (lock). Les verrous mortels (deadlocks) sont rares et les attentes sur les wait events enqueue ne sont pas si fréquentes.

Mais lorsqu'on veut aller plus loin, pour comprendre une situation de deadlock, ou pourquoi une session est bloquée, ou pour éviter les problèmes de performance dans l'intégrité référentielle, alors les choses deviennent plus complexes. Le mécanisme d'Oracle n'est pas facile à comprendre et les différents nommage des modes de verrous rendent les choses plus difficiles. Un exemple: le mode 3 par exemple peut s'appeler 'Row Exclusif' aussi bien que 'Sub Exclusive', abrégé Row-X, Sub-X, RX ou SX. Et il n'est pas au niveau row (d'ailleurs les verrous au niveau enregistrement ne s'appellent pas row mais TX comme transaction), et il n'est pas si exclusif que ça puisque plusieurs session peuvent l'acquérir sur la même ressource...

Pas de panique, on va tout expliquer. La signification des modes de verrouillage, leurs nommage, et leur matrice de compatibilité. Et prendre un exemple an manipulant les vues du dictionnaire.

» Lire la suite!

Ce document tente d'expliquer exactement ce qui arrive lorsque vous utilisez ALTER TABLESPACE ... BEGIN BACKUP et ALTER TABLESPACE  ...  END BACKUP, et pourquoi il est obligatoire de l'utiliser lorsque la sauvegarde à chaud se fait avec un outil qui est extérieur à Oracle (tels que les sauvegardes faites à partir de l'OS utilisant cp, tar, la BCV, etc)
 Il donne également une réponse aux questions suivantes, fréquemment posées:

•  Est-ce qu' Oracle continue d'écrire dans les fichiers (datafiles) lorsque la tablespace est en mode backup ?
•  A quoi sert la commande ALTER DATABASE BEGIN BACKUP ?
•  Pourquoi le mode backup n'est pas utilisé avec RMAN ?
•  Que se passe-t-il si vous faites une sauvegarde sans avoir fait le BEGIN BACKUP ?
•  Que faire si l'instance se plante alors que vous êtes en mode backup ?
•  Comment vérifier quels datafiles sont en mode backup ?
•  Quels sont les archive logs minimum à garder avec la sauvegarde à chaud?
•  Pourquoi utiliser des backups par des commandes OS au lieu de RMAN?
•  Pourquoi la commande BEGIN BACKUP peut prendre du temps ?

» Lire la suite!

En général lorsqu'il y a plusieurs indexes qui peuvent répondre aux prédicats d'une requête, Oracle va choisir l'index le plus selectif, et les autres conditions seront vérifiées au moment d'aller lire l'enregistrement complet dans la table.
Ceci peut nous amener à créer un index concaténé, en combinant toutes les colonnes sur lesquelles il y a des prédicats, afin que l'index soit plus sélectif.

Mais ajouter un index a un coût et va pénaliser les insert/deletes ainsi que les updates qui touchent aux colonnes indexées.

Il y a cependant des cas où Oracle peut combiner deux indexes.
C'est le cas par exemple des indexes bitmap. On peut avoir un index bitmap sur chaque colonne, et Oracle va combiner les bitmaps avant d'aller voir la table (en utilisant des opérateurs binaire AND et OR sur les bitmaps). Mais ce n'est pas le sujet de cet article.

Il y a aussi un cas particulier avec les indexes 'normaux': c'est le chemin d'accès 'INDEX JOIN': les 2 indexes sont lus, et sont réunis, comme si l'on faisait une jointure sur le rowid, et la sortie de cette opération est équivalente à un index qui contiendrait toutes les colonnes.

Voici un exemple de cette opération 'index join', le but de cet exemple était de répondre à la question suivante, sur le forum dba-village: 'Que signifient les indexes index$_join$_9 et index$_join$_8' dans un plan d'exécution, et 'comment les remplacer par mes propres indexes ?'

» Lire la suite!