La base de données Oracle

Date : 28/10/2001
Bruno Delb http://www.brunodelb.com

La base de données Oracle

Sommaire

INTRODUCTION..................................................................................................3

LE PRINCIPE DE L’OPTIMISATION......................................................................3

LES OUTILS DE DIAGNOSTIC..............................................................................3

COMMENT CONFIGURER LA BASE DE DONNÉES ?...............................................4
L’ARCHITECTURE DE BASE ORACLE 7.............................................................................4
LES TABLESPACES...................................................................................................4
COMMENT UTILISER LE DÉCOUPAGE ?............................................................................5
AUDITER LE CODE SQL........................................................................................5
DIAGNOSTIQUER LES PROBLÈMES.................................................................................5
AUDITER LES MODULES.............................................................................................6
COMMENT AUDITER LA ZONE DE PARTAGE DES ORDRES SQL (SHARED POOL) ?
............................................................................................................................7
QU’EST-CE QUE LA LIBRARY CACHE ?............................................................................7
Comment auditer la Library Cache ?..................................................................7
Quelles sont les vues dynamiques relatives à la Library Cache ?...........................7
Comment suivre les performances de la Library Cache ?......................................7
A quoi sert le package DBMS_SHARED_POOL ?...................................................8
QU’EST-CE QUE LE DICTIONARY CACHE ?.......................................................................8
Comment auditer le Dictionary Cache ?..............................................................8
Comment impacter la mémoire utilisateur plutôt que la mémoire partagée ?..........8
COMMENT AUDITER LE BUFFER CACHE ?............................................................8
QU’EST-CE QUE LE BUFFER CACHE ?.............................................................................8
COMMENT LE BUFFER CACHE EST-IL GÉRÉ ?....................................................................8
QUELS SONT LES OBJECTIFS DE L’AUDIT DU BUFFER CACHE ?...............................................9
COMMENT MESURER LE HIT RATIO DU BUFFER CACHE ?......................................................9
COMMENT EXAMINER L’IMPACT DE L’AJOUT OU DE LA SUPPRESSION DE BUFFERS ?........................9
COMMENT UTILISER EFFICACEMENT LES BLOCS ORACLE ?................................9
COMMENT AUDITER LES BLOCS ?..................................................................................9
QU’EST-CE QUE LA HIGH WATER MARK ?........................................................................9
QU’EST-CE QUE LE PACKAGE DBMS_SPACE ?................................................................9
COMMENT SONT RÉORGANISÉS LES INDEX ?...................................................................10
COMMENT SONT GÉRÉS LES FREE LISTS ?.....................................................................10
COMMENT OPTIMISER LES ROLLBACK SEGMENTS ?.........................................10
QU’EST-CE QU’UN ROLLBACK SEGMENT ?.....................................................................10
COMBIEN DE ROLLBACK SEGMENTS FAUT-IL ?................................................................10
COMBIEN DE ROLLBACKS SONT-ILS UTILISÉS ?...............................................................10
COMMENT SONT ALLOUÉS LES ROLLBACK SEGMENTS ?......................................................10
COMMENT AUDITER LES MÉCANISMES DE REDO ?............................................11
COMMENT ÉVITER LES ATTENTES DE CHECKPOINT ?..........................................................11
COMMENT RÉGULER LES CHECKPOINTS ?......................................................................11
COMMENT AUTORISER L’ARCHIVAGE DES FICHIERS REDO LOG ?............................................11
COMMENT DIMENSIONNER LE BUFFER REDO LOG ?..........................................................11
COMMENT RÉDUIRE LES REDO ?.................................................................................11

1

Date : 28/10/2001


COMMENT FONCTIONNENT LES LATCHS DU BUFFER REDO LOG ?...........................................11
Comment fonctionnent les latchs sur les plateformes SMP ?...............................11
Comment suivre la contention du latch Redo ?..................................................11
Comment réduire la contention sur le Redo Allocation Latch ?.............................12
QUELS PEUVENT ÊTRE LES PROBLÈMES ?.......................................................................12
COMMENT SUIVRE ET DÉTECTER LES CONTENTIONS DE VERROUS ?................12
COMMENT FONCTIONNE LE VERROUILLAGE ?...................................................................12
Qu’est-ce que le verrou LMD ?.........................................................................12
Qu’est-ce que le verrou LDD ?.........................................................................13
Quels sont les autres verrous ?.......................................................................13
COMMENT SUIVRE L’ACTIVITÉ DE VERROUILLAGE ?...........................................................14
Qu’est-ce que le Server Manager Lock Monitor ?................................................14
QU’EST-CE QU’UN DEADLOCK ?..................................................................................14
COMMENT LA COHÉRENCE EN LECTURE EST-ELLE ASSURÉE ?................................................14
Qu’est-ce que la lecture logique au niveau traitement ?.....................................14
Qu’est-ce que la lecture de cohérence de niveau transaction ?............................14
Qu’est-ce que les transactions SERIALIZABLE ?.................................................15
COMMENT OPTIMISER POUR DES BESOINS APPLICATIFS DIVERGENTS ?........15
COMMENT OPTIMISER LES APPLICATIONS TRANSACTIONNELLES ?...........................................15
COMMENT OPTIMISER LES APPLICATIONS D’AIDE À LA DÉCISION ?.........................................15
A quoi servent les histogrammes ?..................................................................15
Qu’est-ce qu’un Index Bitmap ?.......................................................................15
Comment s’adapter à la logique de l’application ?..............................................16
COMMENT OPTIMISER LES APPLICATIONS CLIENT/SERVEUR ?................................................16
Comment reconfigurer en fonction des besoins ?...............................................16
COMMENT OPTIMISER LES TRIS ?....................................................................16
COMMENT TRIER EN MÉMOIRE ?.................................................................................16
COMMENT ÉVALUER LES BESOINS EN MÉMOIRE ?.............................................................17
COMMENT ÉVITER LE BUFFER CACHE ?.........................................................................17
COMMENT SUIVRE LES TRIS ?....................................................................................17

COMMENT OPTIMISER LES CONNEXIONS ?......................................................17
QU'EST-CE QUE LE MULTITHREAD ?.............................................................................17
COMMENT CONFIGURER LE MTS ?..............................................................................17
COMMENT RÉGLER LES SERVEURS PARTAGÉS ?................................................................18
QUE FAUT-IL SAVOIR SUR LES SERVEURS PARTAGÉS ET LE SHARED POOL ?.............................18
QUELLES PEUVENT ÊTRE LES PROBLÈMES ?....................................................................18

2

Date : 28/10/2001


Introduction
En général, en cas de problèmes, le DBA tente en premier de les résoudre.
La vérification de la conception du système et des applications doit se faire au plus tôt, car plus tard commence
l’audit, plus cher il coûte.
Auditer est un travail itératif et continu.
L’audit doit porter successivement sur :
• la conception,
• l’application,
• la mémoire,
• les entrées/sorties,
• les contentions.

