标签：主库 备库 top guard IO 日志 data CPU

RDBMS 11.2.0.3

主库： 32CPU + 128G + 2节点RAC（运行四套数据库）

备库：4CPU + 64G + 单节点文件系统（运行四套数据库）

故障描述：

1 主库主机及主库正常

2 监控显示备库所在的主机，CPU利用率很高。

故障分析：

通过查看现状，有以下发现：

1  备库的top负载很高

2  备库所在主机操作的时候，很卡，有时候会发现ssh连接不上，当top负载降下来后，ssh可以连接。

 

分析问题：

1 根据得到的top结果，发现4个cpu的主机，top负载很高。%id是0，%wa是98.4%。首先想到的是IO问题 （或者IO问题导致的CPU紧张，或者CPU紧张导致的IO无法处理的问题）

2 检查主备库的同步问题，发现有1套库，已经有GAP了

3 发现出问题的当天，有一套主库的日志切换很频繁，而且alert log中提示FRA空间已经100%了，随后该FRA空间被数据库释放，并且该主库是同步的。

4 发现出问题的前几天，有一套主库的日志切换也很频繁，但是该主库不知道什么原因出现了GAP。

5 主库的主机top很正常，但是主库的数据库上，有一些归档日志没有被归档策略删除（没有传输到主库，或者没有被主库应用）

6 比较奇怪的是，主库的alert log中，提示备库的密码不正确（并没有修改密码）

7 其中一套主库上，发生故障当天后，就再也没有产生过awr快照

通过这些问题的分析，初步判断备库主机是IO问题。

 

处理问题：

当时根据分析，感觉备库上的资源有限，处理不了主库过来的大量的日志，导致的IO问题，IO问题导致的CPU问题，CPU又处理不了那么多IO。相互影响。因为该备库上没有业务运行，主库暂时没有太大的影响，所以先暂时修复下主库。

修复主库的过程如下：

找到缺少的gap，注册后，备库应用。但是发现备库上的gap确实太多（虽然查询v$archive_gap只有一个，但是修复gap后，又有新的gap）。最后就用当天的备份进行重建了，或者用备份的归档日志，进行recover 也可以。这里选择进行重建。

重建的过程，spfile存在了不需要处理，重新用备份的主库的控制文件来还原出备库控制文件。resotre，recover（或者直接mount状态下，应用mrp，会从主库拉取log），直到控制文件中的scn和datafile中的scn追平，就可以打开库了。

在重建备库的时候，发现top负载很高，甚至发现alert 中有IO huang的情况。

而且发现，平时很快的restore，这会儿很卡。当top负载降低时，restore很快。

协商增加硬件资源，增加后的CPU和内存资源为CPU16，内存128G。

然后查看备库的SGA、PGA设置，发现备库的SGA设置较小，为3G。主库最少的都在10G、20G的样子。随后，调整备库的SGA大小。

随后，再次进行restore 等动作的时候，发现偶尔top值有点高，但是不影响操作。当resotre完毕后，一切正常。

同时因为其中一个备库的日志，没有传输到备库，经过一段时间的media recover 后，主备同步正常。（在media recover 的过程中，top负载正常）

第二天，观察awr的快照的时候，发现已经有awr快照了（这个原因，主库资源较繁忙或主库的归档日志huang住后，awr的mmon进程会停止，当主库资源正常，或者主库的FRA空间回复正常后，awr的mmon进程正常产生快照）

从下图中，可以看到，15日后没有产生快照。17号偶尔产生快照。18正常产生快照。（因为17号下午18点后备库资正常了，主库应该没有什么太大的影响了，比如太多的日志撑爆FRA等等）

当资源恢复正常后，发现主库上再也没有报备库密码不一致的问题（初步怀疑是备库资源太紧张，导致主库无法获取到备库的信息或者无法登录到备库，alert log中明确提到没有办法log on到备库）

到这里，这个问题就处理完毕了。

总结下原因：

1 导致这个备库主机top负载过高的原因，是备库的IO太忙

2 什么原因导致备库的IO太繁忙，主库产生了大量的归档日志，大量的归档日志在备库上产生的过高的IO问题

3 备库上IO的问题，导致了备库的CPU处理不过来（本身备库的CPU资源就很弱），CPU和IO相互影响，死循环

4 备库上的主机内存64G，也可以。但是为什么的处理不过来呢。原因是，每个备库的设置的SGA都很小只有3G，主库上都在10-20G以上。过小的SGA无法处理太多的IO问题（比如media recover等）。举个不恰当的例子，备库资源相比主库很差，主库的有能力每小时处理80G的IO。备库资源太差，根本没有能力每小时处理80G的IO。

所以，增加了备库的资源，调整了备库的数据库内存后，该问题解决。

一些教训

1 使用主备库的时候，最好主备库的硬件配置相差不要太大

2 主备库的数据库的配置，不要有太大的偏差（这里的主库10-20G以上SGA，对比备库的3G SGA 确实太大的差距）

END

 

标签：主库,备库,top,guard,IO,日志,data,CPU
来源： https://blog.csdn.net/xxzhaobb/article/details/118018714

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。