------------------------------------------作者xxxx------------------------------------------日期xxxxOracleCurrentRedolog损坏后恢复数据库【精品文档】【精品文档】【精品文档】【精品文档】【精品文档】【精品文档】CurrentRedolog损坏后恢复数据库禤梓桥00109548关键字：10513事件，_allow_resetlogs_corruption，_corrupted_rollback_segments，dba_rollback_segs，ORA-600[2662]，ORA-600[2663]，ORA-600[4136]。适用场景：1.当前redolog文件发生物理或逻辑损坏；且没有可用的redolog备份；2.没有可用于恢复的备份；3.rman恢复时间过长或备份太旧，不满足业务快速恢复的
要求
对教师党员的评价套管和固井爆破片与爆破装置仓库管理基本要求三甲医院都需要复审吗
。如何判定损坏日志状态为CURRENT：1.以startup启动后，检查alert日志，从”Startedredoscan”日志信息开始如下类似的错误信息：StartedredoscanORA-00313:无法打开日志组3(用于线程1)的成员ORA-00312:联机日志3线程1:'F:\APP\X00109548\ORADATA\ORCL\REDO03.LOG'ORA-27041:无法打开文件OSD-04002:无法打开文件O/S-Error:(OS2)系统找不到指定的文件。Abortingcrashrecoveryduetoerror313或者StartedredoscanORA-368signalledduring:ALTERDATABASEOPEN...注意：如果alert只有ORA-368错误，没有报告具体的redolog文件时，需要先按照损坏redolog文件状态为非current的
办法
鲁班奖评选办法下载鲁班奖评选办法下载鲁班奖评选办法下载企业年金办法下载企业年金办法下载
处理，当无法恢复数据库时，才按以下恢复步骤尝试恢复。2.在startup启动报错后，此时数据库处于MOUNT状态，查看损坏的文件状态是否为CURRENT：SQL>selectmember,,#fromv$logl,v$logfilefwhere#=#;MEMBERSTATUSGROUP#----------------------------------------------------------F:\APP\X00109548\ORADATA\ORCL\REDO01.LOGINACTIVE1F:\APP\X00109548\ORADATA\ORCL\REDO02.LOGINACTIVE2F:\APP\X00109548\ORADATA\ORCL\REDO03.LOGCURRENT3恢复步骤：确认损坏redolog文件为current时，执行以下操作：步骤1：将spfile转存为pfile.ora，并在pfile.ora文件中添加_allow_resetlogs_corruption=true。转存spfileSQL>createpfile=''fromspfile;编辑文件，添加如下参数：*._allow_resetlogs_corruption=true正常关闭数据库SQL>shutdownimmediate;步骤2：以pfile文件启动实例并将数据库挂载SQL>startuppfile=''mount;步骤3：执行recoverdatabaseuntilcancel，并输入cancelSQL>recoverdatabaseuntilcancel;ORA-00279:更改1546960(在10/17/201209:26:37生成)对于线程1是必需的ORA-00289:建议:ORA-00280:更改1546960(用于线程1)在序列#48中指定日志:{
=suggested|filename|AUTO|CANCEL}cancel<---手工输入cancelORA-01547:警告:RECOVER成功但OPENRESETLOGS将出现如下错误ORA-01194:文件1需要更多的恢复来保持一致性ORA-01110:数据文件1:'F:\APP\X00109548\ORADATA\ORCL\SYSTEM01.DBF'注意：此时可能会报告SYSTEM系统
表
关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf
空间数据文件需要恢复，可以忽略此错误。步骤4：以openresetlogs打开数据库SQL>alterdatabaseopenresetlogs;注意：1.此时可能打不开数据库，或者打开数据库后alert日志有ORA-600[2662]、ORA-600[2663]、ORA-600[4136]、ORA-600[4194]、ORA-600[4197]等错误。ORA-600[2662]、ORA-600[2663]等错误通常是因为在实例崩溃时事务已经将数据块写入到数据文件中。ORA-600[2023]、ORA-600[4136]、ORA-600[4194]、ORA-600[4197]等错误是因为undo表空间中的数据需要恢复。2.如果SYSTEM表空间的数据损坏，将无法恢复数据库，如果是业务用的数据文件，考虑删除这些损坏的文件后，接着按以下操作执行。步骤5：在pfile.ora文件中增加如下参数并MOUNT数据库编辑文件，添加和修改如下参数：*.event='10513tracenamecontextforever,level2'undo_management=manual<--此处将auto修改为manualSQL>startuppfile=''mount注意：startuprestrict模式无法打开数据库。步骤6：执行recoverdatabase操作，并打开数据库(recoverdatabase验证数据库文件是否有问题，可不做)SQL>recoverdatabase;完成介质恢复。SQL>alterdatabaseopen;<--此时要以正常方式打开此时alert日志应该没有报错的情况步骤7：需要用exp命令备份业务数据(命令步骤不详细列出)，同时检查dba_rollback_segs表中的回滚段状态SQL>selectsegment_name,tablespace_name,statusfromdba_rollback_segs;SEGMENT_NAMETABLESPACE_NAMESTATUS--------------------------------------------------SYSTEMSYSTEMONLINE_SYSSMU22_1350439519$UNDOTBS1OFFLINE_SYSSMU21_1350439519$UNDOTBS1OFFLINE_SYSSMU20_1350439519$UNDOTBS1NEEDSRECOVERY_SYSSMU19_1350439519$UNDOTBS1OFFLINE_SYSSMU18_1350439519$UNDOTBS1OFFLINE_SYSSMU17_1350439519$UNDOTBS1OFFLINE_SYSSMU16_1350439519$UNDOTBS1OFFLINE_SYSSMU15_1350439519$UNDOTBS1OFFLINE_SYSSMU14_1350439519$UNDOTBS1OFFLINE_SYSSMU13_1350439519$UNDOTBS1OFFLINE_SYSSMU12_1350439519$UNDOTBS1OFFLINE注意：1.当exp命令在执行过程中报ORA-01555错误时，此时不要试着将UNDOTBS1空间扩大，这是因为实例崩溃时数据库中未提交事务占用了大量的回滚段，在打开数据库后undo表空间仍然有数据需要恢复，即使UNDOTBS1表空间增大，这些可用空间依然不能使用。表空间中存在NEEDSRECOVERY的回滚段需要记录到pfile中，并要重建该undo表空间。步骤8：设置参数记录损坏的回滚段，重启后删除并重建UNDOTBS1表空间8.1编辑文件，添加如下参数：*._corrupted_rollback_segments='_SYSSMU20_1350439519$'#上述查询中NEEDSRECOVERY状态的回滚段，如果有多个需要记录的回滚端，设置形式为：*._corrupted_rollback_segments='SEGMENT_NAME1','SEGMENT_NAME2',…8.2正常关闭数据库SQL>shutdownimmediate;8.3重启数据库SQL>startuppfile='';8.4删除UNDOTBS1表空间SQL>droptablespaceundotbs1includingcontentsanddatafiles;8.5重建UNDOTBS1表空间(以下仅是样例)SQL>createundotablespaceundotbs1datafile'F:\app\x00109548\oradata\orcl'size8192m;步骤9：关闭数据库，以原来的spfile参数文件正常启动数据库SQL>shutdownimmediate;SQL>startup;小结：1.在步骤4打开数据库时，如果没有ORA-600[2662]，ORA-600[2663]，ORA-600[4136]等错误，那么不需要执行步骤5~6的操作。这通常是事务中DML操作的数据块没有写到数据文件，而是在buffercache中，因此不需要设置10513事件和_corrupted_rollback_segments，这时按照步骤9操作，观察是否能正常打开、是否有相应的ORA-600错误，如果没有即可正常使用。2.在步骤5必须将undo_management修改为manual，否则在dba_rollback_segs表中可能无法展现有问题的回滚段，从而在数据库正常运行中报ORA-600[2023]和ORA-600[4136]错误。3.当在恢复过程中发生ORA-600[2662]、ORA-600[2663]错误，不论回滚段是否有损坏的情况，建议都重建undo表空间，避免在业务正常运行时发生ORA-01555错误。Redolog损坏验证：1.在正常的数据库中创建一张小数据表t_smalltable，模拟DML操作时，数据块完全在buffercache的情况建立t_smalltable表和索引SQL>createtablet_smalltableasselect*fromall_objects;SQL>createindexix_smalltable_objectidont_smalltable(object_id);1.2模拟未提交事务SQL>updatet_smalltablesetowner=lower(owner);1.3在另一个窗口,以sys用户登录将数据库强行关闭SQL>conn/assysdbaSQL>shutdownabort;将操作系统上的所有重做日志删除2.在正常的数据库中创建一张大数据表t_bigtable，模拟DML操作时，有部分数据块写到磁盘的情况建立t_bigtable表SQL>createtablet_bigtableasselect*fromall_objects;SQL>beginforiin1..10loopinsertintot_bigtableselect*fromt_bigtable;endloop;commit;end;/2.2模拟未提交事务SQL>updatet_bigtablesetowner=lower(owner);2.3在另一个窗口,以sys用户登录将数据库强行关闭SQL>conn/assysdbaSQL>shutdownabort;将操作系统上的所有重做日志删除注意：将undotbs1表空间的总大小设置为100M左右，这时可以模拟在恢复过程中遇到的ORA-1555错误。
浙公网安备 33021202002483