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.

Introduction

Votre base tombe, vous devez la restaurer. Gros coup de pression, l’adrénaline monte, et là on se dit « Mais pourquoi il n’existe pas un logiciel qui s’occupe de restaurer la base tout seul ? » .

Désormais, avec Oracle 11G, c’est chose faîte ! La dernière version d’Oracle Database intègre avec un assistant appelé DRA : Data Recovery Advisor. En trois commandes RMAN, il se charge de restaurer votre base de données avec les sauvegardes RMAN qu’il a sous la main.

Utilisons DRA

Imaginons la situation où vous perdez un datafile et vous voulez restaurer ce datafile perdu.

Supprimons d’abord un datafile :

$ rm /app/oracle/oradata/orcl/users01.dbf

Ensuite, on démarre notre base et hop l’erreur :

$ $ORACLE_HOME/bin/sqlplus / as sysdba

SQL> STARTUP;

ORACLE instance started.

Total System Global Area  422670336 bytes
Fixed Size                  1336960 bytes
Variable Size             318769536 bytes
Database Buffers           96468992 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’

Qu’à cela ne tienne, nous allons démarrer RMAN et exécuter DRA :

$ $ORACLE_HOME/bin/rman target /

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
———- ——– ——— ————- ——-
142        HIGH     OPEN      16-OCT-10     One or more non-system datafiles are missing

RMAN> advise failure;

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /app/oracle/oradata/orcl/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
—— ——————
1      Restore and recover datafile 4
Strategy: The repair includes complete media recovery with no data loss
Repair script: /app/oracle/diag/rdbms/orcl/orcl/hm/reco_3402931289.hm

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /app/oracle/diag/rdbms/orcl/orcl/hm/reco_3402931289.hm

contents of repair script:
# restore and recover datafile
restore datafile 4;
recover datafile 4;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 16-OCT-10
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00004 to /app/oracle/oradata/orcl/users01.dbf
channel ORA_DISK_1: reading from backup piece /app/oracle/flash_recovery_area/ORCL/backupset/2010_10_03/o1_mf_nnndf_TAG20101003T175944_6bkb3qwm_.bkp
channel ORA_DISK_1: piece handle=/app/oracle/flash_recovery_area/ORCL/backupset/2010_10_03/o1_mf_nnndf_TAG20101003T175944_6bkb3qwm_.bkp tag=TAG20101003T175944
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 16-OCT-10

Starting recover at 16-OCT-10
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 2 is already on disk as file /app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_2_6bmlxron_.arc
archived log for thread 1 with sequence 1 is already on disk as file /app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_1_6bndm4h7_.arc
archived log for thread 1 with sequence 2 is already on disk as file /app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_2_6bnfohvy_.arc
archived log for thread 1 with sequence 1 is already on disk as file /app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_05/o1_mf_1_1_6bozlwfs_.arc
archived log file name=/app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_2_6bmlxron_.arc thread=1 sequence=2
archived log file name=/app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_1_6bndm4h7_.arc thread=1 sequence=1
archived log file name=/app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_04/o1_mf_1_2_6bnfohvy_.arc thread=1 sequence=2
archived log file name=/app/oracle/flash_recovery_area/ORCL/archivelog/2010_10_05/o1_mf_1_1_6bozlwfs_.arc thread=1 sequence=1
media recovery complete, elapsed time: 00:00:06
Finished recover at 16-OCT-10
repair failure complete

Do you want to open the database (enter YES or NO)?

Vous devez entrez YES si vous souhaitez réouvrir la nase. Et voilà, il nous réouvert notre base de données et tout marche bien. Tout ça en seulement trois commandes. Magique non ?

Détail des trois commandes

List Failure

Cette commande permet de voir toutes les erreurs de votre base, de voir pourquoi celle-ci ne démarre pas et de lister tous les problèmes.

DRA va s’appuyer sur ADR (Automatic Diagnostic Repository) pour découvrir les erreurs dans votre base de données.

Advise Failure

Advise se charge de créer un script RMAN qui va, normalement, restaurer votre base de données. A la suite de cette commande, Oracle vous indiquera où se situe le script généré pour que vous vérifiez le contenu du script.

Dans l’exemple précédent, voici le moment où il indique l’endroit du script RMAN généré :

Repair script: /app/oracle/diag/rdbms/orcl/orcl/hm/reco_3402931289.hm

Repair Failure

