--查询数据库的保护模式:
>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的最大保护。