synchronisation de base primaire et standby

Version imprimable

Voir 40 message(s) de cette discussion en une page

21/07/2009, 12h16
hrazaka

synchronisation de base primaire et standby

Bonjour,

J'ai une base primaire et un standby (Oracle 10g).
Dans la primaire, on a créé de nouveau tablespace et nouveau schéma.
Mais ça n'a pas été répliqué sur la base secours.
Alors que le commande suivant retourne le même Sequence pour les deux bases :

Code:

select thread# , Sequence# , Archived , FIRST_CHANGE#, to_char(FIRST_TIME,'dd/mm/yyyy hh24:mi:ss') FIRST_TIME from v$log ;

Quelqu"un a t-il une idée
21/07/2009, 14h22
agdid04

Bonjour,

Regardes dans: v$archived_log la dernière archive reçue:

select max(sequence#) from v$archived_log;

Et dans v$log_history: la dernière archive appliquée:

select max(sequence#) from v$log_history;

Crdlt,
21/07/2009, 14h59
pifor

Merci de préciser:
la version Oracle sur 4 chiffres
s'agit d'une base standby physique ou logique ?
y-a-t-il des erreurs dans l'alert log de la primaire ou de la standby ?
que vaut le paramètre STANDBY_FILE_MANAGEMENT sur la standby ?
21/07/2009, 15h12
hrazaka

synchronisation de base primaire et standby

Merci,

j'utilise Oracle 10g R2

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)
--------------
13235

SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
11980

SQL> show parameter STANDBY_FILE_MANAGEMENT

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL

Je crois que j'ai vraiment un problème.
En fait, j'ai essai d'ouvrir ma base standby en mode (Read /Write) mode en utilisant flashback. et c'est là que j'ai découvert que le nouveau schéma n'était pas répliqué ce nouveau schéma était créé il y a 2 mois de cela.
Mais je pense qu'il n'y avait pas d'erreur.
21/07/2009, 15h18
pifor

Il faut au moins que STANDBY_FILE_MANAGEMENT=AUTO pour que les datafiles soient créés automatiquement. Mais il y a sans doute un autre problème.
21/07/2009, 15h28
hrazaka

synchronisation de base primaire et standby

ok!
mais d'après vous à mon config actuel avec STANDBY_FILE_MANAGEMENT
mes datafiles ne serait pas transféré dans mon standby?
je devrait alors les créer manuellemnt dans stand by?
Si oui en quel mode doit-je le créer?

Merci
21/07/2009, 15h43
pifor

Je crois qu'il faut créer le tablespace sur la base standby.

Mais vous n'avez pas répondu précisément aux questions:
la version Oracle sur 4 chiffres
s'agit d'une base standby physique ou logique ?
y-a-t-il des erreurs dans l'alert log de la primaire ou de la standby ?
21/07/2009, 15h55
hrazaka

synchronisation de base primaire et standby

J'ai oracle 10.2.0.1

Comment connaitre que c'est physique ou logique?
En fait c'est pas moi qui a mis en route le standby. Je suis nouveau dans la société ...
21/07/2009, 16h02
hrazaka

synchronisation de base primaire et standby

j'ai vu c'est un phisycal standby

Merci

Voici le log de création du tablespace:

Code:

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
create tablespace MADSTAGE datafile '+DATADG/pmtn1/datafile/madstage.dbf' size 2425829120
Fri Apr 24 15:54:28 2009
Starting control autobackup
Control autobackup written to DISK device
        handle '/dbbackup/cf_c-2138598984-20090424-00'
Completed: create tablespace MADSTAGE datafile '+DATADG/pmtn1/datafile/madstage.dbf' size 2425829120
Fri Apr 24 16:50:32 2009
Thread 2 advanced to log sequence 9033
  Current log# 3 seq# 9033 mem# 0: +ARCHDG/pmtn1/onlinelog/group_3.259.617127239
Fri Apr 24 18:31:06 2009
Thread 2 advanced to log sequence 9034
  Current log# 4 seq# 9034 mem# 0: +ARCHDG/pmtn1/onlinelog/group_4.260.617127241
Fri Apr 24 20:40:05 2009
Thread 2 advanced to log sequence 9035
  Current log# 3 seq# 9035 mem# 0: +ARCHDG/pmtn1/onlinelog/group_3.259.617127239
LNS1 started with pid=29, OS id=11730
Fri Apr 24 21:06:14 2009
Thread 2 advanced to log sequence 9036
  Current log# 4 seq# 9036 mem# 0: +ARCHDG/pmtn1/onlinelog/group_4.260.617127241
Fri Apr 24 21:18:54 2009
Starting control autobackup
Control autobackup written to DISK device
        handle '/dbbackup/cf_c-2138598984-20090424-01'
Fri Apr 24 21:25:54 2009
Errors in file /u01/app/oracle/admin/pmtn1/bdump/pmtn12_arc0_6757.trc:
ORA-16401: archivelog rejected by RFS

et ci-dessus le log sur le standby au 24 avril

Code:

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Fri Apr 24 14:51:48 2009
RFS[978]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12377_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[978]: No standby redo logfiles created
Fri Apr 24 14:51:55 2009
RFS[976]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9031_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[976]: No standby redo logfiles created
Fri Apr 24 16:21:52 2009
RFS[978]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12378_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[978]: No standby redo logfiles created
Fri Apr 24 16:32:25 2009
RFS[976]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9032_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[976]: No standby redo logfiles created
Fri Apr 24 18:01:04 2009
RFS[978]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12379_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[978]: No standby redo logfiles created
Fri Apr 24 18:13:21 2009
RFS[976]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9033_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[976]: No standby redo logfiles created
Fri Apr 24 19:43:29 2009
RFS[978]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12380_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[978]: No standby redo logfiles created
Fri Apr 24 20:22:05 2009
RFS[976]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9034_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[976]: No standby redo logfiles created
RFS[976]: Possible network disconnect with primary database
Closing latent archivelog for thread 2 sequence 9035
EOF located at block 19701 low SCN 0:792162405 next SCN 0:792189516
Latent archivelog '/DRE_Arch/pmtn1/archivelog/2_9035_617125512.dbf'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/DRE_Arch/pmtn1/archivelog/2_9035_617125512.dbf';
Fri Apr 24 20:47:46 2009
RFS[978]: Possible network disconnect with primary database
Closing latent archivelog for thread 1 sequence 12381
EOF located at block 38506 low SCN 0:792122939 next SCN 0:792189676
Latent archivelog '/DRE_Arch/pmtn1/archivelog/1_12381_617125512.dbf'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/DRE_Arch/pmtn1/archivelog/1_12381_617125512.dbf';
Fri Apr 24 20:47:58 2009
RFS[934]: No standby redo logfiles created
Fri Apr 24 20:47:59 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[979]: Assigned to RFS process 16978
RFS[979]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[979]: No standby redo logfiles created
Fri Apr 24 20:48:01 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[980]: Assigned to RFS process 16980
RFS[980]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[980]: No standby redo logfiles created
Fri Apr 24 20:59:30 2009
RFS[934]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9035_617125512.dbf'
Fri Apr 24 21:06:38 2009
RFS[956]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12381_617125512.dbf'
Fri Apr 24 21:07:35 2009
RFS[934]: Archivelog thread 1 sequence 12381 cannot be reused
Fri Apr 24 21:07:35 2009
Errors in file /u01/dr/app/oracle/admin/pmtn1/udump/pmtn1_rfs_22240.trc:
ORA-16401: archivelog rejected by RFS
Fri Apr 24 21:44:03 2009
RFS[980]: Possible network disconnect with primary database
Closing latent archivelog for thread 1 sequence 12382
EOF located at block 16762 low SCN 0:792189735 next SCN 0:792244613
Latent archivelog '/DRE_Arch/pmtn1/archivelog/1_12382_617125512.dbf'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/DRE_Arch/pmtn1/archivelog/1_12382_617125512.dbf';
Fri Apr 24 22:12:40 2009
RFS[956]: Archived Log: '/DRE_Arch/pmtn1/archivelog/1_12382_617125512.dbf'
Fri Apr 24 22:15:44 2009
RFS[979]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9036_617125512.dbf'
Primary database is in MAXIMUM PERFORMANCE mode
RFS[979]: No standby redo logfiles created
Fri Apr 24 23:04:48 2009
RFS[979]: Possible network disconnect with primary database
Closing latent archivelog for thread 2 sequence 9037
EOF located at block 34291 low SCN 0:792307010 next SCN 0:792339712
Latent archivelog '/DRE_Arch/pmtn1/archivelog/2_9037_617125512.dbf'
If you wish to failover to this standby database, you should use the
following command to manually register the archivelog for recovery:
ALTER DATABASE REGISTER LOGFILE '/DRE_Arch/pmtn1/archivelog/2_9037_617125512.dbf';
Fri Apr 24 23:26:52 2009
RFS[934]: Archived Log: '/DRE_Arch/pmtn1/archivelog/2_9037_617125512.dbf'
Sat Apr 25 00:43:26 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[981]: Assigned to RFS process 17553
RFS[981]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[981]: No standby redo logfiles created
Sat Apr 25 00:43:28 2009
RFS[956]: No standby redo logfiles created
Sat Apr 25 00:44:00 2009

tu peux y voir quelque chose?

21/07/2009, 16h25
petitfrere

vérifie qu'il a pas de "dbms_logstdby.skip" sur un owner en cours (ca c'est pour la logycal)

