0

Une solution de “Disaster Recovery” sous Oracle Standard Edition avec DBVisit standby

twitterlinkedinmail

Hello

voici un sujet que les DBA Oracle ont du déjà aborder à plusieurs reprises avec leurs clients en mission, ou en infogérance bases de données. Comment assurer un plan de reprise d’activités fiable, robuste et pérenne dans un environnement de production pour une base Oracle critique.

Aussitôt, nous pensons à l’option “Oracle Dataguard”, celle qui est mise en avant par Oracle dans sa version Enterprise Edition et qui a fait ses preuves. Cette architecture permet d’avoir une instance Oracle primaire qui est répliquée, à la transaction prête, sur un serveur de secours grâce aux mécanismes “transport log” et “redo apply” et administrer via “dgmgrl” ou OEM.

De plus, à partir de la version Oracle 11g, il vous sera possible de profiter de l’option (payante!) “Active Dataguard”, vos applications de reporting, et autres applications analytiques peuvent interroger l’instance Oracle Standby dans un mode “Read Only redo apply” et ne pas pénaliser les IO sur la base primaire qui se charge de l’activité transactionnelle.

Seulement le dilemme qui se présente bien souvent chez nos clients est, comment assurer un secours à notre instance de production lorsque l’on ne dispose pas de la version Oracle Enterprise Edition ? Car “Oracle Dataguard” est avant tout une feature propre à l’édition Entreprise et non la Standard 1 ou 2 et encore moins Express…

C’est la qu’intervient la solution DBVisit avec la partie gestion de la réplication via DBVisit standby .

DBVisit est une société basée à Auckland en Nouvelle Zélande avec des bureaux aux Etats Unis et Prague. Celle ci s’est spécialisée dans les solutions de Disaster Recovery autour d’Oracle Standard Edition. Sa solution logicielle est présente dans un peu plus de 130 pays, y compris en France.

Cet éditeur a la particularité bien utile, de travailler avec la version Standard Edition d’Oracle pour monter une architecture de réplication.
Pour fonctionner, DBVisit aura besoin de travailler avec une base de données démarrée en mode “Archive log” actif.

 

 

Architecture

Voici un schéma d’architecture global sur le fonctionnement de DBVisit Standby sur une instance Oracle Standard Edition ayant une standby attachée

 

L’utilisateur se connecte à une console Web via un navigateur, sur le port 4433.
A partir de la, cette console communique avec les 2 serveurs BDD via les agents “dbvagent” installés sur chacun d’entre eux.

Les bases de données envoient leurs informations, redo et archives, aux processus “dbvnet”, présents sur les serveurs, qui se chargent de transférer les archive logs du site primaire au site secondaire.

Le transfert des archivelogs s’effectue via une communication encryptée entre les 2 sites.
Un processus “Redo Apply” permet de rejouer l’archive transférée sur la base standby.

Sur ces 2 sites, il existe des process daemon en arrière plan qui se chargent d’effectuer ce travail au fur et à mesure du cycle de vie de la base primaire.

 

Installation

 

Prérequis

Comme nous l’avons vu sur le schéma d’architecture ci dessus, nous avons besoin de 3 serveurs pour assurer l’installation de DBvisit Standby.
2 serveurs portant les bases de données, la base primaire, et la base standby.
1 autre serveur sur lequel sera installée la console Web qui permettra d’administrer la solution.

Nous partons du fait que nous possédons déjà les installations suivantes pour ces 3 serveurs :

Serveur 1 : 1 serveur linux RHEL8 adresse IP 172.44.2.238 avec 
1 moteur Oracle 19c Standard Edition 2 et une base Oracle (non multitenant) installée.
Serveur 2 : 1 serveur linux RHEL8 adresse IP 172.44.2.204 avec 
1 moteur Oracle 19c Standard Edition 2 uniquement
Serveur 3 : 1 serveur linux RHEL8  adresse IP 172.44.2.170 
(juste un user linux Oracle)

 

Préparation

Sur chaque serveur, il faudra aller télécharger depuis le site DBvisit standby , la version souhaitée du produit. Pour notre exemple, nous partirons de la version 9.

Attention, il faut savoir que DBVisit n’est pas “open source”, il s’agit d’un software soumis à licence. Cependant, une version d’évaluation est téléchargeable depuis leur site , ainsi, nous pourrons utiliser celle ci durant 10 jours avec une clé de licence gratuite.

