Oracle STANDBY Database

posted in Bases de données, Linux, Oracle on by

STANDBY DATABASE : CAS PRATIQUE

Préambule

Oracle permet l’utilisation de base de données dites « StandBy », copies conformes d’une base de production à un instant t et permettant, en cas de crash de la production de démarrer un plan de secours (PRA et ou PCA).
Oracle propose des produits commerciaux et parfaitement packagés pour cela, comme DataGuard, mais il est tout à fait possible de construire et d’utiliser ces bases de données StandBy sans cette option commerciale (très onéreuse), avec un tout petit peu de scripting et beaucoup de confort administratif en moins.

Cet article va présenter la création d’une base de secours de type StandBy, ses techniques d’alimentations, de surveillance et de démarrage et cas de crash de la base de Production.

Note 1: L’option commerciale Dataguard n’est valable que pour les licences Entreprise Edition, alors que les méthodes décrites dans ce post sont également valables en Standard Edition.

Note 2: Cet article s’applique à un OS de type Linux. Les exercices sont réalisés sur le serveur Linux fourni par Oracle et recommandé par Oracle pour héberger des bases de données Oracle : Oracle Linux Server , même si évidement vous pouvez l’installer sur d’autres versions de Linux ou encore sur du Windows.

Licencing

Comme d’habitude, lorsque l’on utilise des produits Oracle, il faut faire très attention aux modules que vous installez et/ou que vous utilisez afin d’être certain de rester dans le périmètre de la licence que vous avez acquise et d’éviter un redressement par Oracle dans la négative, et ce n’est parfois pas si simple. La plupart des modules « Advisors » sont interdits en Standard Edition (SE) par exemple, mais attention, vous pouvez les activer sur une Standard Edition, passant implicitement de ce fait dans une licence Entreprise (EE)… C’est « limite » mais légal malheureusement.

Il faut savoir plusieurs choses à ce sujet :

Une base StandBy, par définition, s’installe généralement sur un serveur différent de celui de la production. Si la base Standby n’est jamais utilisée (sauf en cas de crash et de déclenchement de votre plan de secours) Oracle va tout de même vous facturer l’utilisation du moteur et de la version de la database (Enterprise ou Standard) en fonction de celle présente en production, comme si vous utilisiez une base primaire.

Une base StandBy sur un serveur installé dans le même Datacenter que le serveur de production, sur le même VLAN de celui du serveur production (éventuellement dans le même cluster d’hyperviseurs) est GRATUITE, cela mérite d’être souligné tellement le mot gratuit est généralement incompatible avec Oracle. Cette option permet de sécuriser une base de données en cas de crash du moteur ou de
son serveur hôte sur un site de production. Attention, si la base Standby est distante ou ne respecte pas strictement le périmètre décris ici, elle devient payante, au même coût que la Production.

Notez que même si un serveur hébergeant une base Standby est éteint électriquement (ou une VM power OFF) Oracle considère qu’il est en ligne et vous fera payer la licence, hors de question par exemple de procéder à une synchronisation bloc au niveau stockage avec un serveur éteint par exemple.
La virtualisation des moteurs Oracle est soumise à des règles commerciales hyper strictes de la part d’Oracle.

Globalement, si votre serveur est installé sur un cluster d’hyperviseurs VMWare (le meilleur choix technique mais le pire choix d’un point de vue commercial car Oracle ne s’entend pas commercialement avec VMWare) alors vous devez absolument respecter les règles suivantes:

  • Les réseaux VMotion du cluster ne doivent pouvoir communiquer avec aucun autre réseau d’hyperviseur et doit utiliser un VLAN dédié uniquement à ce cluster (vous devrez le prouver)
  • Si un serveur de bases de données Oracle est installé sur un cluster, vous ne pouvez pas installer des VMs qui contiennent d’autres applicatifs que des moteurs Oracle, et dans le respect de votre licence (EE ou SE, généralement en mode licence serveur au sens de l’hyperviseur).
  • Le stockage utilisé pour les VMs des serveurs Oracle par ce cluster ne doit pas être accessible par un autre serveur qui n’est pas un hyperviseur de ce cluster (LUN masking).
  • Dans le cadre de licensing au niveau serveur (donc au niveau de vos hyperviseurs physiques, il n’est généralement pas possible de faire autrement), tous les processeurs sont comptabilisés, même s’ils sont désactivés dans le BIOS et que les hyperviseurs ne peuvent pas s’en servir (Hard Patitioning).
  • Un hyperviseur ne peut pas avoir plus de deux processeurs au sens socket, vous n’avez pas de restriction en revanche sur le nombre de cœurs disponibles et l’hyperthreading est (heureusement) autorisé (pour le moment, en EE et en SE2)

