Exadata一体机故障回顾

2016年9月份，中心开始购入Exadata一体机，并于10月份迁入第一套数据库到一体机，截至目前为止（2019年10月份），已经有10多套系统运行在Exadata一体机上。在这3年多的时间里，发生了各种大大小小的一体机故障，有应用方面引起的，有硬件方面引起的，也有一体机本身BUG方面引起的，今天就写这方面。

其实，第一次把数据库迁入一体机后没几天，就发生了一次数据库重启的故障，虽然很快启动完成，影响不是很大，但是暴露出来对一体机的不熟悉以及项目管理的失责。故障发生的原因很简单，其实就是在主机层面设置了大页，但是数据库实例没有设置大页（参数设置了但是没有重启生效），导致部分内存无法使用，在业务高峰期，数据库内存不足导致实例重启。总共256G的内存，设置了128G的大页，数据库使用了80G内存，正常理解，，除去128G设置了大页的内存，还有128G，是有足够内存给数据库用的，但是实际不是这样，因为数据库PGA会突破参数的限制，然后原厂也明确给出建议，必须重启实例以便大页生效，但是当时感觉内存是足够的，而且才刚迁移到一体机，应该不会出现问题，等两天再重启，抱着侥幸心理，没有申请变更时间重启实例生效大页，结果，第三天，数据库实例就重启了，造成了故障，影响了业务正常运行10分钟。

第二次故障，是一次影响面很大的故障，这一次故障是从管理到技术，从客户到原厂，都失责的故障，暴露了对生产环境的管理不规范，以及对业务的不敏感。当时一体机是4个计算节点和3个存储节点，需要扩容3个计算节点，扩容节点，正常来说是比较简单的事情，就是加节点嘛，不会影响原有节点的正常运行，但是在加节点过程中，却出现了提示要重启整个集群的提示，然后扩容节点的原厂哥们，就直接重启集群了，要知道，当时是下午6点多，还是业务高峰期的时间，影响极大，因为是整改集群重启，不像第一次故障那样，是实例重启，一个实例重启了还有另外2个实例可以正常对外提供服务，集群重启是所有实例都会关闭，导致业务不可以，业务系统无法使用接近20分钟，因为集群重启是很消耗时间的。从这次故障来看，暴露出来第一个问题就是，没有申请专门的变更时间进行扩容节点，第二个问题就是原厂扩容节点的技术不熟练，明明说是不影响原有节点的，但是却出现需要重启整个集群的步骤，而且还直接干了，没有一点业务敏感性。从此之后，诞生两个规范，第一个，所有一体机操作必须写方案评审测试通过后方可进行；第二个就是在晚上10点前禁止对一体机做任何操作（后面扩展到所有数据库才做禁止白天操作）。

后面还有使用过程中遇到的故障，升级Image遇到的故障，系统BUG等等，今天先到这里。