DBVisit vous envoie un mail avec la version choisie en pièce jointe, et une clé d’activation.

Il s’agira alors de transférer le fichier “zip” reçu par mail sur les 3 serveurs et de créer les répertoires utilisés pour l’installation

Sous user root :

mkdir /usr/dbvisit
chown -R oracle:oinstall /usr/dbvisit

Sous user Oracle :

mkdir $HOME/dbvisit_9
cd $HOME/dbvisit_9
unzip dbvisit-standby9.0.20-el7.zip
tar xvf dbvisit-standby9.0.20-el7.tar

Si celle ci n’est pas présente, installer la libraire “libnsl” sous root:

# dnf install libnsl

Ouverture de flux

Si comme moi, vous travaillez sur des VMs Amazon AWS, pensez à mettre à jour vos “security group”. Pour fonctionner, DBvisit Standby a besoin des ports suivants:

  • Port 7890, port utilisé pour la communication “dbvnet” entre les 2 serveurs de bases de données
  • Port 7891, port utilisé par les agents de DBVisit sur les serveurs de bases de données
  • Port 4433, port utilisé pour se connecter à la console DBVisit.

Règles entrantes

Type Protocole Plage de ports Source Description – facultatif
TCP personnalisé TCP 4433 172.44.1.***/32 Port pour tests DBVISIT console
TCP personnalisé TCP 7891 172.44.2.0/24 Port pour tests DBVISIT local agent
TCP personnalisé TCP 7890 172.44.2.0/24 Port pour tests DBVISIT distant

Déploiement

Installer tout d’abord le serveur portant la console sur 172.44.2.170 en lançant le binaire d’installation présent dans “/home/oracle/dbvisit_9/dbvisit

Sous Oracle :

$ cd /home/oracle/dbvisit_9/dbvisit/installer
$ ls -l
total 5680
drwxr-xr-x. 2 oracle oinstall 25 Jan 11 23:06 doc
-rwxr-xr-x. 1 oracle oinstall 5812566 Jan 11 23:10 install-dbvisit

Vous pouvez lancer simplement “./install-dbvisit“, l’installation se déroulera alors en mode interactive et vous pourrez entrer les informations nécessaires au cours de l’installation.
Sinon vous pourrez directement installer DBVisit en mode silencieuse :

$ ./install-dbvisit --batch-install --force \
 --dbvisit-base /usr/dbvisit \
 --components dbvserver,observer \
 --dbvserver-local-host 172.44.2.170 \
 --dbvserver-local-port 4433

Ici, nous installons les composants “dbserver” et “observer”. Votre log d’installation sur ce serveur doit contenir l’information suivante :

-----------------------------------------------------------
Summary of the Dbvisit DBVSERVER configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit
DBVSERVER_LOCAL_HOST 172.44.2.170
DBVSERVER_LOCAL_PORT 4433
DBVSERVER_PUBLIC_HOST 172.44.2.170
DBVSERVER_PUBLIC_PORT 4433

-----------------------------------------------------------
Summary of the Dbvisit OBSERVER configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit

Démarrer ensuite les processus “dbserver” et “observer”

$ /usr/dbvisit/dbvserver/dbvserver -d start
Dbvserver daemon started.
$ nohup /usr/dbvisit/observer/observersvc -f /usr/dbvisit/observer/conf/observer.conf &
[1] 9872
$ nohup: ignoring input and appending output to 'nohup.out'

 

Passer aux 2 serveurs de bases de données.

Serveur bases de données 1 :

$ cd /home/oracle/dbvisit_9/dbvisit/installer
$ ./install-dbvisit --batch-install --force \
 --dbvisit-base /usr/dbvisit --components core \
 --dbvnet-local-host 172.44.2.238 --dbvnet-local-port 7890 \
 --dbvagent-webserver-host 172.44.2.170 \
 --dbvagent-webserver-port 4433 --dbvnet-passphrase testcapdata \
 --dbvagent-local-host 172.44.2.238 \
 --dbvagent-local-port 7891 --dbvagent-passphrase testcapdata

Nous venons d’installer le composant “core” qui comprend le “dbvnet” et “dbvagent”. La log d’installation donnera le tableau suivant :

