一次ODA宕机分析

问题详细描述

故障诊断分析

1.1 ODA 数据库1节点异常宕机

通过现场当天去机房排查时发现，ODA数据库机1节点服务器处于异常宕机状态（即不可用）。此时，所有的业务都连至ODA机2节点，导致所有的业务负载均在2节点上。在业务高峰期时，会加剧2节点资源的争用，由此可能会引起数据库性能问题。

建议：在业务低峰期时，尝试重启ODA数据库机1节点，确认1节点异常宕机原因以及是否有硬件模块损坏。

1.2 本地系统空间/opt、/u01使用率100%

排查时发现，数据库软件安装目录/u01空间基本满了，客户反馈/u01空间使用曾达到100%，当数据库安装目录空间满掉，会造成数据库不可用或者异常宕机。通过分析发现，/u01下的数据库相关日志占用掉很大一部分空间，比如listener.ora和listener_scan1.log就占用掉几十G磁盘空间。/opt目录下部署了osw工具，保留了服务器资源负载的监控日志，但保留策略设置不合理导致/opt空间占用100%。

建议：对/u01和/opt目录下占用大量磁盘空间的文件进行分析及确认，最后进行清理。

1.3 process 设置不合理

从AWR报告中不难看出，系统分配的process数增长到1000，达到了数据库设置的上限阈值。当达到阈值时，此时其他站点或者客户端继续连入数据库，就会直接报错，从而影响业务。建议调整数据库参数process阈值。

1.4 重复性sql问题

从AWR报告分析，数据库中存在大量的类似SQL，这将大大的增加数据库解析的成本，在业务高峰期时段，大量的该类SQL高频执行，将会极大的加剧资源的消耗，由此可能会引发数据库性能问题。建议对该类SQL使用绑定变量。

1.5 数据库审计未关闭

11g 默认启用的审计选项，表示审计数据将记录在 数据库 中的SYS.AUD$审计字典基表上。在11g中CREATE SESSION将被作为受审计的权限来被记录，因此当SYSTEM表空间因磁盘空间而无法扩展时将导致这部分审计记录无法生成，最终普通用户的新会话将无法正常创建，普通用户将无法登陆数据库。导致数据库整体挂起。其次，该审计记录会持续占用system系统空间，非常容易使得system表空间达到阈值，由此可能会造成数据库宕机。建议关闭数据库默认的审计功能。

1.6 容灾备份相关问题

跟客户沟通交流中， ODA数据库机就单纯的两个节点的RAC架构。当前，RAC架构中1节点异常宕机，只有2节点单独运行。在没有任何灾备的前提下，若遭遇突发情况，导致数据库不可用，将极大的影响业务。考虑配置第三方容灾产品，增加数据库的安全性。