Une goutte de sueur froide qui coule, le palpitant qui va sortir de votre poitrine et les mains moites comme un automne anglais, ça y est vous êtes au moment fatidique : la restauration de votre base de données.

Si il y a bien quelquechose qui doit être maîtriser quand on est Administrateur de bases de données, c’est la restauration des données en cas de panne de votre base de données. Qu’ils s’agissent d’un disque dur cassé, d’un contrôleur raid mort etc… vous devez pouvoir restaurer vos données sinon vous pourrez y laisser votre job assez rapidement.

Pour ça, Oracle vous fournit un outil formidable qui répond au doux nom de RMAN (Recovery Manager) et qui permet de gérer complètement ses sauvegardes et ses restaurations en quelques lignes de commandes.

Mise en situation

Avant de faire quelques scénarios de restauration, il est important de positionner notre situation. Nous avons une base de données Oracle avec les ControlFiles et les RedoLogs multiplexés.Nous allons nous baser sur le schéma classique HR en y ajoutant quelques lignes pour voir la restauration.

On admet que la base de données est en ArchiveLog Mode et qu’il n’y a pas de catalogue RMAN installé. Nous avons un volume de données risible et un environnement très basique donc il est bon

Tout d’abord, nous allons rajouter une ligne dans la table countries :

SQL> INSERT INTO hr.countries (country_id,country_name,region_id) VALUES (‘BZ’,'Bretagne’,1);

SQL > COMMIT;

Ensuite, on va faire une backup entière de notre base de données avec RMAN :

$ bin/rman target /

RMAN > backup full database;

Enfin, nous allons rajouter une autre ligne dans la table employees après cette sauvegarde :

SQL> INSERT INTO hr.employees (employee_id,first_name,last_name,email,hire_date,job_id) VALUES (hr.employees_seq.nextval,’Guireg’,'CAPITAINE’,'guireg@company.com’,sysdate,’MK_MAN’);

SQL > COMMIT;

Maintenant que notre scénario est là, on va essayer de couvrir le plus de situations possibles pour retrouver nos données. Il est important de savoir que même si notre dernière ligne a été enregistrée après la sauvegarde, nous DEVONS absolument la retrouver une fois la restauration faite.

Les différents scénarios

Perte d’un ou plusieurs datafiles

Le scénario le plus simple, nous perdons un datafile, celui qui contient notre nouvelle ligne : la base se monte mais ne pas s’ouvrir.

SQL> startup;
ORACLE instance started.

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             327158144 bytes
Database Buffers           88080384 bytes
Redo Buffers                6094848 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 – see DBWR trace file
ORA-01110: data file 4: ‘/app/oracle/oradata/orcl/users01.dbf’

Du coup, nous ouvrons RMAN et nous lançons la restauration de notre datafile perdu.

$ bin/rman target /

RMAN> restore datafile 4;

RMAN> recover datafile 4;

Puis on ouvre la base de données.

SQL> alter database open;

Comment connaît-on le numéro du datafile à restaurer ?

Il est tout simplement indiqué dans le message d’erreur lorsque nous démarrons la base de données (Cannot identify data file 4)

On vérifie si notre employés est toujours présent :

SQL> select last_name from hr.employees where first_name=’Guireg’;

LAST_NAME
————————-
CAPITAINE

Tout est bon !

Perte d’un controlfiles

Par défaut, les controlfiles sont multiplexés en 2 exemplaires. Si vous perdez un seul controlfile, il vous suffira de copier votre controlfile restant dans l’emplacement de celui perdu.

Par défaut, un controlfile est situé dans le répertoire oradata et le deuxième la flash_recovery_area.

Perte de tous les controlfiles

Lorsque vous perdez tous les controlfiles, votre base ne peut même pas être montée et dans notre cas, nous avons aussi perdus notre « catalogue » RMAN rendant impossible une multitude de commande RMAN qui automatise la restauration. Qu’est-ce qu’on va alors faire ? Dans l’hypothèse que vous aviez sauvegardé votre DBID et votre controlfile dans votre dernière backup RMAN, nous sommes sauvés !

On ouvre RMAN puis on renseigne le DBID et on restore notre controlfile à partir de notre sauvegarde faites la veille :

$ bin/rman target /

RMAN> set DBID=1256634398

RMAN> restore controlfile from ‘/app/oracle/flash_recovery_area/ORCL/backupset/2010_10_03/o1_mf_ncsnf_TAG20101003T175944_6bkb9tc1_.bkp’;
Starting restore at 04-OCT-10
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/orcl/control01.ctl
output file name=/app/oracle/flash_recovery_area/orcl/control02.ctl
Finished restore at 04-OCT-10

Ensuite, il faut qu’on synchronise le controlfile avec l’état actuel de la base de données car il a quelques heures de retard !

On monte la base de données puis on fait un recover de la base. Ensuite, on finit par l’ouvrir en mode resetlogs.

RMAN> alter database mount;

RMAN> recover database;

RMAN> alter database open resetlogs;

Notre base est ouverte. Il ne reste plus qu’à vérifier que notre ligne ajoutée après la sauvegarde est toujours là :

SQL> select last_name from hr.employees where first_name=’Guireg’;

LAST_NAME
————————-
CAPITAINE

C’est encore un coup gagnant !

Où je trouve le DBID ?

Le DBID est un identifiant que vous pourrez trouver en exécutant cette requête :

SQL> SELECT DBID FROM v$database;

Il est aussi renseigné à chaque login sur RMAN. Il doit être impérativement écrit quelque part lorsque vous installez une base de données en cas de perte de votre catalogue RMAN.

Où je trouve ma sauvegarde ?

Par défaut, les sauvegardes se trouvent dans $ORACLE_BASE/flash_recovery_area/[SID]/backupset/[Date]/xxx.bkp.

Perte de vos archivelog

Si vous perdez l’ensemble de vos archiveLog, vous ne pourrez restaurer votre base de données qu’à la date de votre dernière sauvegarde. Aucune modification entre votre sauvegarde et le moment où votre base a crashée pourra être restaurée.

Utilisateurs de la 11G

Pour les utilisateurs de Oracle 11G, vous pouvez restaurer votre base en 3 commandes grâce à l’utilitaire Data Recovery Advisor. Voici un article pour savoir comment l’utilisateur : Restaurer votre base Oracle en 3 lignes avec Data Recovery Advisor

Conclusion

Les backups sont une grande part du travail du DBA. Il est crucial de multiplexer vos redo logs , vos control files et vos archive log dans votre base de données si vous voulez perdre absolument aucune donnée lors d’une restauration. N’hésitez surtout pas à tester vos sauvegardes même si tout va bien en ce moment car ce n’est pas le jour J qu’il faudra vous rendre compte que vos backups sont corrompus.

Dans le monde de la base de données, notamment en DataWareHouse, il arrive fréquemment d’avoir à exécuter de très grosses requêtes SQL sur de très gros volumes de données combinant des jointures, des aggrégats etc…

Ces requêtes sont très consommatrices de ressources et peuvent ralentir votre base de données pendant un petit bout de temps.

Pour pallier à ce problème, Oracle dispose d’une fonctionnalité qui s’appelle les vues matérialisées. Ces objets vont permettre de prendre les résultats d’une requête et d’en créer une table pour pouvoir par la suite juste consulter la table et non plus calculer les résultats.

Les plus fins d’entre vous se demanderont comment ça se passe lorsque les données sont mises à jour sur une des tables concernées. Oracle a tout prévu pour ça et propose plusieurs rafraichissement de votre vue matérialisée.

Cet article couvrira seulement le côté « Tuning » des vues matérialisées mais ne couvrira pas entièrement tout sur les vues matérialisées. Pour ce dernier, la doc officielle Oracle est très bien faite ;)

