一、需求：DG最大可用模式下,dg備庫可能對主庫有什么影響？
上一篇文章測試了最大保護模式下,dg備庫出現問題，對主庫的影響？
那么如果是最大可用模式下呢？
二、測試
--查詢數據庫的保護模式: >select name,database_role,protection_mode from v$database; NAME DATABASE_ROLE PROTECTION_MODE --------- ---------------- -------------------- DINGDING PHYSICAL STANDBY MAXIMUM AVAILABILITY --驗證最高可用性日志傳輸模式： 插入數據：切換日志組：通過主庫告警日志查詢：通過什么方式發生日志 16:26:44 SQL> insert into a select * from emp where rownum=1; 1 row created. 16:26:54 SQL> commit; 16:25:54 SQL> alter system switch logfile; Clearing Resource Manager plan via parameter Wed Jan 10 16:27:11 2018 LGWR: Standby redo logfile selected to archive thread 1 sequence 28 LGWR: Standby redo logfile selected for thread 1 sequence 28 for destination LOG_ARCHIVE_DEST_2 --LGWR 通過遠程發生歸檔日志 --測試最高可用模式：在備庫不可用的情況下的影響 --備庫：service network stop --主庫：DML操作事務，提交： 16:26:56 SQL> insert into a select * from emp where rownum=1; ---------短時間停頓幾秒，開始還是會按照LGWR進程寫入歸檔線程2，遠程； --等待3秒，驗證歸檔線程2不可用后，很快忽略，之后的事務不受到日志是否可以傳送備庫的影響 16:29:39 SQL> commit; --網絡連接被遺棄：歸檔日志文件錯誤 LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned Error 16198 for archive log file 1 to 'sh' ORA-錯誤：LGWR從KSR受到超出誤差 ORA-16198: LGWR received timedout error from KSR LGWR: Error 16198 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'sh' 目的地與線程二，無法同步 Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED --備庫發現日志間隙：通過fal_server 主庫的db_unique_name：向主庫請求發生間隔日志 --最高可用，最初按照最大保護的同步日志LGWR傳送，一旦沒有收到確認，立即轉為類似最大性能的，忽略最大保護的同步日志傳送 最高可用：模式不會變化，變化的是日志同步、忽略的傳輸模式的改變 ***備庫告警日志： TNS-00505: Operation timed out nt secondary err code: 110 nt OS err code: 0 Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.20.67)(PORT=44838)) RFS[1]: Possible network disconnect with primary database與主庫斷開網絡 RFS[4]: Assigned to RFS process 17980 RFS 進程 RFS[4]: Opened log for thread 1 sequence 30 dbid 2042277967 branch 962041105 ---打開日志線程1 序列30 數據庫ID -- Wed Jan 10 11:53:57 2018 Primary database is in MAXIMUM AVAILABILITY mode Changing standby controlfile to RESYNCHRONIZATION level Standby controlfile consistent with primary RFS[7]: Assigned to RFS process 17992
小結：在最大可用的情況下，DG出現問題，主庫由於最初與dg連通性正常 level級別等同於最大保護，因此有將近3s的時間，主庫hang,隨后主庫保護模式進行降級到最大性能模式；
隨后的主庫事務不在受到影響！ 也就是說如果dg不可用，主庫會在一定時間內性能出現明顯問題，db甚至會Hang等待幾秒降級。 db alert有記錄！
三、案例學習-轉載
https://blog.51cto.com/hsbxxl/1846499 https://blog.csdn.net/weixin_30895723/article/details/110218082
案例一、 備庫IO性能差
近日處理一個由於standby 磁盤IO性能較差，導致Primary的性能受到影響。
主庫主要是等待"log file switch completion"，通過ASH dump分析，最終發現實際等待事件是"LGWR-LNS wait on channel”.
這個事件基本上可以將問題歸結到網絡性能和standby的IO性能，而客戶的傳輸模式是“MAXIMUM AVAILABILITY"
最后提出兩個解決方案，
(1). 更換性能更好的standby存儲
(2). 修改傳輸模式為MAXIMUM performance，並使用LGWR ASYNC傳輸模式
案例二、 同樣還是備庫主機硬件資源問題，使用虛擬機，反向影響主庫性能
1）監控告警，通過zabbix監控到的會話阻塞信息；
2）定位阻塞源頭
查詢1331會話信息，發現是日志寫進程LGWR，1311會話不再被其它會話阻塞，可以判定該會話為阻塞源頭，1331會話的等待事件是LGWR-LNS wait on channel。
3）等待事件分析
在本案例中，一共出現了2種類型的非空閑等待事件：
log file sync
LGWR-LNS wait on channel(阻塞源頭)
什么是log file sync：當用戶提交一個事務之后就開始等待log file sync，直到LGWR進程完成了對SCN的傳播和對應重做日志的寫入操作。所以log file sync的等待時間是由重做日志I/O時間和SCN傳播時間兩部分構成的，如果還使用了DataGuard，且日志傳送時使用了同步+確認(SYNC+AFFRIM)選項時，那么LGWR還需在用戶提交事務之后將重做日志信息傳遞到遠程備庫節點。總結一下，log file sync的計算公式如下：
4） a1~a4是LGWR傳送重做日志到備庫的過程
a1：LGWR將事務對應的重做信息發送給本地節點的LNS(network server)進程
a2：LNS進程通過網絡將重做信息發送給備庫的RFS(remote file server)進程
a3：RFS進程將重做日志信息寫入到備庫的備用重做日志文件(Standby redo log)，返回消息給主庫的LNS進程
a4：主庫的LNS進程通知LGWR進程重做信息已經寫入到備庫的備用重做日志文件
5）b1~b4代表LGWR傳播SCN
SCN是數據庫內部的時鍾，不重復，單項增長，SCN是針對數據庫的，不是針對實例的，也就是說，對於RAC數據庫，雖然有多個實例，這些實例會使用相同的SCN，但是每個實例都可以進行各自的任務，這就意味着實例之間需要傳播SCN。對於分布式數據庫(例如，使用了DB Link)，也同樣存在着同步SCN的概念。同步SCN的過程如下：
b1：LGWR進程將事務提交的SCN發送給本地的一個LMS進程
b2：本地節點的LMS進程將包含了SCN的消息發送給所有遠程節點的LMS進程
b3：所有遠程節點的LMS進程接受到了SCN消息並反饋給本地節點的LMS進程
b4：本地節點的LMS進程通知LGWR，所有遠程節點都受到了事務的SCN
6）c1~c2代表LGWR執行重做日志寫I/O。過程如下：
c1：LGWR進程將redo buffer cache中的日志寫入到online redo log
c2：寫完之后LGWR會收到通知已完成
7）由LGWR傳送重做日志到備庫引起的log file sync
需要特別注意的是，只有在LOG_ARCHIVE_DEST_n參數中使用了"SYNC，AFFIRM"屬性時，log file sync等待事件才會與LGWR傳送日志有關，如果使用了其它屬性，不用考慮。
LNS進程DataGuard環境中主庫用來傳送日志到備庫的進程，查看所有與之相關的等待事件。
SQL> SELECT NAME FROM v$event_name a WHERE a.name LIKE '%LNS%';
回過頭，再次查看我們的生產環境的問題，是log file sync伴隨着LGWR-LNS wait on channel出現，再次確認數據庫的參數信息，發現數據庫運行在最大可用模式，備庫采用了同步(sync)方式傳送數據。
8）進一步分析"LGWR-LNS wait on channel"等待事件：
什么是LGWR-LNS wait on channel：這個等待事件監視LGWR或LNS進程等待在KSR通道上接收消息所花費的時間(This wait event monitors the amount of time spent by the log writer (LGWR) process or the network server processes waiting to receive messages on KSR channels. Data Guard Wait Events (Doc ID 233491.1) )。
KSR通道的解釋:https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/DBA_HIST_CHANNEL_WAITS.html#GUID-682C58F4-5787-4C8E-844C-9DFE04612BDD。
可以斷定，數據庫的異常等待是由於主庫的LNS進程同步傳送在線日志信息給DG環境引起的，且引起的瓶頸在備庫端。想到我們的主庫是高配的物理服務器，備庫是低配的雲主機(虛擬機)，出現這種問題也就不足為奇了
9）解決方案
使用異步方式傳送日志信息，修改日志傳送方式為異步(async)傳送
SQL> alter system set log_archive_dest_2= SERVICE="adg_orcl" LGWR ASYNC VALID_FOR=(all_logfiles, primary_role) DB_UNIQUE_NAME="adg_orcl" scope=both;
-- 重新啟用通道
SQL> alter system set log_archive_dest_state_2= defer;
SQL> alter system set log_archive_dest_state_2= enable;
四、官方文檔
Maximum Availability This protection mode provides the highest level of data protection that is possible without compromising the availability of
a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to
the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot
write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to
preserve primary database availability until it is again able to write its redo stream to a synchronized standby database. This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a
complete set of redo data from being sent from the primary database to at least one standby database.
Maximum Performance This protection mode provides the highest level of data protection that is possible without affecting the performance
of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by
those transactions has been written to the online log. Redo data is also written to one or more standby databases, but
this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays
in writing redo data to the standby database(s). This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on
primary database performance. This is the default protection mode.
Oracle 默認使用最大性能，因此不能保證數據百分白不丟失數據！
然而最大可用的模式=dg好的時候=最大保護，dg不好的時候降級=最大性能！
目前國產的db,例如阿里ob,騰訊tdsql,tbsql之類的數據保護的技術= 最大可用，多個副本或者備庫的情況下，多數同步即可，如果只剩下單台備庫或者副本，降級為異步同步，
否則一主一備的情況下，數據同步使用同步模式= Oracle的最大保護。