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.

Après avoir installé votre système Linux et que vous l’avez préparé pour accueillir votre base de données, vous devez installer Oracle.

Vous avez deux façons d’installer Oracle : L’installation graphique et l’installation silencieuse (sans interface graphique, juste avec la ligne de commande). Ici, nous verrons l’installation graphique mais vous retrouverez comment installer votre base de données sans interface graphique dans cet article.

Téléchargement de l’installeur

Avant toute chose, il faut télécharger l’archive qui vous permettra d’installer votre base de données. Pour ceci, allez sur la page de téléchargement de Oracle.com.

Télécharger les Disk1 et Disk2 de la base de données correspondant à votre architecture de processeur. Pour cet article, nous utiliserons l’architecture Linux x86.

Une fois téléchargées, placez les deux archives zip dans le dossier /tmp de votre serveur.

Décompression des archives

Avertissement : A partir de maintenant, toutes les actions sont faites sous l’utilisateur Oracle

Placez-vous dans le dossier /tmp

cd /tmp

Puis décompressez les deux archives

unzip linux_11gR2_database_1of2.zip

unzip linux_11gR2_database_2of2.zip

Un dossier database a été créé dans le dossier /tmp où sont situés tous les fichiers extraits des deux zips.

Lancement de l’installeur

Note : Les actions sont toujours réalisées avec l’utilisateur Oracle

A partir de maintenant, vous devez vous logger avec l’utilisateur Oracle sur votre serveur en physique et non en SSH.

Avertissement : Loggez-vous bien avec l’utilisateur Oracle et non l’utilisateur root sinon rien ne va marcher.

Vous arrivez sur un écran de ce type :

Un peu rudimentaire mais ça fait largement l’affaire. Vous avez deux éléments : une horloge et un terminal. Toutes les commandes ci-dessous seront à rentrer dans le terminal.

Pour lancer l’installeur, il suffit d’exécuter le script runInstaller

cd /tmp/database

./runInstaller

L’Universal Installer fait quelques vérifications de pré-requis (Espace temporaire, SWAP, et nombre de couleur du moniteur) puis démarre :

L’écran d’accueil vous demande d’entrer votre e-mail et votre mot de passe de support Oracle.

Si vous n’en avez pas, cliquez sur Next puis sur Yes au message d’avertissement.

A l’écran suivant, 3 options vous sont proposées :

• Création et configuration d’une base
• Installation seulement du logiciel de la base de données
• Mise à jour d’une base de données

Vous vous demandez sûrement qu’elle est la différence entre la première et la deuxième option. Avec la première, vous allez créer tous les fichiers nécessaires à faire fonctionner une base de données Oracle et vous allez en créer une et la configurer par la suite. Avec la deuxième option, vous allez seulement créer les fichiers de base puis vous allez devoir créer votre base de données tout seul par la suite.

Note : Hé oui, vous l’avez deviné, il peut avoir plusieurs base de données sur un serveur Oracle.

Nous choisissons la première option et on clique sur Next.

L’installeur nous demande si la base de données sera installé sur un serveur ou sur une station de travail. Nous choisissons « Server Class » et nous continuons.

La base de données sera t-elle toute seule ou sera t-elle un noeud d’un cluster ? Nous n’avons pas installé de Cluster donc on choisit Single Instance. Comme d’habitude, on clique sur Next

On nous demande de choisir entre une installation basique ou complète. Pour ne pas compliquer les choses, nous allons choisir l’installation basique.

Voici la seule page de configuration technique que vous pourrez avoir dans cette installation. Voici les explications de tout ce qu’on peut vous demander :

Oracle Base : Répertoire de base où se trouveront tous les fichiers de votre logiciel Oracle.

Software Location : Répertoire de base de votre base de données où se trouveront tous les fichiers spécifiques à la base de données que vous venez de créer

Storage Type : Type de stockage. Peut-être le système de fichier ou une instance ASM. Ce dernier est un logiciel Oracle qui permet de gérer complètement votre stockage. Ici, nous choisirons FileSystem

Database File location : Répertoire où se trouveront tous les fichiers de données de vos bases de données. Les fichiers de données, comme son nom l’indique, contiennent toutes les données de vos bases.

Database Edition : Version de votre base de données. L’édition Enterprise est la plus aboutie mais c’est celle qui coûte la plus chère. Nous allons garder la version Enterprise pour cette installation.

OSDBA group : Tous les users qui seront dans ce groupe UNIX pourront se connecter et administrer de A à Z vos base de données.

Global database name : Nom que vous allez donner à votre base de données que vous êtes en train de configurer.

Administrative password : Mot de passe qui sera attribué à tous les utilisateurs créés lors de l’installation (sysman, sys, dbsnmp etc…)

Une fois remplis, cliquez sur Next

Cette étape vérifie que tout a été installé. Vérifiez qu’il n’y a aucun problème puis cliquez sur « Next ».

Il arrive qu’il y ait des bugs de vérification de Swap et de mémoire physique dans les machines virtuelles comme sur notre capture d’écran ci-dessus. Dans ce cas, cliquez sur Ignore All puis sur Next.

Un dernier écran vous fait un bilan des actions que l’installeur va faire. Jetez un coup d’oeil rapide puis une fois que vous êtes sûr que tout est bon, cliquez sur Finish.

Vous avez le temps de vous prendre un bon café le temps que votre base de données s’installe.

A la fin de l’installation, un écran vous donne quelques informations sur votre toute nouvelle base de données. Notez dans un coin ceux-ci puis cliquez sur OK.

Une dernière fenêtre vous demande d’exécuter deux scripts en tant que root. Pour ceci, ouvrez un nouveau terminal et rentrez ces commandes :

su

(rentrez votre mot de passe) puis Entrée

sh /app/oraInventory/orainstRoot.sh

sh /app/oracle/product/11.2.0/dbhome_1/root.sh

Une fois exécutés, cliquez sur Ok dans notre fenêtre et une nouvelle fenêtre nous informant que l’installation s’est bien passée apparaît. Fermez la en cliquant sur Close

Vous en avez jamais eu marre d’installer Oracle avec le lourd Universal Installer en Java ? Ou alors vous voulez installer Oracle sur votre serveur mais vous ne voulez pas utiliser X ? Le silent mode est donc fait pour vous.

Le mode d’installation silencieux utilise des fichiers de réponses (Response files dans son appellation original) qui permet de spécifier toutes les informations nécessaires.

Créer votre response file

Un response file est un fichier texte qui porte par défaut l’extension .rsp . Vous pouvez en créer un vous-même avec toutes les informations que vous voulez ou en générer un à la fin d’une installation graphique de Oracle.

Voici un exemple de response file que j’utilise pour une installation d’Oracle Database toute simple : Le télécharger . Vous pouvez vous en inspirez et changer les valeurs pour que ça colle à votre installation.

L’installation en silent mode

L’installation en silent mode est très simple. Après avoir dézippé les deux archives d’installation que vous pourrez télécharger en cliquant ici , vous vous positionnez dans le répertoire créé

unzip linux_11gR2_database_1of2.zip

unzip linux_11gR2_database_2of2.zip

cd database

Vous devez définir la variable DISTRIB avant de commencer

export DISTRIB=`pwd`

Puis vous lancer l’Universal Installer avec quelques options supplémentaires

./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -responseFile /chemin/vers/responsefile

L’installation durera une petite dizaine de minute.

Par la suite, il ne vous restera plus qu’à exécuter les classiques deux scripts en tant que root comme indiqué lors de l’installation. Facile non ?

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.