standby redos logs

**aline** · 29/07/2005, 19h07

Bonjour,

Oracle9.2.0.6 sur Linux Rhas3

Je suis en train de tester une base standby en lgwr.
J'ai des bases qui tourne avec arch comme process. tout est nickel.
Et j'ai pleins de problèmes quand j'essaye de passer en lgwr.

Premier problème (il y aura d'autres posts pour les autres

):

J'ai crée des standby logfile pour pouvoir créer mes archives de la base de standby. Le problème, c'est que sur 8 logfiles une seule (voir deux après un switch) sont utilisés!
Et pourquoi pas les autres?

voici un peux de code pour faire du concret:

Code :

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

1
2
3
4
5
6
7
8
9
 
ALTER DATABASE ADD STANDBY LOGFILE group 9 '/opt/oracle/oradata/TEST/srl1.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 10 '/opt/oracle/oradata/TEST/srl2.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 11 '/opt/oracle/oradata/TEST/srl3.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 12 '/opt/oracle/oradata/TEST/srl4.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 13 '/opt/oracle/oradata/TEST/srl5.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 14 '/opt/oracle/oradata/TEST/srl6.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 15 '/opt/oracle/oradata/TEST/srl7.f' SIZE 104857600;
ALTER DATABASE ADD STANDBY LOGFILE group 16 '/opt/oracle/oradata/TEST/srl8.f' SIZE 104857600;

cela passe évidement nickel.

et voici ce que me dis mon fichier d'alertes:

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
18
19
20
21
22
23
24
25
26
27
28
 
Fri Jul 29 18:42:00 2005
ARC1: Archive log thread 1 sequence 658 available in 10 minute(s)
ARC1: Completed archiving  log 9 thread 1 sequence 658
Fri Jul 29 18:42:00 2005
[b]RFS: Successfully opened standby logfile 9: '/opt/oracle/oradata/TEST/srl1.f'[/b]
Fri Jul 29 18:43:30 2005
ARC1: Evaluating archive   log 9 thread 1 sequence 659
ARC1: Beginning to archive log 9 thread 1 sequence 659
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/TEST/archives/659.arc'
Fri Jul 29 18:43:30 2005
ARC1: Archive log thread 1 sequence 659 available in 10 minute(s)
ARC1: Completed archiving  log 9 thread 1 sequence 659
Fri Jul 29 18:43:30 2005
[b]RFS: Successfully opened standby logfile 9: '/opt/oracle/oradata/TEST/srl1.f'[/b]
Fri Jul 29 18:44:34 2005
ARC1: Evaluating archive   log 9 thread 1 sequence 660
ARC1: Beginning to archive log 9 thread 1 sequence 660
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/TEST/archives/660.arc'
Fri Jul 29 18:44:34 2005
ARC1: Archive log thread 1 sequence 660 available in 10 minute(s)
ARC1: Completed archiving  log 9 thread 1 sequence 660
Fri Jul 29 18:44:34 2005
[b]RFS: Successfully opened standby logfile 9: '/opt/oracle/oradata/TEST/srl1.f'[/b]
Fri Jul 29 18:45:34 2005
ARC1: Evaluating archive   log 9 thread 1 sequence 661
ARC1: Beginning to archive log 9 thread 1 sequence 661
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/TEST/archives/661.arc'

un seul redo fait le boulot!!!!

Quelqu'un est familier avec cela?

**LeoAnderson** · 30/07/2005, 12h25

Mais est-ce que le "boulot" est fait finalement ?

Et que donne la vue V$STANDBY_LOG comme préconisé ici : http://oraclesvca2.oracle.com/docs/c...rt.htm#1038266

**simple4u** · 30/07/2005, 20h38

Hello,

Le comportement que vous observez n'est pas anormal. Votre base de secours en STANDBY semble tourner sur deux pattes (2 SRL seulement). En vérité, elle n'a pas grand chose à faire, sinon récuper des journaux et copier des blocs de données en mode binaire dans ses fichiers base.

Chargez donc massivement (boucle PL/SQL) la base principale avant de simuler un sinistre (FAILEOVER qui va réincarner de la base de secours en la plaçant en lecture et en écriture). Vous devriez observer de l'activité et les fichiers de reprise standby devraient tous être sollicités.

voici pourquoi :

le processus LGWR de la base primaire achemine, de façon synchrone ou asynchrone, les REDO directement vers la base de secours au moment même les entrées sont écrites localement (base principale).

Ce procédé permet de hausser le niveau de protection du système Data Guard (MAXIMUM AVAILABILITY). Le système Data Guard peut aussi protéger une application sans perte de données (MAXIMUM PROTECTION) en cas de défaillance de la base primaire.

Pour qu’il en soit ainsi, la base de secours en standby PHYSICAL doit posséder des fichiers de reprise particuliers. Ils sont semblables aux fichiers de reprise REDO et s'appellent STANDBY REDO LOG (une base de secours LOGICAL DATA GUARD n’en a par contre pas besoin).

