辽宁电力营销系统灾备端复制延迟分析整改建议.docVIP

辽宁电力营销系统灾备端复制延迟分析整改建议 一OGG复制进程延迟原因： 1.OGG bug，不能正常显示lag信息，由于时区设置不正确，或者本身程序等造成。 2.OGG 灾备端复制进程延时大，这个时候主要是取决与当前主机CPU,IO，在硬件资源达到超负荷时候，对复制进程的处理就会挂起乃至延时，造成lag过大或者是显示不正确。 3.OGG 源端传送进程延时大，这个时候主要是取决于主机的CPU,IO,NETWORK，在除了与2中的硬件资源有关之外，还跟OGG传送的网卡，生产到目的端网络情况（包括网络通信长度，网络繁忙度， 网络有效负荷等），生产与目的端防火墙对发送包的限制情况。 4.OGG 目标端lag很大，跟目标端的cpu，io有关，这个时候目标端的cpu压力主要来自于3方面：系统运行，数据库运行，OGG运行；IO压力主要来自于OGG以及数据库的日志写和读，造成repliact进程延时过大主要有一下方面原因： 1.io不够，cpu够，你数据库有能力1秒能写200M数据，但是你存储io只能写100M，这个时候就积累延时了 2.io够了，cpu不够，这个时候你也会发现有延时，因为你处理速度远远低于源端传过来的数据的速度，这个时候延时也就积累了 3.io够了，cpu够了，这个时候你硬件很ok，但是你的延时很大，这个就是进程积累的日志过多； 4.数据量大造成进程负载量过大，传输过来的数据量比写入的数据量过多。 二：提高目标端Oracle处理速度 1.提高备库服务器的内存大小，为Oracle设置更大的buffer cache，shared pool，减少VMM控制的整体的换页频率所带来的对cpu和io的额外负荷。 2.确认异步IO是否开启。未开启的过程请打开服务器的aio，aix确认如下lsdev -Cc aio 3.提高PGA的大小，为多个的repliacat进程们提供足够的缓存区域。 4.对目标端ogg的接收源端发来的data文件 和 oracle本身的数据文件错开到不同的（存储级别）vg上面，以避免disk hot的情况出现，进而提高io效率。 三：从业务逻辑上拆分繁忙的延时大复制进程 方法一： 在局部进程延时大的时候，可能是这种情况，业务处理的核心压力都集中在一些对象上面，而这些对象都被安排设置到一个进程中，这个时候大部分的日志都集中在这个进程中，出现了这个进程很忙，其他进程很闲，类似多点闲单点热的情况，如果这个时候硬件资源满足情况下，可以从业务逻辑上去拆分这个进程，按照表的繁忙度把热点表平摊到2-N个进程中。 在这方面，从数据库角度提出建议，应用从业务角度划分出来的表可以从数据库对应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; 方法二： 表的DML频率并无法估算到具体产生的redo量，理论上redo的产生量越大，对应的操作涉及的数据（比如表的字段多，数据量大）就越多，所以从这个角度上讲，我们是要找到redo量产生多的那些表，这种情况下就需要用到logmnr工作，通过对归档日志的挖掘分析，开对ogg的部署进行决策支持，在当前项目，这个角度比较不倾向实际，但是可以作为一个参考方向。