Création d’une vue matérialisée

Tout d’abord un petit rappel, nous allons voir comment créer une vue matérialisée.  Ceci se passe grâce à la DDL CREATE MATERIALIZED VIEW avec la syntaxe ci-contre :

(Source : Oracle.com)

Voici un exemple très simple de création d’une vue matérialisée qui ferait la jointure entre la table Employees et Departments

CREATE MATERIALIZED VIEW hr.mymv AS
SELECT employee_id, first_name, last_name, department_name
FROM employees e
JOIN departments d on (e.department_id=d.department_id);

La clause QUERY REWRITE

La clause QUERY REWRITE est sans aucun doute le plus gros avantage des vues matérialisées. Cette petite clause qui va s’ajoute dans notre DDL de création de vue matérialisée va nous permettre d’autoriser Oracle à s’appuyer le plus possible sur nos VMs pour exécuter nos requêtes SQL.

Késako ? Vous avez rien compris à ce que je voulais dire ? Voici un exemple pour mieux comprendre.

Tout d’abord, nous allons observer le plan d’exécution de notre requête qui a servi à faire notre vue matérialisée :

Tout va bien, l’optimizer fait la jointure et la requête a un coût de 6 . Maintenant, nous allons supprimer notre ancienne vue matérialisée et la recréer en prenant soin de positionner le paramètre QUERY REWRITE à ENABLE.

DROP MATERIALIZED VIEW hr.myMV;
CREATE MATERIALIZED VIEW hr.myMV
ENABLE QUERY REWRITE
AS
SELECT employee_id, first_name, last_name, department_name
FROM hr.employees e
JOIN hr.departments d on (e.department_id=d.department_id);

Puis on re-regarde le plan d’exécution de notre requête :

Surprise ! On voit que notre requête ne recalcule plus la jointure mais va carrément consulter notre vue matérialisée de façon complètement transparente. Ceci a fait diviser le coût par 2 pour atteindre un coût de 3.

Encore mieux, si on regarde le plan d’exécution de cette requête :

SELECT e.employee_id
FROM hr.employees e
JOIN hr.departments d on (e.department_id=d.department_id)
ORDER BY d.department_name;

On voit que l’Optimizer vient faire un GROUP BY sur les résultats de notre vue matérialisée sans recalculer tout.

Pas mal non ?

Quand faire des vues matérialisées ? Quelles précautions prendre ?

Chacun a « son seuil » pour créer des vues matérialisées. Personnellement, je le fais très souvent. Dès qu’un ordre SQL est très consommateur de ressources et revient relativement souvent, je positionne une vue matérialisée avec la clause QUERY REWRITE.

Certains DBAs déconseillent de trop créer de vues matérialisées sur une table, entraînant des pertes de performances lors des COMMIT car il doit rafraîchir les vues matérialisées.

Une dernière indication est à prendre en compte, lorsque vous faites un nombre conséquent de DML ou une modification d’un nombre conséquent de lignes, il est parfois plus rapide de reconstruire complètement sa vue matérialisée que de faire du FAST REFRESH.

Certains d’entre vous doivent se dire que les vues matérialisées peuvent consommer beaucoup d’espace disque. Oui c’est vrai, mais à l’heure actuelle, quand on voit le coût du stockage, ça ne pose pas tellement de problèmes.

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 !

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.