oracle data guard dest_id 出现错误（wrong)目标号 通过SRL解决此问题
适合版本：
Oracle Server - Enterprise Edition - Version: 10.2.0.5 to 11.2.0.2 - Release: 10.2 to 11.2
Information in this document applies to any platform.
问题描述：
Within a Dataguard environment the value of dest_id in v$archived_log on standby database lists the
primary dest_id instead of the standby dest_id. This happens only in case of a GAP issue which is resolved by FAL. Please see the example below:
在一个data gurd环境下，备库的v$archived_log的dest_id值被主库的dest_id的替代，这种情况仅仅发生成归档间隙（GAP)被FAL解决的情况下，如下的例子可以说明：
Oracle Server - Enterprise Edition - Version: 10.2.0.5 to 11.2.0.2 - Release: 10.2 to 11.2
Information in this document applies to any platform.
问题描述：
Within a Dataguard environment the value of dest_id in v$archived_log on standby database lists the
primary dest_id instead of the standby dest_id. This happens only in case of a GAP issue which is resolved by FAL. Please see the example below:
在一个data gurd环境下，备库的v$archived_log的dest_id值被主库的dest_id的替代，这种情况仅仅发生成归档间隙（GAP)被FAL解决的情况下，如下的例子可以说明：
Primary:
*.fal_client='EXPRESS'
*.fal_server='EXPDR'
*.instance_name='EXPRESS'
*.log_archive_dest_1='LOCATION=/u07/archlogs/EXPRESS'
*.log_archive_dest_2='service=EXPDR LGWR SYNC AFFIRM'
Standby:
*.fal_client='EXPDR'
*.fal_server='EXPRESS'
*.instance_name='EXPDR'
*.log_archive_dest_1='LOCATION=/u07/archlogs/EXPRESS'
*.standby_archive_dest='/u07/archlogs/EXPRESS'
query on standby:
select dest_id, sequence#, creator, registrar, archived, fal from v$archived_log;
DEST_ID SEQUENCE# CREATOR REGISTRAR ARCHIVED FAL
=================================================
1 1597 ARCH RFS YES YES NO
1 1598 ARCH RFS YES YES NO
2 1599 ARCH RFS YES YES YES-> dest_id: 2 expected 1!
1 1600 ARCH RFS YES YES NO
1 1601 ARCH RFS YES YES NO
解决方案：
This is expected and by design, that an entry in v$archived_log where FAL=YES
will use the DEST_ID from the sending instance. This is because for FAL
shipments, the log file is written directly to disk by RFS and does not go
via an SRL and a local archive. All gaps are shipped via the FAL engine of
the sender DB. It does not matter if FAL_SERVER/FAL_CLIENT are set up
because the heartbeat PING ARCH on the primary will detect gaps and schedule
the FAL engine to send them to the standby.
If the standby does not have SRLs configured (or they can not be used) then
all entries for remotely shipped logs (REGISTRAR=RFS) will use the sender's
destination as the the DEST_ID recorded.
使用SRL来解决此问题
*.fal_client='EXPRESS'
*.fal_server='EXPDR'
*.instance_name='EXPRESS'
*.log_archive_dest_1='LOCATION=/u07/archlogs/EXPRESS'
*.log_archive_dest_2='service=EXPDR LGWR SYNC AFFIRM'
Standby:
*.fal_client='EXPDR'
*.fal_server='EXPRESS'
*.instance_name='EXPDR'
*.log_archive_dest_1='LOCATION=/u07/archlogs/EXPRESS'
*.standby_archive_dest='/u07/archlogs/EXPRESS'
query on standby:
select dest_id, sequence#, creator, registrar, archived, fal from v$archived_log;
DEST_ID SEQUENCE# CREATOR REGISTRAR ARCHIVED FAL
=================================================
1 1597 ARCH RFS YES YES NO
1 1598 ARCH RFS YES YES NO
2 1599 ARCH RFS YES YES YES-> dest_id: 2 expected 1!
1 1600 ARCH RFS YES YES NO
1 1601 ARCH RFS YES YES NO
解决方案：
This is expected and by design, that an entry in v$archived_log where FAL=YES
will use the DEST_ID from the sending instance. This is because for FAL
shipments, the log file is written directly to disk by RFS and does not go
via an SRL and a local archive. All gaps are shipped via the FAL engine of
the sender DB. It does not matter if FAL_SERVER/FAL_CLIENT are set up
because the heartbeat PING ARCH on the primary will detect gaps and schedule
the FAL engine to send them to the standby.
If the standby does not have SRLs configured (or they can not be used) then
all entries for remotely shipped logs (REGISTRAR=RFS) will use the sender's
destination as the the DEST_ID recorded.
使用SRL来解决此问题
SRL文件是为了解决下列两个主要问题
数据保护 如果没有使用SRL文件，而且与数据库的连接中断，将无法保留传入的重做数据--例如如果主数据库出现故障，然后进行故障转移，那么连接中断时正在发送的数据就会丢失。 如果将重做数据写入SRL，故障转移时已经永久保存了重做数据并可供使用。
性能目标
当LNS连接到备用数据库时，仅当在备用数据库上的RFS进程创建和初始化了归档日志，LNS/ARCH才能开始发送重做数据。如果日志文件很大，这会导致暂停时间过长。 该事件在日志切换时发生，因而对主数据库的吞吐量影响很大。 如果是ASYNC模式下的LSN不会阻止LGWR日志切换，当会响应备数据库在日志切换后的落后幅度。
配置了SRL，实时应用成为可能。
SRL的语法
alter database add standby logfile '+flash' size 500M
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29446986/viewspace-1649508/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
