性能问题导致的数据库严重故障案例之一，故障案例
好久不来这里写东西，今天有点时间，来这里写点最近遇到的事情。前段时间，某电信业务用户因某核心生产库最近多次宕机重启，多方人员介入无果后，给我发来了邮件，大概意思就是现在该问题已经造成了比较严重的后果，希望能帮助介入分析、诊断并解决该问题。通过之前介入该问题的人员了解到，到目前为止，已经是第三次宕机重启了，时间区间大概为2个多月的样子。第一次重启后，因为运维人员并未获取到当时有价值的信息，因此，并没有一个结论；第二次其他数据库相关人员定位到可能是该版本（11.2.0.4,3）的某个bug引起的，并给出了解决方案，他们之所以这么解决，是因为在数据库的alert.log中发现了该bug的信息，因此，都坚信这就是该问题的根源所在，实施该方案后，大家心里就踏实了。可令大家没想到的是，过了不久，同样的故障依旧重现了，至此，给我发来了邮件。通过和相关人员的沟通，并获得了问题发生时仅有的信息（获取的信息并不全），只是听到他们说，该问题发生时很奇怪，系统突然hang住的样子，而且期间，无论是DB还是OS层面的操作，都没什么反应，他们也有的怀疑OS或DB层面的异常，甚至怀疑到了硬件的问题。。。，当然，他们的怀疑也不无道理。通过运维人员提供的DB日志，发现了一个奇怪的问题，该数据库在问题发生期间，并不是因为故障导致的自动宕机，而极可能是人为关闭了数据库，这有点出人意料，其他相关人员也极力否认，这是预料中的，没人愿意承认这种事情，况且，其中一次在23点左右发生的，他们用这个时间来反驳我：这个时间点，谁还会操作数据库？想想也是，这毕竟只是一个线索而已，如下就是当时的日志信息:
会不会CLUSTER因为某些因素主动重启了数据库呢？因为运维人员几乎没提供什么信息，于是，又让他们采了OS层面的信息，进一步证实了我的猜测：
那么，什么因素导致了cluster主动重启了数据库呢？继续看看运维提供的awr报告，定位到了异常过程和相应sql如下：
反馈用户后，用户侧人员很快定位到问题所在，处理后，至今近半年，故障没再发生，一切正常。
如果系统故障造成数据库非正常关闭，在下一次open的时候自动进行recover操作，未提交的操作会被回滚，提交的操作会根据日志进行恢复。只要某个事务修改了数据，那么更新前的原有数据就会被写入一个回滚段或undo段，在你提交之前，其他会话查询的是undo段，实际上你的操作已经写在数据块上了，但是会有标志，表示未提交，只有你的会话可见。你commit之后这个标志会被更改，操作会写入redo日志。
新增archives 时的状况：
条件和假设：自上次镜像备份以来已经生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的镜像（冷）拷贝；archive log(s) 可用。
恢复步骤：
1. 如果数据库尚未关闭，则首先把它关闭： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 将备份文件抄送回原始地点： 所有Database Files
所有Control Files（没有archive(s) 或redo(s) 的情况下，control files 的更新无任何意义）
所有On-Line Redo Logs (Not archives) init.ora file（选项）
3. 启动数据库： $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
数据文件, 重作日志和控制文件同时丢失或损坏：
条件和假设：Archivelog Mode; 有同步的所有所失文件的镜像（冷）拷贝；archive log(s) 可用
恢复步骤（必须采用不完全恢复的手法）：
1. 如果数据库尚未关闭，则首先把它关闭： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 将备份文件抄送回原始地点：
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
init.ora file（选项）
3. 启动数据库然而并不打开：
svrmgrl>startup mount
4. 做不完全数据库恢复，应用所有从上次镜像（冷）备份始积累起来的archives：
svrmgrl> recover database until cancel using backup controlfile;
......
......
cancel
5. Reset the logfiles （对启动而言不可省略）：
svrmgrl> alter database open resetlogs;
6. 关闭数据库并做一次全库冷备份。
数据文件和控制文件同时丢失或损坏：
条件和假设：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷贝；archive log(s) 可用
恢复步骤：
1. 将冷拷贝的datafiles(s) 和control file(s) 抄送回原始地点:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 选项启动数据库：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以旧的control file 来恢复数据库：
svrmgrl> recover data......余下全文>>