Articles avec le tag ‘10G’

Introduction

Lorsqu’un serveur redémarre de façon brutale, il est toujours utile que votre base de donnée Oracle redémarre automatiquement lorsque le système s’initialise. Ceci peut vous éviter des downs très longs et de nombreuses interventions de votre part qui s’avèrent au final pas très utiles. En plus, Oracle vous as facilité la vie pour mettre ça en place ! Vous n’avez donc aucune raison pour ne pas lire le reste de l’article

Modification de /etc/oratab

Il va vous falloir modifier le fichier /etc/oratab . Le fichier est au format

$ORACLE_SID:$ORACLE_HOME:N|Y

La dernière colonne indique aux scripts dbstart et dbshut (vu par la suite) de démarrer (Y) ou pas (N) cette instance.

Exemple :

orcl:/app/oracle/product/11.2.0/dbhome_1:N

Il faut que vous changiez le « N » de la ligne de l’instance que vous voulez démarrer en « Y ». Ce qui donnera pour notre ligne en exemple :

orcl:/app/oracle/product/11.2.0/dbhome_1:Y

Création du script de démarrage

A partir de maintenant, nous allons créer un script bash qui sera exécuté à chaque démarrage. Ce script appellera les deux scripts dbstart et dbshut qui s’occuperont respectivement de lancer et d’arrêter votre base de données.

Vous pouvez télécharger ce script à cette addresse. Copiez le dans le dossier /etc/init.d en prenant soin de remplacer les valeurs {A remplacer} par le ORACLE_HOME et le ORACLE_SID respectivement.

Exécuter ce script au démarrage

Pour exécuter ce script au démarrage de votre système Linux, il faudra placer un alias dans les répertoires rc3.d et rc5.d (dépend de votre runlevel). Pour faire ceci :

ln -s /etc/init.d/oracle /etc/rc.d/rc3.d/S99oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc5.d/S99oracle

Inversement, pour arrêter vos bases proprement à chaque extinction de votre système :

ln -s /etc/init.d/oracle /etc/rc.d/rc3.d/K01oracle

ln -s /etc/init.d/oracle /etc/rc.d/rc5.d/K01oracle

Vous pouvez dorénavant redémarrer votre système et vérifier que votre base de données se lance au démarrage !

Introduction

Votre instance peut vous poser de très nombreux problèmes. Parmi ceux-ci,il y en a que tous les débutants font les premiers jours en tant que DBA Oracle. Vous trouvez ici une liste non-exhaustive d’erreurs courantes et leurs solutions

Les erreurs

Error while loading shared libraries

Système : Oracle Enterprise Linux 5 / Oracle Database 11G

Cause : SELinux en mode Enforcing

Solution : Lancer la commande setenforce 0 . Vous pouvez vérifier l’état de SELinux avec la commande getenforce

SP2-0024 : Rien à modifier

Cause: Oracle n’arrive pas à trouver le .sql que vous spécifiez

Solution: Mettre le chemin complet dans la commande. Exemple : @/app/oracle/scripts/script.sql au lieu de @script.sql

ORA-32017: failure in updating SPFILE

Autre : ORA-16179: incremental changes to « log_archive_dest_2″ not allowed with SPFILE

Cause : Erreur fréquente. Lors de l’ALTER SYSTEM, vous avez oublié la clause LOCATION

Solution : ALTER SYSTEM SET log_archive_dest_2=’LOCATION=/app/oracle/oradata/arch’ scope=both

Introduction

Comme vous avez pu dans le voir dans l’article Générer des traces sur votre instance Oracle , les traces en elle-même sont globalement illisibles

Pour vous éviter un mal de tête, Oracle a développer un outil très pratique nommé Tkprof qui se chargera de vous décoder vos traces et de vous fournir quelques éléments pratiques comme le plan d’exécution des requêtes.

Utilisation de TkProf

TkProf est inclut dans Oracle Client et Oracle Database. C’est un outil en ligne de commande que vous pouvez via une invite de commande sous Windows ou un terminal sous Linux.

Sans plus attendre, voici la syntaxe :

Windows :

tkprof  C:/oracle/…./trace.trc output=C:/oracle/…./trace_output.txt

Linux :

$ORACLE_HOME/bin/tkprof  /app/oracle/…/trace.trc output=/app/oracle/…/trace_output.txt

Attention : La version de TkProf doit être impérativement la même que celle de la base de donnée où vous avez généré vos traces. Si elles sont différentes, vous aurez à coup sûr des valeurs aberrantes dans votre output file.

Les options indispensables

Pour que vos rapports TkProf soient plus lisibles, quelques options sont indispensables.

• SYS=no : Ne pas afficher les ordres SQL exécutés par l’utilisateur SYS
• EXPLAIN=user/password : Permet de spécifier le schéma dans lequel tkprof va générer les explain plan. Inutile si vous générez vos traces directement avec le compte oracle en local sur votre base de donnée
• AGGREGATE=no : Permet de ne pas regrouper les ordres SQL similaires
• SORT= : Permet de triées les instructions selon l’option désirée

Et comment je les utilise ces options ?

Simple comme bonjour ! Par exemple, pour des traces sans ordres SQL exécutées par SYS et pas de regroupements d’ordres SQL similaires sous Linux :

$ORACLE_HOME/bin/tkprof  /app/oracle/…/trace.trc sys=no aggregate=no output=/app/oracle/…/trace_output.txt

Comment lire mon rapport ?

Pour mieux illustrer, prenons la trace qui avait été générée dans mon article Générer des traces sur votre instance Oracle.

********************************************************************************

