mysql undo损坏_Current online Redo 和 Undo 损坏的处理方法

Oracle不同故障的恢复方案

Oracle undo表空间管理

上面的2篇Blog讲到了Oracle一些故障下的恢复方法，但是还有2点，之前没有做详述。即current online redo损坏的情况和undo的损坏情况。 之所以把他们放一起讲，是因为他们之间有联系。

在做操作之前，最好把控制文件，redo log 和数据文件做一个冷备份，以防万一.

一. UNDO的补充信息

所以这里补充说明一下。 在补充之前先讲一下undo segment的概念。

在blog：Oracle undo管理

中提到了Oracle的undo有两种管理方式，通过参数undo_management来设置auto和manual。

https://www.cndba.cn/dave/article/525

1.1当undo_management被设置成MENUAL时使用系统回滚段,即将undo records记录到SYSTEM表空间下的SYSTEM段。

SQL> col segment_name format a10

SQL>select segment_name,tablespace_name,bytes,next_extentfrom dba_segments where segment_type='ROLLBACK';

SEGMENT_NA TABLESPACE_NAMEBYTES NEXT_EXTENT

---------- ------------------------------ ---------- -----------

SYSTEMSYSTEM3932161048576

通过上面的这条语句，我们查到了这个用于rollback的system segment存在与system表空间。 默认情况下，只有一个segment，并且它还比较小，所以，如果使用system段来存储undo records。肯定会影响数据库的性能。 所以Oracle是建议使用Undo tablespace来管理undo records。

1.2当undo_management设置成AUTO时使用UNDO tablespace来管理回滚段。 这个时候，我们将有多个undo segment，并且这些segment是存放在UNDO表空间里的。 这样对DB的性能就会提高。

SQL>select segment_name,tablespace_name,bytes,next_extentfrom dba_segments where segment_type='TYPE2 UNDO';

SEGMENT_NAMETABLESPACE_NAMEBYTES NEXT_EXTENT

-------------------- -------------------- ---------- -----------

_SYSSMU1$UNDOTBS1117964865536

_SYSSMU3$UNDOTBS1222822465536

_SYSSMU4$UNDOTBS1117964865536

_SYSSMU5$UNDOTBS126214465536

_SYSSMU6$UNDOTBS1117964865536

_SYSSMU7$UNDOTBS1117964865536

_SYSSMU8$UNDOTBS1117964865536

_SYSSMU9$UNDOTBS1117964865536

_SYSSMU10$UNDOTBS1117964865536

通过以上SQL的查询结果，我们可以看出，有10个undo segment来存放undo records。

以上我们是通过dba_segment表查看的结果。 也可以通过v$rollstat和v$rollname两个视图来查看信息。这2个视图会显示所有rollback段的信息。包括system段和undo段。

SQL> col name format a15

SQL> select s.usn,n.name,s.extents,s.hwmsize,s.status from v$rollstat s, v$rollname n where s.usn=n.usn;

USN NAMEEXTENTSHWMSIZE STATUS

---------- --------------- ---------- ---------- ---------------https://www.cndba.cn/dave/article/525

0 SYSTEM6385024 ONLINE

1 _SYSSMU1$37659520 ONLINE

2 _SYSSMU2$39691136 ONLINE

3 _SYSSMU3$47462912 ONLINE

4 _SYSSMU4$376668928 ONLINE

5 _SYSSMU5$48511488 ONLINE

6 _SYSSMU6$37462912 ONLINE

7 _SYSSMU7$333480704 ONLINE

8 _SYSSMU8$38577024 ONLINE

9 _SYSSMU9$37462912 ONLINE

10 _SYSSMU10$313754368 ONLINE

11 rows selected.

二. UNDO损坏的情况

了解了第一部分的补充知识后，我们在来看一下undo损坏的情况。 出现这种情况，大多数是因为异常宕机，在启动的时候报的错误。DB不能启动。

比如：ORA-00600: internal error code, arguments: [4194],

对于Undo损坏的情况，能用备份恢复最好，如果不能，就只能通过一些特殊的方法来恢复。

2.1方法一,使用system segment。

在Blog：

Oracle undo表空间管理