Repair est l’ultime étape, celle qui va exécuter le script RMAN généré par Advise. Nous préférons vous prévenir qu’il est quand même plus sûr de vérifier ce que RMAN nous as généré comme script. Il est même quasiment indispensable de le vérifier. Si DRA vous génère de mauvaises commandes, ils risquent de vous mettre encore plus dans le pétrin et d’allonger significativement le downtime.

C’est d’ailleurs dans ce but que RMAN vous demande si vous êtes sûr d’exécuter les commandes générés par Advise avant de lancer le traitement.

Y a t’il un moment où DRA ne fonctionne pas ?

Il y a quelques cas où DRA ne fonctionne pas.

Par exemple, lorsque vous ne disposez pas de catalogue RMAN et que vous avez perdu vos controlfile, DRA sera dans l’impossibilité de vous dépanner car il ne trouvera pas les backups ni la base de données etc…

Sinon, DRA ne fonctionne pas dans les environnements RAC.

Voilà c’est fait ! Après un mois intensif de bachotage, je suis Oracle Certified Associate (OCA) Database Administrator 11G. Durant mon mois de préparation, j’aurais aimé trouver un site avec plusieurs articles qui couvrait en détail tous les aspects techniques de la certification OCA et je n’ai rien trouvé !

C’est pour ça que je veux lancer cette série d’articles qui serviront aux futurs candidats à cette certification. Et je compte bien commencer cette série d’article par une présentation de cette certification en détail.

Est-ce que je dois faire quelque chose avant de passer l’OCA ?

Alors avant de passer cette certification, vous devez passer une certification en rapport avec le SQL. Il y en a trois qui sont envisageables :

• 1Z0-007 – Introduction to Oracle 9i SQL
• 1Z0-051 – Oracle DB 11G : SQL Fundamentals 1
• 1Z0-047 – Oracle DB SQL Expert

Les deux premières peuvent être passées en mode non-surveillé. Ce qui implique que vous pouvez la passer chez vous, ou au travail, avec un accès aux ressources sans problème. La dernière, quant à elle, doit être forcément passée dans un centre d’examen PearsonVue.

Comment je prépare ma certification ?

Pour préparer cette certification, je vous conseille le bouquin officiel d’Oracle qui couvre ce cursus. Vous pouvez vous le procurer en cliquant ici (Amazon). Dans le livre, vous pourrez trouver un test blanc de 70 questions et vous avez un code pour avoir un deuxième test blanc sur Internet.

J’ai utilisé ce livre pendant un mois, à raison d’environ 2-3 chapitres par jour.

Autrement, vous pourrez bien sûr l’ensemble des cours que je ferai sur mon blog.

Combien coûte t-elle ?

Le passage de la certification coûte 140€. Si vous la ratez, vous devrez repayer la même somme.

Quel est le score à avoir ?

A l’heure actuelle, vous devez avoir 66% de bonnes réponses sur un total de 70 questions. Soit, après un vite calcul, 42 bonnes réponses. Je dis à l’heure actuelle, car les pools de questions sont renouvelés assez régulièrement et le score change d’un pool à l’autre.

Il est important de savoir qu’en cas de réponses multiples, il n’y a pas de demi-point. Si vous avez les 2 bonnes réponses, vous avez 1 point. Si vous avez choisi une bonne réponse et une mauvaise, vous avez 0 point.

Est-elle vraiment difficile ?

Réponse courte : relativement. Réponse longue : C’est toujours la même rengaine, si vous apprenez bien votre bouquin, que vous notez tous les points clés, que vous révisez bien tous les encadrés « Exam Watch » et que vous comprenez très bien tous les principes et la logique, vous l’aurez haut la main.

Il est important d’avoir de l’expérience de terrain avant d’attaquer votre certification. Déjà, parce que passer une certification sans expérience, ça n’a pas vraiment d’intérêt et deuxièmement parce que vous risquez d’avoir à assimiler trop d’informations et de manquer de recul sur certaines questions.

Est-elle vraiment « reconnue » ?

La 1Z0-052, couramment appelée OCA, est une certification « Premier pas » dans la vie d’un DBA. Elle aborde un panel de sujet assez large sans aller vraiment dans les détails. Cependant, elle reste très bien reconnue dans les entreprises pour des DBAs Juniors. Lorsque vous commencez à avoir de l’expérience, il est fortement conseillé de passer à l’OCP qui est beaucoup plus technique et pointilleuse.

Et pour toutes les autres questions ?

Pour toutes les autres questions, vous pouvez allez voir cet article (Tout ce qu’il faut savoir pour se préparer à une certification Oracle) qui retrace mon expérience sur les passages de certifications.

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

Introduction