-----------------------------------------------------------
Summary of the Dbvisit DBVNET configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit
DBVNET_LOCAL_HOST 172.44.2.238
DBVNET_LOCAL_PORT 7890
DBVNET_PASSPHRASE testcapdata 
-----------------------------------------------------------
Summary of the Dbvisit DBVAGENT configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit
DBVAGENT_LOCAL_HOST 172.44.2.238
DBVAGENT_LOCAL_PORT 7891
DBVAGENT_PASSPHRASE testcapdata
DBVAGENT_WEBSERVER_HOST 172.44.2.170
DBVAGENT_WEBSERVER_PORT 4433

On démarre les processus une fois l’installation terminée.

$ /usr/dbvisit/dbvnet/dbvnet -d start
Dbvnet daemon started.
$ /usr/dbvisit/dbvagent/dbvagent -d start
Dbvagent daemon started.

 

Serveur bases de données 2 :

$ cd /home/oracle/dbvisit_9/dbvisit/installer
$ ./install-dbvisit --batch-install --force \
 --dbvisit-base /usr/dbvisit --components core \
 --dbvnet-local-host 172.44.2.204 --dbvnet-local-port 7890 \
 --dbvagent-webserver-host 172.44.2.170 \
 --dbvagent-webserver-port 4433 --dbvnet-passphrase testcapdata \
 --dbvagent-local-host 172.44.2.204 \
 --dbvagent-local-port 7891 --dbvagent-passphrase testcapdata

Avec la log d’installation

-----------------------------------------------------------
Summary of the Dbvisit DBVNET configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit
DBVNET_LOCAL_HOST 172.44.2.204
DBVNET_LOCAL_PORT 7890
DBVNET_PASSPHRASE testcapdata

-----------------------------------------------------------
Summary of the Dbvisit DBVAGENT configuration
-----------------------------------------------------------
DBVISIT_BASE /usr/dbvisit
DBVAGENT_LOCAL_HOST 172.44.2.204
DBVAGENT_LOCAL_PORT 7891
DBVAGENT_PASSPHRASE testcapdata
DBVAGENT_WEBSERVER_HOST 172.44.2.170
DBVAGENT_WEBSERVER_PORT 4433

 

Démarrer également les composants sur le noeud 2

$ /usr/dbvisit/dbvnet/dbvnet -d start
Dbvnet daemon started.
$ /usr/dbvisit/dbvagent/dbvagent -d start
Dbvagent daemon started.

 

Configuration

 

La suite concernant la partie configuration se déroulera depuis un navigateur Web. Nous nous connecterons directement sur l’URL de notre serveur ou est installé la console via le port 4433 :

http://172.44.2.170:4433

Le compte est, par défaut, “admin”, password “admin”. Il faudra bien entendu le changer par mesure de sécurité pour une utilisation en mode production.

 

Une fois connecté, vous arrivez sur une page principale présentant les différentes options liées au fonctionnement de DBVisit Standby.

Seules les options “manage hosts” “manage users” et “user quick guides” sont accessibles.

 

Enregistrement des serveurs et instances

 

Pour créer notre configuration, nous irons sur “manage hosts”.


Puis cliquer sur “+NEW”.

Entrer les paramètres liés à notre base primaire tout d’abord, sur 172.44.2.238.

Puis la standby sur 172.44.2.204

 

Pour la passphrase, nous avions mis “testcapdata”. Il faudra renseigner celle ci pour chaque instance.

Les 2 serveurs sont maintenant enregistrés sur notre console d’administration. Il reste à configurer notre réplication.

En revenant sur l’écran principal des options, on peut voir que l’option “Manage Configuration” est passée active.

Nous ajouterons les bases de données liées à nos 2 serveurs en cliquant sur “+NEW”.

 

Tout d’abord enregistrer le serveur hébergeant l’instance primaire, ici 172.44.2.238

Il faudra accepter la licence d’utilisation pour l’étape 2. L’étape 3 consistera à entre le nom de l’instance SOURCE. Attention à bien configurer les informations liés aux archivelogs et au port de communication ‘dbvnet’

 

 

Puis l’on passe à la partie instance standby, avec le choix du serveur, de l’instance , le ORACLE_HOME, le SID et le chemin des archives

Cliquer sur SUBMIT pour valider cette configuration

 