Problématique de Oracle Database en mode « hébergé »

La difficulté d’utiliser la virtualisation avec les bases de données Oracle ne s’arrête pas là. Si vous décidez d’utiliser des VMs Oracle, quel que soit l’hyperviseur (VMWare, Xen, ProxMox / KVM, etc) et que vous décidez d’utiliser cette technologie chez un hébergeur, dans un Datacenter par définition qui ne vous appartient pas, alors :

  • Vous n’avez pas le droit d’utiliser un cluster Mutualisé de l’hébergeur sur lesquelles tournent des VMs Oracle avec vos propres licences.
  • Si vous désirez que l’hébergeur vous apporte une licence adéquate, il ne peut le faire que dans le périmètre « On Behalf« , c’est à dire que la licence appartient légalement à l’hébergeur et vous est mise à disposition de façon exclusive à travers un contrat tripartite entre Oracle, vous et l’hébergeur. Cette licence est limitée à l’utilisation de VM contenant des moteurs Oracle : Vous n’avez pas le droit d’y héberger d’autres VMs contenant des produits, commerciaux ou non, non Oracle Database.

En gros, en mode hébergé, optez soit pour une solution avec des machines physiques redondantes et des licences « classiques » de type Processeur ou Utilisateur nommé, que les serveurs vous appartiennent ou pas ne sera pas un problème.

Si vous désirez utiliser de la VM, optez pour un cluster d’hyperviseurs dédié (de préférence d’un point de vue licence OLV / Oracle Linux Virtualisation à base de KVM, ou OLK) à licencier au processeur, sinon, les risques de redressement sont énormes. Notez que si le cluser vous appartient (mode Housing) vous n’êtes pas obligé de demander les licences à l’hébergeur et vous pouvez vous même les apporter : Si cela vous apporte plus de liberté car l’accès aux bases n’est pas limité à votre usage stricte, elles seront par contre bien plus onéreuses.

Prérequis du Filesystem

Le filesystem de votre moteur Oracle hébergeant la Standby doit être strictement identique à celui de la base primaire pour ce qui concerne les fichiers de la base de données, le moteur et le reste de l’OS peuvent éventuellement être installés à des endroits différents (En fait ce n’est pas tout à fait vrai, vous pouvez très bien les placer ailleurs, mais pour simplifier, cet article ne traitera que de ce cas).

Cela concerne les emplacements suivants:

  • Fichiers de contrôle
  • Redologs
  • Archivelogs
  • Datafiles
  • Flash recovery area (FRA)

Le principe général de l’alimentation d’une Standby par une Primary est le transport d’archivelogs depuis la PRIMARY et son application sur la STANDBY. Si les chemins sont différents, la création d’un fichier de données DBF renseigné dans une archive log peut par exemple échouer. Il faut alors spécifier au processus une sorte de « translation » de filesystem pour lui indiquer à quelle source sur la Primary correspond une source sur la Standby, mais pour simplifier, cet article considère que les filesystems sont symétriques.

Prérequis réseau

Communication SSH inter serveurs

Echange de clés RSA en SSH

Afin de pouvoir transporter les archives log de la Primary vers la Standby, le moteur de la Primary doit pouvoir se connecter au moteur de la Standby sans authentification. Le plus pratique est d’utiliser le user « oracle » sur les deux serveurs et de procéder à un échange de clés RSA SSH pour automatiser l’authentification.
Rappel du principe : Sur le serveur Primaire, générer une clé SSH de type RSA, copier la clé publique sur le serveur Standby. Faire ensuite l’opération inverse depuis le serveur Standby vers le serveur Primaire :

a) Sur le serveur Standby:

root@serveur-standby : / > su - oracle
oracle@serveur-standby : / > cd
oracle@serveur-standby : ~ > ssh-keygen -t RSA
oracle@serveur-primary : ~ > scp .ssh/id_rsa.pub root@serveur-primary:/home/oracle/.ssh/STANDBY.pub

b) Sur le serveur Primary:

