Discussion :

[devkais]

Bonjour
Que est-ce qui pourrait provoquer la désynchronisation d'une standby par rapport a une primary dans une solution dataguard ? Comment la détecter ?
Si on doit changer un paramètre ou ajouter un .dbf par exemple dans la primary doit on faire pareil dans la stand by? Merci

[funoracle]

Bonjour,
s'agit-il d'un dataguard "physique" ?
si oui par principe tout ce qui est créé au niveau physique sur la primary est envoyé dans les redo, donc la standby aussi.
Un bon moyen de contrôler la synchro est de vérifier régulièrement l'écart de séquence entre le dernier archivelog de la primary et celui de la standby, trop d'écart = problème potentiel : réseau, base de données, disques.
En fonction du mode de synchronisation choisit (maximum performance, etc ...) l'action corrective peut être différente.

Ensuite les causes, par expérience, sont rarement dues à Oracle. Principalement on trouve :
- une mauvaise manip lors d'un switchover pour une opération de maintenance : tablespace TEMP HS (classique), non redémarrage du process MRP sur la stanby (pourquoi le faire puisque c'est temporaire, j'ai déjà entendu ça), non application des archivelogs en retards, ...
- réseau cassé : voir les écarts d'archivelogs, listener, ...
- disque ou FS plein

Bref, une supervision standard doit permettre d'évacuer 99% des problèmes.

Franck.

[devkais]

Bonjour,
s'agit-il d'un dataguard "physique" ?

Comment puis-je le savoir ? en consultant la base ? une vue du dictionnaire ?

si oui par principe tout ce qui est créé au niveau physique sur la primary est envoyé dans les redo, donc la standby aussi.

Et si la primary redémarre , quel impact sur la standby ?

Un bon moyen de contrôler la synchro est de vérifier régulièrement l'écart de séquence entre le dernier archivelog de la primary et celui de la standby, trop d'écart = problème potentiel : réseau, base de données, disques.

Quel est l'écart max accepté ?

En fonction du mode de synchronisation choisit (maximum performance, etc ...) l'action corrective peut être différente.

Exemples d'actions correctives ?

Ensuite les causes, par expérience, sont rarement dues à Oracle. Principalement on trouve :
- une mauvaise manip lors d'un switchover pour une opération de maintenance : tablespace TEMP HS (classique), non redémarrage du process MRP sur la stanby (pourquoi le faire puisque c'est temporaire, j'ai déjà entendu ça), non application des archivelogs en retards, ...
- réseau cassé : voir les écarts d'archivelogs, listener, ...
- disque ou FS plein

Comment le TEMP pourrait engendrer une désynchro ?

Bref, une supervision standard doit permettre d'évacuer 99% des problèmes.

Quels sont les points importants à surveiller pour s'assurer du bon fonctionnement du dataguard ? par quels outils/moyens ? merci beaucoup !