Dbvisit Standby : le test (prise en main)
- Détails
- Catégorie : Dataguard
- Publié le dimanche 15 février 2015 20:11
- Écrit par Administrator
- Affichages : 13603
Cet article décrit comment installer, paramétrer et manager Dbvisit Standby. Même si l’outil permet de gérer des standby (et pas des Dataguard), il se trouve dans la rubrique Dataguard, le but de l’outil étant de remplacer de Dataguard en rajoutant une couche logicielle sur un Standby.
L’installation software
Le soft peut être téléchargé >ici<. On peut demander une licence temporaire pour tester. La licence dure 1 mois alors je vous conseille de préparer vos bancs de test avant. La version tester dans le présent article est la 7.0.22.
Nous allons installer DBStandby sur 2 serveurs de base de données : oradbm2 et oradbm3 en Oracle Linux 6.6. Sur oradbm2 tourne une base de données nommé WINDB en file system sur un moteur 11.2.0.4. Sur oradbm3, il y a juste un moteur 11.2.0.4.
Un prérequis avant l’installation est de mettre en place le ssh équivalence entre les 2 comptes oracle (comme lors de l'installation RAC voir : testbed : 11gR2 RAC ASM ). Une fois cela mis en place, l’installation peut commencer, elle est assez simple :
[root@oradbm2 ~]# cd /usr/local
[root@oradbm2 local]# ls
bin etc games include lib lib64 libexec sbin share src
[root@oradbm2 local]# mkdir dbvisit
[root@oradbm2 local]# chown oracle:dba dbvisit
[oracle@oradbm2 tmp]$ tar xvf dbvisit-standby7.0.22-el6.tar
[oracle@oradbm2 tmp]$ cd dbvisit
[oracle@oradbm2 dbvisit]$ cd installer/
Le script d’installation peut alors être lancé. C’est un script interactif. Ci-dessous le début de l'installation (c'est presque du suivant-suivant)
[oracle@oradbm2 installer]$ ./install-dbvisit
Il faut indiquer le répertoire où le soft va être déposé:
Enter a custom value or press ENTER to accept default [/usr/dbvisit]:
> /usr/local/dbvisit
Ensuite, il demande le user propriétaire du soft, il faut que ce soit le compte "owner" du moteur de base de données. Ici oracle, le défaut:
Custom value or ENTER for default [oracle]:
>
Ensuite le port de communication de la couche DBVNET (la couche de communication du soft dbvisit entre les divers site). Ici 7890, le défaut:
>>> DBVNET PORT NUMBER
Custom value or ENTER for default [7890]:
>
Puis le mot de passe du compte d'administration de Dbvisit
>>> DBVNET PASSWORD
Custom value or ENTER for default [admin]:
>
Ainsi de suite... vous pouvez tout laisser par défaut. A la fin de l'instllation il faut retenir le port de l'interface web 8443 (par défaut) qui va vous permettre entre de configurer la suite. Sinon prenez le soins de bien lire l'affichage, il vous apprendra l'architecture de l'outil : les scripts à connaitre, les ports utilisés, les daemons : dbvnet (la couche de communication) et dbvserver (la couche serveur GUI), où se trouve les fichiers de configuration DDC...
Une fois l'installation fini, aller sur le serveur oradbm03 et répéter la même installation.
Autostart au boot
Suite à l’installation j’ai constaté qu’au boot des serveurs aucun daemon n’était démarré, alors qu’après l’installation il y avait plusieurs processus dbvnet et dbserverd. Je n’ai pas trouvé dans la documentation comment paramétrer l’autostart. Mais en fait la solution se trouve tout simplement dans le output de l’installation du soft, comme dit précédemment il faut bien prendre le temps de le lire , il y a écrit :
>>> Adjusting init script templates for product dbvserver...
Please find some init script templates in the following directory:
/usr/local/dbvisit/dbvserver/conf/init.d
These templates will allow your Systems Administrator to automatically
start Dbvserver after a database server reboot.
Templates are available for Sun Solaris, IBM AIX, and the Linux flavours
OpenSuSE, RedHat/Centos/Fedora & Debian/Ubuntu.
Mes deux serveurs sont en Oracle Linux ils ont donc une saveur 
de RedHat.
Donc pour dbvserverd:
[root@oradbm2 redhat]# pwd
/usr/local/dbvisit/dbvserver/conf/init.d/redhat
[root@oradbm2 redhat]# ls -ltr
total 4
-rwxr-xr-x. 1 oracle oinstall 1027 Nov 11 18:50 dbvserverd
[root@oradbm2 redhat]# cp dbvserverd /etc/init.d/
[root@oradbm2 redhat]# chkconfig --add dbvserverd
[root@oradbm2 redhat]# chkconfig --level 345 dbvserverd on
[root@oradbm2 redhat]# service dbvserverd start
Et pour dbvnetd:
[root@oradbm2 redhat]# pwd
/usr/local/dbvisit/dbvnet/conf/init.d/redhat
[root@oradbm2 redhat]# cp dbvnetd /etc/init.d
[root@oradbm2 redhat]# chkconfig --add dbvnetd
[root@oradbm2 redhat]# chkconfig --level 345 dbvnetd on
[root@oradbm2 redhat]# service dbvnetd start
Configuration de la base de données
Nous avons donc une base de données nommée WINDB sur le serveur oradbm02, et nous voulons mettre en place notre site DRS sur oradbm03 qui va donc hébergé la standby database de WINDB.
Cela peut être fait avec DBVisit Standby soit en mode interactif soit en mode graphique, dans les deux cas le déroulement reste le même.
Ici nous allons le faire par la GUI, commençons donc par l’ouvrir. Si vous n’avez pas changé le port par défaut l’url est https://oradmb02:8443
|
|
|
 |
