Oracle异常关闭后谨防数据文件受损
数据库是智慧校园下各类信息系统的核心组成部分。Oracle数据库凭借其强大的稳定性和可伸缩性，目前基本是国内所有高校作为软件平台底层数据仓库的主流选择。
正所谓“好马配好鞍，宝剑赠英雄”，稳定高效的Oracle数据库，自然也对运维人员技术水平和底层硬件运行环境的要求更高，一次意外的停电或一个存储磁盘的坏块，都有可能让数据库出错，进而导致信息系统罢工，接下来就以一则案例“现身说法”。
问题现象
数据文件无法读取导致系统罢工
近期，我们频频接到多所高校来电咨询，均反馈其数据库的部分数据文件出现无法读取的情况，这将直接导致其对应的信息系统无法使用，影响学校业务开展。问题出现时数据库后台告警日志如下，该案例显示第6号数据文件无法读取：
数据库运维工程师第一时间与现场沟通了解到，系意外断电导致数据库异常关闭，再重启时出现上述问题，这也为后续问题的分析与解决缩小了排查范围。
问题分析
异常关闭后数据库都做了什么
既然在问题产生前，出现过意外断电导致的数据库异常关闭现象，那我们就需要了解数据库在异常关闭到重新启动的过程中发什么了什么事情？同步还需要了解数据库正常的数据操作及关闭原理，以找出差异和原因所在。
Part.1
当我们在进行数据操作的时候，均会产生两种不同类型的数据：
重做记录
目的是确保数据库具有可恢复性
VS
被修改数据块本身
目的是为了保证数据库的持久性
oracle规定：保证重作记录先于对应的脏数据块写入永久层（也就是数据库文件）
那么，一个更改产生的重作记录和脏数据块，DBWn必须在LGWR将重做记录写入在线重做日志之后才可以把对应的脏数据块写入磁盘，这就导致数据文件永远比在线重做日志旧。
Part.2
当数据库正常关闭与启动时，数据库会做三件事：
☑ Oracle会发起一个完全检查点，此时任何新的变更将不被允许。
☑ LGWR将日志缓冲区中现有的重作记录写入在线重做日志——>清空日志缓冲区——>停下LGWR——>在线日志停止更新。
☑ DBWn将相对应的脏数据库写入数据文件
以上三件事情目的就是实现在线重做日志和数据文件的同步。对正常关闭的数据库发出start命令后，数据库要在open阶段检查在线重做日志和数据文件是否同步，这也是打开数据库的必要条件。
Part.3
当数据库异常关闭与启动时，数据库做了什么：
Step.1
管理员发出startup命令。
Step.2
打开参数文件，启动实例。
Step.3
打开控制文件。
Step.4
检查在线重做日志和数据文件是否同步，结果为不同步。
Step.5
对已经提交事务实施前滚，对没有写如数据文件的脏块写进数据文件。
Step.6
打开数据库。
Step.7
对没有提交的事务实施回滚，将相当于sql命令中的rollback,将相对应的已经写入数据文件的块给修改掉，完成之后数据文件中不会存在由于上一次强制关闭而留下的，未提交的脏数据块。
而问题就恰恰就出现在这里：在某些情况下在线重做日志或数据文件在数据库异常关闭的过程中可能产生了坏块，使得数据库无法顺利的完成前滚和回滚操作，就会出现数据文件发生无法读取的问题。
解决思路
全面检查日志以恢复数据文件
经过上述分析明确故障原因后，其实对症下药地去排障的思路就相对十分清晰了：
1
全面检查操作系统和数据库系统的告警日志，定位问题发生的根本原因。
2
找出损坏的数据库文件，确认其目前的状态。
3
利用在线日志与归档日志中的重做记录手动对数据文件进行恢复。
至此，数据文件经过恢复后，数据库同步状态回归正常，受影响的信息系统就可以重新正常访问了。
专家建议
做好UPS与容灾备份双重预防
无论意外断电或存储坏块，数据库异常关闭导致数据文件受损时，都可以通过上述思路在线快速恢复，即使无法快速恢复，也可以通过数据库备份对数据文件进行恢复。但是为了保证业务连续运行，避免承受可能存在的数据丢失风险，专家建议学校做好以下预防工作：
建设UPS不间断电源并定期检修
建议学校机房建设UPS不间断电源，并定期对UPS进行检修，有条件的情况下可以每年进行一次机房断电演练，确保在异常断电时核心服务器可以正常运行。
做好容灾应急恢复方案
当学校信息系统遇到严重的故障时，比如核心存储损坏、机房断电等情况，若没有整体有效的数据保护与应急恢复方案，学校核心信息系统将长时间停摆，造成无法估计的损失与严重的社会影响。建设信息系统容灾可以在信息系统发生严重故障时快速对数据与系统进行切换与恢复，减少数据丢失的可能性，保证业务连续性。目前比较主流的容灾解决方案包括：存储卷复制技术、磁盘阵列复制技术、数据库复制技术。