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 :
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 switchoverAutomatic 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 :
- Création d’un Dataguard physique (Benjamin VESAN) [Oracle]
- AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ? (Emmanuel RAMI) [AWSNon classéOracle]
- Haute disponibilité de PostgreSQL avec Patroni (Ludovic AUGEREAU) [PostgreSQL]
- PostgreSQL : la streaming replication en 12. (Emmanuel RAMI) [PostgreSQL]
- Le chiffrement Oracle : native network encryption (Emmanuel RAMI) [Oracle]