Cliquer sur SETUP |
 |
Cliquer sur New DBvisit Setup, car ici nous sommes dans la mise en place d’une nouvelle configuration pour une nouvelle base de données. L’outil peut gérer plusieurs base de données primaires (pas testé dans ce tutoriel) |
 |
DBVisit a détecté automatiquement la base de données du serveur oradbm02. Il a utilisé pour cela le oratab qui était à jour sur le banc. Si le oratab n'est pas jour, il faut le mettre à jour. Choisir donc la base de données et cliquer sur Continue. |
  |
Nous n’utilisons pas ASM sur ce serveur, mais nous laissons comme indiquer la valeur +ASM. Ce champs doit particulièrement servir en RAC pour indiquer sur qu’elle instance ASM nous nous trouvons. Nous laissons le port par défaut pour le deamon Dbvnet (c’est la couche qui communique entre la primaire et les standby). Il est intéressant de noter que l’outil va créer un schéma sur WINDB. Ce sera le repository de l’application. |
|
|
Nous donnons le nom du serveur de destination (bien penser à le mettre dans le /etc/hosts). L’emplacement du soft dbvisit sur le serveur de destination (je n’ai pas choisi le défaut lors de l’installation pour être conforme à la documentation du guide d’installation et aussi de l’admin guide par la suite). Tout le reste peut être laissé par défaut à l’exception du chemin des destinations des archivelogs sur le DR. Renseigner donc ce chemin et créez le si il n’existe pas déjà. |
 |
Cliquer directement sur Next. J’aurais aimé testé sur du RAC-RAC mais hélas cela fait trop de machines virtuelles à démarrer et je n’ai que 8Go sur mon PC |
 |
Mail obligatoire. Ici j’ai choisi Yes pour « Success Mail », mais dans le cas d’une production le choix No semble plus judicieux (mail uniquement en cas d’erreur ou dépassement de seuil) |
|
|
Ici l’IHM est spécifique au management des archivelogs, et les choix sont clairs une fois de plus, et dans un anglais facile à comprendre Le management par Dbvisit n'est pas obligatoire.
(Remarque : Num Archsource To Keep apparait en double, cela ne vient pas de Dbvisit mais de mes captures d’écran) |
 |
Tout par défaut |
 |
Pour finir on précise dans quel tablespace l’utilisateur dbvisit7 précédemment définit va créer ses objets et son tablespace temporaire. Histoire de faire un reproche : je ne vois pas trop bien pourquoi cela arrive à la fin et pas précédemment au moment de la définition du user… |
 |
Eh non ce n’est pas fini. Nous avons juste fini la configuration du DDC file (fichier regroupant toute la configuration) et la création du user propriétaire du repository ainsi que les objets associés. Il faut cliquer maintenant su « Create Standby DB » car nous avons en fait déjà fait le « Run DBvisit Standby » dans le paragraphe Installation du softaware. |
 |