Le principe de l’optimisation
Les principes de l’optimisation sont les suivants :
• Les requêtes SQL doivent utiliser le plus petit nombre possible de blocs Oracle.
• Un bloc utilisé doit être en mémoire.
• Les utilisateurs doivent partager le même code.
• Quand du code est utilisé, il doit être en mémoire.
• Les lectures et les écritures doivent être rapides que possible.
• Les utilisateurs ne doivent jamais attendre les ressources utilisées par d’autres.
• Les sauvegardes (ainsi que les autres opérations de maintenances) doivent être effectuées le plus
rapidement possible.

Les outils de diagnostic
Les outils de diagnostic sont :
• les vues V$ (basées sur les tables X$)
Elles appartiennent à l’utilisateur sys. Le script rdbms/admin/utlmontr.sql permet de donner un accès
public sur quelques vues V$.
• les tables X$ (dont le contenu change constamment)
Elles sont rarement directement interrogées.
Les vues V$ et les X$ sont renseignées au démarrage de l’instance et remises à blanc à la fermeture.
• l’analyse (commande ANALYZE)
• le Server Manager,
Ecran Description
CIRCUITS Pour le serveur multi-thread.
DISPATCHERS Pour le serveur multi-thread.
FILE I/O Activité de lecture et d’écriture pour chaque fichier.
LATCH Les latches sont des verrous internes de bas niveau.
LIBRARY CACHE Performances des curseurs partagés.
LOCK Verrous tenus et libérés.
PROCESS Process background et process utilisateur.
ROLLBACK Rollback segments.
SESSION Sessions utilisateurs.
SHARED SERVER Pour les serveurs multi-threads.
SQL AREA Ordres SQL en mémoire.
SYSTEM I/O Activités d’entrées/sorties générées par les process.
SYSTEM STATISTICS Statistiques sur les mesures de performances.
TABLE ACCESS Objets accédés dans chaque session.
TABLESPACE Informations sur les tablespaces.
• les fichiers trace
Les fichiers trace générés par les utilisateurs sont stockés dans le répertoire spécifié par le paramètre
USER_DUMP_DEST.
Les autres sont stockés dans le répertoire spécifié par le paramètre BACKGROUND_DUMP_DEST.
Fichier Description
Rdbms/log/alert.log (un Les événements majeurs et les erreurs les plus importantes

3

Date : 28/10/2001

fichier par instance) Il faut le supprimer de temps en temps, après l’avoir consulté.
Rdbms/log/*.trc Les erreurs des background process d’Oracle 7.
• Oracle Enterprise Manager Performance Pack
Outil de diagnostic Description
Oracle Expert Optimisation des performances de l’environnement de la base de
données : aide à la configuration initiale de la base, collecte et
évaluation des caractéristiques des performances des bases.
Oracle Lock Manager Suivi des verrous : liste sur plusieurs colonnes avec une ligne par
verrou actif dans la base.
Oracle Performance Manager Suivi des performances de la base en temps réel : graphiques
prédéfinis sur les utilisateurs, les consommations, les tablespaces, les
redo logs, les buffers, les caches, les E/S, …
Oracle TopSessions Utilisation en temps réel des ressources de l’instance de la base par
les sessions connectées : activité des sessions, …
Oracle Tablespace Manager Suivi et gestion du stockage dans la base de données : informations
générales sur l’utilisation de l’espace, compression pour regrouper
des blocs libres adjacents.
Oracle Trace Suivi des performances en recueillant des données sur les
événements survenant dans les applications.
• les sorties de statistiques (les scripts utlbstat.sql et utlestat.sql génère des états de statistiques sur cette
période de temps),

Comment configurer la base de données ?

L’architecture de base Oracle 7
Parmi les fichiers physiques, on compte :
• les fichiers de données,
• les fichiers de contrôle,
• les fichiers redo log en ligne,
• les fichiers redo log archivés,
• les fichiers de paramètres.
La SGA (System Global Area) comprend :
• le Buffer Cache de la base de données,
• le Buffer du redo log,
• la zone partagée des ordres.
Les principaux process sont :
• les process utilisateurs,
• le process serveur,
• le process d’écriture dans les fichiers de données (DBWR),
• le process d’écriture dans les fichiers redo log (LGWR),
• le process checkpoint (CKPT),
• le process system monitor (SMON),
• le process process monitor (PMON),
• le porcess archiver (ARCH),
• le process recoverer (RECO),
• le process lock (LCKn),
• le process job queues (SNPn),
• le process parallel query (Pnnn),
• le process dispatchers (Dnnn),
• le process shared servers (Snnn).

Les tablespaces
Une base de données Oracle7 contient au moins six tablespaces :
• SYSTEM
Il ne doit contenir que les objets du dictionnaire de données (exemple : les packages, les triggers).

4

Date : 28/10/2001


• TEMP
Temporaire, il est alloué lors de la création d’un utilisateur pour les opérations de tri. Le tablespace par
défaut est le tablespace SYSTEM.
• RBS
Il est dédié aux rollback segments.
• USERS
De petite taille, il permet de stocker les objets créés par les utilisateurs. Il doit être le tablespace par
défaut des utilisateurs autres que SYSTEM ou SYS.
• xxx_DATA
C’est le tablespace des données de la première applications (dont le nom est « xxx »).
• xxx_INDEX
C’est le tablespace des index de la première applications (dont le nom est « xxx »).

Comment utiliser le découpage ?
• Les tablespaces sont constitués de plusieurs fichiers, répartis sur plusieurs disques.
• Les index et les tables de manière sont répartis sur ces disques.
Tous les systèmes d’exploitation ne le permettent pas. Sous Unix, le plus répandu est le RAID (Redundant
Array of Inexpensive Disks).
Il existe plusieurs niveaux de répartition :
• la répartition par le système d’exploitation,
• la répartition manuelle.
Cette méthode est un peu lourde : Oracle remplit les extents l’un après l’autre et à tout moment un
extent peut être chargé et les autres moins actifs.

Auditer le code SQL
Il y a deux modes d’optimisation :
• Basé sur les règles
Les process choisissent le chemin d’accès aux données par analyse de la requête.
• Basé sur les coûts
L’optimiseur examine chaque traitement et identifie tous les chemins possibles d’accès aux données.
Il calcule ensuite le coût (principalement basé sur le nombre de lectures logiques) en ressource de
chaque chemin d’accès.
Il choisit le moins cher.
Ce mode d’optimisation peut être appliqué sur trois niveaux :
• au niveau de l’instance : utiliser le paramètre OPTIMIZER_MODE,
• au niveau de la session : ALTER SESSION SET OPTIMIZER_GOAL = valeur,
• au niveau de l’ordre (en utilisant les hints) : SELECT /*+ FIRST_ROWS */ * From dual ;

