Dimanche 15 février 2009 7 15 /02 /Fév /2009 19:34
Bonsoir,

Dans l'article précédent, nous avons vu comment mettre en place une base de secours tout en utilisant une version standard d'Oracle.

Maintenant que notre base est de secours est en place voyons comment effectuer la mise à jour de notre base.

1 ère étape : Créer de l'activité transactionnel sur la base principale.


SET ORACLE_SID=DB1

SQLPLUS /nolog
CONNECT system/oracle

CREATE USER app IDENTIFIED BY app;
GRANT CONNECT, RESOURCE TO app;

CONNECT app/app

CREATE TABLE my_table (col1 NUMBER);

BEGIN
   FOR i IN 1..10000 LOOP
      INSERT INTO my_table VALUES (i);
   END LOOP;
   COMMIT;
END;
/




Afin de s'assurer que les fichiers d'archives log soient générés


CONNECT system/oracle
ALTER SYSTEM SWITCH LOGFILE;



2 ème étape : Appliquer les modifications sur la base de secours

On peut facilement vériifier dans C:\FRA\DB1\ARCHIVELOG\YYYY_MM_DD\ qu'un fichier d'archive vient d'étre fraichement crée.

Nous allons copier le fichier d'archive crée sur le serveur de secours, dans le répertoire C:\FRA\DB1\ARCHIVELOG\YYYY_MM_DD\

Puis sur le serveur de secours, dans une fenêtre dos:


SET ORALCE_SID=DB2

SQLPLUS /nolog
CONNECT / as sysdba

ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE UNTIL CANCEL;
ALTER DATABASE RECOVER CANCEL;




Et voila... le tour est joué, votre base de secours est maintenant au même niveau que votre base primaire.

REMARQUE : La base est à l'état "MOUNT" et par conséquent n'est pas accessible pour intérrogation.

On peut cependant vérifier que la mise à jour a bien été effectuée.


SQLPLUS /nolog
CONNECT / as sysdba

ALTER DATABASE OPEN;

CONNECT  app/app
SELECT COUNT(*) FROM my_table;



Remarque :  On constate, que les trois types d'opérations (CREATE USER, CREATE TABLE , INSERT) ont bien été appliquées.

Si nous voulons que notre base de secours puisse à nouveau être mise à jour, il faut la remettre en etat "MOUNT"


SQLPLUS /nolog
CONNECT / as sysdba
STARTUP FORCE MOUNT;




Remarque : Lorsque la base est ouverte, elle en fait accessible en lecture seule. Il n'est pas possible de modifier les données ou de créer de  nouveaux objets.


On voit bien ici le début des limites de ce type d'architecture. La première c'est qu'il va falloir se fabriquer un petit script pour déplacer régulièrement les archives et les appliquer sur la ou les bases de secours.

Une autre limite concerne la structure de la base. Si il me venait la bonne idée d'ajouter un tablespace, la transaction echouerait sur la base de secours.

Au final, tout n'est pas à jeter. Lorsque l'on n'a pas les budgets, cela peut quand même être utile.
  • En cas de crash, on peut limiter l'interruption de service à la durée du "recover" des archives logs manquants.
  • Dans le cas d'une opération de maintenance nécessitant l'arrêt de la base, on peut donner l'accès en lecture aux utilisateurs en attendant la remise en route du serveur principal.
  • ....
Dans un prochain article, nous étudierons le cas d'un crash de la base primaire, et comment transformer notre base de secours en base principale.

LAO.
Par LAO - Publié dans : Dataguard - Communauté : ORACLE
Ecrire un commentaire - Voir les 2 commentaires
Retour à l'accueil

Catégories

Recherche

Calendrier

Avril 2014
L M M J V S D
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
<< < > >>

Profil

  • LAO
  • My Oracle blog
  • Homme
  • 06/05/1972
  • DBA
Contact - C.G.U. - Rémunération en droits d'auteur - Signaler un abus - Articles les plus commentés