近期某客户的Oracle exadata出现故障，最后4个计算节点全部crash，然后最后无法正常启动，在open数据库时写丢失错误，如下：

从上述的报错来看，数据库最后open时报错无法进行instance recovery；主要是因为在进行实例恢复时遇到了逻辑坏块。

也就是说该数据库在之前出现了写丢失，导致出现了逻辑坏块，最后导致实例重启后无法进行实例恢复。

通过分析4个rac节点的故障前后顺序发现，最早出现crash的是节点3，该节点因为出现out of memory，进而导致数据库crash：

我们可以看到，该数据库实例的核心进程LMS因为OOM被kill，所以导致实例异常终止，最终也影响了其他节点的通信，陆续出现了其他节点LMON终止实例的情况。那么该节点为什么会出现内存耗尽的情况呢？分析了故障前20分钟的监听日志发现确实存在大量连接：

大家不难看出，从10:29分开始暴涨，但是在10:27和10:28分是异常的，一分钟居然只有2个连接，甚至没有。查看该时间段的ASH数据也会发现存在大量的SQL*Net more data from client、SQL*Net more data from dblink等待。检查上述等待的相关应用SQL，没有什么特殊的，都是一些常规insert into操作，按理说不应该出现这种异常等待。对于一个event而言：

该等待事件本质上是指服务器进程等待客户端发送更多的数据或者消息。

客户端发送数据传输的过程，大概分为如下4个步骤：

• 服务器进程变成开始接收数据的状态
• 客户端开始发送数据
• 通过网络传输
• 服务器进程接收数据完成

由于Oracle Net通过SDU (Session Data Unit) 来控制着发送和收接数据的大小，如果传输数据时，数据大于用于传输的SDU大小的话（SDU默认8K），就需要进行多次传输；此时的表现就是会话等待SQL*Net more data from client;直到数据传输完毕，该等待才会结束。

 因此该等待事件产生通常为如下几个原因:

• 应用SQL传输数据过大
• 数据库SDU配置过小
• 网络问题

因此我们很容易排出前面2个因素，那么极大概率就是网络问题了。再看第2个event，这就完全跟网络有关系了，基于dblink的访问操作，如果应用SQL本身ok的话，也不应该出现这么大量的等待，这样明确的指向了网络问题。

后经过客户了解到，该单位业务部门在10:26分左右进行了网络调整，这一切都能解释通了。。。

那么此次问题的根源就是业务期间进行了网络调整；导致数据库其中一个节点出现了堵塞，进而出现连接暴涨的情况，最后内存耗尽，导致实例crash，最终引发了一系列的连锁反应。

罪魁祸首已经找到了。那么最前面的写丢失是如何产生的呢？从这里来看，并非常见的物理坏块，比如因为IO出现块写断裂，不完整的情况；而是逻辑坏块。逻辑坏块本身表示块结构是完整，只是数据不一致，比如无法应用redo，或者表和索引数据不一致等。

由于最后启动时报错的block scn相对旧一些，因此我们认为仍然是这次实例突然crash引发的写丢失。