15 février 2009
7
15
/02
/février
/2009
16:43
Bonjour;
Aujourd'hui, je vais commencer à parler de la sécurité des données. Non pas au sens cryptage ou confidentialité, mais plutôt dans une optique de ne pas perdre de données, ou d'éviter une interruption de service suite à un crash de serveur par exemple.
Tout dépend bien evidemment des données que l'on veut protéger, et également du budget alloué pour la mise en plus en place d'une telle architecture. Vous savez certainement qu'Oracle "offre" une solution appelée DATA GUARD.
Rapidement en quoi consiste cette solution ?
Il s'agit de récuperer les archives logs de la base principales (appelée également base primaire), et de les rejouer sur une ou plusieurs base de secourds (appelées bases "standby" ou de secours).
Ces bases de secours peuvent être sur le même serveur que la base primaire ou mieux sur un autre serveur dans un autre site.
Le petit bémol à cette architecture, est que cela implique de disposer de versions Enterprise d'ORACLE. Ce qui en terme de cout peut avoir un certain impact.
Il existe cependant des possibilités avec une version standard d'Oracle.
Afin de réaliser cette petite architecture, j'ai mis en place l'environnement suivant.
Deux machines virtuelles en XP avec sur chacune une version standard 10.2.0.3 d'Oracle installée.
Sur chacunes des machines, un listener écoutant sur le port 1521 a été crée via netca (Network Configuration Assistant)
Liens utiles (sur www.lao-dba.com) pour la compréhension de l'article:
Préparation de la base "primaire".
-1 Création d'une base (cf . article "Création d'une base manuelle")
-2 Donner le droit à un poste client de se connecter en SYS (cf. article précédent : "Connexion à une base distante")
orapwd file=E:\oracle\product\10.2.0\db_1\database\pwdDB1.ora password=oracle entries=5
-3 Passage de la base en mode Archivelog.
Contrairement aux articles précedents, je vais activer la FRA(FLASH RECOVERY AREA) en ajoutant les deux lignes suivante dans mon fichier init.ora. Je fais cela uniquement pour ne pas tomber dans la répétition. Vous avez le droit de mettre vos archives log ou vous le désirez
db_recovery_file_dest_size=5G
db_revovery_file_dest='C:\FRA'
Attention : Il faut que le fichier C:\FRA existe.
mkdir C:\FRA
Il ne reste plus qu'a ouvrir une fenêtre dos et executer les commandes suivantes.
SET ORACLE_SID=DB1
SQLPLUS /nolog
CONNECT / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP MOUNT pfile='e:\oracle\product\10.2.0\admin\DB1\pfile\init.ora';
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
Préparation de la base de secours.
-1 Création de l'arborescence.
Pour simplifier l'exemple, j'ai choisi de garder la même arborescence, mais cela n'est nécessaire.
MKDIR E:\oracle\product\10.2.0\admin
MKDIR E:\oracle\product\10.2.0\oradata
MKDIR E:\oracle\product\10.2.0\admin\DB1
MKDIR E:\oracle\product\10.2.0\oradata\DB1
MKDIR E:\oracle\product\10.2.0\admin\DB1\bdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\cdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\pfile
MKDIR E:\oracle\product\10.2.0\admin\DB1\udump
MKDIR C:\FRA
-2 Permettre au serveur de secours de se connecter à la base primaire.
Pour cela, il suffit d'ajouter les lignes suivantes dans le fichier tnsnames.ora (%ORACLE_HOME%\NETWORK\admin) en prenant soin d'indiquer le bon service name et le bon host.
DB1_SRV1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORA10-SRV1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = DB1)
)
)
-3 Création du fichier init.ora
Je vais copier le fichier init.ora de ma base primaire.
Dans le fichier, il faut uniquement modifier la ligne
db_unique_name=DB1 par db_unique_name=DB2
-4 Création et démarrage de l'instance ORACLE
oradim -new -sid DB2
SET ORACLE_SID=DB2
SQLPLUS /nolog
CONNECT / as sysdba
STARTUP NOMOUNT;
DISCONNECT;
EXIT;
Maintenant que nos environnements sont quasi prêt, il ne reste plus qu'a dupliquer la base primaire vers la base de secours. Pour effectuer cette opération, je vais utiliser RMAN. Il existe d'autres moyens dont nous reparleront peut êre un autre jour.
-1 Sauvegarde de la base primaire.
RMAN target /
run
{
backup database;
backup current controlfile for standby database;
SQL 'Alter system switch logfile';
}
-2 Clonage de la base primaire vers la base de secours.
Pour cela, il faut d'abord récuperer l'intérieur de la "FRA" (c:\FRA\) de mon serveur principal pour le copier dans la "FRA" de la base de secours. Attention à copier l'arborescence et pas uniquement les fichiers.
Une fois la copie effecutée, il ne reste plus qu' a effectuer le clonage....
SET ORACLE_SID=DB2
rman target sys/oracle@DB1_SRV1 auxiliary /
duplicate target database for standby nofilenamecheck;
Si tout se passe bien au bout d'un moment, vous devez avoir le message suivant
Finished Duplicate Db at DD-MMM-YY
Nous venons de mettre en place une base de secours. Cela était une étape nécessaire mais pas suffisante. Nous verrons dans un prochain article comment rejouer les transactions de notre base primaire sur la base de secours. Nous verrons également les limites de ce type d'architecture qui si elle n'est pas complète à le mérite d'exister et de pouvoir survivre à un crash serveur avec une durée d'indisponibilité faible.
Remarque 1 : Nous avons mis en place une seule base de secours, mais nous aurrions pu en créer plusieurs, que ce soit sur des des serveurs distants ou bien sur le même serveur que la base primaire. Dans ce cas, nous aurions du adapter la procédure (notamment pours les arboresences).
LAO.
Aujourd'hui, je vais commencer à parler de la sécurité des données. Non pas au sens cryptage ou confidentialité, mais plutôt dans une optique de ne pas perdre de données, ou d'éviter une interruption de service suite à un crash de serveur par exemple.
Tout dépend bien evidemment des données que l'on veut protéger, et également du budget alloué pour la mise en plus en place d'une telle architecture. Vous savez certainement qu'Oracle "offre" une solution appelée DATA GUARD.
Rapidement en quoi consiste cette solution ?
Il s'agit de récuperer les archives logs de la base principales (appelée également base primaire), et de les rejouer sur une ou plusieurs base de secourds (appelées bases "standby" ou de secours).
Ces bases de secours peuvent être sur le même serveur que la base primaire ou mieux sur un autre serveur dans un autre site.
Le petit bémol à cette architecture, est que cela implique de disposer de versions Enterprise d'ORACLE. Ce qui en terme de cout peut avoir un certain impact.
Il existe cependant des possibilités avec une version standard d'Oracle.
Afin de réaliser cette petite architecture, j'ai mis en place l'environnement suivant.
Deux machines virtuelles en XP avec sur chacune une version standard 10.2.0.3 d'Oracle installée.
Sur chacunes des machines, un listener écoutant sur le port 1521 a été crée via netca (Network Configuration Assistant)
Liens utiles (sur www.lao-dba.com) pour la compréhension de l'article:
- Création d'une base manuelle.
- Connexion à une base distante.
- Clonage de base.
Préparation de la base "primaire".
-1 Création d'une base (cf . article "Création d'une base manuelle")
-2 Donner le droit à un poste client de se connecter en SYS (cf. article précédent : "Connexion à une base distante")
orapwd file=E:\oracle\product\10.2.0\db_1\database\pwdDB1.ora password=oracle entries=5
-3 Passage de la base en mode Archivelog.
Contrairement aux articles précedents, je vais activer la FRA(FLASH RECOVERY AREA) en ajoutant les deux lignes suivante dans mon fichier init.ora. Je fais cela uniquement pour ne pas tomber dans la répétition. Vous avez le droit de mettre vos archives log ou vous le désirez
db_recovery_file_dest_size=5G
db_revovery_file_dest='C:\FRA'
Attention : Il faut que le fichier C:\FRA existe.
mkdir C:\FRA
Il ne reste plus qu'a ouvrir une fenêtre dos et executer les commandes suivantes.
SET ORACLE_SID=DB1
SQLPLUS /nolog
CONNECT / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP MOUNT pfile='e:\oracle\product\10.2.0\admin\DB1\pfile\init.ora';
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
Préparation de la base de secours.
-1 Création de l'arborescence.
Pour simplifier l'exemple, j'ai choisi de garder la même arborescence, mais cela n'est nécessaire.
MKDIR E:\oracle\product\10.2.0\admin
MKDIR E:\oracle\product\10.2.0\oradata
MKDIR E:\oracle\product\10.2.0\admin\DB1
MKDIR E:\oracle\product\10.2.0\oradata\DB1
MKDIR E:\oracle\product\10.2.0\admin\DB1\bdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\cdump
MKDIR E:\oracle\product\10.2.0\admin\DB1\pfile
MKDIR E:\oracle\product\10.2.0\admin\DB1\udump
MKDIR C:\FRA
-2 Permettre au serveur de secours de se connecter à la base primaire.
Pour cela, il suffit d'ajouter les lignes suivantes dans le fichier tnsnames.ora (%ORACLE_HOME%\NETWORK\admin) en prenant soin d'indiquer le bon service name et le bon host.
DB1_SRV1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORA10-SRV1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = DB1)
)
)
-3 Création du fichier init.ora
Je vais copier le fichier init.ora de ma base primaire.
Dans le fichier, il faut uniquement modifier la ligne
db_unique_name=DB1 par db_unique_name=DB2
-4 Création et démarrage de l'instance ORACLE
oradim -new -sid DB2
SET ORACLE_SID=DB2
SQLPLUS /nolog
CONNECT / as sysdba
STARTUP NOMOUNT;
DISCONNECT;
EXIT;
Maintenant que nos environnements sont quasi prêt, il ne reste plus qu'a dupliquer la base primaire vers la base de secours. Pour effectuer cette opération, je vais utiliser RMAN. Il existe d'autres moyens dont nous reparleront peut êre un autre jour.
-1 Sauvegarde de la base primaire.
RMAN target /
run
{
backup database;
backup current controlfile for standby database;
SQL 'Alter system switch logfile';
}
-2 Clonage de la base primaire vers la base de secours.
Pour cela, il faut d'abord récuperer l'intérieur de la "FRA" (c:\FRA\) de mon serveur principal pour le copier dans la "FRA" de la base de secours. Attention à copier l'arborescence et pas uniquement les fichiers.
Une fois la copie effecutée, il ne reste plus qu' a effectuer le clonage....
SET ORACLE_SID=DB2
rman target sys/oracle@DB1_SRV1 auxiliary /
duplicate target database for standby nofilenamecheck;
Si tout se passe bien au bout d'un moment, vous devez avoir le message suivant
Finished Duplicate Db at DD-MMM-YY
Nous venons de mettre en place une base de secours. Cela était une étape nécessaire mais pas suffisante. Nous verrons dans un prochain article comment rejouer les transactions de notre base primaire sur la base de secours. Nous verrons également les limites de ce type d'architecture qui si elle n'est pas complète à le mérite d'exister et de pouvoir survivre à un crash serveur avec une durée d'indisponibilité faible.
Remarque 1 : Nous avons mis en place une seule base de secours, mais nous aurrions pu en créer plusieurs, que ce soit sur des des serveurs distants ou bien sur le même serveur que la base primaire. Dans ce cas, nous aurions du adapter la procédure (notamment pours les arboresences).
LAO.
Partager cet article
