Discussion :

[scheu]

Bonjour

J'ai une config Dataguard en Oracle 9i sous Windows avec une primary et une standby
En cas de failover (crash sur ma primary), je vérifie que tous les redo archivés ont bien été transférés et réappliqués sur ma standby (c'est bien le cas), puis j'applique sur ma standby les commandes suivantes (commandes de la doc oracle) sans aucune erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;

Le problème c'est que les transactions validées qui étaient dans le redo courant de la base primary avant le crash n'ont pas été réappliqués sur ma base standby
Aurais-je oublié quelque chose ? J'ai entendu parlé des standby redo logs mais j'en avais bien créé sur ma standby

Merci de votre aide

[mildiou51]

Oui, mais poru que les standbys redologs soient utilisés, il faut envoyer par LGWR... A quoi ressemble ton log_archive_dest_2 ?
Sinon, avec un failover, perte de données possibles... Il faudrait simplement provoquer 1 ou 2 switchs sur la primary avant tout ceci (histoire justement que les transactions courantes soient bien jouées).

[scheu]

Merci pour ta réponse

Mon paramètre log_archive_dest_2 est positionné à 'SERVICE=DB9I2' où DB9I2 est le nom de service correspondant à ma base standby, d'ailleurs les redo archivés sont envoyés correctement vers ma standby et rejoués sans problème
Dans le scénario où il y a un crash sur la primary, il est impossible de faire un switchover
Je voulais savoir si lors d'un failover c'est possible de rejouer sur la standby (qui deviendra la future primary) les transactions validées dans le redo log courant de la primary avant le crash. Est-ce le rôle des standby redo logs ?

Quelqu'un saurait-il si c'est possible et comment s'y prendre ?

[orafrance]

as-tu lu la note 227196.1 de Metalink ?

Tu ne peux pas redémarrer la primaire pour faire un checkpoint ?

Pour info :

2.1 Failover on Physical Standby Database

A Failover can be performed when all or most of the information until the
Unavailability of the Primary Database was propageted to the Standby. The
usage of Standby RedoLogs ia a great advantage here. If you have no Standby
RedoLogs available, you will always encounter some Data Loss (depending on
the Changes since the latest LogSwitch). To perform a Failover just follow
these steps:

- The Primary Database is down for any reason

- Verify a Standby RedoLog is in use for Primary current Online RedoLog. You
then find in the ALERT.LOG of the Standby something like:

RFS: Successfully opened standby logfile 4:'C:\ORACLE\ORADATA\PRIMARY\STBY01.LOG'

- If this is the case run the following commands:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

This cancels the normal managed Recovery. To get the Standby RedoLog Information
is still required. Therefore issue this command:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

- If a Standby RedoLog is not used for any reason, then run this one:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILE;

Please keep in mind that this one causes (Minimal) Data Loss as the latestet
information from the down Primary Database is not available anymore.

- Once this is complete (This performs a complete Recovery or incomplete
Recovery until the last SCN included in the latest archived Log available at
the Standby), you can now make the Standby Database a Primary:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY

WARNING: This will only succeed if the correct RECOVER FINISH-statement was
issued before. If you forgot the 'SKIP STANDBY LOGFILE' although you
have no Standby RedoLogs, the COMMIT to Switchover will fail with the
error that more Media Recovery is required here.

- If the COMMIT TO SWITCHOVER fails for any reason you have to use the ACTIVATE
command which forces the Failover (and may cause Data Loss !!)

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

- Shutdown and restart the Databse after this command ended successfully:

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

- Now the Standby is open as a new Primary Database

[scheu]

Merci pour la note orafrance
En fait je fais juste des tests pour maitriser Dataguard (je dois le mettre en place dans ma boîte), je n'ai pas rencontré de situation réelle de crash de la primary (enfin pour l'instant)
Je me suis rendu compte qu'en fait les standby redo logs de la standby n'étaient pas utilisés car le LGWR n'était pas utilisé
Mon paramètre log_archive_dest_2 valait 'SERVICE=DB9I2', je l'ai modifié en 'SERVICE=DB9I2 LGWR' , sinon par défaut c'est ARCH et non pas LGWR(c'était sans doute ce que voulait vérifier mildiou51)
Doc Oracle Dataguard 9i :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
5.5.1 Specifying the Process that Transmits Redo Data
To minimize data loss in the event of a primary database failure, you want to copy data from the primary database to the standby database as it is being generated. You can choose to have either the log writer process or the archiver process transmit redo logs to a destination.
 
To specify which process transmits redo data, use either the ARCH or LGWR attribute of the LOG_ARCHIVE_DEST_n initialization parameter.
 
Attribute Example Default 
{ ARCH | LGWR}
 LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR'
 ARCH
 
 
The LGWR and ARCH attributes are mutually exclusive. Therefore, you cannot specify both attributes for the same destination. However, you can specify either the LGWR or the ARCH attribute for individual destinations. This allows you to choose the log writer process to transmit redo data for some destinations, while the archiver process transmits redo data to other destinations.
 
Choosing the ARCH attribute indicates that an archiver process (ARCn) will archive the current redo logs to the associated destination when a redo log switch occurs on the primary database. This is the default setting.
 
Choosing the LGWR attribute indicates that the log writer process (LGWR) will transmit redo data to the associated destination as it is generated. As redo is generated for the primary database, it is also propagated to the standby system where the RFS process writes the redo to either a standby redo log or to a standby archived redo log.

Maintenant ça marche ! Encore merci à vous

[ZashOne]

un petit conseil pour ceux qui comme scheu ou moi il y a quelqes semaines doivent mettre en place un environnement dataguard.

Je vous consei de lire la doc officielle data guard broker et de mettre en place un environnement "broker" au dessus de dataguard.

-La configuration dataguard est alors distribuee sur toute les bases (primaire et standbys)
-les failover et switchover se font en une commande
-Sur mes configs, la broker n a pas rajouter la moindre surcharge
-Les diagnostiques pevent se faire sur n importe quel base via un bete script shell

(Il y a juste le parametrages du listener qui est un peu compliqué -> developpez/metalink/google/...)

[mildiou51]

Mon paramètre log_archive_dest_2 valait 'SERVICE=DB9I2', je l'ai modifié en 'SERVICE=DB9I2 LGWR' , sinon par défaut c'est ARCH et non pas LGWR(c'était sans doute ce que voulait vérifier mildiou51)

Absolument
Si LGWR n'est pas spécifié, pas moyen d'utiliser les standby redologs en face. D'ailleurs regarde, tu as pas mal de petits trucs mettables dans le log_archive_dest_2 pour tuner la taille des paquets à envoyer (donc la perte possible), le nombre d'erreurs avant que la primary n'arrête d'envoyer, ...