Retourner au menu, et il sera maintenant possible de créer notre instance Standby.
Mais avant cela, il faut enregistrer notre licence du produit.

Rappelons que pour nos tests, nous bénéficions d’un version d’essai de 10 jours, notre clé nous a été envoyé par mail avec le “zip” d’installation.

          puis entrez votre numéro de clé et valider.

 

Création de la base standby

Dans le menu principal, repérer l’option ci dessous :

       Rappelons que notre serveur de secours n’a aucune instance d’installée, juste un moteur Oracle identique à notre primaire.

 

Les informations liées à l’instance source devront être renseignées

 

Les paramètres Oracle de la source nous sont remontés

 

A partir de ces informations, l’assistant de création va pouvoir mettre en place la standby.
DBVisit utilise pour cela les montages “/usr/tmp” pour effectuer un backup RMAN. Vérifier que vous ayez assez de place dans ces FS. C’est un backup RMAN de la primaire qui sera fait, puis transférer vers le serveur de la standby, et enfin, restaurer via un DUPLICATE FOR STANDBY pour créer la base de standby.

 

 

Cliquer sur SUBMIT pour lancer la création de la standby.

Vous pourrez suivre la création de votre instance standby dans l’onglet “View Task History”.

 

Avec en fin de log :

 

Ca y’est vous avez une base de données standby configurée.

🙂

 

—————————-

 

Administration

Voici une présentation non exhaustive des tâches que nous pouvons effectuer sur la console Web afin d’administrer notre réplication. DBVisit fournit un petit utilitaire bien pratique qui effectue les tâches ci dessous en mode lignes de commandes, il s’agit de “dbvctl”. Celui ci est présent sur les 3 serveurs.

Gérer les process de surveillance

Afin de s’assurer que les ordres passent bien entre notre serveur primaire et le serveur standby, il faut penser à démarrer les daemon qui communiquent entre les “dbvnet” des serveurs.

Aller dans “Database Configuration” et choisir le daemon à démarrer si celui ci est arreté.

  Puis “START”         

 

 

Faire de même pour le serveur standby “172.44.2.204”.

Avec “dbvctl”, il faudra lancer, sur le serveur primaire et le serveur standby,  la commande :

$ /usr/dbvisit/standby/dbvctl -d MANUDB -D start

 

Gérer le redo apply

Sur la page “Database Actions”, il sera possible d’avoir de nombreuses informations sur l’état de notre réplication.

Report gap

Nous pourrons voir notamment le délai entre notre primaire et notre standby, un tableau pourra être édité avec l’option “log gap report”.

Puis

Il sera possible d’actionner manuellement l’envoi de log via l’option “send logs”, puis appliquer le log envoyé via l’option “Apply log”

 

Send logs

 

Avec un report associé, cliquer dans l’option “View task History” en base à gauche 

 

Avec “dbvctl”, lancer la commande suivante :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB

 

Apply logs

Avec un report que nous pourrons éditer

Avec “dbvctl”, lancer la commande suivante :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB

 

Gérer l’état des bases de données

Il sera également possible d’agir directement sur les bases de données dans “Database Actions”.
En cliquant sur l’icône “Database Actions” ,nous aurez le choix d’agir sur la base primaire ainsi que sur la standby avec les actions suivantes :

 

Sur l’instance primaire, vous pourrez redémarrer, démarrer ou arrêter la base :

 

Avec “dbvctl”, lancer l’une des commandes suivantes sur le serveur primaire :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB -o restart
$ /usr/dbvisit/standby/dbvctl -d MANUDB -o start
$ /usr/dbvisit/standby/dbvctl -d MANUDB -o stop

 

Sur la standby, vous pourrez la redémarrer, la démarrer, l’arrêter ou bien la passer en mode “read only” et passer des requêtes SELECT dessus.

 

 

Avec “dbvctl”, lancer l’une des commandes suivantes sur le serveur standby :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB -o restart
$ /usr/dbvisit/standby/dbvctl -d MANUDB -o start
$ /usr/dbvisit/standby/dbvctl -d MANUDB -o stop
$ /usr/dbvisit/standby/dbvctl -d MANUDB -o open (pour le mode READ-ONLY)


Switchover

Il sera possible de procéder à un switchover d’instances pour cette configuration :

Choisir la configuration en cours, un récapitulatif est alors envoyé directement. Nous avons l’information sur l’état de notre réplication et notamment le gap entre les 2 instances.

 