Dans chacun de ces cas, les valeurs possibles sont :
Valeur Description
CHOOSE (valeur par défaut) L’optimiseur utilise le mode basé sur les coûts si les statistiques
sont disponibles pour les tables. Sinon, il utilise le mode basé sur
les règles.
RULE
FIRST_ROWS Minimise le temps de réponse d’obtention des premiers
enregistrements (peut-être au détriment du temps de réponse total).
ALL_ROWS Minimise le temps de réponse total.

Diagnostiquer les problèmes
SQL Trace peut être activé pour une instance ou une session.
Pour utiliser SQL Trace, il faut :
1. Initialiser les paramètres d’initialisation (dans le fichier init.ora).
MAX_DUMP_FILE_SIZE doit contenir la taille du fichier de sortie.
USER_DUMP_DEST doit contenir le nom du fichier de sortie.
TIMED_STATISTICS = TRUE pour obtenir des informations de temps (avec une résolution d’un
centième de seconde).
2. Activer SQL Trace.
SQL_TRACE = TRUE

5

Date : 28/10/2001

Pour une session : ALTER SESSION SET sql_trace = TRUE ;
Pour votre session : EXECUTE dbms_system.set_sql_trace (TRUE) ;
Pour la session d’un autre utilisateur : EXECUTE dbms_system.set_sql_trace_in_session (session_id,
serial_id, TRUE) ;
Remarque : « session_id » est la colonne SID de la table V$SESSION et « serial_id » est la colonne
SERIAL# de la table V$SESSION.
3. Exécuter l’application.
4. Arrêter SQL Trace.
SQL_TRACE = FALSE
Pour une session : ALTER SESSION SET sql_trace = FALSE ;
Pour votre session : EXECUTE dbms_system.set_sql_trace (FALSE) ;
Pour la session d’un autre utilisateur : EXECUTE dbms_system.set_sql_trace_in_session (session_id,
serial_id, FALSE ) ;
Remarque : « session_id » est la colonne SID de la table V$SESSION et « serial_id » est la colonne
SERIAL# de la table V$SESSION
5. Formater le fichier trace avec la commande TKPROF :
TKPROF fichier_trace fichier_résultat [explain=nom_d’utilisateur/mot_de_passe]
[table=schéma.nom_de_table] [print=n] [insert=nom_de_fichier] [sys=NO] [record=nom_de_fichier]
[sort=option]
6. Interpréter la sortie.
La sortie comprend des statistiques.
L’objectif est de réduire au maximum le temps CPU et les buffers logiques accédés dans les phases d’exécution
et de fetch.
Le coût d’un plan d’exécution a une valeur proportionnelle au temps écoulé nécessaire à l’exécution de l’ordre
durant ce plan d’exécution.
Pour déterminer quel process est le process parent, sélectionner les colonnes id et parent_id de la table
plan_table.

Auditer les modules
Si l’appel d’un module applicatif est enregistré dans la base de données, vous pouvez connaître les informations
suivantes pour chaque modules :
• la performance,
• l’utilisation des ressources.
Les procédures du package DBMS_APPLICATION_INFO sont :
Procédure Description
SET_MODULE (module, action) Spécifier le nom du module et (optionnellement)
l’action.
Appeler cette procédure à chaque démarrage de
module.
« module » est le nom du module (48 caractères au
maximum). Il est stocké dans V$SQLAREA.
« action » est le nom ou la description de l’action (32
caractères au maximum). Il est stocké dans
V$SQLAREA.
SET_ACTION (action) Spécifie le nom de l’action en cours dans un module
enregistré.
Appeler cette procédure avant chaque nouvelle
transaction et à nouveau après la transaction pour
remettre l’action à NULL.
V$SQLAREA.
SET_CLIENT_INFO (client) Donne des informations sur le client pour la session.
« client » contient des informations complémentaires
(64 caractères au maximum). Il est stocké dans
V$SESSION.
READ_MODULE (module, action) Lit le dernier module et le dernier nom de l’action
positionnés par SET_ACTION ou SET_MODULE.
« module » est le nom du module (48 caractères au
maximum). Il est stocké dans V$SQLAREA.

6

Date : 28/10/2001

V$SQLAREA.
READ_CLIENT_INFO (action) Lit les dernières informations sur le client pour la
session.
V$SQLAREA.

Comment auditer la zone de partage des ordres SQL (Shared Pool) ?
La Shared Pool contient principalement les structures suivantes :
• la Library cache (contient le SQL et le PL/SQL partagés),
• le Dictionary Cache (contient les informations sur les objets du dictionnaire), c’est l’objet sur lequel l’audit
porte principalement,
• des informations sur les utilisateurs (dont les zones de tri et les zones SQL privé) (dans le cas d’un serveur
multi-thread) car :
• Les serveurs partagés travaillent sur la base d’un ordre.
• Chaque serveur peut donc avoir besoin d’accéder aux informations de tout utilisateur.

Qu’est-ce que la Library Cache ?
Un algorithme LRU permet de gérer le cache.
Si un utilisateur demande un traitement qui est déjà dans le cache, Oracle utilise la version cache sans
réinterprétation.
Pour savoir si un traitement est déjà en cache, Oracle :
• réduit le traitement à la valeur numérique du texte ASCII,
• utilise une fonction hash de ce nombre.

Comment auditer la Library Cache ?
Les objectifs sont de s’assurer que :
• La phase d’interprétation (parsing) est maintenue à un minimum.
• Tout objet volumineux peut trouver assez d’espace contigu dans le pool.

Quelles sont les vues dynamiques relatives à la Library Cache ?
• V$SQLAREA
• V$SQL
• V$SQLTEXT
• V$DB_OBJECT_CACHE
• V$LIBRARYCACHE
• V$SGASTAT
• V$SHARED_POOL_RESERVED

Comment suivre les performances de la Library Cache ?
Les colonnes importantes de la vue V$LIBRARYCACHE sont :
• PINS
• RELOADS
Les paramètres suivants affectent la Library Cache :
Paramètre Description
SHARED_POOL_SIZE Taille de la Shared Pool (en octets).
CURSOR_SPACE_FOR_TIME La valeur par défaut est FALSE.
S’il vaut TRUE, les zones SQL partagées ne sont pas
sorties tant que le curseur référencé n’est pas fermé.
Ne pas changer cette valeur sauf si la valeur de
RELOADS dans V$LIBRARYCACHE est
continuellement à 0.
Si l’application utilise Forms ou du SQL dynamique,
laisser la valeur à FALSE.
SHARED_POOL_RESERVED_SIZE Taille de la liste réservée, une zone de la Library

7

Date : 28/10/2001

Cache pour les objets volumineux.
Les objets plus petits ne sont pas autorisés dans cette
zone et ne peuvent donc pas fragmenter la liste
réservée.
Le maximum est la moitié de SHARED_POOL_SIZE.
SHARED_POOL_RESERVED_MIN_ALLOC Taille minimale (en octets) des objets qui peuvent
utiliser la liste réservée.
Les objets volumineux peuvent utiliser la liste réservée
s’ils ne peuvent trouver d’espace ailleurs.
La valeur par défaut est 5000.
Si SHARED_POOL_RESERVED_SIZE est non nulle,
la valeur maximale est
SHARED_POOL_RESERVED_SIZE.