Maintenant que votre système Linux est bien installé, vous devez le préparer pour accueillir votre bijou de base de données.

C’est partit !

Téléchargement de Oracle

Tous les produits Oracle sont disponibles gratuitement sur leurs sites web Oracle.com. Deux versions pour Linux existent : une pour processeur 32 bits et une autre pour processeur 64 bits. Nous choisirons la version 32 bits dans le cadre de cet article.

Pour plus de facilités, mettez les deux zips d’installation dans le dossier /tmp de votre serveur.

Création de l’utilisateur Oracle et des groupes d’administration

Tout d’abord, il va vous falloir créer deux groupes : dba et oinstall. Les membres du groupe dba auront tous les privilèges sur la base de données tandis que les membres du groupe oinstall auront tous les privilèges sur les fichiers physiques de la base de données.

groupadd oinstall

groupadd dba

Une fois ceci fait, il vous faudra créer votre utilisateur oracle qui exécutera la base de données. Ensuite, on lui choisit un mot de passe.

useradd -m oracle

passwd oracle

Puis on place l’utilisateur oracle dans les deux groupes car il devra modifier les fichiers systèmes de votre base Oracle mais aussi pourra administrer la base de données.

usermod -g oinstall -G dba oracle

Création des répertoires de base

Pour l’installation, nous allons avoir besoin de créer les répertoires de base.

mkdir -p /app/oracle

Puis nous positionnons les permissions correctes dessus :

chown -R oracle:oinstall /app

chmod -R 0775 /app

Installation des packages nécessaires

Une base de données oracle nécessite quelques packages systèmes pour fonctionner. Pour les installer, insérer le DVD d’installation de Oracle Enterprise Linux 5 et montez-le dans votre système de fichiers :

mount /dev/cdrom /mnt

Ensuite, positionnez-vous dans le répertoire Server du lecteur DVD. Vous y trouverez tous les RPMs du DVD. Lancez ces commandes :

cd /mnt/Server

rpm -Uvh gcc-4.1.2-46.el5.i386.rpm libgomp-4.4.0-6.el5.i386.rpm elfutils-libelf-devel-static-0.137-3.el5.i386.rpm elfutils-libelf-devel-0.137-3.el5.i386.rpm glibc-devel-2.5-42.i386.rpm glibc-headers-2.5-42.i386.rpm gcc-c++-4.1.2-46.el5.i386.rpm libaio-devel-0.3.106-3.2.i386.rpm libstdc++-devel-4.1.2-46.el5.i386.rpm sysstat-7.0.2-3.el5.i386.rpm unixODBC-devel-2.2.11-7.1.i386.rpm unixODBC-2.2.11-7.1.i386.rpm kernel-headers-2.6.18-164.el5.i386.rpm

Note : Ces packages sont valables pour la version i386 de OEL 5. Si vous avez choisis la version 64 bits, il faudra remplacer i386 par x86-64 dans le nom des packages le nécessitant.

Modification de quelques paramètres

Certains paramètres dans le kernel sont bien trop restrictifs pour qu’une base de données Oracle puisse fonctionner correctement avec un grand nombre de connexions simultanées. Nous allons éditer les paramètres du kernel et les charger à chaud :

echo ‘fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
# semaphores: semmsl, semmns, semopm, semmni
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=1048586′ >> /etc/sysctl.conf

/sbin/sysctl -p

Le nombre processus pouvant être lancés et de fichiers pouvant être ouverts par l’utilisateur Oracle simultanément sont trop petits pour fonctionner correctement à plein régime. Nous allons changer la limite dans le fichier /etc/security/limits.conf

echo ‘oracle              soft    nproc   2047
oracle              hard    nproc   16384
oracle              soft    nofile  1024
oracle              hard    nofile  65536′ >> /etc/security/limits.conf

Puis rajouter une ligne au fichier de configuration de pam.d :

echo ‘session    required     pam_limits.so’ >> /etc/pam.d/login

Enfin, il vous faudra lever les protections sur le nombre de processus lancés à chaque login de l’utilisateur Oracle. Pour ceci, nous allons éditer le fichier /etc/profile