Comme on peut le voir dans le log de l’observer, il faut arreter les daemon qui tournent sur les serveurs avant de faire le switchover. Nous pouvons le faire directement dans “Database Actions”, et choisir “Daemon actions” ou bien passer la commande suivante sur les 2 serveurs :

$ /usr/dbvisit/standby/dbvctl -d MANUDB -D stop
Stopping Dbvisit Daemon...
Successfully stopped.

 

Puis cliquer sur SUBMIT. Un rapport complet pourra être édité dans le “View Task History” :

 

 

Connectez vous aux serveurs et interroger les bases pour vous assurer que tout a bien switché

SQL> select i.INSTANCE_NAME,i.HOST_NAME,d.name,d.database_role from v$instance i inner join v$database d on (i.instance_name=d.name);

INSTANCE_NAME    HOST_NAME                          NAME      DATABASE_ROLE
---------------- ---------------------------------- --------- ----------------
MANUDB           ip-172-44-2-204.capdata-aws.fr     MANUDB    PRIMARY

et

SQL> select i.INSTANCE_NAME,i.HOST_NAME,d.name,d.database_role from v$instance i inner join v$database d on (i.instance_name=d.name);

INSTANCE_NAME    HOST_NAME                         NAME      DATABASE_ROLE
---------------- --------------------------------- --------- ----------------
MANUDB           ip-172-44-2-238.capdata-aws.fr    MANUDB    PHYSICAL STANDBY

L’instance est primaire maintenant sur 172.44.2.204 et standby sur 172.44.2.238.

Avec “dbvctl”,  la commande est la suivante sur l’un des 2 serveurs :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB -o switchover

Automatic Failover

Il est possible de configurer un failover automatique grâce à notre process “dbvobserver”. Ce process se charge d’effectuer un failover vers l’instance de standby si la primaire venait à devenir injoignable.

Aller dans l’option “Manage Configurations” et ajouter l’observer.

 

Nous avons installé l’observer sur le même serveur que la console Web, soit 172.44.2.170, renseigner également la passphrase.

Clique sur SAVE pour enregistrer la configuration.

Il sera également possible de forcer un failover vers la standby avec “dbvctl”,  il suffira d’exécuter la commande suivante sur le serveur de standby :

 

$ /usr/dbvisit/standby/dbvctl -d MANUDB -o activate

 

Les différentes logs

Sur chacun des serveurs Linux, vous pourrez trouver les logs des différents composants sous des répertoires suivants.

Les traces liés aux processus DBVisit

[oracle@ip-172-44-2-238 dbvisit]$ ls -lrt
total 0
drwxr-xr-x. 5 oracle oinstall 54 Mar 30 09:38 dbvnet
drwxr-xr-x. 6 oracle oinstall 67 Mar 30 09:38 dbvagent
drwxr-xr-x. 14 oracle oinstall 203 Mar 30 09:55 standby

 

Si l’on prend l’exemple de la partie standby, le répertoire “trace” regroupe les processus systèmes propres

[oracle@ip-172-44-2-238 trace]$ pwd
/usr/dbvisit/standby/trace
[oracle@ip-172-44-2-238 trace]$ ls -rtl
total 17840
........
-rw-rw-rw-. 1 oracle oinstall 54916 Mar 31 15:30 4115_dbvctl_i_MANUDB_202103311530.trc
-rw-rw-rw-. 1 oracle oinstall 54916 Mar 31 15:30 4139_dbvctl_i_MANUDB_202103311530.trc
-rw-rw-rw-. 1 oracle oinstall 54916 Mar 31 15:31 4163_dbvctl_i_MANUDB_202103311530.trc
-rw-rw-rw-. 1 oracle oinstall 50877 Mar 31 15:31 4193_dbvctl_switchover_MANUDB_202103311531.trc
-rw-rw-rw-. 1 oracle oinstall 54916 Mar 31 15:33 4221_dbvctl_i_MANUDB_202103311533.trc
-rw-rw-rw-. 1 oracle oinstall 35823 Mar 31 15:40 4847_dbvctl_f_recovery_scn_time_MANUDB_202103311540.trc
-rw-rw-rw-. 1 oracle oinstall 238757 Mar 31 15:40 4893_dbvctl_MANUDB_202103311540.trc
-rw-rw-rw-. 1 oracle oinstall 333410 Mar 31 15:40 4257_dbvctl_switchover_MANUDB_202103311536.trc

 

