如何拯救你，数据库“假期综合征”？

今年春节假期，过的还顺心吗？下面要说的主人公，大概经历了假期最糟心的一天。

新年才刚过，还沉浸在新年的喜悦里。但是，A客户的数据库却“嗨”不起来。因为归档日志满导致挂起，数据库无法正常使用。（客户环境是Linux平台下双节点rac ，数据库版本11.2.0.4）

美创春节保障小分队的值班工程师小汤，接到客户的救急电话后，立马上线远程检查。一番“剥丝抽茧”后发现，其中一个节点由于oracle软件目录使用率100%，导致本地连接数据库异常，归档删除脚本策略失效。

而客户每天归档量又非常巨大，归档没能及时删除导致空间不足而引起数据库挂起。

发现问题了，工程师开启技能，对故障进行修复。查看软件目录子目录使用情况，发现监听日志目录使用量在十几个G，清理监听日志后数据库本地连接恢复正常，归档删除脚本策略生效，数据库业务恢复正常。

这个例子是因为监听日志未及时清理，进而引发软件目录满，归档目录满等一系列连环问题，最终导致数据库业务异常。 

每逢节假日，都是运维故障多发期。一方面，很多客户选择在节假日开展数据库、系统升级维护，另一方面，人为疏忽发生的概率增加。美创科技每每在这关键时间，都会组建运维保障小分队，为客户的数据库、系统等保驾护航。

多年的运维经验，对节假日容易碰到的数据库问题做了盘点梳理。除了上面提到的空间问题，还包括： 

01

软件问题

实例：

某客户节假日期间服务器中病毒，导致oracle软件中某些组件被删除，数据库无法启动。工程师在其它机器上安装相同版本正常的oracle软件，再将数据文件控制文件、参数文件等拷贝到新机器上，异机迁移恢复了数据库。

结论：

节假日期间要保证网络环境的安全，保证数据安全，防止被黑客攻击。对于数据库而言，打上最新的补丁，避免出现软件问题。

针对软件问题导致的故障，要根据不同情况来处理。如果是数据库、操作系统bug引起的故障，通过设置参数等方法绕过bug来修复故障；若是rac集群问题引起的故障，需要具体分析日志判断错误原因。

02

硬件问题

实例：

某客户数据库服务器cpu使用率几乎百分之百，数据库非常卡。环境是rac双节点，检查发现一个节点由于心跳网络问题导致该节点被驱逐，日常两个节点1700多个外部连接平均分配到两个节点，故障时正在使用的节点连接数达到3500，资源耗尽。工程师将一节点心跳网络修复后重启实例，恢复正常。

结论：

网络、存储、光纤、光交等硬件会引起服务器、数据库宕机，节假日前期检查硬件是否正常，避免出现硬件问题导致的故障。

03

sql性能问题

实例：

某医院客户节假日系统某模块卡，检查发现是某sql消耗大量资源运行缓慢，工程师找到该sql进行优化，检查关联表的last_analyzed，发现很久没有更新，导致统计信息不准确而影响执行计划。重新收集关联表的统计信息，运行更合理执行计划，从而解决某模块卡的问题。

结论：

由于sql导致数据库运行慢的性能问题，需要具体分析。

04

人为问题

实例：

某客户重新建实例，在12.1rac环境下oracle用户dbca建库的时候无法读取到asm磁盘组。检查发现是在grid用户的sqlnet.ora中添加了DIAG_ADR_ENABLED = off参数导致的。在11g环境下是可以加这一个参数的，但12.1环境下已不适用了。

结论：

有些参数不一定适用新版本的数据库，要以严谨的态度尽量避免人为误操作引起的问题。而因人为产生的误删除误操作或者断电等，引起的数据库损坏，需要备份恢复数据库；如果用户表被锁，需要解锁。

还要特别强调一点是，如果数据库配置了“备份”，那么还需要检查数据库日常的物理逻辑备份是否正常。如果没有备份，建议部署。万一节假日出现问题需要恢复数据，一份正常的数据备份集是最好的良药！

总而言之，节假日期间，数据库运维故障高发，要在节前对硬件、软件、备份等进行全面检查，以好的状态迎接节假日。同时，要加强运维管理，避免人为误操作的发生。当然，如果假期数据库不消停，及时call美创，专业的运维技术团队陪你安心过节。

阅读推荐

围观

热文

热文