oracle数据库从串行到并行的优化(log file sync 优化)

–oracle数据库从串行到并行的优化(log file sync 优化)============

1、通过CPU主频提升已经基本达到瓶颈。
2、通过AWR报告中DB Time的时间，可以看到数据库的负载情况。
3、通过AWR报告中log file sync时间可以估算从log buffer写到日志文件的耗费时间。

salve进程的引用，串行到并行

1）单库串行到并行优化： LGWR—>LGnn
1、LGWR的作用： 将log buffer中的内容写到redo log中
2、LGWR相关的等待： forground:log file sync background:log file parallel write
3、log file sync产生原因： commit过于频繁？log buffer过大？ cpu负载高？
4、log file sync等待：
1）commit操作
2）rollback操作
3）DDL操作（ddl操作实施前都会首先执行一次commit）
4）ddl操作导致数据字典修改所产生的commit
5）某些能递归修改数据字典的操作：比如查询SEQ的next值，可能导致修改数据字典。

5、log file sync的过程：
	1）用户进程发起commit	（cpu资源，前台进程通知lgwr后就开始等待log file sync）
	2）用户进程通知lgwr写日志	（cpu资源）
	3）lgwr收到请求开始写	（一直到写完，物理IO，然后lgwr进入睡眠，等待log file parallel write）
	4）lgwr写完成	
	5）lgwr通知用户进程写完成	（cpu资源）
	6）用户进程获得通知，继续做其他事。	（前台进程接收到lgwr的通知，返回cpu运行队列，处理其他事务，log file sync结束）

	log file sync=cpu资源等待时间+log file parallel write的时间

6、group commit机制：LGWR写入日志时，以log buffer的最高点为写入重点，这就需要等待最高点一下所有事务都完成copy，并且完成后会唤醒所有的睡眠的前台进程，造成CPU资源的争夺。

7、如果指定log file sync存在瓶颈：
	1）查看awr报告，查看log file sync和log file parallel write，看看之间是否存在很大的差值。
	2）moats工具：地址为http://www.oracle-developer.net/utilities.php
	2）select event,wait_time_milli,wait_count from v$event_histogram where event='log file parallel write';

8、log file sync诊断：
	1）IO延迟诊断：通过log file parallel write后台进程等待事件辅助判断
	2）CPU资源：	log file sync 时间和log parallel write时间的差异
	3）应用诊断：提交是否过于频繁，小事务（不懂业务的DBA不是好的DBA）
	4）数据库诊断：redo log buffer的大小，如果log buffer设置的比较大，lgwr很长时间处于空闲状态，一旦达到写的临界，一次需要写太多东西造成压力大。（现在很少会有这种情况）
	
9、log file sync调优：
	1）提高存储响应：降低单次log file parallel write等待时间
	2）业务端合并短小事务：降低每秒处理的事务数量。
	3）初始化参数commit_wait=nowait： 前台通知lgwr写日志的时候，让前台进程不用等，不用等log file sync等待时间，不太推荐这样的设置，可能造成数据的丢失，短期的测试或者业务需求可以这么设置。
	4）增加实例：分担单个实例每秒处理事务的数量，比如RAC，每个实例可以分担业务
	5）数据库级切分：增加新的数据库来分担每秒处理事务数量，比如全国的数据可以按省来建库分担业务。（遇到全局数据量的查询和组合的时候需要考虑怎么解决）
	6）数据库版本升级到12.1：slave进程的引入，可以增加多个slave进程来增加LGnn并行的处理。

2）RAC并行优化： LMs---->RMVn,CRn
–=关于cache fusion=

1、RAC对全局资源的访问机制：
	1）每个节点都是资源的主节点，每个节点负责一部分资源
	2）好处：共on工作负载被分配到各节点，主节点出现问题时，资源重构时间短，不会影响系统的高可用和性能。
	3）坏处：节点间信息交互比较多。
2、RAC资源访问的一般流程：
	1）资源申请节点发送请求到资源主节点
	2）资源主节点将对应的请求发送给资源持有节点
	3）资源持有节点将本地持有的资源锁进行响应的改变，之后将资源发送给资源申请节点
	4）资源申请节点获得需要的资源，通知资源主节点更新资源的相关锁信息。

3、LMS进程的作用：
	LMS进程主要用来管理集群中数据块的访问，并在不同实例的BUFFER CACHE中传输块镜像，LMS进程跨集群管理数据库的请求，并保证所有实例buffer cache数据库的镜像只能出现一次。

4、RAC间CR块的访问：
	1）申请者节点的服务器进程发送CR请求给本地的LMS进程
	2）如果本地节点包含了所需的CR块，直接返回信息给服务器进程，整个进程结束，如果没有，进入第三步。
	3）申请者节点的LMS进程发送请求给主节点，主节点分析后找到拥有满足要求的CR块所在的节点，如果所有节点都没有满足要求的CR块，那么主节点会把这个请求发送给拥有距离CR块最近的PI的节点。
	4）持有对应PI或者CR块的节点的LMS收到请求，如果满足要求的CR块存在，直接跳到第9步，过程结束，否则从PI开始重构CR块。
	5）持有节点的LMS进程从自己拥有的PI开始重构CR块。
	6）LMS进程访问UNDO表空间，构建需要的CR块，如果不需要clean一些undo block的话，进入步骤9.
	7）在构建CR块的时候，通知LGWR进程将clean out操作信息记录到重做日志文件中。
	8）LGWR向重做日志中写入对应的redo信息。
	9）CR块构建完成，持有者节点的LMS进程发送CR块给申请者节点的服务器进程，完成。

5、RAC的log file sync时间：
	RAC的log file sync时间=LGWR执行重做日志I/O时间（单实例）+SCN传播时间（需要把修改后的SCN传给所有节点，其他节点参考SCN来进行操作，保证所有节点之间的时间一致）
	如果配置了同步环境：log fil sync的时间=LGWR执行重做日志I/O时间（单实例）+LGWR传播重做日志信息到备库的时间（信息写入standby redo log后返回主库已写）

6、RAC引入RMVn进程，增加并行LMS，协助LMS进程来处理业务。

3）Dg并行优化： Multi MRP