Nous pourrons alors regarder toutes les actions menées par la console, et avoir des informations sur les tâches qui ont éventuellement échouées.

Dans le répertoire “Log” nous suivrons les actions menées sur la base en elle même.

[oracle@ip-172-44-2-238 log]$ pwd
/usr/dbvisit/standby/log
[oracle@ip-172-44-2-238 log]$ ls -rtl
total 1104
-rw-rw-rw-. 1 oracle oinstall 87968 Mar 30 09:55 dbvisit_install.log
-rw-rw-rw-. 1 oracle oinstall 0 Mar 30 09:56 dbvisit_MANUDB_arch_management.log
-rw-rw-rw-. 1 oracle oinstall 432 Mar 30 09:59 DBV_MANUDB_CSD_db_file_info.txt
-rw-rw-rw-. 1 oracle oinstall 12 Mar 31 09:25 dbv_heartbeat_MANUDB.lck
-rw-rw-rw-. 1 oracle oinstall 994080 Mar 31 15:33 dbvisitd_MANUDB.log
-rw-rw-rw-. 1 oracle oinstall 812 Mar 31 15:40 datafiles_MANUDB.json
-rw-rw-rw-. 1 oracle oinstall 313 Mar 31 15:40 dbv_MANUDB_info.json
-rw-rw-rw-. 1 oracle oinstall 25263 Mar 31 15:40 dbvisit_MANUDB.hist

Dans le fichier “dbvisitd_MANUDB.log“, nous pourrons suivre le processus de log apply sur notre standby.

Exemple, on passe un switch de log sur la base primaire :

[oracle@ip-172-44-2-204 log]$ sqlplus / as sysdba

SQL> alter system switch logfile;

System altered.

SQL> select status, sequence# from v$log;

STATUS           SEQUENCE#
---------------- ----------
ACTIVE           108
ACTIVE           107
CURRENT          109

 

Puis sur la standby, si l’on suit la log  :

[oracle@ip-172-44-2-238 log]$ tail -5f dbvisitd_MANUDB.log
20210331 16:03:09 main::dmn_worker: Command=RUN_MONITOR
20210331 16:03:09 main::try {...} : Newlogs=0 (Next required log 1_108_1068477110.arc not found)
20210331 16:03:15 main::dmn_worker: Command=RUN_MONITOR
20210331 16:03:15 main::try {...} : Newlogs=1
20210331 16:03:16 main::dmn_worker: Command=RUN_DBVISIT
20210331 16:03:16 main::dmn_check_ddc4changes: start
20210331 16:03:16 main::cmn_checksum: file=/usr/dbvisit/standby/conf/dbv_MANUDB.env
20210331 16:03:16 main::cmn_checksum: use internal cksum
20210331 16:03:16 main::cmn_checksum: use SHA1
20210331 16:03:16 main::cmn_checksum: crc=06a881bda229864cdeead13bfa7b1d710b31f430 len=25361 exitval=0 file=/usr/dbvisit/standby/conf/dbv_MANUDB.env
20210331 16:03:17 main::dmn_worker: Next log to apply: thread 1 sequence 109
20210331 16:03:18 main::dmn_run: TRACEFILE 5080_3_2_dbvctl_MANUDB_202103311603.trc
20210331 16:03:21 main::dmn_worker: Command=RUN_MONITOR

On voit bien le switch qui se fait vers la séquence numéro 109.

Un checksum se fait via la fonction de hashage SHA1 lors du transport de log. Celle ci n’est, aujourd’hui, pas la plus sécurisée, la version 10 de DBVisit propose peut être du SHA256 voir SHA384…. A voir.

La gestion des datafiles

DBVisit prend en compte la gestion des datafiles sur notre instance standby, même si le paramètre ‘STANDBY_FILE_MANAGEMENT’ est configuré à MANUAL.

Exemple.

Interrogeons les datafiles composant le tablespace DATA sur la base primaire et la standby.
Notre tablespace DATA se compose de 2 fichiers.

 

Primaire :

SQL> select file_name, status from dba_data_files where tablespace_name ='DATA';

