Dbvisit Standby : le test (prise en main)

 

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 :

 

Lire la suite : Dbvisit Standby : le test (prise en main)

Dataguard... en gros

[EDIT : MAJ 14/10/2013 : rajout apport des flashbacks]

[EDIT : MAJ 12/10/2013 : rajout broker]

 Cet article traite de dataguard pour une 11gR2. Il peut être appliqué à une 10gR2, excepté sur certains  points techniques qui seront signalés. Normalement il doit aussi pouvoir s’appliquer à une 12cR1.

L’article a pour objectif de présenter dataguard de l’installation à sa gestion tout au long d’un enchainement logique de manipulation. Il peut être lu comme un TP.

Dans cet article nous allons commencer par configurer une dataguard, mais avec une petite subtilité, la base primaire initiale est sous ASM alors que la base standby sera sous filesystem. Cela permettra de couvrir la création puis la vie d’un datagaurd en rajoutant le facteur deux arborescences différentes, mais aussi deux systèmes de fichier différent et voir que cela est possible et fonctionne sans aucuns soucis.

Ensuite nous allons faire le classique switchover, inversion de rôle qui validera que la dataguard est bien fonctionnel dans les deux sens de réplication. Puis le failover pour montrer comment cela fonctionne et ce que cela implique au niveau dataguard par la suite.

Cela étant, nous enchainerons avec  la gestion des archivelog, quand et comment peuvent-ils être supprimés.

Nous enchainerons par la mise en place du broker, l’outil d’administration facultatif de dataguard mais qui peut simplifier l’administration.

Et pour finir, nous mettrons en place les flashbacks pour montrer l’intérêt de ceux-ci après un failover.

 

Lire la suite : Dataguard... en gros