oracle@serveur-primary : / > cd
oracle@serveur-primary : ~ > ssh-keygen -t RSA
oracle@serveur-primary : ~ > scp ./ssh/id_rsa.pub root@serveur-standby:/home/oracle/.ssh/PRIMARY.pub
oracle@serveur-primary : ~ > cat ./ssh/STANDBY.pub >> ./ssh/authorize_keys

c) Sur le serveur Standby:

root@serveur-standby : / > su - oracle
oracle@serveur-standby : / > cd
oracle@serveur-standby : ~ > cat ./ssh/PRIMARY.pub >> ./ssh/authorize_keys

Les deux users « oracle » des deux serveurs peuvent maintenant communiquer en SSH entre eux sans authentification par password, ce qui permettra de transporter les archives log automatiquement pour l’alimentation de la base Standby par la base Primary.

Définition des noms TNS

Les deux moteurs Oracle des deux serveurs vont communiquer entre eux, notamment pour créer la database Standby et pour procéder à sa première alimentation depuis la Primary : Il faut donc, sur les deux serveurs, configurer la couche TNS à l’identique en terme d’identifiants de noms d’instances (SID).

Exemple sur le serveur Primary :

oracle@serveur-primary : ~ > cat $ORACLE_HOME/network/ad
DB1PRIMARY =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT =
      (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1PRIMARY)
   )
)
DB1SECONDARY =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.2)(PORT
      (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1SECONDARY)
   )
)

Exemple sur le serveur Standby:

oracle@serveur-standby : ~ > cat $ORACLE_HOME/network/ad
DB1PRIMARY =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT
      (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1PRIMARY)
   )
)
DB1SECONDARY =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.2)(PORT
      (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = DB1SECONDARY)
   )
)

Mots de passe des instances

Afin que la première génération de la base Standby à partir de la Primary puisse se faire, nous allons fixer sur la base Standby exactement le même mot de passe pour un user de type « sysdba« , nous allons utiliser la commande « orapwd » tel que :

oracle@serveur-standby : ~ > orapwd file=$ORACLE_HOME/dbs/orapwDB1SECONDARY password=monSuperPassword entries=1000

Note: Le mot de passe doit être identique sur la base Primary pour l’instance DB1PRIMARY.

Création de la STANDBY

Création de l’instance de la STANDBY

La création de l’instance Standby est un procédé très simple, tous les paramètres par défaut du moteur Oracle sont utilisés, seul le nom de l’instance sera précisé, à savoir DB1SECONDARY.
Nous allons créer un fichier de paramétrage d’instance « startMinimalStandBy.ora » puis nous allons démarrer une instance sur sa base tel que :

oracle@serveur-standby : ~ > echo "db_name='DB1SECONDARY'" > $ORACLE_HOME/dbs/startMinimalStandBy.ora
oracle@serveur-standby : ~ > ORACLE_SID=DB1SECONDARY && export ORACLE_SID
sqlplus> startup nomount pfile="$ORACLE_HOME/dbs/startMinimalStandBy.ora
Total System Global Area 122449892 bytes
Fixed Size 282596 bytes
Variable Size 88080384 bytes
Database Buffers 33554432 bytes
Redo Buffers 532480 bytes
ORACLE instance started.

Voilà, notre instance est démarrée, c’est à dire tous les processus oracle sont loadés et les buffers mémoires sont alloués, le processus d’injection des données à partir de la Primary va pouvoir être
entamé.


Note: Nous démarrons en mode « nomount » car dans ce cadre là évidement, nous ne disposons pas encore de control files qui seront dynamiquement créés plus tard lors de la première alimentation à
partir de la Primary.

Génération de la database de la STANDBY

Le principe général est de se servir du dernier backup RMAN de la dabase Primary et de la restaurer sur la StandBy.

Depuis la version 11G, il est possible également de générer les données de la standby depuis les données actives de la Primary, sans passer par un backup, ce qui économisera le temps nécessaire à la récupération des fichiers du backup peut être sur bandes ou sur un périphérique lent : C’est cette option que nous allons adopter ici. Il faut donc utiliser RMAN pour se connecter simultanément aux deux serveurs (auxilirary connection) puis ordonner la copie des datas de la base de production vers la stand by, s’ne suivra un recovery automatique car ceci se fera base ouverte et activité en cours.


Nous allons créer un script pour RMAN que nous allons positionner dans le dossier $ORACLE_HOME/dbs/createStandbyFromPrimay.rcv et qui contient :

