如何进行ora-01110错误的异常恢复

如何进行ora-01110错误的异常恢复，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。某日，生产数据库服务器异常宕机，在重启服务器开启数据库时报如下错误：SQL> startup
ORACLE instance started.
Total System Global Area 1.6911E+10 bytes
Fixed Size
2113696 bytesVariable Size
8472498016 bytesDatabase Buffers
8422162432 bytesRedo Buffers
14659584 bytesDatabase mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/oracle/PRD/data1/system_1/system.data1’
有一种解决方法是这样的
SQL> RECOVER DATAFILE ‘/oracle/PRD/data1/system_1/system.data1’
恢复受损的文件.
SQL> recover tablespace system;//不一定需要，提示不要求恢复的时候，可以直接打开数据库。
恢复系统表空间.
SQL> RECOVER DATABASE;
恢复数据库.
SQL> ALTER DATABASE OPEN;
Database altered.做这类操作时，不一定能成功。所以请一定先备份当前状态下所有数据文件、控制文件和日志文件，先做到保护现场，然后再做其他尝试。经过冷备后，尝试这种方法不行。咨询Dbsnake后，尝试异常恢复强行打开数据库。
#su – oracle
$vi /oracle/PRD/data1/init.ora 修改初始化参数
*._allow_resetlogs_corruption=FALSE
修改为*._allow_resetlogs_corruption=TRUE(#正常启库后修改为原值FALSE)
(这个参数允许在数据不一致的情况下打开)
*.undo_management=’AUTO’
修改为*.undo_management=’MANUAL’（#正常启库后修改为原值AUTO）
(这个参数是让UNDO表空间由自动管理变手动管理)
增加此句
*._corrupted_rollback_segments=(_SYSSMU12$)(#正常启库后去掉此句)
(屏蔽出错的事务回滚段,根据ALERT提示ORA-01555: snapshot too old: rollback segment number 12 with name “_SYSSMU12$” too small)
然后保存参数文件，重新打开库，发现还是不行。检查ALERT日志发现SCN号不一致, 下一步推进SCN值。
查看估算SCN值
SQL> select dbms_flashback.get_system_change_number()/(1024*1024*1024) from dual; DBMS_FLASHBACK.GET_SYSTEM_CHAN
——————————
3.185796233
估值为3.18NG,推进的SCN值要比这个值大，所以设置值为4$vi /oracle/PRD/data1/init.ora 增加此句

*._minimum_giga_scn=4再然后尝试打开库

SQL> startup mount pfile=’/oracle/PRD/data1/init.ora’;

ORACLE instance started.SQL> recover database until cancel;SQL> alter database open resetlogs;

Database altered.

数据库成功打开。去掉隐含参数，恢复初始参数。

最后SQL> create spfile from pfile=’/oracle/PRD/data1/init.ora’;File created.SQL> startupORACLE instance started.然后及时用EXP全库导出以保护数据,做DBV的数据校验看是否有物理坏块.
以上方法仅限特殊情况下的应用，请慎重参考。附SCN知识点:
1、Oracle的SCN在每秒16384次commit的情况下可以维持534年，每秒16384次commit是Oracle早先认为的任何系统的极限commit强度；2、Oracle里SCN的起点是1988年1月1日；3、_minimum_giga_scn=n的含义是把SCN往前推进到nG，但请注意，只有在SCN小于nG的时候才会用到这个隐含参数，反之则Oracle会置这个隐含参数于不顾。SCN原理:在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候，Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较，如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块多已经提交，所有数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。但在异常当机的情况下,由于最后一次检查点未进行或进行中间被中止,因而在控制文件,就存在部分的数据文件stop SCN为最大值,在数据库重新启动后,会检查控制文件中对应每个数据文件的stop SCN,如果stop SCN不等于控制文件中对应每个数据文件的checkpoint SCN,就会使用日志文件redo从checkpoint SCN开头到stop SCN为止的全部数据库操作.当数据库发现SCN不一致，应该是redo log文件中的SCN>=数据文件中的SCN.在定位到底是使用哪一个redo log文件时,就用到了日志文件头中的low scn,next scn,也就是说要使用的redo log 的low scn ,next scn必须包含数据文件重做所须的change vecto开发云主机域名r. 在确定了哪个数据文件须redo,oracle会比较change vector中的SCN和数据文件数据块中的SCN,如果change vector的SCN小于数据块的scn,则跳过此change vector,否则redo。
看完上述内容，你们掌握如何进行ora-01110错误的异常恢复的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注开发云行业资讯频道，感谢各位的阅读！

相关推荐: RPC远程调用该如何理解

本篇文章为大家展示了RPC远程调用该如何理解，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。今天我又给自己挖坑了，打算将 rpc 远程调用的知识，好好地梳理一下，花了周末整整两天的时间。什么是RPC呢？百度百科给出的解释…