关于dataguard备库宕机后重启后的问题

[复制链接]
查看11 | 回复9 | 2007-10-20 08:38:44 | 显示全部楼层 |阅读模式
1、dataguard环境,主库2RAC,备库2RAC-启动在1号节点上
2、发生宕机后,发现在备库上
SEQUENCE# STATUS
---------- ----------
0 UNASSIGNED
0 UNASSIGNED
3913 ACTIVE
3917 ACTIVE
0 UNASSIGNED
0 UNASSIGNED
0 UNASSIGNED
0 UNASSIGNED
3902 ACTIVE
0 UNASSIGNED
0 UNASSIGNED
SEQUENCE# STATUS
---------- ----------
0 UNASSIGNED
0 UNASSIGNED
0 UNASSIGNED
始终有一个序列号是3913的
并且如下
STATUSSEQUENCE# KNOWN_AGENTS ACTIVE_AGENTS
------------ ---------- ------------ -------------
CLOSING
3915
0
0
CLOSING
3901
0
0
IDLE
0
0
0
APPLYING_LOG 3913
0
0
IDLE
3917
0
0
IDLE
3902
0
0
一直在applying_log,这个是为什么啊?

回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
ASMCMD [+fradg/surf_st/archivelog/2011_10_02] > ls
thread_1_seq_3911.2740.763448417
thread_1_seq_3912.2743.763448467
thread_2_seq_3895.2741.763448419
thread_2_seq_3896.2742.763448465
thread_2_seq_3897.2744.763495911
thread_2_seq_3898.2745.763496905
thread_2_seq_3899.2746.763497083
ASMCMD [+fradg/surf_st/archivelog/2011_10_03] > ls
thread_1_seq_3915.2748.763534829
thread_1_seq_3916.2749.763534851
thread_2_seq_3900.2747.763534815
thread_2_seq_3901.2750.763534863
ASMCMD [+fradg/surf_st/archivelog/2011_10_03] >
并且发现在ASM上,没有3913的归档情况
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
没有顶吗
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
看看alert是否正常?
看看v$managed_standby是否正常?
如果缺那个日志可否从主库copy过来?
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
查看v$archive_gap,如果有gap,看是否可以从主库copy,然后register。
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
iori809 发表于 2011-10-3 09:58
看看alert是否正常?
看看v$managed_standby是否正常?
如果缺那个日志可否从主库copy过来?

alert正常
v$managed_standby一直有以下这样
STATUSSEQUENCE# KNOWN_AGENTS ACTIVE_AGENTS
------------ ---------- ------------ -------------
CLOSING
3915
0
0
CLOSING
3901
0
0
IDLE
0
0
0
APPLYING_LOG 3913
0
0
IDLE
3917
0
0
IDLE
3902
0
0
一直在applying_log,这个是为什么啊?
缺失的那个日志由于今天凌晨主库RMAN备份已经将归档日志清除了
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
Impostor 发表于 2011-10-3 11:12
查看v$archive_gap,如果有gap,看是否可以从主库copy,然后register。

在备库节点上执行
SQL> select * from v$archive_gap
2;
no rows selected
没有GAP嘛?
这个是不是没有问题了,我是不是应该将备库节点关闭一下,然后将备库启动到只读状态查看一下,是否数据库在正常同步?
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
看你的archive log的sequence已经大于3913了~
你的alert输出什么呢?显示一直在 recover 3913还是?
你可以停止在应用下看看~
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
iori809 发表于 2011-10-3 13:06
看你的archive log的sequence已经大于3913了~
你的alert输出什么呢?显示一直在 recover 3913还是?
你可 ...

是的,目前archivelog的sequence已经大于3913了
alter的输入如下:
Physical Standby Database mounted.
Completed: ALTER DATABASE MOUNT
Sun Oct2 18:11:50 2011
Using STANDBY_ARCHIVE_DEST parameter default value as +FRADG
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 18621
RFS[1]: Identified database type as 'physical standby'
Sun Oct2 18:11:50 2011
RFS LogMiner: Client disabled from further notification
RFS[1]: Archived Log: '+FRADG/surf_st/archivelog/2011_10_02/thread_2_seq_3897.2744.763495911'
Sun Oct2 18:14:52 2011
alter database recover managed standby database using current logfile disconnect from session
Sun Oct2 18:14:52 2011
Attempt to start background Managed Standby Recovery process (surf1)
MRP0 started with pid=31, OS id=19755
Sun Oct2 18:14:52 2011
MRP0: Background Managed Standby Recovery process started (surf1)
Sun Oct2 18:14:57 2011
Managed Standby Recovery starting Real Time Apply
Sun Oct2 18:15:00 2011
parallel recovery started with 15 processes
Sun Oct2 18:15:01 2011
Waiting for all non-current ORLs to be archived...
Media Recovery Log +FRADG/surf_st/archivelog/2011_10_02/thread_2_seq_3897.2744.763495911
Sun Oct2 18:15:02 2011
Completed: alter database recover managed standby database using current logfile disconnect from session
Sun Oct2 18:15:02 2011
Recovery of Online Redo Log: Thread 1 Group 15 Seq 3913 Reading mem 0
Mem# 0: +DATADG/surf_st/onlinelog/group_15.284.731905313
Mem# 1: +FRADG/surf_st/onlinelog/group_15.364.731905315
Sun Oct2 18:21:08 2011
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 22148
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 13: '+DATADG/surf_st/onlinelog/group_13.301.731905305'
Sun Oct2 18:25:36 2011
db_recovery_file_dest_size of 20480 MB is 55.22% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sun Oct2 18:27:58 2011
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 24732
RFS[3]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 20: '+DATADG/surf_st/onlinelog/group_20.266.731905335'
Sun Oct2 18:28:13 2011
RFS[1]: Successfully opened standby log 21: '+DATADG/surf_st/onlinelog/group_21.270.731905339'
Sun Oct2 18:31:22 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 21: '+DATADG/surf_st/onlinelog/group_21.270.731905339'
Mon Oct3 05:00:15 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 20: '+DATADG/surf_st/onlinelog/group_20.266.731905335'
Mon Oct3 05:00:28 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 14: '+DATADG/surf_st/onlinelog/group_14.285.731905309'
Mon Oct3 05:00:51 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 16: '+DATADG/surf_st/onlinelog/group_16.271.731905319'
Mon Oct3 05:01:04 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 21: '+DATADG/surf_st/onlinelog/group_21.270.731905339'

你说的停止应用再应用
是不是将备库执行如下操作:
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;
谢谢!
回复

使用道具 举报

千问 | 2007-10-20 08:38:44 | 显示全部楼层
请各位高手再看看,顶一下。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行