Cliquer sur Continue |
|
|
Direct Copy : Ici comme la base n’est pas très volumineuse, nous ne passons pas par RMAN, les datafiles seront donc copiés à chaud (comme nous pourrons le constater dans l’alert.log plus loin)
File Compression : lors du transfert ssh des datafile (ou des backups RMAN si choisi précédemment), le transfert sur le réseau peut être allégé par compression
File Location : ici nous pouvons mettre des chemins alternatifs pour le serveur de standby.
Online Log Locations : Les redologs aussi peuvent avoir un chemin alternatif sur la standby.
Cliquer sur Create Standby Database |
 |
C'est parti! |
 |
Il est intéressant de suivre la création de la dataguard… oups pardon… standby dans l’alert.log de la primaire : Clearing standby activation ID 1782213086 (0x6a3a69de) Nous pouvons voir que les tablespaces sont copié à chaud (dans notre cas) avec un « begin backup » préalable mais aussi nous pouvons voir que les « standby redologfile » sont aussi générés. |
 |
Et voilà un petit coup d'oeil sur le dashboard… tout va bien, DBvisit dit que tout est synchro à l’archivelog près. |
. A noter que le produit est donc compatible RAC.
.
L’activation de la licence
Il faut configurer une base de données pour pouvoir activer la licence. Nous pouvons donc renseigner la licence maintenant. La licence trial est valable un mois et pour une seule base de données. Rien ne vous empêche de l'installer sur plusieurs bancs qui ne communiquent pas par la couche dbvnet , mais elle est horodatée.
La base de données qui tourne actuellement sur mon banc oradbm02 se nomme WINDB.
[oracle@oradbm2 standby]$ ./dbvisit -lic WINDB XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
=============================================================
Dbvisit Standby Database Technology (7.0.22.12963) (pid 3200)
dbvisit started on oradbm2: Tue Nov 11 22:12:18 2014 ()
=============================================================
Dbvisit Standby license information for: WINDB
customer_seq=1
customer_key_seq=0
license_type=DEMO (0)
expiry_date=2014-12-02
=>Update with license key: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX? <Yes/No> [Yes]:
License updated.
Status: Valid
=============================================================
dbvisit ended on oradbm2: Tue Nov 11 22:12:29 2014
=============================================================
Les transferts et les apply
Et maintenant ? Ça marche ? Ça synchronise… ? …non. La standby est configurée mais pas le transfert des archivelogs.
Un test simple est de remplir les redologs pour qu’ils s’archivent, avec quelque « alter system switch logfile » pour les plus impatients. Et si nous regardons le dashboard, il n’y pas de synchronisation :
SQL> insert into test select * from test
4194304 rows created.
SQL> commit;
SQL> alter system switch logfile;
La primaire utilise le redolog avec la séquence 23 et donc le dernier archivelog généré est le 22, mais le dernier archivelog transféré reste le 17:
Le transfert peut être lancé manuellement, c’est ce que nous faisons (ci-dessous) par l’interface graphique (HOME > RUN > RUN INTERACTIVE ; onglet Primary Server à Run Action (Default) à Run):
Nous pouvons retrouver nos archivelogs transférés dans /oradata/stbyarch/WINDB sur le serveur oradbm03 :
[oracle@oradbm3 WINDB]$ ls
1_15_863369310.arc.gz 1_17_863369310.arc.gz 1_19_863369310.arc.gz 1_21_863369310.arc.gz
1_16_863369310.arc.gz 1_18_863369310.arc.gz 1_20_863369310.arc.gz 1_22_863369310.arc.gz
Notez qu'ils sont compressés (par gzip) car nous avons activé la compression lors de la mise en place de la configuration du transfert.
Le dashboard montre bien le transfert des archivelogs jusqu’à la séquence 22 inclus mais toujours pas d’apply (synchro):
Nous continuons donc en mode manuel et lançons l’apply à la main (HOME > RUN > RUN INTERACTIVE ; onglet Standby Server à Run Action (Default) à Run):
Une fois l’apply exécuté, nous pouvons voir que notre standby a enfin l’archivelog 22 d’intégré :
Alors à ce moment-là, si vous êtes DBA, vous avez l’habitude qu’on vous pose la question qui fatigue : oui mais comment peut-on être sûr que la standby est synchronisée ? Vous expliquez alors que les SCN sont proches ou bien que les séquences d’archivelog sont identiques… mais cela ne convainc pas, ce n’est pas du concret. L’interlocuteur veut comparer les données, il veut en général compter les lignes, la preuve ultime, la seule à ses yeux ! … eh bien faisons lui plaisir … ouvrons la base en Read-Only... pour qu’il les comptes ses 
de lignes !
Et comptons les lignes sur la standby
SQL> select count(*) from winroc.test;
COUNT(*)
----------
4194304
Voilà notre interlocuteur septique est convaincu. Il ne reste plus qu’à relancer la base en mode « standby »:
Et voilà la prise en main est simple. Ci-dessous quelques exemples des même commandes précédentes mais en mode ligne de commandes :
pour un transfert:
[oracle@oradbm2 standby]$ pwd
/usr/local/dbvisit/standby
[oracle@oradbm2 standby]$ ./dbvisit WINDB
=============================================================
Dbvisit Standby Database Technology (7.0.22.12963) (pid 4293)
dbvisit started on oradbm2: Thu Nov 13 21:15:50 2014 ()
=============================================================
>>> Obtaining information from standby database (RUN_INSPECT=Y)...
>>> Sending heartbeat message... - done.
>>> Checking Dbvisit Standby for configurational differences between oradbm2 and oradbm3...
No configurational differences found between oradbm2 and oradbm3.
>>> Log file(s) for WINDB will be transferred from oradbm2 to oradbm3...
> Transferring 'o1_mf_1_23_b650459f_.arc.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [5895 KB/s] - done.
1 archive log transfer to oradbm3 for WINDB completed.
Last sequence was 23.
>>> Dbvisit Archive Management Module (AMM)
Config: number of archives to keep = 0
Config: number of days to keep archives = 3
Config: archive backup count = 0
Config: diskspace full threshold = 90%
Current disk percent full (/oradata) = 8%
Number of archive logs deleted = 0
=============================================================
dbvisit ended on oradbm2: Thu Nov 13 21:16:00 2014
=============================================================
pour un apply, idem mais à partir du serveur de la standby:
oracle@oradbm3 standby]$ pwd
/usr/local/dbvisit/standby
[oracle@oradbm3 standby]$ ./dbvisit WINDB
Et les reports aussi pour voir le gap entre la primaire et la standby:
[oracle@oradbm2 standby]$ ./dbvisit -i WINDB
=============================================================
Dbvisit Standby Database Technology (7.0.22.12963) (pid 4854)
dbvisit started on oradbm2: Thu Nov 13 21:27:14 2014 ()
=============================================================
Dbvisit Standby log gap report for WINDB at 201411132127:
-------------------------------------------------------------
Standby database on oradbm3 is at sequence: 23.
Primary database on oradbm2 is at log sequence: 24.
Primary database on oradbm2 is at archived log sequence: 23.
Dbvisit Standby last transfer log sequence: 23.
Dbvisit Standby last transfer at: 201411132115.
Archive log gap for WINDB: 0.
Transfer log gap for WINDB: 0.
Standby database time lag (DAYS HH:MI:SS): 1 23:00:29.
=============================================================
dbvisit ended on oradbm2: Thu Nov 13 21:27:17 2014
=============================================================
Les transferts automatiques et apply automatiques
Les transferts manuels c’est bien, les automatiques c’est mieux.
Nous pouvons soit utiliser le scheduler de DBVisit (interface graphique ci-dessous) :
(Petit soucis de capture d’écran, je n’ai que pour le transfert et je n’ai plus de licence pour refaire des captures d’écran)
Nous pouvons aussi utiliser la crontab des serveurs pour y programmer les scripts de transfert et d’apply que nous avons lancé dans le paragraphe précédent.
Exemple :
Sur la primaire toutes les 20 minutes tous les jours, nous programmons un transfert d’archivelog
[oracle@oradbm2 ~]$ pwd
[oracle@oradbm2 ~]$ crontab -e
00,20,40 * * * * /usr/local/dbvisit/standby WINDB >>/dev/null 2>&1
Sur la standby toutes les 20 minutes tous les jours, nous programmons un apply (mais avec un décalage sur le transfert)
[oracle@oradbm3 ~]$ pwd
[oracle@oradbm3 ~]$ crontab -e
10,30,50 * * * * /usr/local/dbvisit/standby WINDB >>/dev/null 2>&1
L'avantage de la syntaxe est que si la standby passe primaire et la primaire standby il n’y a rien à changer au niveau du schedule : la commande reste la même.
Autre chose intéressante, c’est ici que l’on peut gérer le start automatique des bases de données. Pour la primaire, onglet Primary Server, si vous n’avez pas de couche grid (ASM), vous pouvez activer l’autostart de la base primaire en OPEN au démarrage du serveur (partie Autostart sur la capture d’écran ci-dessus). Et pour la base standby, onglet Standby Server, vous pouvez configurer l’autostart de la base standby en MOUNT au démarrage du serveur.
Switchover
Pour faire un switchover (une inversion de rôle), une seule commande suffit, comme le permet aussi la couche Database Broker d’Oracle avec Dataguard mais ici nous n’avons pas de licence Entreprise Edition.
Evidement une standby ne se réplique pas en temps réel comme pourrait le faire un Dataguard (suivant sa configuration), il faut donc vérifier que la Standby est bien synchronisé avant. Mais cela n’est pas choquant car un switchover est une opération de maintenance prévue.
Et si on lance un switchover alors qu’il n’y pas de synchronisation que se passe-t-il. Nous retrouverons nous dans un état instable ? Testons :
[oracle@oradbm2 standby]$ ./dbv_oraStartStop switchover WINDB 6666
=============================================================
Dbvisit Standby Database Technology (7.0.22.12958) (pid 4472)
dbv_oraStartStop started on oradbm2: Sun Nov 16 21:27:24 2014 ()
=============================================================
Graceful Switchover starting on Primary Database WINDB.
Timestamp: 201411162127.
>>> Database WINDB will be shutdown and restarted <<<
Ensure Dbvisit is no longer scheduled.
>>> Graceful Switchover will attempt to reset Oracle parameters db_file_name_convert and log_file_name_convert to default values (null strings) in the spfile <<<
Obtaining archive log gap....
Contacting Standby Database WINDB on oradbm3...
Next standby sequence required for recovery (113) for thread 1.
201411162127 - Archive log gap between primary and standby database for thread 1 is 1, and this difference is too much to perform graceful switchover. Please first run dbvisit on oradbm3 to ensure standby database is more up to date
Dbvisit Standby terminated.
Return code = 923
(Tracefile required if contacting Dbvisit Standby support: /usr/local/dbvisit/standby/trace/4472_dbv_oraStartStop_switchover_WINDB_201411162127.trc (server:oradbm2))
Dbvisit a détecté un gap de 1 archivelog; il refuse donc logiquement le switchover. Parfait.
Maintenant synchronisons comme nous l’avons appris précédemment, et aussi désactivons les schedules comme il est conseillé/demandé dans le output de la première tentative de switchover (voir ci-dessus).
[oracle@oradbm2 standby]$ ./dbvisit WINDB
[oracle@oradbm3 standby]$ ./dbvisit WINDB
Maintenant réessayons un switchover. Comme vous l’avez peut être remarqué, dans la première tentative nous avons écrit un chiffre : 6666. Ce chiffre ne correspond à rien, mais il est obligatoire d’en donner un. Pourquoi ? En fait précédemment j’ai dit une seule commande suffit pour le switchover, c’est vrai, sauf que cette seule commande, il faut la lancer sur les 2 nœuds (primaire et standby) et avec le même chiffre, c’est une sécurité sur le point de synchronisation (c’est ce que j’en ai déduit après analyse des logs de l’exécution ci-dessous). Il faut lancer donc la commande switchover avec le même numéro sur les 2 noeuds sinon le switchover ne se fera pas.
[oracle@oradbm2 standby]$ ./dbv_oraStartStop switchover WINDB 6666
=============================================================
Dbvisit Standby Database Technology (7.0.22.12958) (pid 4658)
dbv_oraStartStop started on oradbm2: Sun Nov 16 21:29:41 2014 ()
=============================================================
=============================================================
Graceful Switchover starting on Primary Database WINDB.
Timestamp: 201411162129.
>>> Database WINDB will be shutdown and restarted <<<
Ensure Dbvisit is no longer scheduled.
>>> Graceful Switchover will attempt to reset Oracle parameters db_file_name_convert and log_file_name_convert to default values (null strings) in the spfile <<<
Obtaining archive log gap....
Contacting Standby Database WINDB on oradbm3...
Next standby sequence required for recovery (114) for thread 1.
Archive Log Gap for thread 1 is: 0. This is correct to continue.
Please enter unique key to begin graceful switchover for database WINDB.
The same key must be entered on both primary and standby server.
Please start command: dbv_oraStartStop switchover WINDB
on oradbm3 if not already started.
Batch key will be used: 6666
Key 6666 entered.
Contacting oradbm3 to ensure the same unique key is entered for WINDB.
Waiting for Key 1 on oradbm3...
Checkpoint 1 completed. Key found on oradbm3
Waiting for Checkpoint 2 on oradbm3...
Checkpoint 2 completed. Key found on oradbm3
Waiting for Checkpoint 3 on oradbm3...
Checkpoint 3 completed. Key found on oradbm3
Shutting down regular Database WINDB...
Regular Database WINDB shutdown successfully.
Starting Regular Database WINDB...
Regular Database WINDB started restrict.
Performing Oracle Checkpoint.
Waiting 3 seconds for log switch completion...
Creating standby control file as '/usr/local/dbvisit/standby/tmp/GS/WINDB/X.dbvisit.6666.WINDB.standbycontrolfile'...
Waiting for Checkpoint 4 on oradbm3...
Checkpoint 4 completed. Key found on oradbm3
Copying new archives for WINDB to oradbm3...
Compressing o1_mf_1_114_b6l2clmc_.arc...
> Transferring 'o1_mf_1_114_b6l2clmc_.arc.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [5837 KB/s] - done.
Compressing o1_mf_1_115_b6l2dxq5_.arc...
> Transferring 'o1_mf_1_115_b6l2dxq5_.arc.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [3251 KB/s] - done.
Shutting down regular Database WINDB...
Regular Database WINDB shutdown successfully.
Copying redo logs ... this may take a while...
Compressing X.dbvisit.6666.WINDB.redo_1.log...
> Transferring 'X.dbvisit.6666.WINDB.redo_1.log.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [4304 KB/s] - done.
Compressing X.dbvisit.6666.WINDB.redo_2.log...
> Transferring 'X.dbvisit.6666.WINDB.redo_2.log.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [14412 KB/s] - done.
Compressing X.dbvisit.6666.WINDB.redo_3.log...
> Transferring 'X.dbvisit.6666.WINDB.redo_3.log.gz' to server oradbm3:7890
Progress: 0%...20%...40%...60%...80%...100% [13452 KB/s] - done.
Waiting for Checkpoint 5 on oradbm3...
Checkpoint 5 completed. Key found on oradbm3
Backing up current control files for WINDB oradbm2...
Database WINDB on oradbm2 is already down. No action taken.
Starting Regular Database WINDB...
Regular Database WINDB started nomount.
Control file backed up as /usr/local/dbvisit/standby/tmp/GS/WINDB/X.dbvisit.6666.WINDB.controlfile.
Shutting down standby Database WINDB...
Standby Database WINDB shutdown successfully.
Waiting for Checkpoint 6 on oradbm3...
Checkpoint 6 completed. Key found on oradbm3
Waiting for Checkpoint 7 on oradbm3...
Checkpoint 7 completed. Key found on oradbm3
Waiting for Checkpoint 8 on oradbm3...
Checkpoint 8 completed. Key found on oradbm3
Waiting for Checkpoint 9 on oradbm3...
Checkpoint 9 completed. Key found on oradbm3
Waiting for Checkpoint 10 on oradbm3...
Checkpoint 10 completed. Key found on oradbm3
Waiting for Checkpoint 11 on oradbm3...
Checkpoint 11 completed. Key found on oradbm3
Waiting for Checkpoint 12 on oradbm3...
Checkpoint 12 completed. Key found on oradbm3
Database WINDB on oradbm2 is already down. No action taken.
Starting Regular Database WINDB...
Regular Database WINDB started nomount.
STANDBY control file(s) restored from /usr/local/dbvisit/standby/tmp/GS/WINDB/X.dbvisit.6666.WINDB.standbycontrolfile.
Shutting down standby Database WINDB...
Standby Database WINDB shutdown successfully.
Starting Standby Database WINDB...
Standby Database WINDB started .
Waiting for Checkpoint 13 on oradbm3...
Checkpoint 13 completed. Key found on oradbm3
Waiting for Checkpoint 14 on oradbm3...
Checkpoint 14 completed. Key found on oradbm3
File /usr/local/dbvisit/standby/conf/dbv_WINDB.env copied to
/usr/local/dbvisit/standby/conf/dbv_WINDB.env.201411162129.
Dbvisit Database configuration (DDC) file /usr/local/dbvisit/standby/conf/dbv_WINDB.env has been updated
and variables have been reversed between primary and standby server.
SOURCE=oradbm3 DESTINATION=oradbm2.
Waiting for Checkpoint 15 on oradbm3...
Checkpoint 15 completed. Key found on oradbm3
Waiting for Checkpoint 16 on oradbm3...
Checkpoint 16 completed. Key found on oradbm3
Uncompressing o1_mf_1_114_b6l2clmc_.arc.gz...
Uncompressing o1_mf_1_115_b6l2dxq5_.arc.gz...
Tempfiles dropped.
Waiting for Checkpoint 17 on oradbm3...
Checkpoint 17 completed. Key found on oradbm3
Waiting for Checkpoint 18 on oradbm3...
Checkpoint 18 completed. Key found on oradbm3
Graceful switchover completed.
This database (WINDB) is now a standby database.
To keep this new standby database in synch,
reschedule Dbvisit as per normal:
dbvisit WINDB
=============================================================
dbv_oraStartStop ended on oradbm2: Sun Nov 16 21:34:21 2014
=============================================================
Remarque : Si vous ne lancez pas la commande « ./dbv_oraStartStop switchover WINDB 6666 » sur le serveur de la standby, la commande « ./dbv_oraStartStop switchover WINDB 6666 » lancé sur le serveur de la primaire reste en attente jusqu’à ce que vous lanciez la bonne commande sur la standby.
Il est intéressant de lire le log du output (et aussi les alert.log des 2 nœuds), il permet de suivre toutes les nombreuses étapes nécessaire à un switchover sur une standby : vérification du gap, création du standby controlfile, archivage des redo courant et transfert, cancel du recover sur la standby, apply des nouveaux archivelog sur l’ex standby, copie des redolog, apply des redolog sur la nouvelle primaire, génération des nouveaux redo standby, recréation des nouveaux tempfile…
Failover
Un failover est un changement de rôle non réciproque. La standby devient primaire, et la primaire … meurt. Un failover n’est pas une opération de maintenance mais une opération d’urgence… par exemple un stagiaire qui croyant être sur une base de dev fait un …
[oracle@oradbm3 oradata]$ rm -fr WINDB/*
… sur la base primaire (ici sur oradbm03 suite à notre switchover précèdent)
Qu’il est c.. ce stagiaire ! Soit dit en passant comment un stagiaire peut-il se retrouver sur une production hein ? Bon toujours est-il qu’il faut réagir rapidement : restauration ? non nous avons une standby : failover toute !
Le dashboard indique bien quel la primaire est down :
Une seule commande pour remettre en urgence la standby en primaire et par la même occasion accepter la perte des transactions non répliquées de l’ancienne primaire.
[oracle@oradbm2 standby]$ ./dbv_oraStartStop activate WINDB
=============================================================
Dbvisit Standby Database Technology (7.0.22.12958) (pid 4004)
dbv_oraStartStop started on oradbm2: Sat Nov 22 21:51:07 2014 ()
=============================================================
Activating means this database will become a Primary Database.
It will no longer be a Standby Database for WINDB on oradbm3.
Activation cannot be reversed.
=>Activate Standby Database on oradbm2? <Yes/No> [No]: Yes
Are you sure? <Yes/No> [No]: Yes
Activating now...
Activate Standby Database WINDB...
Standby Database WINDB activated.
Shutting down standby Database WINDB...
Standby Database WINDB shutdown successfully.
Starting Activated Standby Database WINDB...
Activated Standby Database WINDB started .
File /usr/local/dbvisit/standby/conf/dbv_WINDB.env copied to /usr/local/dbvisit/standby/conf/dbv_WINDB.env.201411222151.
Dbvisit Database configuration (DDC) file /usr/local/dbvisit/standby/conf/dbv_WINDB.env has been updated and variables have been reversed between primary
and standby server.
SOURCE=oradbm2 DESTINATION=oradbm3.
Activation complete. Please ensure a backup of this Database is made.
Old archives from before the activation should be removed to avoid mix-up between new and old archive logs.
Database has no tempfiles defined. You may need to add tempfiles to this database using ALTER TABLESPACE ADD TEMPFILE command.
If the Dbvisit Standby process is to be reversed, then
Database on oradbm3 will need to be rebuilt as a Standby Database.
=============================================================
dbv_oraStartStop ended on oradbm2: Sat Nov 22 21:51:35 2014
=============================================================
Remarque : Ici la sécurité du failover qui serait lancé par erreur est une double confirmation, le script demande deux fois de confirmer le failover.
J’avais noté dans mes notes :
SQL> alter tablespace TEMP add tempfile '/oradata/WINDB/temp01.dbf' size 100m;
(Je suppose que j’avais donc dû le faire pour remettre dans tablespace temporay un tempfile. Pour le switchover cela se fait seul. Mais je n’ai plus de licence valide pour retester)
Une fois le failover fini, cela signifie que nous n’avons plus de DR, il faut donc régénérer une standby. C’est la même opération que fait dans le paragraphe Configuration de la base de données. Vous pouvez le faire en mode graphique ou bien en mode script interactif.
[oracle@oradbm2 standby]$ ./dbvisit_setup
Ensuite il faut répondre à toutes les questions, les mêmes que dans l’interface graphique vu au paragraphe Configuration de la base de données.
Le reporting
Dans les dashboards affichés jusqu’à présent dans cet article, il manque les courbes : Archive Log Transfer Time et Archive Log Gaps, car je n’avais pas compris qu’il fallait installer le plugin flash. Sinon une fois installé voici ce que donne la page dashboard :
L’affichage des deux courbes est intéressant. La première « Archive Log Transfert Time » permet de visualiser le temps que prennent les transferts des archivelogs. La deuxième «Archive Log Gaps » de visualiser les gaps de transfert et d’apply d’archivelog, et donc éventuellement d’ajuster les schedules des transferts et les schedules d’apply de log : par exemple augmenter la fréquence de transfert pour éviter une grosse perte en cas de failover, et pourquoi pas diminuer les apply pour avoir un décalage dans le temps sur la standby pour pouvoir l’ouvrir en readonly « dans le passé ».
Le reporting à proprement parler consiste en trois onglets dans le menu Reporting accessible à la page Main Menu.
L’onglet « Dbvisit Standby reporting » :
Affiche les mêmes informations que celles du dashboard mais nous pouvons sélectionner une plage de date.
L’onglet « Transfer process reporting » :
Cet onglet permet de visualiser la quantité en megaoctet que prennent les transferts des archivelog sur le réseau, la taille générée d’archivelog par jour et le nombre d’archivelog généré par jour.
(Evidement les courbes ci-dessus ne sont pas très parlantes car je n’ai testé que très ponctuellement Dbvisit, la base de données a passé plus de temps éteinte qu’allumée, et il n’y avait aucun flux continue de production)
L’onglet « Standby sync status » :
Je n’avais pas pris de capture d’écran lors de mes tests. Donc ci-dessous une capture d’écran trouver dans la documentation :
Cet onglet permet de voir le gap en détail entre le primaire et la standby. Nous voyons la différence au niveau SCN (avec la correspondance date et heure : presque 2 jour de différences ici), nous voyons que la standby a besoin d’appliquer l’archivelog 424 qui date du 10 janvier 2014 02h25.
Et chose très intéressante ! Sur le datafile numéro 4 il y a eu une transaction faite en nologging (le 17/12/2014) alors que l’on a un standby, c’est mal ! Cela signifie qu’une transaction n’a pas été inscrite dans l’archivelog et donc non transféré et donc non appliqué sur la standby et donc à jamais perdu sur la standby. Il faudrait que la primaire soit en « force logging » pour empêcher cela. J’ai donc cherché dans la documentation Dbvisit si on pouvait réparer un datafile de façon unique et oui cela est possible comme suit. Si cela avait été notre base WINDB la commande aurait été :
[oracle@oradbm2 standby] $ ./dbv_functions -a WINDB refresh_datafile 4
Conclusion
Les tests ci-dessus sont plus une prise en main que des tests poussés, cependant la première impression de l’outil est qu’il est très simple à prendre en main. Il permet de générer facilement une standby sans trop connaitre Oracle et la gestion du switchover et failover est simple.
L’outil peut sans problème remplacer une dataguard sauf si la réplication a besoin d’être en temps réel (mode MAXPROTECTION ou MAXAVAILABILITY), en revanche pas de soucis pour le mode MAXPERFORMANCE dont l’application des redologs ne serait pas configuré "au fil de l’eau". (MAXPERFORMANCE peut être presque du temps réel si la dataguard est en « using current logfile » c’est juste que la primaire n’attend pas les acknowledges de la dataguard : Voir l’article Dataguard... en gros )
C’est donc une très bonne alternative à Dataguard si le temps réel n’est pas requis et que vous n’avez pas besoin de Entreprise Edition, et en plus vous ferez une bonne économie. Sinon pas de soucis Dbvisit Standby est Oracle Gold Partner ;-)
{jcomments on}