Discussion :

[Pomalaix]

Bonjour à tous

J'ai un client qui a un système standby 8i, et pour limiter les interventions manuelles suite aux incidents possibles, j'essaye d'utiliser le paramètre REOPEN.
Je voudrais qu'un court arrêt de la base standby, voire un redémarrage du serveur, soit transparent quant au transfert et à l'application des archives.

Dans la base maître, je mets donc
LOG_ARCHIVE_DEST_2='SERVICE=<standby> REOPEN=600'

Mais je constate à l'usage que ça ne fonctionne pas : dès lors qu'une archive n'a pu être transmise pour cause de base standby indisponible, les transferts cessent.
Visiblement, aucune tentative de réémission des archives n'a lieu.

Pourtant, ma base n'est restée arrêtée qu'une minute, et je la repasse évidemment en "RECOVER MANAGED STANDBY DATABASE".


A la lecture de la doc, je n'ai pas compris clairement si c'était censé fonctionner.
Quelqu'un l'a-t-il déjà réussi ?

Pom'

[LeoAnderson]

D'après la note 122636.1, le reopen ne sert simplement qu'à relancer automatiquement le process d'archiver suite à un freeze pour saturation de l'espace...

Hors, dans ton cas, il semblerait que ce ne soit pas ça, mais la base distante qui soit indisponible, non ?

[Pomalaix]

D'après la note 122636.1, le reopen ne sert simplement qu'à relancer automatiquement le process d'archiver suite à un freeze pour saturation de l'espace...

Hors, dans ton cas, il semblerait que ce ne soit pas ça, mais la base distante qui soit indisponible, non ?

J'avais lu cette note, mais je ne la comprends pas du tout comme toi.
On y dit simplement que sans REOPEN, on ne retentera pas l'archivage en cas d'erreur.

En outre, la doc laisse à penser que ce que je veux faire est possible :

Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to determine whether and when ARCn attempts to re-archive to a failed destination following an error. REOPEN applies to all errors, not just OPEN errors.

(http://www.csee.umbc.edu/help/oracle...hredo.htm#4396)

[LeoAnderson]

Lors de l'incident sur la base destination, quel est l'état de v$archive_dest ? (notamment status ?)

Après le redémarrage de la stand by, comment reprends-tu l'archivage ?
est-ce que le

Code :

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

SQL> alter system archive log start to '<[current destination]>';

comme indiqué dans la note est suffisant ?

[Pomalaix]

Après le redémarrage de la stand by, comment reprends-tu l'archivage ?
est-ce que le

Code :

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

SQL> alter system archive log start to '<[current destination]>';

comme indiqué dans la note est suffisant ?

Comme je disais plus haut, au redémarrage de la standby, je fais uniquement
RECOVER MANAGED STANDBY DATABASE
puisque la mécanique de transfert et d'application est censée être automatique grâce au REOPEN.

Quant à la commande de la doc, elle ne s'applique que si l'archivage sur la base primaire a échoué (en particulier à cause de la saturation du répertoire désigné par LOG_ARCHIVE_DEST). Or il n'a pas échoué, l'archivage local continue de fonctionner sans problème.
Comme l'archivage distant vers le service standby n'est pas déclaré MANDATORY, il est facultatif, et ne bloque donc pas l'archivage de la base primaire en cas d'erreur.

[LeoAnderson]

l'archive_dest_1 a certes continuer, mais la question est de savoir comment l'archive_dest_2 a réagit ? est-il en erreur ? (d'où ma question sur v$archive_dest ! )

et si au lieu de faire un recover sur la standby tu faisais un archive log start to.. histoire de continuer à piloter depuis le maitre ?