Ca existe pour la logical mais je suis pas sur pour la physical
21/07/2009, 16h37
pifor

Quel est le contenu des alert.log actuellement ?

Que donne sur la primaire et la standby:

Code:

SELECT MESSAGE FROM V$DATAGUARD_STATUS;

Que donne sur la standby:

Code:

select open_mode from v$database;
21/07/2009, 16h38
pifor

Citation:

Envoyé par petitfrere

vérifie qu'il a pas de "dbms_logstdby.skip" sur un owner en cours (ca c'est pour la logycal)

Ca existe pour la logical mais je suis pas sur pour la physical

Cela n'existe que pour une logical standby.

synchronisation de base primaire et standby

Code:

1
2
3
vérifie qu'il a pas de "dbms_logstdby.skip" sur un owner en cours (ca c'est pour la logycal)
 
Ca existe pour la logical mais je suis pas sur pour la physical

comment on connait ca?

21/07/2009, 16h54
petitfrere

Tu peu pas avoir cette fonction elle n'est dispo que sur une logycal stanby

merci hrazaka
21/07/2009, 16h54
agdid04

Bonjour,

Je dirai que certaines archives n'ont pas été reçues par la standby ! vérifies qu'il n'ait pas de trou dans tes archives (GAP) ?
@+
Crdlt,
21/07/2009, 17h04
petitfrere

Je vais pas faire avancer le chmilblic mais j'ai pas mal de soucis avec la 10.2.0.1, regarde du coté metalink si tu peux, et prévoir un update de ta base
21/07/2009, 17h20
agdid04

Bonjour,

Regardes si t'es pas en présence d'1 GAP (trou dans tes archives sur la standby) ?

@+
22/07/2009, 08h31
hrazaka

synchronisation de base primaire et standby

Merci les gars!

Mon problème c'est que les logs plus de 1 mois sont supprimés.
Je crois que je dois remettre en oeuvre mon standby
22/07/2009, 10h46
agdid04

Bonjour,

Tu sauvegardes avec Rman ? si oui tu peux : ne supprimer que
- les archives sauvegardées.
- celles qui ont été appliquées sur la standby ...
@+

Voir 40 message(s) de cette discussion en une page