La base de données Oracle

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

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..........................................................................................4LES TABLESPACES....................................................................................................................4COMMENT UTILISER LE DÉCOUPAGE ?..........................................................................................5

AUDITER LE CODE SQL..................................................................................5

DIAGNOSTIQUER LES PROBLÈMES................................................................................................5AUDITER LES MODULES.............................................................................................................6

COMMENT AUDITER LA ZONE DE PARTAGE DES ORDRES SQL (SHARED POOL) ?7

QU’EST-CE QUE LA LIBRARY CACHE ?.........................................................................................7Comment auditer la Library Cache ?..............................................................................7Quelles sont les vues dynamiques relatives à la Library Cache ?................................7Comment suivre les performances de la Library Cache ?.............................................7A quoi sert le package DBMS_SHARED_POOL ?.............................................................8

QU’EST-CE QUE LE DICTIONARY CACHE ?....................................................................................8Comment auditer le Dictionary Cache ?........................................................................8Comment 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 ?..........................................................................................8COMMENT LE BUFFER CACHE EST-IL GÉRÉ ?.................................................................................9QUELS SONT LES OBJECTIFS DE L’AUDIT DU BUFFER CACHE ?..........................................................9COMMENT MESURER LE HIT RATIO DU BUFFER CACHE ?................................................................9COMMENT EXAMINER L’IMPACT DE L’AJOUT OU DE LA SUPPRESSION DE BUFFERS ?..............................9

COMMENT UTILISER EFFICACEMENT LES BLOCS ORACLE ?..............................9

COMMENT AUDITER LES BLOCS ?................................................................................................9QU’EST-CE QUE LA HIGH WATER MARK ?.....................................................................................9QU’EST-CE QUE LE PACKAGE DBMS_SPACE ?..........................................................................10COMMENT SONT RÉORGANISÉS LES INDEX ?...............................................................................10COMMENT SONT GÉRÉS LES FREE LISTS ?..................................................................................10

COMMENT OPTIMISER LES ROLLBACK SEGMENTS ?.......................................10

QU’EST-CE QU’UN ROLLBACK SEGMENT ?..................................................................................10COMBIEN DE ROLLBACK SEGMENTS FAUT-IL ?............................................................................10COMBIEN DE ROLLBACKS SONT-ILS UTILISÉS ?............................................................................11COMMENT SONT ALLOUÉS LES ROLLBACK SEGMENTS ?................................................................11

COMMENT AUDITER LES MÉCANISMES DE REDO ?.........................................11

COMMENT ÉVITER LES ATTENTES DE CHECKPOINT ?.....................................................................11COMMENT RÉGULER LES CHECKPOINTS ?...................................................................................11COMMENT AUTORISER L’ARCHIVAGE DES FICHIERS REDO LOG ?.....................................................11COMMENT DIMENSIONNER LE BUFFER REDO LOG ?.....................................................................11COMMENT RÉDUIRE LES REDO ?...............................................................................................11COMMENT FONCTIONNENT LES LATCHS DU BUFFER REDO LOG ?...................................................11

1



Comment fonctionnent les latchs sur les plateformes SMP ?.....................................12Comment suivre la contention du latch Redo ?...........................................................12Comment 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 ?...............................................................................12Qu’est-ce que le verrou LMD ?.....................................................................................13Qu’est-ce que le verrou LDD ?......................................................................................13Quels sont les autres verrous ?....................................................................................13

COMMENT SUIVRE L’ACTIVITÉ DE VERROUILLAGE ?.......................................................................14Qu’est-ce que le Server Manager Lock Monitor ?........................................................14

QU’EST-CE QU’UN DEADLOCK ?................................................................................................15COMMENT LA COHÉRENCE EN LECTURE EST-ELLE ASSURÉE ?.........................................................15

Qu’est-ce que la lecture logique au niveau traitement ?............................................15Qu’est-ce que la lecture de cohérence de niveau transaction ?.................................15Qu’est-ce que les transactions SERIALIZABLE ?..........................................................15

COMMENT OPTIMISER POUR DES BESOINS APPLICATIFS DIVERGENTS ?.........15

COMMENT OPTIMISER LES APPLICATIONS TRANSACTIONNELLES ?....................................................15COMMENT OPTIMISER LES APPLICATIONS D’AIDE À LA DÉCISION ?...................................................15

A quoi servent les histogrammes ?..............................................................................16Qu’est-ce qu’un Index Bitmap ?...................................................................................16Comment s’adapter à la logique de l’application ?.....................................................16

COMMENT OPTIMISER LES APPLICATIONS CLIENT/SERVEUR ?..........................................................16Comment reconfigurer en fonction des besoins ?.......................................................17

COMMENT OPTIMISER LES TRIS ?.................................................................17

COMMENT TRIER EN MÉMOIRE ?...............................................................................................17COMMENT ÉVALUER LES BESOINS EN MÉMOIRE ?.........................................................................17COMMENT ÉVITER LE BUFFER CACHE ?......................................................................................17COMMENT SUIVRE LES TRIS ?...................................................................................................18

COMMENT OPTIMISER LES CONNEXIONS ?....................................................18

QU'EST-CE QUE LE MULTITHREAD ?..........................................................................................18COMMENT CONFIGURER LE MTS ?............................................................................................18COMMENT RÉGLER LES SERVEURS PARTAGÉS ?...........................................................................18QUE FAUT-IL SAVOIR SUR LES SERVEURS PARTAGÉS ET LE SHARED POOL ?.....................................18Quelles peuvent être les problèmes ?.............................................................................19

2



IntroductionEn 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’optimisationLes 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 diagnosticLes 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 DescriptionCIRCUITS 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 traceLes 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 DescriptionRdbms/log/alert.log (un Les événements majeurs et les erreurs les plus importantes

3



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 PackOutil de diagnostic DescriptionOracle 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 7Parmi 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 tablespacesUne 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). TEMP

4



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 SQLIl 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 DescriptionCHOOSE (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.

RULEFIRST_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èmesSQL 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.

5



SQL_TRACE = TRUEPour 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 = FALSEPour 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 modulesSi 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 DescriptionSET_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.« action » est le nom ou la description de l’action (32 caractères au maximum). Il est stocké dans 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.

6



« 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.

READ_CLIENT_INFO (action) Lit les dernières informations sur le client pour la session.« action » est le nom ou la description de l’action (32 caractères au maximum). Il est stocké dans 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 RELOADSLes paramètres suivants affectent la Library Cache :Paramètre DescriptionSHARED_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.

7



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 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),

8



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.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 DescriptionINDX 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 DescriptionINDX 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.

9



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.

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 DescriptionLF_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,

10



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.

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.

11



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 :Type de demande DescriptionWILLING_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 DescriptionIMMEDIATE_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,

12



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 : 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 DescriptionVerrous 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 DescriptionRow 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

13



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 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 ID1TX 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.

14



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 interrogations

Lancer avant la première interrogation : SET TRANSACTION READ ONLY ;

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.

15



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 bitmapEMPNO JOB JOB='MANAGER' JOB='PROGRAMMER'0001 MANAGER 1 00002 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

16



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.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.

17



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 :Nom du fichier Contenulistener.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 ValeurMTS_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

Technology

La base de données Oracle