A quoi sert le package DBMS_SHARED_POOL ?
Conseil : Si l’application utilise du PL/SQL, s’assurer qu’il a été écrit dans un package plutôt que comme
fonction ou procédure isolée ou comme bloc anonyme. Conserver dans la Shared Pool tous les packages
volumineux des applications (exemple : les packages STANDARD, DBMS_STANDARD, DIUTIL).

Qu’est-ce que le Dictionary Cache ?
Il est utilisé pour conserver en mémoire la définition des objets du dictionnaire.
Oracle partage la somme allouée entre le Dictionary Cache, la Library Cache et la UGA (dans le cas d’un
serveur multi-thread).

Comment auditer le Dictionary Cache ?
Les principales colonnes de la vue V$ROWCACHE sont :
• PARAMETERS
• GETS
• GETMISSES

Comment impacter la mémoire utilisateur plutôt que la mémoire partagée ?
S’il vaut FALSE (valeur par défaut), le curseur d’un utilisateur n’est pas fermé lors d’un COMMIT, ce qui
épargne en général une réinterprétation.
Si les ordres sont rarement réutilisés, fermer le curseur après le COMMIT en positionnant ce paramètre à
TRUE pour économiser de la mémoire.

Comment auditer le Buffer Cache ?

Qu’est-ce que le Buffer Cache ?
Le Buffer Cache :
• fait partie de la SGA,
• contient les copies des blocs de données, partageables par tous les utilisateurs,
• est dimensionné avec le paramètre DB_BLOCK_BUFFERS dans le fichier init.ora.
La taille du cache (en octets) est DB_BLOCK_BUFFERS * DB_BLOCKS_SIZE.
Chaque buffer du cache contient un seul bloc base de données.
A un moment donné, le buffer cache peut avoir plusieurs copies d’un même bloc base de données. Seule une
copie de bloc est courante, mais les process serveur peuvent avoir besoin de construire des copies cohérentes en
lecture pour répondre à des interrogations, en utilisant les informations des rollbacks.

Comment le Buffer cache est-il géré ?
Lors de la restitution d’un bloc de données à l’utilisateur, le serveur :
• regarde dans le buffer cache (en utilisant une fonction hash),
• lit le bloc depuis le disque (si nécessaire).
Quand le serveur utilise un accès indexé, il lit toujours un bloc à la fois.
Tous les blocs sont présents dans une liste du moins récemment utilisé (LRU – Last Recently Used). Le process
DBWR écrit les blocs sur le disque en partant de la fin de la liste LRU.

8

Date : 28/10/2001

La taille d’une écriture DBWR est égale à DB_FILES * DB_FILE_SIMULTANEOUS_WRITES / 2 avec
comme limite celle du port spécifique (ou DB_BLOCKS_BUFFERS / 4).
Le serveur effectue une lecture multiple de blocs dans le Buffer Cache.
En général, l’ensemble de blocs va à la fin de la liste LRU.
Il est possible de mettre en mémoire des tables entières dans la liste des blocs les plus récemment utilisés (MRU
– Most Recently Used).

Quels sont les objectifs de l’audit du Buffer Cache ?
Dans un système OLTP bien audité :
• L’immense majorité des utilisateurs trouvent les données qu’ils veulent en mémoire.
• Les process serveurs ont rarement besoin d’aller chercher les données sur le disque.
Sur de grands systèmes de datawarehouse, la plupart des données sont lues depuis le disque. L’audit des Buffer
Cache est alors moins important tandis que l’audit des entrées/sorties est vital.

Comment mesurer le Hit Ratio du Buffer Cache ?
Remarque : Si vous utilisez le raw device, le système d’exploitation ne peut conserver dans son cache les blocs
de données écrits par DBWR et sortis du Buffer Cache.

Comment examiner l’impact de l’ajout ou de la suppression de buffers ?
Les colonnes de la table virtuelle X$KCBRBH sont :
Colonne Description
INDX Identifiant pour chaque nouveau buffer (démarre à 0).
COUNT Nombre d’accès supplémentaires en cache qui serait
gagné par ajout de ce buffer.
Les colonnes de la table virtuelle X$KCBCBH sont :
Colonne Description
INDX Identifiant pour chaque nouveau buffer (démarre à 0).
COUNT Nombre d’accès sur ce buffer.
Pour le buffer 0, c’est le nombre de blocs placés dans
le buffer plutôt que le nombre d’accès.

Comment utiliser efficacement les blocs Oracle ?
Les unités de la plus petite à la plus grande sont : Blocs, Extents, Segments, Files, Tablespaces, Database.

Comment auditer les blocs ?
Pour auditer les blocs, consulter la table DBA_TABLES.

Qu’est-ce que la high water mark ?
La High Water Mark est enregistrée dans le bloc d’entête du segment et est :
• initialisée au début du segment,
• incrémentée de 5 blocs quand les lignes sont insérées,
• réinitialisé par les ordres TRUNCATE,
• recalculée au niveau d’une table en utilisant la commande ALTER TABLE <nom_table> DEALLOCATE
UNUSED.
Remarque : Cette marque n’est pas recalculée suite à un ordre DELETE.
Lors d’une lecture séquentielle, Oracle lit tous les blocs situés en deçà de la marque High Water. Les blocs
libres au-delà de la marque High Water peuvent donc signifier une perte d’espace mais en aucun cas une
dégradation des performances.
Des blocs sous utilisés situés en deçà de cette marque impliquent une dégradation des performances.

Qu’est-ce que le package DBMS_SPACE ?
Le package DBMS_SPACE contient les procédures :
• UNUSED_SPACE,
• FREE_BLOCS.
Elles sont créées et documentées par le script dbmsutil.sql, qui est lancé par catproc.sql.

9

Date : 28/10/2001


Comment sont réorganisés les index ?
Oracle peut insérer des lignes dans l’espace libéré par la suppression de ligne.
Oracle ordonne séquentiellement les entrées.
Si vous supprimez toutes les entrées d’un bloc d’index, Oracle réintègre le bloc dans la Free List.
Si vous insérez les valeurs en ordre ascendant dans un index et si vous supprimez les anciennes valeurs, si un
bloc contient seulement une entrée, il faut le maintenir. Pour cela, il faut reconstruire les index régulièrement.
Les colonnes de la vue INDEX_STATS sont :
Colonne Description
LF_ROWS Nombre de valeurs courantes dans l’index.
LF_ROWS_LEN Total en octets de la longueur de toutes les valeurs.
DEL_LF_ROWS Nombre de valeurs supprimées dans l’index.
DEL_LF_ROWS_LEN Longueur de toutes les valeurs supprimées.
Remarques :
• Une carte des extents se trouvant dans l’entête du segment, de multiples extents ne détériorent pas les
performances.
• Les DROP sont plus lent sur les segments ayant plusieurs extents.
Conseil : Ne pas tailler les objets à la taille d’un extent, car cela gaspille beaucoup d’espace au début.

