最近临时接手一个ogg的项目，前面的兄弟没处理好，算是临危而上了。当时是这种情况，ogg的初始化完成了，但是发现复制进程的延时有100多个小时，而且越积越多，但是进程还是在正常允许没有hang住，根据这个情况根据数据库和ogg的角度提出和执行了一些优化上的处理事宜，具体如下：

首先延时是一个相对的代表当前数据同步处理情况，相对主库运行时间段的一种判断，也是OGG提供给我们当前进行的工作进度展示，影响Goldnenate进程lag的因素有哪些？

具体我统计如下：

1.OGG bug，不能正常显示lag信息，由于时区设置不正确，或者本身程序等造成

2.OGG 源端抽取进程延时大，这个时候主要是取决与当前主机CPU,IO，在硬件（上述任1）资源达到超负荷时候，对抽取进程的处理就会挂起乃至延时，造成lag过大或者是显示不正确，或者是抽取开始的scn距离当前的主库scn有时间的差距。

3.OGG 源端传送进程延时大，这个时候主要是取决于主机的CPU,IO,NETWORK，在除了与2中的硬件资源有关之外，还跟OGG传送的网卡，生产到目的端网络情况（包括网络通信长度，网络繁忙度， 网络有效负荷等），生产与目的端防火墙对发送包的限制情况。

举些例子，如果你的日志量很大，但是你的网卡为百M网卡，你传送需求是20M/s，传送速率只有理论的10/S，这时候延时显而易见就出来了，你每秒就有10m的延时，相当于1s就积累1s的延时。
比如传输长度，光纤输出平均1公里增加延时1ms，这个时候比如吉林长春到北京亦庄的光纤是经过了1000公里，那么这里1000*0.001=1s，这是理论的情况下最小的延时。
再接着是防火墙，还有无线网络的考虑情况，这些跟网络传输环境息息相关的方面都需要考虑进去。
4.OGG 目标端lag很大，跟目标端的cpu，io有关，这个时候目标端的cpu压力主要来自于3方面：系统运行，数据库运行，OGG运行；IO压力主要来自于OGG以及数据库的日志写和读，那么repliact进程延时大了主要是什么情况？

4.1.io不够，cpu够，你数据库有能力1秒能写200M数据，但是你存储io只能写100M，这个时候就积累延时了

4.2.io够了，cpu不够，这个时候你也会发现有延时，因为你处理速度远远低于源端传过来的数据的速度，这个时候延时也就积累了

4.3.io够了，cpu够了，这个时候你硬件很ok，但是你的延时很大，这个就是进程积累的日志过多；

数据库性能问题，OGG性能问题就和看病一样，需要对症下药，如果诊断错了，你开的药就错了，出现的结果就是病没治好，有可能身体本身器官负载还更大了.在这个项目中的情况，和我上述描述的症状对比起来，在多次诊断中，我比较倾向4.1，4.2，4.3的综合类型，就是目标端replicat应用日志的速度无法追上（4.1，4.2），而且在初始化完成后本身在目标端积累了过多的日志（4.3）。

那又怎么处理？对症下药。优化资源使用，提高数据库的处理速度是我们要做的事情。那么怎么处理？根据情况可以考虑下面的2种方式来做

一：提高目标端Oracle处理速度

1.关闭备库的日志补全级别，关闭备库的强制日志模式，减少redo产生，降低io。
2.置备库为noarchive（非归档模式），减少archive过程产生的io。
3.提高备库服务器的内存大小，为Oracle设置更大的buffer cache，shared pool，减少VMM控制的整体的换页频率所带来的对cpu和io的额外负荷。
4.确认异步IO是否开启。未开启的过程请打开服务器的aio，aix确认如下lsdev -Cc aio
5.提高PGA的大小，为多个的repliacat进程们提供足够的缓存区域。
6.对目标端ogg的接收源端发来的data文件 和 oracle本身的数据文件错开到不同的（存储级别）vg上面，以避免disk hot的情况出现，进而提高io效率
7.对无查询，存插入更新（全表）的对象的索引进行删除

二：从业务逻辑上拆分繁忙的延时大复制进程

角度1：工作量最小，但是统计会有一定误差

在局部进程延时大的时候，可能是这种情况，业务处理的核心压力都集中在一些对象上面，而这些对象都被安排设置到一个进程中，这个时候大部分的日志都集中在这个进程中，出现了这个进程很忙，其他进程很闲，类似多点闲单点热的情况，如果这个时候硬件资源满足情况下，可以从业务逻辑上去拆分这个进程，比如这次宋经理根据应用开发商的提供的表的更改频率表按照等级来拆分进程，按照表的繁忙度把热点表们平摊到2个进程中。而周五我的建议是全部平摊出去，这样效果才会明显，而根据文档显示宋经理已经按照应用商提供的将热点表全部平摊到各个进程中。
在这方面，我方从数据库角度提出建议，应用从业务角度划分出来的表可以从数据库对应DML操作的频率记录上进行check对应。因为存在一种情况，应用提供商提供的是表的操作频率，比如查询，更新，插入，删除都是在一起统计的，从细化上我们需要的表的更新，插入，删除方面的统计信息，这类信息可以通过oracle 实例中的ALL_TAB_MODIFICATIONS表进程查询数据库中所有对象的delete，insert，update的频率，根据频率高的进行排序，再对频率高的前100，或者200的表进行拆分，这样的效果可能会更理想，具体语句如下：

select TABLE_OWNER,TABLE_NAME,INSERTS,UPDATES,DELETES from ALL_TAB_MODIFICATIONS ORDER BY 3,4,5;


或者

select TABLE_OWNER,TABLE_NAME，INSERTS+UPDATES+DELETES "ALL_DML_COUNTS" from ALL_TAB_MODIFICATIONS ORDER BY 3;

角度2：工作量较大，但是统计效果精准

表的DML频率并无法估算到具体产生的redo量，理论上redo的产生量越大，对应的操作涉及的数据（比如表的字段多，数据量大）就越多，所以从这个角度上讲，我们是要找到redo量产生多的那些表，这种情况下就需要用到logmnr工作，通过对归档日志的挖掘分析，开对ogg的部署进行决策支持，在当前项目，这个角度比较不倾向实际，但是可以作为一个参考方向。