FILE_NAME STATUS
------------------------------------------------------- ---------
/data/oradata/MANUDB/datafile/o1_mf_data_j65xs6jk_.dbf AVAILABLE
/data/oradata/MANUDB/datafile/o1_mf_data_j690qcov_.dbf AVAILABLE

 

Standby:

SQL> select name, status from v$datafile where ts#=6 ;

NAME STATUS
------------------------------------------------------- -------
/data/oradata/MANUDB/datafile/o1_mf_data_j690plft_.dbf ONLINE
/data/oradata/MANUDB/datafile/o1_mf_data_j63w7wh9_.dbf ONLINE

 

Notons que nous utilisons OMF pour la gestion de nos datafiles, les noms ne sont donc pas identiques. Le paramètre STANDBY_FILE_MANAGEMENT est à MANUAL.

 

SQL> show parameters standby_file

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
standby_file_management              string      MANUAL

 

Et pourtant si l’on crée un 3e fichier sur la base primaire :

 

SQL> alter tablespace DATA add datafile size 50M autoextend on maxsize 100M;

Tablespace altered.

SQL> select file_name, status from dba_data_files where tablespace_name ='DATA';

FILE_NAME STATUS
------------------------------------------------------- ---------
/data/oradata/MANUDB/datafile/o1_mf_data_j65xs6jk_.dbf AVAILABLE
/data/oradata/MANUDB/datafile/o1_mf_data_j690qcov_.dbf AVAILABLE
/data/oradata/MANUDB/datafile/o1_mf_data_j699cj5r_.dbf AVAILABLE


SQL> alter system switch logfile;

System altered.

On s’assure que l’ordre de switch de log est passé sur la standby :

[oracle@ip-172-44-2-238 log]$ tail -5f dbvisitd_MANUDB.log
.....
20210331 16:38:45 main::dmn_worker: Command=RUN_MONITOR
20210331 16:38:45 main::try {...} : Newlogs=0 (Next required log 1_112_1068477110.arc not found)
20210331 16:38:51 main::dmn_worker: Command=RUN_MONITOR
20210331 16:38:51 main::try {...} : Newlogs=0 (Next required log 1_112_1068477110.arc not found)
20210331 16:38:57 main::dmn_worker: Command=RUN_MONITOR
20210331 16:38:57 main::try {...} : Newlogs=1
20210331 16:38:58 main::dmn_worker: Command=RUN_DBVISIT
20210331 16:38:58 main::dmn_check_ddc4changes: start
20210331 16:38:58 main::cmn_checksum: file=/usr/dbvisit/standby/conf/dbv_MANUDB.env
20210331 16:38:58 main::cmn_checksum: use internal cksum
20210331 16:38:58 main::cmn_checksum: use SHA1
20210331 16:38:58 main::cmn_checksum: crc=06a881bda229864cdeead13bfa7b1d710b31f430 len=25361 exitval=0 file=/usr/dbvisit/standby/conf/dbv_MANUDB.env
20210331 16:38:59 main::dmn_worker: Next log to apply: thread 1 sequence 113
20210331 16:38:59 main::dmn_run: TRACEFILE 5080_3_9_dbvctl_MANUDB_202103311638.trc
20210331 16:39:03 main::dmn_worker: Command=RUN_MONITOR
20210331 16:39:03 main::try {...} : Newlogs=0 (Next required log 1_113_1068477110.arc not found)
20210331 16:39:09 main::dmn_worker: Command=RUN_MONITOR
20210331 16:39:09 main::try {...} : Newlogs=0 (Next required log 1_113_1068477110.arc not found)

 

Et on interroge l’instance de standby

SQL> select name, bytes/1024/1024 "Size", status from v$datafile where ts#=6;

NAME Size STATUS
------------------------------------------------------- ---------- -------
/data/oradata/MANUDB/datafile/o1_mf_data_j690plft_.dbf   50        ONLINE
/data/oradata/MANUDB/datafile/o1_mf_data_j63w7wh9_.dbf   100       ONLINE
/data/oradata/MANUDB/datafile/o1_mf_data_j699f33l_.dbf   50        ONLINE

 

Notre 3e fichier, avec une taille de 50Mo, est bien créé pour le tablespace DATA, statut ONLINE.

 

Quelques remarques