Comment sont gérés les Free Lists ?
Il y a au moins une free list (liste de blocs libres) dans l’entête de chaque segment.
Les free lists sont liées.
Des blocs sont ajoutés à la free list :
• lors de l’allocation de blocs au segment,
• lors de la suppression de lignes faisant tomber l’espace utilisé en dessous de PCTUSED,
• lors de la modification de la marque High Water.
Lors d’un INSERT, le process recherche les blocs dans la free list. Ainsi, si le système est surchargé en
INSERT et en DELETE, le process peut être mis en attente.

Comment optimiser les rollback segments ?

Qu’est-ce qu’un Rollback Segment ?
Un Rollback Segment :
• est enregistré dans les fichiers base de données,
• est utilisé pour conserver les images-avant des enregistrements,
• est utilisé pour ROLLBACK, pour restauration et pour cohérence en lecture,
• est constitué d’au moins deux extents utilisés de façon circulaire.

Combien de Rollback Segments faut-il ?
Une table des transactions est conservée dans l’entête de chaque Rollback Segment.
Conseil : Pour les applications de type batch, compter un Rollback Segment par job concurrent.

Combien de Rollbacks sont-ils utilisés ?
Les DELETE sont gourmands en Rollback Segments. TRUNCATE permet d’optimiser les performances.
Les INSERT n’utilisent que peu de place dans les rollbacks : seul le ROWID est écrit.
La consommation des UPDATE dépend du nombre de colonnes mises à jour.
Les valeurs indexées génèrent plus de rollback.
Les UPDATE de colonnes indexées nécessitent l’enregistrement :
• de l’ancienne valeur de la donnée,
• de l’ancienne valeur de l’index,
• de la nouvelle valeur de l’index.

Comment sont alloués les Rollback Segments ?
Remarque : Chaque validation (explicite ou implicite) met fin à la transaction : la commande peut donc être
incluse de façon répétitive. Cela peut être utile pour les traitements batch.

10

Date : 28/10/2001


Comment auditer les mécanismes de Redo ?
Les fichiers redo log sont organisés en groupes. Un groupe doit avoir un ou plusieurs membres. Tous les
membres d’un groupe ont un contenu identique.
Conseil : Par sécurité, il doit y avoir deux membres ou plus dans chaque groupe ou les fichiers doivent être
mirorrés par matériel.
Conseil : Puisque LGWR écrit presque continuellement dans les fichiers redo log d’un même groupe, ils
doivent être répartis sur des supports rapides.

Comment éviter les attentes de Checkpoint ?
Le process LGWR écrit de façon circulaire et séquentielle dans les groupes de redo log.
Quand un groupe est plein, Oracle exécute un Checkpoint. Cela signifie que :
• LGWR écrit le buffer log sur le disque,
• DBWR écrit tous les blocs validés (présents dans la Dirty List) dans les fichiers de données,
• LGWR ou CKPT mettent à jour les entêtes des fichiers de données.

Comment réguler les Checkpoints ?
DBWR doit toujours exécuter un checkpoint à la fin de chaque groupe de redo log.

Comment autoriser l’archivage des fichiers redo log ?
L’archivage des fichiers redo log permet une plus grande flexibilité dans les options de sauvegarde et de
restauration. Dans ce cas, il vaut mieux avoir plus de deux groupes de redo log.
Quand un groupe est rempli, DBWR fait un checkpoint et un fichier doit être archivé. Ceci doit se faire avant
que LGWR ait de nouveau besoin d’écrire sur le fichier.

Comment dimensionner le Buffer Redo Log ?
Le Buffer Redo Log fait partie de la SGA.

Comment réduire les Redo ?
Remarque : Si vous utilisez le SQL*Loader en mode chemin direct ou si vous utilisez la création parallèle et
que vous ne créez pas de redo log, vous devez sauvegarder le tablespace une fois la commande terminée.
Remarque : Si vous tentez d’accéder à ces objets après une restauration de la dernière sauvegarde (antérieure au
chargement UNRECOVERABLE ou à la création), un message d’erreur signalant que les blocs sont corrompus
est affiché.

Comment fonctionnent les latchs du Buffer Redo Log ?
Quand un process a besoin d’écrire ses changements dans le Buffer Redo Log, un « Redo Allocation Latch » lui
est alloué.
Ce process :
• obtient un Redo Allocation Latch,
• copie son travail dans le buffer,
• libère le latch.
Sur les machines à plusieurs CPU, il est plus efficace d’avoir plusieurs latchs.

Comment fonctionnent les latchs sur les plateformes SMP ?
Dans un système multi-process, plusieurs process peuvant être prêts en même temps pour copier leur travail
dans le Buffer Redo Log, un process a toujours besoin d’obtenir un Redo Allocation Latch.
Une fois l’espace dans le buffer alloué, il peut :
• conserver le latch tans qu’il écrit dans le buffer,
• libérer le latch et en conserver une copie pendant qu’il écrit.
A la fin de l’écriture, il libère le latch.
Il est possible d’avoir plusieurs copies du latch, mais seulement un latch.
L’obtention d’un latch peut provoquer un goulot d’étranglement.

Comment suivre la contention du latch Redo ?
Il y a deux types de demande :

11

Date : 28/10/2001

Type de demande Description
WILLING_TO_WAIT Le process attend le latch.
Utilisé avec le latch, le process ne pouvant pas
continuer sans obtenir le latch.
IMMEDIATE Le process continue son travail sans attendre.
Utilisé avec les copies de latch. S’il n’obtient pas une
copie de latch, le process conserve le latch.
Les colonnes de la vue V$LATCH sont :
Colonne Description
IMMEDIATE_GETS, IMMEDIATE_MISSES Informations sur les demandes de type IMMEDIATE.
GETS, MISSES, SLEEPS Informations sur les demandes de type
WILLING_TO_WAIT.
SLEEPS Nombre d’attentes des process.

Comment réduire la contention sur le Redo Allocation Latch ?
Chaque process avec une entrée de log supérieure à LOG_SMALL_ENTRY_MAX_SIZE doit libérer le Redo
Allocation Latch et obtenir une copie de Redo Allocation Latch avant l’écriture. Les process dont l’entrée est
inférieure à cette valeur peuvent conserver le Redo Allocation Latch lors de l’écriture.

Quels peuvent être les problèmes ?
Remarque : Il est possible de mettre le paramètre LOG_BLOCK_CHECKSUM à TRUE, mais ceci induit une
surcharge sensible au niveau des performances.

Comment suivre et détecter les contentions de verrous ?