La présence des STANDBY REDO LOG est nécessaire pour pallier une perte de données lors d’une transition de rôle non planifiée (FAILEOVER). Dans ce cas, il sera sans doute nécessaire de récupérer davantage de données de reprise qu’il n’y en a dans les seules archives.

Il faut donc créer sur la base de secours un groupe supplémentaire de STANDBY REDO LOG (avec le nombre de membres qui convient) qu'il n'y a de groupes REDO sur la base principale. La taille de chacun doit être strictement identique (REDO et STANDBY REDO LOG).

Par ailleurs, si un basculement de type SWITCHOVER (maintenance logicielle ou matérielle par exemple) devait avoir lieu, la base primaire prendra pour un temps le rôle de la base de secours. Il est normal qu'elle posséde ses propres STANDBY REDO LOG pour pallier une défaillance de l'autre base!

J'en profite pour donner un avis à propos du RAC d'Oracle, en comparaison de Oracle Data Guard. Ces deux technologies sont complémentaires et non pas concurrentes ainsi que le laissent entendre certains échanges.

Les deux mécanismes contribuent à mettre en place un plan de reprise d'activité, voire même, sous certaines conditions, assurer la continuité de service (y compris dans l'esprit de Bâle II).

RAC protège les transactions contre une perte d'instance (mémoire, processeur, etc) tandis que Data Guard protège l'application contre une perte de données. D'un point de vue technique, RAC est un système à couplage serré tandis que Data Guard est un système à couple lâche. Cela veut dire que les instances d'un RAC émettent et réceptionnent en même temps. Avec Data Guard, à un instant donné une base émet et l'autre récupère (et même, elle peut être arrêtée pour être sauvegardée).

En revanche, dans le cas du système sous Data Guard, chaque base peut être hébergée sur un site géographiquement distant. Cette option est intéressante pour protéger un site.

On peut également placer plusieurs bases dans le système Data Guard (une PRODUCTION, une LOGICAL pour effectuer de grosses éditions et une PHYSICAL pour effectuer des sauvegardes et restaurer périodiquement un environnement de pré-production, à chaud ou à froid).

Mais rien ne vous empêche de combiner les deux systèmes RAC et Data Guard (complémentarité). Dans ce cas chaque site possède son cluster Oracle RAC en mettant en oeuvre Data Guard entre eux.

Les deux technologies réclament une compétence dès lors que l'application concernée doit passer en production. Forcément!

Data Guard est plus "prédictible" dans la mesure ou un RAC peut parfois conduire à un ajustement des performances sans avoir de maîtrise sur l'application.

Je vois aujourd'hui un avantage pour Data Guard dans le monde SAP. SAP R/3 (ISU BW CRM & Solution Manager) supporte d'être placé sous DATA GUARD (PHYSICAL uniquement) tandis que la version de SAP compatible RAC est en cours de certification (second semestre 2005).

Comme les clients SAP demeurent assez conservateurs (beaucoup de gens n'adoptent que rarement et immédiatement la toute dernière version d'une application), il faudra attendre un petit peu avant de voir SAP déployé régulièrement sous Oracle RAC.

amicalement.

**LeoAnderson** · 31/07/2005, 12h47

Pour un premier message, c'est un coup de maitre !

Clair, précis, argumenté, en français, avec des phrases construites, tout en élargissant le sujet...

Surtout, si vous avez envie de faire d'autres réponses comme celle-ci, ne vous en privez pas !

**orafrance** · 01/08/2005, 07h42

si avec tout ça Aline n'arrive pas à nous rédiger un article béton, je veux bien finir moine tibéthain

Aline... dit moi que tu fais un doc sur le standby

**aline** · 03/08/2005, 17h41

Envoyé par simple4u

Hello,

Le comportement que vous observez n'est pas anormal. Votre base de secours en STANDBY semble tourner sur deux pattes (2 SRL seulement). En vérité, elle n'a pas grand chose à faire, sinon récuper des journaux et copier des blocs de données en mode binaire dans ses fichiers base.

Chargez donc massivement (boucle PL/SQL) la base principale avant de simuler un sinistre (FAILEOVER qui va réincarner de la base de secours en la plaçant en lecture et en écriture). Vous devriez observer de l'activité et les fichiers de reprise standby devraient tous être sollicités.

amicalement.

Bonjour et tout d'abord merci pour votre réponse très précise.

J'ai bien fais vos tests avec des boucles plsql massives, et des petits redos logs (pour switcher plus rapidement). Et bien je tourne toujours sur 1 ou 2 redos!
Et ceci en testant toutes sortes de crash sur la base primaire et de récupération ensuite.

Ce qui parait réellement bizarre.

Mais la bonne nouvelle, c'est que tout marche très bien et quelle que soit la panne simulé, j'arrive toujours à récuperrer toute mes données (je suis en max availability).

