oracle data guard dest_id 出現錯誤（wrong)目標號 通過SRL解決此問題

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來解決此問題

SRL檔案是為了解決下列兩個主要問題

資料保護 如果沒有使用SRL檔案，而且與資料庫的連線中斷，將無法保留傳入的重做資料--例如如果主資料庫出現故障，然後進行故障轉移，那麼連線中斷時正在傳送的資料就會丟失。 如果將重做資料寫入SRL，故障轉移時已經永久儲存了重做資料並可供使用。

效能目標
當LNS連線到備用資料庫時，僅當在備用資料庫上的RFS程式建立和初始化了歸檔日誌，LNS/ARCH才能開始傳送重做資料。如果日誌檔案很大，這會導致暫停時間過長。 該事件在日誌切換時發生，因而對主資料庫的吞吐量影響很大。 如果是ASYNC模式下的LSN不會阻止LGWR日誌切換，當會響應備資料庫在日誌切換後的落後幅度。

配置了SRL，實時應用成為可能。

 

SRL的語法

alter database add standby logfile '+flash' size 500M