Comment fonctionne le verrouillage ?
Les verrous permettent d’assurer un haut niveau de concurrence sur les données : plusieurs utilisateurs peuvent
accéder aux mêmes données en même temps.
Le verrouillage LMD se fait au niveau ligne.
Une interrogation ne pose aucun verrou, à moins que l’utilisateur ne spécifie le contraire.
Il existe plusieurs niveaux de cohérence des données : l’utilisateur voit une image statique des données, même
si les autres utilisateurs sont en train de la modifier.
Une transaction conserve le verrou tant qu’il n’y a pas eu de validation ou d’annulation (COMMIT ou
ROLLBACK).
Oracle ne convertit jamais les verrous de niveau ligne en verrous de niveau table.
Les verrous d’Oracle sont efficaces et peu coûteux, et la plupart des sites n’ont pas de problèmes de
verrouillage. Si les verrous provoquent une contention, c’est souvent parce que :
• les développeurs ont codé sans nécessité de hauts niveaux de verrouillage,
• les développeurs ont codé sans nécessité de longues transactions,
• les utilisateurs ne valident pas leurs modifications dès que possible,
• l’application utilise Oracle en conjonction avec d’autres produits imposant de plus hauts niveaux de
verrouillage.
Il existe plusieurs types de verrous :
• les verrous LMD,
• les verrous LDD,
• les autres.

Qu’est-ce que le verrou LMD ?
Il y a deux sortes de structures de verrous pour les traitements LMD (INSERT, UPDATE ou DELETE) :
• verrou partagé sur la table,
• verrou exclusif sur chacune des lignes modifiées.
Les verrous sont maintenus comme des files d’attente. Ce mécanisme peut garder trace :
• des utilisateurs en attente,
• du mode de verrou qu’ils désirent,
• de l’ordre dans lequel les utilisateurs ont fait la demande de verrou.
Le verrou LMD est de type Row Exclusive (RX). Sur l’écran du Server Manager Monitor :

12

Date : 28/10/2001


• le verrou table est de type TM dans la colonne Lock Type,
• les verrous lignes sont de type TX dans la colonne Lock Type,
• dans les colonnes Mode, les deux sont de type SX.
Les files d’attente diffèrent des latchs :
• Un latch est tenu par un process et les autres process essayant d’accéder à l’objet, tenu par le latch, sont
mis en attente.
• Une file d’attente est une liste de process en attente d’une ressource.
Au niveau bloc, Oracle conserve un identifiant pour chaque transaction active dans l’entête de bloc.
Au niveau ligne, l’octet verrou stocke un identifiant pour le slot contenant la transaction.

Qu’est-ce que le verrou LDD ?
Il y a trois sortes de verrous LDD :
Type de verrou Description
Verrous exclusifs LLD Les ordres CREATE, ALTER et DROP doivent obtenir
un verrou exclusif sur l’objet sur lequel ils portent.
Les utilisateurs ne peuvent pas poser un verrou
exclusif sur une table si d’autres utilisateurs l’ont déjà
verrouillée : ALTER TABLE échoue donc si d’autres
utilisateurs ont des transactions non validées sur la
table.
Verrous partagés LDD Les autres GRANT et CREATE PACKAGE doivent
obtenir un verrou partagé LDD sur les objets
référencés.
Les utilisateurs ne peuvent pas modifier la structure de
l’objet ou le supprimer.
Verrous de parsing Un ordre ou un objet PL/SQL en Library Cache
conserve un de ces verrous pour chaque objet
référencé.
Le verrou de parsing permet d’invalider l’ordre en cas
de modification des objets référencés. Il ne verrouille
pas vraiment l’objet et peut être « brisé ». Il ne peut
pas provoquer d’attente ni de contention.

Quels sont les autres verrous ?
L’ordre LOCK TABLE permet de demander explicitement un verrou Exclusive et Row Exclusive.
Type de verrou Description
Row Share (RS) Pour verrouiller les lignes lors d’une interrogation :
SELECT … FOR UPDATE ;
• Un verrou partagé de niveau table (similaire au
verrou table posé par un verrou RX) est posé.
• Un verrou exclusif sur les lignes sélectionnées est
posé.

Share (S) Le verrou Share empêche tout ordre LMD sur la table.
Les ordres SQL qui posent implicitement un verrou
Share impliquent les contraintes d’intégrité
référentielle. S’il n’y a pas d’index sur la colonne de
clé étrangère dans la table détail :
• Tout DELETE sur la table maître pose un verrou
Share sur la table détail.
• Tout UPDATE sur les colonnes de la table maître
pose un verrou Share sur la table détail.
Pour éviter ce comportement, indexer les colonnes de
clé étrangère dans la table détail.
La raison de ce comportement est qu’un
enregistrement de la table maître ne doit pas être
supprimé (ou voir sa clé primaire modifiée) alors
qu’elle est encore référencée par au moins une ligne
dans une table détail. La table détail est verrouillée

13

Date : 28/10/2001

pour empêcher les insertions et les modifications qui
transgresseraient cette règle.
Cependant, si la clé étrangère est indexée dans la table
détail, Oracle peut empêcher les changements sur les
lignes détail en verrouillant les valeurs modifiées dans
l’index.
Share Row Exclusive (SRX) Le verrou Share Row Exclusive empêche les ordres
LMD et SELECT … FOR UPDATE.
Les ordres SQL qui posent implicitement un verrou de
type Share Row Exclusive impliquent l’intégrité
référentielle.
Vous posez ce verrou sur la table détail quand vous
supprimez dans la table maître dans les cas suivants :
• Une contrainte de clé étrangère inclut l’option ON
DELETE CASCADE.
• Il n’y a pas d’index sur la colonne de la clé
étrangère dans la table détail.
La solution est donc d’indexer la colonne de clé
étrangère dans la table détail.

Comment suivre l’activité de verrouillage ?
Les autres vues sur les verrous sont : DBA_LOCKS, DBA_DDL_LOCKS, DBA_DML_LOCKS,
DBA_BLOCKERS et DBA_WAITERS.

Qu’est-ce que le Server Manager Lock Monitor ?
Tout process qui bloque les autres détient certainement un verrou obtenu via une application utilisateur. Les
verrous acquis par les applications utilisateurs sont :
• la file d’attente LMD (TM),
• la file d’attente de transaction (TX),
• la demande d’utilisateur (UL).
Les autres verrous non décrits ici sont des verrous système qui sont posés de façon très brève.
Le Server Manager Lock Monitor identifie deux types de verrou :
Type de verrou Ressource ID1
TX Numéro de rollback segment et numéro de slot.
TM Identifiant de la table en cours de mise à jour.

Qu’est-ce qu’un deadlock ?
Le serveur les détecte automatiquement et les résout en annulant l’ordre qui a détecté le deadlock.
Les deadlocks sont moins fréquents quand les applications acquièrent les verrous dans le même ordre ou quand
les transactions acquièrent les verrous les plus restrictifs en premier.
Une application où plusieurs utilisateurs mettent à jour les lignes d’une même table de façon aléatoire peut
générer des deadlocks. Une solution consiste à trier les lignes avant leur validation.