https://www.cndba.cn/dave/article/525

https://www.cndba.cn/dave/article/525

提到了一种方法，就是使用SYSTEM的回滚段,步骤如下：

(1)用spfile创建pfile，然后修改参数：

#*.undo_tablespace='UNDOTBS1'

#*.undo_management='AUTO'

#*.undo_tablespace

#*.undo_retention

undo_management='MANUAL'

rollback_segments='SYSTEM'

(2)用修改之后的pfile，重启DB

SQL> STARTUP MOUNT pfile='F:/initorcl.ora' ;

(3)删除原来的表空间，创建新的UNDO表空间

SQL> drop tablespace undotbs;

SQL> create undo tablespace undotbs1 datafile '/u01/oradata/undotbs1.dbf' size 10M;

(4)关闭数据库，修改pfile参数，然后用新的pfile创建spfile，在正常启动数据库。

*.undo_tablespace='UNDOTBS1'

*.undo_management='AUTO'

#undo_management='MANUAL'

#rollback_segments='SYSTEM'

2.2.方法二：跳过损坏的segment

在方法一里面，我们使用了system segment。 通过第一部分我们了解到，undo segment有多个，我们可以通过alert log来查看正在使用的是哪些segment，这些段有可能损坏了。 我们只需要把这些损坏的segment跳过，先正常启动DB，在创建新的UNDO表空间，在切换一下。

https://www.cndba.cn/dave/article/525

(1)修改pfile，添加参数：

*._corrupted_rollback_segments='_SYSSMU11$','_SYSSMU12$','_SYSSMU13$'

这些字段的值，我们通过alert log查看。也可以通过如下命令查看：

#strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u

(2)用修改之后的pfile启动DB

因为跳过了哪些损坏的segment，所以DB可以正常启动。

(3)创建新的UNDO表空间，并切换过来

SQL> create undo tablespace undotbs1 datafile '/u01/oradata/undotbs1.dbf' size 10M;

SQL> alter system set undo_tablespace=undotbs1;

SQL> drop tablespace undotbs;

(4)修改pfile，创建spfile，并正常启动

删除：

*._corrupted_rollback_segments='_SYSSMU11$','_SYSSMU12$','_SYSSMU13$'

以上就是UNDO出现故障的2种处理方法。

https://www.cndba.cn/dave/article/525

三. Current online Redo损毁的处理

其实在之前的不同故障处理的那篇blog里已经提到了这点。 但这种情况是一种特殊的情况。 所以还是单独拿出来说明一下。

current online log损坏有两种恢复方法：

(1)如果有归档和备份，可以用不完全恢复。

SQL>startup mount;

SQL>recover database until cancel;先选择auto，尽量恢复可以利用的归档日志，然后重新执行：

SQL>recover database until cancel;这次输入cancel，完成不完全恢复,

用resetlogs打开数据：

SQL>alter database open resetlogs； 打开数据库

(2)强制恢复，这种方法可能会导致数据不一致

sql>startup mount;

sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;

sql>recover database until cancel;

sql>alter database open resetlogs;

这里主要看2点：https://www.cndba.cn/dave/article/525

(1)使用了_allow_resetlogs_corruption参数

(2)这种情况下，可能会报ORA-600[2662](SCN有关)和ORA-600[4000](回滚段有关)的错误。

使用_allow_resetlogs_corruption参数，强制的打开数据库，可能会导致逻辑的坏块，从而影响数据字典。所以，即使使用该参数正常打开后，也需要做的一个操作：逻辑导出数据。重建实例，导入实例。消除逻辑坏块的可能性。

如果使用_allow_resetlogs_corruption参数启动报了undo segment的错误而无法启动，处理方法参考第二节中undo的处理情况。 只要DB能正常open，就导出数据，重建实例，在导入。

------------------------------------------------------------------------------

Blog：http://blog.csdn.net/tianlesoftware

网上资源：http://tianlesoftware.download.csdn.net

相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx

DBA1群：62697716(满); DBA2群：62697977(满)

DBA3群：62697850DBA超级群：63306533;

聊天 群：40132017

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请

版权声明：本文为博主原创文章，未经博主允许不得转载。