Comme tout outil tiers travaillant avec un éditeur, cette solution a des limites.

  • Même si DBVisit fournit un outil en lignes de commande “dbvctl”, celui ci reste limité vis à vis de ce que peut effectuer la console Web. Il est donc indispensable de gèrer ce 3e serveur qui fait office d’outil graphique à cette solution Disaster Recovery.
    Le scripting shell est cependant possible pour une administration au quotidien avec “dbvctl”.
  • Au niveau tarification, c’est assez opaque, rien n’est mentionné sur le site, il faut contacter l’éditeur de la solution pour avoir un devis.
    Pour ma part, ayant utilisé une version d’essai pour ce test, je n’ai pas d’information au sujet du prix. Il est, cependant, bien probable, que le tarif penche en faveur de DBVIsit vis à vis d’une licence Enterprise Edition Oracle.
  • Le “lag” entre la base primaire et la base standby peut s’avèrer important. Il n’a pas été rare, au cours de mes tests, de rencontrer des décalages supérieurs à 1h dans le champ “Time Gap”. Sans doute car l’activité redo de ma base primaire est très faible.
    Dans une configuration “Dataguard” classique, c’est le paramètre “ArchiveLagTarget” qui permet de s’affranchir de ce souci.
  • DBVisit standby, via son processus ‘dbvnet’ transfère les archivelogs de notre instance primaire, vers le site de secours. Il n’y a donc pas de création, sur la base primaire d’un ‘LOCATION=SERVICE’ via le paramètre “Log_archive_dest”.
    Les seuls processus d’archivage configurés coté primaire et standby sont les suivants :

Primaire:

 

SQL> select i.INSTANCE_NAME,i.HOST_NAME,d.name,d.database_role from v$instance i inner join v$database d on (i.instance_name=d.name);

INSTANCE_NAME    HOST_NAME                                                        NAME      DATABASE_ROLE
---------------- ---------------------------------------------------------------- --------- ----------------
MANUDB           ip-172-44-2-238.capdata-aws.fr                                   MANUDB    PRIMARY

SQL> select DEST_NAME,STATUS,TARGET,DESTINATION,LOG_SEQUENCE,PROCESS,REGISTER from v$archive_dest where status <> 'INACTIVE';

DEST_NAME            STATUS    TARGET           DESTINATION                                        LOG_SEQUENCE PROCESS    REG
-------------------- --------- ---------------- -------------------------------------------------- ------------ ---------- ---
LOG_ARCHIVE_DEST_1   VALID     RIMARY           USE_DB_RECOVERY_FILE_DEST                          131          ARCH       NO

 

Standby:

SQL> select i.INSTANCE_NAME,i.HOST_NAME,d.name,d.database_role from v$instance i 
inner join v$database d on (i.instance_name=d.name);
INSTANCE_NAME    HOST_NAME                                                        NAME      DATABASE_ROLE
---------------- ---------------------------------------------------------------- --------- ----------------
MANUDB           ip-172-44-2-204.capdata-aws.fr                                   MANUDB    PHYSICAL STANDBY

SQL> select DEST_NAME,STATUS,TARGET,DESTINATION,LOG_SEQUENCE,PROCESS,REGISTER from v$archive_dest 
where status <> 'INACTIVE';

DEST_NAME            STATUS    TARGET           DESTINATION                                        LOG_SEQUENCE PROCESS    REG
-------------------- --------- ---------------- -------------------------------------------------- ------------ ---------- ---
LOG_ARCHIVE_DEST_1   VALID     LOCAL            USE_DB_RECOVERY_FILE_DEST                           0           ARCH       NO
STANDBY_ARCHIVE_DEST VALID     LOCAL            USE_DB_RECOVERY_FILE_DEST                           0           RFS        NO

Nous pouvons voir que les archivelogs de la base primaire sont envoyés sur la FRA mais qu’aucune autre destination n’est configurée pour la partie ‘Transport log’.

Le processus “RFS” de la standby n’est donc pas directement connecté au LGWR comme peut l’être une configuration Dataguard en “Max Protection”, c’est l’archivelog transféré qui est rejoué sur la standby à la manière d’un “recover” manuel.

Il y’a donc, potentiellement, un risque de perte de transaction si un souci venait à survenir sur le site primaire et la perte des redologs non archivés.

 

 

Continuez votre lecture sur le blog :

twitterlinkedinmail

Emmanuel RAMI

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.