Comment la cohérence en lecture est-elle assurée ?

Qu’est-ce que la lecture logique au niveau traitement ?
Chaque interrogation voit toujours une image cohérente des données sélectionnées. Oracle utilise les rollback
segments pour reconstruire les données si le SCN (System Change Number) de l’interrogation est antérieur au
SCN des données.

Qu’est-ce que la lecture de cohérence de niveau transaction ?
Il n’est pas possible de lancer un ordre LMD dans ses transactions en lecture seulement.
Oracle utilise comme base le SCN au démarrage de la transaction et reconstruit chaque bloc modifié depuis
pour donner une image cohérente en lecture.
Conserver une image cohérente sur de multiples Lancer avant la première interrogation : SET
interrogations TRANSACTION READ ONLY ;

14

Date : 28/10/2001


Qu’est-ce que les transactions SERIALIZABLE ?
Dans une transaction en mode SERIALIZABLE, la vue sera cohérente et tiendra compte de ses propres
modifications.
Une transaction en mode SERIALIZABLE peut contenir des ordres LMD. Toute interrogation de la transaction
verra les changements de sa propre transaction mais pas les modifications faites par les autres utilisateurs.
Initialiser une transaction en mode SERIALIZABLE SET TRANSACTION isolation_level =
SERIALIZABLE ; ou ALTER SESESSION SET
isolation_level = SERIALIZABLE ;

Comment optimiser pour des besoins applicatifs divergents ?

Comment optimiser les applications transactionnelles ?
Les applications transactionnelles (OLTP - Online Transaction Processing) sont des systèmes à haut débit et à
fort taux d’insertion et de mise à jour. Elles contiennent généralement de gros volumes de données qui
grossissent de façon continuelle et sont accédées de façon concurentielle par des centaines d’utilisateurs.
Les buts du tuning sont :
• la disponibilité,
• la rapidité,
• la concurrence d’accès,
• la possibilité de restauration.
Conseil : Les contraintes sont toujours moins coûteuses à exécuter que les règles de gestion par code applicatif.
Les contraintes d’intégrité référentielle ou les contraintes de type CHECK sont les principaux types de
contraintes à considérer. Si vous utilisez les règles de gestion par code applicatif, il faut s’assurer que le code
est bien partagé.
Conseil : Il faut maintenir la charge de parsing au minimum. Pour cela, il faut que le code de l’application
utilise bien les variables plutôt que les valeurs littérales.

Comment optimiser les applications d’aide à la décision ?
Les applications d’aide à la décision utilisent un gros volume d’informations pour construire les rapports de
synthèse. Elles collectent des informations en provenance de systèmes OLTP tout en les groupant et en les
totalisant. La méthode d’accès est souvent la lecture séquentielle (full table scan) sur de gros volumes de
données.
Les principaux objectifs du tuning sont :
• la rapidité,
• la disponibilité.
L’option Parallel Query est très bien adaptée à ce type de système.
L’optimiseur a besoin de statistiques à jour pour choisir le plan d’exécution correct de recherche des données. Il
est donc nécessaire de mettre en place des procédures d’analyse statistique régulière des tables.

A quoi servent les histogrammes ?
L’optimiseur par les coûts (CBO) évalue relativement précisément le coût d’une requête dans le cas de données
uniformément réparties. S’il ne peut pas, il ne peut pas estimer la sélectivité d’une interrogation.
Les barres des histogrammes sont de même hauteur (height balanced) : la valeur maximale de chaque
fourchette de valeurs indique donc le nombre de valeurs appartenant à la fourchette.

Qu’est-ce qu’un Index Bitmap ?
Les index bitmap sont particulièrement utiles dans un système d'aide à la décision (IAD ou DSS).
Si vous lancez une requête SQL avec de nombreuses clauses WHERE, Oracle peut utiliser les opérateurs AND
et OR pour combiner ce bitmap avec des bitmaps portant sur d'autres colonnes.
Aucune règle ne porte sur l'ordre des colonnes.
Oracle peut combiner n'importe quel nombre d'index bitmap dans n'importe quel ordre.
Les index bitmaps :
• utilisent peu d'espace de stockage,
• travaillent très rapidement sur de multiples prédicats sur des colonnes faiblement discriminantes.
Un index bitmap a une catégorie pour chaque valeur possible. Exemple :
Table EMP Index bitmap
EMPNO JOB JOB='MANAGER' JOB='PROGRAMMER'

15

Date : 28/10/2001

0001 MANAGER 1 0
0002 PROGRAMMER 0 1

Comment s’adapter à la logique de l’application ?
Dans les applications d'aide à la décision (IAD), le temps passé à analyser l'ordre SQL est négligeable en
comparaison du temps passé à exécuter l'interrogation.
Le tuning de la Library Cache est donc moins important dans ce type d'applications que dans les applications
OLTP.
Il est d’autant plus important de parvenir au plan d'exécution optimal que de petites variations peuvent coûter
des minutes ou des heures.
Les développeurs doivent donc :
• analyser attentivement (éventuellement avec les hints),
• tester sur des volumes de données réalistes,
• utiliser des fonctions PL/SQL dans les interrogations.
Dans les versions antérieures à la 7.3, si les statistiques étaient correctement calculées, l'optimiseur
connaissait :
• les places de valeurs d'une colonne,
• le nombre de valeurs distinctes.
En Oracle 7.3, il a en plus la connaissance de la distribution des données dans les plages de valeurs grâce aux
histogrammes.
Si l'application utilise des variables (exemple : Select * From nom_table WHERE nom_colonne = :1), cette
architecture n'est plus valable.
L'optimiseur ne peut en effet pas calculer avec précision le nombre d'enregistrements concernés par cette
interrogation. Le plan d'exécution ne sera donc pas optimal.
Conseil : Les variables de type Bind sont conseillées pour les applications OLTP mais surtout pas pour les
applications IAD.

Comment optimiser les applications client/serveur ?
L’objectif est essentiellement de minimiser les échanges entre l'applicatif et la base de données.

Comment reconfigurer en fonction des besoins ?
Conseil : Les UPDATE en OLTP impliquent un PCTFREE plus bas que celui préconisé en IAD. Maintenir
deux bases au lieu d'une a un coût. Il est possible d'utiliser des fichiers de paramètres différentes pour le jour et
la nuit, en arrêtant et redémarrant la base.

Comment optimiser les tris ?
Les traitements suivants génèrent du tri :
La création d'un index Le processus serveur (ou des processus si l'index est
créé en parallèle) doit trier les valeurs indexées avant
de construire le B*tree.
Les clauses Order By et Group By Le processus serveur doit trier les valeurs spécifiées
dans les clauses Order By et Group By.
L'utilisation de Distinct Lors de l'utilisation du mot clé Distinct, le tri élimine
les valeurs identiques.
Les opérateurs UNION, INTERSECT ou MINUS Les serveurs ont besoin de trier les tables sur lesquelles
ils travaillent pour éliminer les valeurs identiques.