Sur ce point, je concluerai comme cela (si personne n'enrichit!).

tout marche très bien mais de manière bizarre et pas comme expliqué dans la doc!

Orafrance, je ne fais pas de doc sur la standby, j'essaye juste de bien comprendre comment elle marche dans les process que l'on lance.
Et je simule tout les crash possible histoire de ne pas être surprise un jour!

Par contre, je ne maitrise pas tout les aspects et je risque de vous décevoir en écrivant un article...

ou alors dès que j'ai un peux de temps

**orafrance** · 03/08/2005, 17h50

ça m'étonnerait qu'on soit déçu

Si on pouvait profiter de ton expérience sur le sujet ce serait super

**learn** · 03/08/2005, 21h11

Bonjour à tous et merci à simple4u pour ses précieux commentaires,

aline si tu veux voir de l'action sur tes REDOS, index ou Rebuild un index d'une grande table dans ta BD primaire.

Contexte :
Tout d'abord je suis en oracle 9i 9.2.0.4 Standard Edition sur Linux RH ES/3.
Par conséquent je ne dispose pas de l'outil Oracle Data Guard, j'ai été contraint de developper mes propres scripts Linux pour récuperer les REDOS de ma BD primaire et les appliquer à ma BD standby.
Seulement la seule façon que j'ai trouvé pour pouvoir récuperer un fichier REDO entier est en consultant le fichier alert de ma BD primaire et attendre un message comme " Completed archiving" avec un numero de séquence approprié.
Le problème avec cette solution est que si un jour il y a un crash sur la BD primaire, je risque de perdre au maximum la taille de mon fichier REDO en données.
La question est : Y a t-il une autre façon de faire pour simuler la récuperation complète et sans perte de données ( sans considérer le passage à l'Entreprise Edition biensur ).

**aline** · 04/08/2005, 16h01

Bonjour,

Envoyé par learn

Bonjour à tous et merci à simple4u pour ses précieux commentaires,

aline si tu veux voir de l'action sur tes REDOS, index ou Rebuild un index d'une grande table dans ta BD primaire.

J'ai bien essayé cela,

et des création de datafile énorme,
et des deletes sur des tables énormes
trufées d'index
et des rollbacks des deletes
et tout cela en lême temps

et entre 1 et 2 standby redos!!!!

Mais comme je le disais, cela fonctionne....

Alors o rigole parce que ca marche quand même ou on pleure parce qu'on comprends pas?

Envoyé par learn

Contexte :
Tout d'abord je suis en oracle 9i 9.2.0.4 Standard Edition sur Linux RH ES/3.
Par conséquent je ne dispose pas de l'outil Oracle Data Guard, j'ai été contraint de developper mes propres scripts Linux pour récuperer les REDOS de ma BD primaire et les appliquer à ma BD standby.
Seulement la seule façon que j'ai trouvé pour pouvoir récuperer un fichier REDO entier est en consultant le fichier alert de ma BD primaire et attendre un message comme " Completed archiving" avec un numero de séquence approprié.
Le problème avec cette solution est que si un jour il y a un crash sur la BD primaire, je risque de perdre au maximum la taille de mon fichier REDO en données.
La question est : Y a t-il une autre façon de faire pour simuler la récuperation complète et sans perte de données ( sans considérer le passage à l'Entreprise Edition biensur ).

J'ai d'jà pas mal travaillé sur le problème et n'ai rien trouvé.
Même avec un standby en arch, on a ce type de problème
et de toute façon, sauf si tu te trouve en maximum protection (ce qui necessite une architecture lpus que beton qu'on ne trouve que dans les très très grosses structures), le risque de perdre des données existe.

Nous, ce que l'on fait, c'est que les applis sensibles qui ecrivent dans la base, spoolent ce qu'elles écrivent dans des fichier log (indépendemment d'oracle).
Et en cas de crash, on pourra toujours s'y retrouver...

**mildiou51** · 06/08/2005, 22h43

Une bonne solution consister à forcer un switch toutes les n minutes (ou à mettre ca en automatique via un paramètre de l'init.ora dont je ne me souviens plus par coeur), puis à transporter juste après l'archivelog. Généralement, on met n=5 ou n=10.

**aline** · 08/08/2005, 09h20

oui, evidement, tu peux mettre ce paramètre, mais tu nr pourras pas éviter de perdre le redo log courant.
En gros, le standby te fait passer du mode discret au continu!
De plus le problème de ta solution, c'est que tu peux programmer un switch au plus toutes les n minutes, mais il peux se faire avant. Donc ta technique de récup n'est pas au point dans ce cas!

**mildiou51** · 08/08/2005, 11h15

Oui il peut se faire avant, mais quand on a pas la version entreprise, c'est la seule solution... Et dans la grande majorité des cas, cette solution est très largement suffisante ;-)