SELECT e.last_name, j.job_title from oracle.employees e
    JOIN oracle.jobs j ON (e.job_id=j.job_id)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.13          0          4          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0         15          0         107
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.01       0.14          0         19          0         107

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS

Rows     Row Source Operation
-------  ---------------------------------------------------
    107  HASH JOIN  (cr=15 pr=0 pw=0 time=5798 us)
     19   TABLE ACCESS FULL JOBS (cr=7 pr=0 pw=0 time=187 us)
    107   TABLE ACCESS FULL EMPLOYEES (cr=8 pr=0 pw=0 time=796 us)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       2        0.00          0.00
  SQL*Net message from client                     2        0.14          0.15
********************************************************************************

Nous pouvons distinguer trois parties :

• Un tableau avec plein de nombres. (On reviendra dessus après)
• L’explain plan de la requête
• Les Wait events générés par la requête

Comment je le lis le tableau ?

Ce fameux tableau est découpé en trois lignes :

• Parse : Cette étape détermine le plan d’exécution de votre requête
• Execute : Pour les ordres INSERT, UPDATE, DELETE : modifie les données. Pour l’ordre SELECT : Identifie les lignes à extraire
• Fetch : Extraction des lignes et opérations de tri. Concerne uniquement l’ordre SELECT.

Concernant les lignes, voici leurs significations :

• Count : Nombre de fois que le Parse/Execute/Fetch a été exécuté
• CPU (Seconde) : Temps total de traitement CPU
• Elapsed (Seconde) : Temps total pris par le Parse/Execute/Fetch.
• Disk : Nombre total de blocs lus physiquement dans les fichiers de données
• Query : Nombre de buffers exploités en mode cohérent
• Current : Nombre de buffers exploités en mode courant
• Rows : Nombre de lignes affectés par la requête.

Quelques consignes pour bien commencer

1. Vérifier qu’il n’y a pas de grosses différences entre CPU et Elapsed
2. N’oubliez jamais de diviser vos valeurs par la valeur de Count
3. Prenez l’habitude d’additionner Current et Query pour connaître le nombre total de buffers extraits
4. Comparer le nombre de blocs parcourus aux nombre de lignes fetchées pour vérifier s’il ne manque pas un index. (Inutile si vous avez l’explain plan)
5. Ne perdez pas de temps à trop décoder, ça se parcoure vraiment très rapidement

Conclusion

TkProf est un outil très facile à utiliser mais néanmoins indispensable à tous les DBAs. Il vous permettra de comprendre et résoudre de nombreux problèmes en très peu de temps.

Introduction

Imaginez-vous dans cette situation : un programmeur vous appelle « Monsieur CAPITAINE, j’ai des problèmes avec un de mes traitements sur l’instance de Dèv, c’est très lent. Pouvez-vous me dire ce qui est lent ? ». Qu’allez-vous faire ? Vous allez lancer des traces.

C’est un des outils les plus pratiques du DBA Oracle. Une trace est un fichier plat qui recense tous les ordres SQL passés entre un laps de temps que vous définirez. Dans l’exemple plus haut, l’intervalle serait Début du traitement – Fin du traitement .

Un peu de technique

Voici une trace : Cliquez ici pour la voir

Première impression : « Gné ? » . Vous avez tout à fait raison. Les traces, en elle-même, sans être parsées par l’utilitaire tkprof sont globalement illisibles sauf pour les DBA très expérimentés qui se feront une joie de vous les déchiffrer.

Pour satisfaire votre curiosité, voici la même trace qu’au dessus mais à la différence d’être parsées par TKPROF : Cliquez ici pour la voir

Comment on trace ?

Il y a plusieurs façons de générer des traces. Vous pouvez les générer pour « vous » au niveau session, mais vous pouvez aussi les générer pour une session différente de la vôtre.

Tracer votre propre session

Tout d’abord au niveau de votre de votre session, la solution la plus simple est l’ALTER SESSION :

ALTER SESSION SET EVENTS ‘10046 trace name context forever,level 12′;

Vous n’avez plus qu’à exécuter votre traitement qui pose des soucis de performance. Une fois terminée, vous n’avez qu’à entrer cette commande :

ALTER SESSION SET EVENTS ‘10046 trace name context off’;

Tiens d’ailleurs en parlant de ça je pourrais les trouver où mes traces ?

Pour trouver l’emplacement de vos traces, il suffit d’ouvrir SQL*plus et de copier la commande

show parameter user_dump_dest

Le résultat est le dossier exact où se trouve toutes vos traces générées.

Tracer une session distante

Maintenant, pour tracer des sessions distantes, vous pouvez utiliser le package DBMS_SYSTEM comme ceci :

EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (sid=>[sid],serial#=>[serial],sql_trace=>TRUE);

Exécutez votre traitement puis pour stopper les traces :

EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (sid=>[sid],serial#=>[serial],sql_trace=>FALSE);

Attention : Votre utilisateur doit avoir le droit EXECUTE sur le package DBMS_SYSTEM pour faire ceci.

Je fais comment pour récupérer le SID et le SERIAL ?

Le SID (Session ID) et le Serial# sont des identifiants uniques attachés à chaque session sur votre base de données Oracle. Pour récupérer le SID de la session visée, exécutez cette requête :

SELECT SYS_CONTEXT('userenv','SID') SID FROM DUAL;

Ensuite, avec un utilisateur qui a les privilèges de SELECT sur la vue V$SESSION, vous pouvez retrouver le serial avec cette requête :

SELECT serial# FROM V$SESSION WHERE sid=[SID précédemment trouvé];

Conclusion

Maintenant que vous savez lancer des traces de votre session et d’une distante, il vous faut les rendre lisibles. Pour ceci, la page suivante vous apprendra à manipuler l’utilitaire tkprof.