On a tous déjà été confronté à la mise an place d’une standby database en version Standard Edition.
Si la création de la base de données n’est généralement pas un problème, le transport des archivelogs, leurs applications sur la base standby et la supervision de ces processus restent des éléments très sensibles.
Une solution existe pourtant, elle nous est proposée par la société Dbvisit avec son produit Standby.
Je vous propose de vous présenter l’installation et la mise en œuvre de ce produit.
Vous pourrez juger de sa simplicité d’installation et de mise en œuvre.

Description de l’environnement

Le POC a été réalisé sur 2 machines virtuelles Virtualbox en OEL 6.9 (testprmy et teststby) avec Oracle Database 11.2.0.4 qui sont installées sur un poste Windows.
Une fois l’installation de Dbvisit Standby effectuée sur les 2 serveurs et les démons dbvnet, servant à la communication inter-serveurs en lieu et place de ssh, et dbagent, utilisé pour la communication avec la console centralisée, démarrés, on peut passer à la configuration de l’instance Standby.

Configuration de l’environnement Standby

Pour cette présentation, j’ai choisi d’utiliser l’interface graphique, mais toutes ces opérations sont réalisables en ligne de commande.

        Référencements des hosts

La première étape consiste à référencer les hosts.
Cliquez sur le pavé « MANAGE HOSTS »

puis sur le bouton « NEW« .

Remplissez la grille comme demandé

puis « SAVE » pour sauvegarder les informations.
Si la connexion entre les 2 serveurs s’effectue correctement, une coche verte apparait au niveau du serveur qui vient d’être ajouté.

Effectuer la même opération pour le second serveur.
 

          Création de la configuration Standby

Une fois les hosts définis, on peut créer la configuration Standby. C’est un préalable à la création de la base Standby.
Cliquez sur le pavé « MANAGE CONFIGURATION »

puis sur le bouton « NEW« .

Sélectionnez le nom du serveur supportant la base primaire.

Accepter la clause de licensing en faisant défiler l’ascenseur de la boite de dialogue.
Sélectionnez la base primaire.

Des informations complémentaires s’affichent, libre a vous de les modifier si nécessaire.
Sélectionnez le serveur supportant la base Standby.
Si les informations affichées conviennent, saisir la clef de licence, puis « submit ».
Si la configuration est correcte et que les 2 serveurs (primaire et standby) communiquent bien entre eux, le statut de la configuration est au vert.

          Création de la base de données Standby

On peut maintenant créer la base de données Standby.
Cliquez sur le pavé « CREATE STANDBY DATABASE ».

Sélectionnez la configuration qui vient d’être créée

puis « NEW DATABASE ».
La taille de la base apparait, ainsi que les options de paramétrage de la configuration.
Ceux-ci peuvent être modifiés maintenant si nécessaire, ou plus tard en passant par le pavé « MANAGE CONFIGURATIONS » et en cliquant sur le stylo au bout de la ligne correspondant à notre configuration.
La mise en place de la Standby se fait par l’intermédiaire d’une sauvegarde Rman.
On renseigne ici le Directory de stockage des fichiers de sauvegarde sur le serveur source et le serveur cible. Assurez-vous de disposer de la place nécessaire au stockage des fichiers sur ces 2 répertoires. La copie vers le serveur cible est assurée par Dbvisit.

Lancez le processus en cliquant sur « Submit ».
Le process se lance en tâche de fond. Il peut être plus ou moins long en fonction de la taille de la base primaire.
Une fois le traitement terminé avec succès, on peut contrôler par la console la création de la base Standby et le décalage qui existe entre les 2 bases.

          Contrôle des gaps

Cliquez sur le pavé « DATABASE ACTIONS« .

Dans les Actions correspondant à la configuration choisie, sélectionnez les feuillets.

Un popup apparait avec le résultat de la recherche.

On constate un décalage entre les 2 bases. Il correspond à l’activité de la base primaire durant la création de la base Standby.

          Mise en place des process de transport et d’application des archivelogs

Il faut maintenant mettre en place les process de transport et d’application des archivlogs sur les 2 serveurs. Pour cela, à l’aide de votre outil de scheduling favori (dans notre cas crontab) planifiez les tâches suivantes :
Sur le serveur primaire, lancez le transport des archivelogs, par habitude j’utilise la crontab du user root.

crontab -e
0,10,20,30,45,50 * * * * su - oracle -c '/u01/app/dbvisit/standby/dbvctl -d TESTJFF >> /tmp/dbvctl_TESTJFF.log'

Sur le serveur standby, lancez l’application des logs. Prenez soin de décaler les 2 planifications.

crontab -e
03,13,23,33,43,53, * * * * su - oracle -c '/u01/app/dbvisit/standby/dbvctl -d TESTJFF >> /tmp/dbvctl_TESTJFF.log'

On peut constater que la commande est identique dans les 2 cas. Il n’y a donc rien à faire suite à un switchover.
On a pris soin de décaler légèrement le lancement du transfert des archivelog et leurs application sur la base standby pour s’assurer de la présence des fichiers au moment du lancement du script sur le serveur Standby.

Comment effectuer un switchover

Pour effectuer un swichtover en passant par l’interface graphique, cliquez sur le pavé « PERFORM GRACEFUL SWITCHOVER ».

Sélectionnez la configuration voulue

puis « submit ».
Une fois la bascule effectuée, il faut passer par la console, pavé « MANAGE CONFIGURATIONS » pour actualiser la configuration qui vient de basculer.

Le host source devient teststby et le host destination devient testprmy.
Bien évidemment, ce qui est possible en passant par la console centralisée l’est aussi en ligne de commandes directement sur les serveurs de base de données.
 

Conclusion

On est en présence d’un produit complet, qui satisfera aussi bien les partisans du clic que ceux de la ligne de commande.
Il est simple d’installation, et ne nécessite pas de produits complémentaires. les prérequis en terme d’ouverture de port restent limités.
Le produit nous assiste dans la mise en place de la Standby Database et gère lui-même le transfert des archivelogs. De plus, par défaut, il génère un log switch avant de lancer le transfert s’il n’y a pas eu de génération d’archivelogs depuis le dernier transfert.
Il prend en charge les bases en RAC aussi bien pour la base primaire que pour la base Standby ainsi que le stockage sous ASM.
Autre point, même si ce n’est pas abordé dans l’article, il y a la possibilité de mettre en place des remontées d’alerte soit par mail soit par trappe snmp.
Enfin, et ce n’est pas neutre, il y a la question du prix. La facturation se fait à la base adressée. Dans le cas d’une configuration standalone classique, on a donc 2 bases.
On arrive à un prix public de 3360€ pour un an ou 5600€ pour 3 ans pour un environnement de production (Tarif en Novembre 2017).
Pour un environnement de test, on est à 2100€ pour 3 ans.
C’est à rapprocher du coût de licence supplémentaire engendré par le passage à une version Enterprise de la Base de Données Oracle.