Comment trier en mémoire ?
Si un tri a besoin de plus d'espace :
• les données sont séparées et triées en plusieurs fois,
• le process serveur écrit dans un segment temporaire sur disque,
• les segments conservent les données pendant que le serveur effectue un autre tri.
La taille du tri :
• est stockée dans la zone mémoire utilisateur,
• n'a pas d'impact sur la SGA (à moins d'être en configuration multithread : MTS),
• est intégrée à la Shared Pool en UGA (en configuration multitherad).
Conseil : Si des tris importants sont effectués, ne pas utiliser MTS.

16

Date : 28/10/2001

Lorsque le tri est terminé mais que la zone mémoire contient toujours des enregistrements triés, cette zone peut
se réduire (shrink) à la valeur précisée dans le paramètre SORT_AREA_RETAINED_SIZE.

Comment évaluer les besoins en mémoire ?
Un plan d'exécution peut contenir de nombreux tris. Exemple : une jointure tri-fusion (Sort Merge) de deux
tables suivies d'un tri pour une clause Order By. Cela fait trois tris au total.
Si un serveur travaille sur un tri, lorsqu'il fait le Order By, il consomme :
• une zone de taille SORT_AREA_SIZE (en octets) pour chaque tri actif,
• deux zones de la taille SORT_AREA_RETAINED_SIZE (pour les tris de jointure).
Si vous parallélisez le traitement, chaque serveur d'interrogation a besoin de SORT_AREA_SIZE octets.
Avec l'option Parallel Query, deus groupes de serveurs peuvent travailler en même temps, ce qui consomme :
• SORT_AREA_SIZE * 2 * degré de parallélisation,
• SORT_AREA_RETAINED_SIZE * degré de parallélisation * (nombre_de_tri - 2).
La valeur optimale de SORT_AREA_SIZE et de SORT_AREA_RETAINED_SIZE pour l'option Parallel
Query est de 1Mo.
Normalement, SORT_AREA_SIZE et SORT_AREA_RETAINED_SIZE devraient avoir la même valeur, sauf
si :
• vous êtes juste en mémoire,
• vous utilisez un serveur MTS.

Comment éviter le Buffer Cache ?
La consommation mémoire (en octets) de chaque tri est de SORT_WRITE_BUFFERS *
SORT_WRITE_BUFFER_SIZE + SORT_AREA_SIZE.
Un tri parallèle a besoin de ((SORT_WRITE_BUFFER * SORT_WRITE_BUFFER_SIZE) +
SORT_AREA_SIZE) * 2 * degré de parallélistation

Comment suivre les tris ?
Vous devez vous assurer que :
• le maximum de tris est réalisé en mémoire,
• lors de l'utilisation inévitable des segments temporaires, les E/S sont aussi rapides que possible.

Comment optimiser les connexions ?

Qu'est-ce que le Multithread ?
Le Serveur Multi-Thread (MTS) donne la possibilité aux utilisateurs de partager des process.
Il ne rend pas le système plus rapide mais permet à un plus grand nombre d'utilisateurs de travailler en même
temps sur le base de données.
Sans MTS, chaque utilisateur standard Unix (ou se connectant d'un client distant) a besoin d 'un serveur dédié
pour accéder aux fichiers du serveur Oracle et à ses structures mémoires.
Dans les applications interactives, où les utilisateurs passent le plus clair de leur temps à parler à leurs clients,
ces serveurs dédiés sont en grande partie inactifs. Ils ont du travail lorsque l'utilisateur envoie une interrogation
ou effectue un changement dans la base.
Avec MTS, plusieurs utilisateurs partagent des process dispatchers, qui accèdent au serveur Oracle pour eux.
Oracle utilise des serveurs partagés pour effectuer les ordres SQL qui lui sont donnés par les dispatchers.
MTS est utile sur :
• les systèmes Unix, où ils évitent la consommation d'un serveur dédié pour chaque utilisateur,
• d'autres serveurs auxquels accèdent de nombreux clients distants,
• les machines qui approchent les limites de ressources sur les process et les sémaphores.
Pour la gestion des process dispatchers, augmenter la CPU. Donc, si les ressources CPU posent un problème, ne
pas mettre en place MTS.
Conseil : MTS est conseillé sur les systèmes ayant plus de 100 utilisateurs. Il fonctionne néanmoins avec un
nombre moins élevé mais sans bénéfice notable. Par contre, il n’y a aucun intérêt à utiliser les serveurs partagés
sur des bases de données travaillant intensivement.

Comment configurer le MTS ?
Avant toute chose, il faut installer et configuer SQL*Net v2.
Il y a deux fichiers :

17

Date : 28/10/2001

Nom du fichier Contenu
listener.ora L'adresse du listener et des instances auxquelles il peut
se connecter.
tnsnames.ora Alias de spécification des connexions utilisables.
Les paramètres d'initialisation sont :
Paramètre Valeur
MTS_LISTENER_ADDRESS Adresse exacte identique à celle spécifiée dans
listener.ora.
MTS_SERVICE Valeur du mot clés SID dans la clause CONNECT
DATA dans tnsnames.ora.
MTS_SERVERS Nombre initial de serveurs partagés.
MTS_DISPATCHERS Nombre initial de dispatchers.
MTS_MAX_SERVERS Nombre maximum de process serveurs.
MTX_MAX_DISPATCHERS Nombre maximum de process dispatchers.

Comment régler les serveurs partagés ?
S'il n'y a pas assez de serveurs partagés, le serveur en démarrera d'autres. Ils seront supprimés lorsqu'ils
deviennent inactifs, sauf si vous avez précisé cette valeur dans le paramètre MTS_SERVERS.
S'assurer que le nombre de serveurs n'avoisine pas MTS_MAX_SERVERS ou PROCESSES.

Que faut-il savoir sur les serveurs partagés et le Shared Pool ?
Si vous utilisez MTS, des informations conservées dans la PGA sont transférées dans la Shared Pool de la zone
UGA (User Global Area).
Demander moins de mémoire à la Shared Pool mais, en contre-partie, diminuer les demandes des utilisateurs
pour leurs propres mémoires.

Quelles peuvent être les problèmes ?
Conseil : Il est dangereux de supprimer un process de serveur utilisateur au niveau du système d'exploitation
(utiliser plutôt KILL SESSION) : supprimer un dispatcher peut aussi affecter d'autres utilisateurs.
Conseil : Ne pas effectuer des opérations sensibles (exemple : STARTUP, SHUTDOWN) sur un serveur
partagé. Le DBA doit avoir une connexion dédiée.
Les serveurs et dispatchers comptent autant de process background pour une instance.
Remarque : Dimensionner convenablement MTS_MAX_SERVERS et MTS_MAX_DISPATCHERS.

18

La base de données Oracle

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à La base de données Oracle

Similaire à La base de données Oracle (20)

Plus de Bruno Delb

Plus de Bruno Delb (20)

La base de données Oracle