echo ‘if [ \$USER = "oracle" ]; then
if [ \$SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
umask 022
fi’ >> /etc/profile

Conclusion

C’est la fin de la configuration de votre serveur. Passons à l’installation de la base de données Oracle en cliquant sur la flêche verte.

Les controls files sont des éléments très importants pour une base de données Oracle. Si vous perdez vos controls files lors d’une panne de disque dur par exemple, vous risquez d’être fortement embêté pour remettre sur pied votre base de données dans un délai pardonnable.

C’est pourquoi, Oracle et tous les DBAs vous le diront : il est très important de multiplexer vos fichiers de contrôle. Voici comment le faire.

Comment multiplexer mes control files ?

Avant de commencer cet article, il est important de savoir que l’annotation [SID] est censé remplacer le SID que vous avez donné à votre instance. Il faut donc le remplacer à chaque commande ci-dessous.

Première étape : Changer les paramètres de votre SPFILE puis arrêtez votre base de données.

$ORACLE_HOME/bin/sqlplus / « as sysdba »

SQL > ALTER SYSTEM SET control_files = ‘/u01/app/oracle/oradata/[SID]/control01.ctl’, ‘/disk2/[SID]/control02.ctl’ SCOPE=SPFILE;

SQL > SHUTDOWN IMMEDIATE;

Ensuite, copiez votre fichier de contrôle actuel vers votre deuxième disque dur (pour nous c’est /disk2)

cp /u01/app/oracle/oradata/[SID]/control01.ctl /disk2/[SID]/controlfiles/control02.ctl

Puis redémarrez votre base de données.

$ORACLE_HOME/bin/sqlplus / « as sysdba »

SQL > STARTUP

Voilà vos fichiers de données sont multiplexés sur plusieurs disques durs pour être armé contre les pannes de disques durs.

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 ?

Exemple de page APEX

Introduction

Oracle APEX est un portail web rattachée à la base de donnée Oracle qui permet de développer des applications web en un temps record.

Pour les initiés aux technologies Oracle, ça pourrait leur faire penser à un forms/reports en version web.

APEX est installable très facilement avec une base de donnée Oracle. Nous allons voir ici comment l’installer sur la version 11GR2 de Oracle.

Installation de Oracle APEX sur Oracle Database 11GR2

Pour installer Oracle APEX, rien de bien compliqué.

Connectez-vous en SYSDBA à votre base de données.

cd $ORACLE_HOME

bin/sqlplus / « as sysdba »

A l’invite de commande, lancez le script apxconf.sql

@ ?apex/apxconf.sql

Entrez un mot de passe pour l’utilisateur admin

Entrez le port sur lequel vous voulez que le serveur web tourne (par défaut 8080)

Débloquer l’utilisateur ANONYMOUS

Pour pouvoir vous connecter, il vous suffira de débloquer l’utilisateur ANONYMOUS à l’aide de la commande :

ALTER USER anonymous ACCOUNT UNLOCK ;

Créer un workspace

Maintenant que tout est bien installé et prêt, il est temps de vous connecter à l’administration d’APEX. Pour ceci, ouvrez un navigateur web et allez à l’adresse http://server-ip:port-choisit/apex/apex_admin. Cette page apparaît :

Ecran de login de l'administration APEX

Rentrez le login Admin et votre mot de passe défini lors de l’installation. Vous arrivez sur cette page :

Ecran d'accueil Administration APEX

Cliquez sur la flêche à côté de l’icône Manage Workspaces => Manage Workspaces => Create Workspace . Vous arrivez sur cet écran.

Créer Workspace - Etape 1

Donnez un nom à votre workspace et un commentaire.

Créer un Workspace - Etape 2

Oracle vous demande le schéma auquel est rattaché le workspace. Vous avez le choix entre utiliser un schéma existant ou en créer un nouveau.

Créer un workspace - Etape 3

Donner l’identité de l’utilisateur qui pourra administrer complètement ce workspace. Cet utilisateur est complètement indépendant d’un utilisateur Oracle ou de votre utilisateur Admin précédemment créé.

Créer un workspace - Etape 4

Comme à son habitude, Oracle vous fait un briefing de ce que vous allez créer. Cliquez sur Create et votre Workspace sera enfin créé !

Vous connecter à votre Workspace

Enfin, pour finir, voici comment vous connecter à votre workspace. En haut à droite de votre écran, cliquez sur Logout. Une page avec 3 champs apparaît :

Ecran login de votre Workspace

Il ne vous reste plus qu’à rentrer le nom de votre workspace, votre login et votre mot de passe créé dans la partie précédente et vous voici prêt à créer un projet web avec Oracle APEX !

Note : Vous retrouverez cette interface sans forcément passer par l’admin en allant à l’url http://serveur-url:port-choisit/apex

Conclusion

Oracle APEX est très facile à installer et sa console d’administration web puissante vous permettra d’avoir un très rapide aperçu de tous les workspaces et de les gérer de façon très efficace.