host "echo 'START TIME : date' / >> /data/oracle/scripts/generationStandBy.trace
run {
allocate channel chan1 device type disk;
allocate auxiliary channel chan2 device type disk;
duplicate TARGET DATABASE FOR STANDBY FROM ACTIVE DATABA
DORECOVER
SPFILE
SET DB_UNIQUE_NAME='DB1SECONDARY'
SET STANDBY_FILE_MANAGEMENT='AUTO'
SET SGA_MAX_SIZE='2G'
SET SGA_TARGET='2G'
NOFILENAMECHECK;
}
host "echo 'END TIME : date' / >> /data/oracle/scripts/generationStandBy.trace

Nous ouvrons donc deux canaux de communication de type « Disk« , un sur la base Primary, l’autre sur la base Standby (auxiliary).


L’instruction « DORECOVER » indique que une fois les datafiles de la base primaire recopiés, il faudra procéder à un recovery pour automatiquement appliquer les données qui auront bougé pendant cette construction.


Les valeurs de la SGA sont ici à titre d’exemple, vous pouvez (et vous devez) bien sur utiliser la mémoire que votre serveur Standby possède.
Il faut simplement se connecter à Rman sur les deux databases, puis appliquer ce script tel que :

oracle@serveur-standby : ~ > rman target sys/monSuperPas
Recovery Manager: Release 19.0.0.0.0 - Production on Thu
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.
connected to target database: DB1PRIMARY (DBID=274758736
connected to auxiliary database: DB1SECONDARY (not mount
RMAN> @$ORACLE_HOME/dbs/createStandbyFromPrimay.rcv
…
…
RMAN> Recovery terminated.

L’opération peut être plus ou moins longue selon la taille de la base de données.

Attention, prévoyez aussi de dimensionner les liens réseaux convenablement, il ne faudrait pas qu’une copie massive de données surcharge vos liens de production.
A ce stade, les données de la production ont été recopiées sur la StandBy qui est en mode « mount » (not open), il faut maintenant mettre en place le transfert automatique des archives de la Primary vers la Standby et appliquer les archives automatiquement sur la Standby.

Alimentation de la STANDBY avec les archivelogs de la PRIMARY

Il nous reste deux choses à effectuer:

  • Automatiser le transport des archive logs générés sur la Primary vers la Standby
  • Appliquer automatiquement les archive logs reçues sur la baseStandby

Transfert des archive logs de la Primary vers la Standby

Le principe est simple : Dès qu’un archive log est généré sur la Primary, il faut le transférer dans le dossier des archive logs sur le serveur de la StandBy.


On peut traiter le problème de plusieurs façon, la plus simple est d’automatiser le transfert des nouveaux fichiers qui apparaissent dans le répertoire de la Primary vers la Standby avec un gestionnaire de transfert de fichiers incrémental, par exemple « rsync » déclenché toutes les minutes via la crontab du user « oracle ».


Attention, si l’activité des redos est assez basse, il peut arriver qu’un seul redo mettent trop de temps avant de se remplir puis de switcher et enfin de générer une archive log. Pour éviter ce phénomène et être certain que les archive logs sont régulièrement générées mêmes si les redos ne sont pas pleins, nous allons forcer le switch d’un redo toutes les 5 minutes par exemple tel que :

oracle@serveur-primary : ~ > ORACLE_SID=DB1PRIMARY && export ORACLE_SID
SQL*Plus: Release 11.2.0.3.0 Production on Thu May 12 16
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connect :
Oracle Database 11g Enterprise Edition Release 11.2.0.1.
sql> alter system set ARCHIVE_LAG_TARGET=300;

Une fois cela fait, positionnons dans la cron du serveur Primary la
synchronisation incrémentale des archives via rsync:
*/5 * * * * rsync -e ssh -uav4 --progress /oracle/DB1PR

Note) Vous trouverez ici quelques informations utile sur l’utilisation de rsync.

Nous considérons dans cet exemple que les archives logs sont dans le dossier « /oracle/DB1PRIMARY/archivelog/ » pour la base Primary et dans le dossier « /oracle/DB1SECONDARY/archivelog/ » pour la StandBy.

Intégration des archives logs transférées sur la base Standby

De part la construction de notre base Standby, les archive logs se trouvent donc dans le répertoire
« oracle/DB1SECONDARY/archivelog/« , nous allons demander :

  • A la database d’intégrer les archives dont les SCN sont plus récents
    que ceux qu’elle détient.
  • A RMAN de supprimer les archives plus vieilles de « n » jours (n à
    définir en fonction du niveau de sécurité que vous désirez garder et
    conformément à la politique de sauvegarde RMA de la Primary
    (explications plus bas).

Il suffit de se connecter sur la Standby tel que :

oracle@serveur-secondary : ~ > ORACLE_SID=DB1SECONDARY & export ORACLE_SID
oracle@serveur-secondary : ~ > sqlplus / as sysdba
SQLPlus: Release 11.2.0.3.0 Production on Thu May 12 16 
Copyright (c) 1982, 2011, Oracle. All rights reserved. 

Connect : Oracle Database 12c Enterprise Edition Release 12.2.0.1. 

sql> spool off; 
sql> alter database recover automatic standby database; 
sql> ...
sql> ...
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile x - see DBWR trace file
ORA-01110: datafile x: '/data/database/arch/arch_x.dbf'
sql> alter database recover managed standby database cancel.

Notez que la dernière ligne, selon les versions des moteurs Oracle, est une erreur, mais c’est une erreur « normale » car le moteur procède à l’intégration des archives, une par une, jusqu’au moment où il va chercher à intégrer une archive suivante qu’il ne va pas trouver car celle-ci n’a pas encore été générée et/ou transférée. Une fois cela fait, on stoppe la procédure d’intégration des archives telle que : sql> alter database recover managed standby database cancel.

Voilà, vos archives sont intégrées, il faut simplement mettre ceci sous la forme de script dans la crontab qui se déclenche toutes les minutes par exemple. 2.2) Suppression des vieilles archives Votre politique de sauvegarde des archives log de la Primary via RMAN décide de la politique de rétention des archives, par exemple :

BACKUP ARCHIVELOG ALL TAG 'BCKARCHLOG' NOT BACKED UP 3 T DELETE NOPROMPT ARCHIVELOG UNTIL TIME='SYSDATE-7';

Dans cet exemple, ce script RMAN sauvegarde les archive logs qui n’ont pas été au moins sauvegardées déjà 3 fois, puis, supprime celles qui sont plus vieilles de 7 jours (Il vaut mieux garder des archives sur disque quelques jours pour éviter d’aller à avoir à la récupérer sur un NAS ou sur bandes en cas de besoin de recovery). Donc, au bout de 7 jours, des archives vont êtres supprimées : Il suffit de rajouter le commutateur « –delete » à notre script rsync pour que celui-ci delete aussi sur la StandBy les archives qui n’existent plus sur la Primary et qui avaient été transportées sur le serveur de la Standby.

Activation de la base STANDBY

« Activer » une base Standby équivaut à dire à Oracle de transformer la structure de la base en base « PRIMAIRE » ouvrable et exploitable. Cette opération est irréversible et n’est à utiliser que si vous souhaitez démarrer votre production sur cette base de données en cas de PRA par exemple.

Il n’est pas possible ensuite de faire l’opération inverse (du moins en Standard Edition).

L’activation consiste en l’application de cette commande :

oracle@serveur-secondary : ~ > ORACLE_SID=DB1SECONDARY & export ORACLE_SID
oracle@serveur-secondary : ~ > sqlplus / as sysdba
SQLPlus: Release 11.2.0.3.0 Production on Thu May 12 16
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connect :
Oracle Database 11g Enterprise Edition Release 12.2.0.1.
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.
SQL >

Il faut donc savoir que cette opération n’est pas réversible : Une Standby activée en Primary ne peut pas revenir en mode Standby et il faudra reconstruire une Standby sur l’ancien serveur de Production, la
synchroniser avec la nouvelle Primary et réaliser l’opération inverse pour normaliser et revenir sur le site de Production. Ceci fait, il faudra de nouveau reconstruire la Standby sur le site de PRA. Une opération
assez lourde qui est entre autre évitée par l’utilisation d’outils disponibles en SE, notamment Dataguard. Dataguard permet de transformer une Standby en Primary et inversement (SWITCH), ce qui simplifie grandement les opérations, mais il faut pour cela passer en licence Enterprise et vous préparer à un don d’organe 🙂 .

Scripting

Pour simplifier le tout, j’ai renseigné toutes ces opérations dans quelques scripts pour la Primary et pour la Standby que vous pouvez télécharger en cliquant ici.

Publications similaires :

  1. TDPO : Sauvegarde Rman Oracle avec TSM (Tivoli Storage Manager)
  2. Cluster HA DRBD
  3. CHROOT et SFTP
  4. LVM (Logical Volume Manager)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *