!
!
!
!
!
!
!
!

Table de matières
Table de matières 1
Préambule 1
Data Guard 1
Préambule
Tous les documents suivants sont accessibles uniquement à mes clients. Pour pouvoir y accéder, un mot de passe associé à un nom utilisateur est nécessaire. Pour les avoir, demandez-les par email ou bien utilisez les informations dont vous disposez dèja.

Data Guard
Cet article présente une implémentation de data guard, une amélioration 9i de la standby database.
La standby database est apparue en Oracle 7.3. Elle est une base de données en perpétuelle restauration avec les redologs ou les archives de redo logs de la base source et qui lors de la chute de celle-ci reprend ses activités. Dans les versions antérieures à 8i, le DBA devait transférer les redo logs vers leur destination manuellement, en 8i ceci peut être effectué automatiquement. Pour la vérification de la disponibilité de l’option, vérifiez les options (v$options) l’y concernant : Managed Standby à TRUE. A partir de la 9i, les rôles de la base primaire et de la standby peuvent être échangés.
Comme la standby est alimenté par les redo logs archivés (ou les redo logs mêmes) de la base source, nous devons indiquer l’emplacement de ces fichiers. Un nouveau paramètre est introduit en V8, standby_archive_dest, qui indique le répertoire d’arrivage des archives.
Le concept data guard (standby database) repose sur l’existence de plusieurs entités :
  • Primary Database – La base de production qui est l’origine de de(s) standby databases. Les archive logs de la primary database sont transférés et appliqués à la standby database qui se trouve dans un état de perpétuel recouvrement. Une standby est associée à une unique primary database, mais une primary database peut être associée à plusieurs standby.
  • Standby Database – Une des répliques de la primary database.
  • Log Transport Services – Contrôlent le transfert automatique des archives de redo log de la base primaire vers la (les) standby.
  • Oracle Net – La communication entre les divers bases se fait via Oravcle Net (ancien NET8).
  • DMON - Un nouveau process monitorise la base de production et celle de secours. Ce process peut être piloté soit manuellement (dgmgrl) soit avec le DataGuard Manager. Les process DMON existent sur les deux machines (prod/secours).
  • Log Apply Services – Appliquent les archives des redo logs à la standby database (MPR - Managed Recovery Process).
L’intégralité de ce document WORD (1.5M) est disponible à l’adresse :
http://tafora.dyndns.biz/cli/dataguard/dataguard.doc

Copyright © 1998-2002 Radu Caulea, TAFORA MAJ 06/11/2006 !
Commentaires et suggestions radu[CHEZ]tafora.fr