|
那么如果是最大可用模式下呢？ 二、测试
--查询数据库的保护模式:
>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操作事务，欧博abg提交：
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
https://blog.51cto.com/hsbxxl/1846499
https://blog.csdn.net/weixin_30895723/article/details/110218082 在本案例中，一共出现了2种类型的非空闲等待事件： 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）解决方案 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;
Maximum Availability
This protection mode provides the highest level of data protection that is possible without compromising the availability of |