当undo_management被设置成MENUAL时使用系统回滚段, 即将undo records 记录到SYSTEM 表空间下的SYSTEM段。 SQL> col segment_name format a10SQL> select segment_name,tablespace_name,bytes,next_extent from dba_segments where segment_type='ROLLBACK'; SEGMENT_NA TABLESPACE_NAME BYTES NEXT_EXTENT---------- ------------------------------ ---------- -----------SYSTEM SYSTEM 393216 1048576 通过上面的这条语句,我们查到了这个用于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_extent from dba_segments where segment_type='TYPE2 UNDO'; SEGMENT_NAME TABLESPACE_NAME BYTES NEXT_EXTENT-------------------- -------------------- ---------- -----------_SYSSMU1$ UNDOTBS1 1179648 65536_SYSSMU2$ UNDOTBS1 1179648 65536_SYSSMU3$ UNDOTBS1 2228224 65536_SYSSMU4$ UNDOTBS1 1179648 65536_SYSSMU5$ UNDOTBS1 262144 65536_SYSSMU6$ UNDOTBS1 1179648 65536_SYSSMU7$ UNDOTBS1 1179648 65536_SYSSMU8$ UNDOTBS1 1179648 65536_SYSSMU9$ UNDOTBS1 1179648 65536_SYSSMU10$ UNDOTBS1 1179648 65536 通过以上SQL的查询结果,我们可以看出,有10个undo segment来存放undo records。 以上我们是通过dba_segment 表查看的结果。 也可以通过v$rollstat和v$rollname 两个视图来查看信息。 这2个视图会显示所有rollback 段的信息。 包括system段和undo段。 SQL> col name format a15SQL> select s.usn,n.name,s.extents,s.hwmsize,s.status from v$rollstat s, v$rollname n where s.usn=n.usn; USN NAME EXTENTS HWMSIZE STATUS---------- --------------- ---------- ---------- --------------- 0 SYSTEM 6 385024 ONLINE 1 _SYSSMU1$ 3 7659520 ONLINE 2 _SYSSMU2$ 3 9691136 ONLINE 3 _SYSSMU3$ 4 7462912 ONLINE 4 _SYSSMU4$ 3 76668928 ONLINE 5 _SYSSMU5$ 4 8511488 ONLINE 6 _SYSSMU6$ 3 7462912 ONLINE 7 _SYSSMU7$ 3 33480704 ONLINE 8 _SYSSMU8$ 3 8577024 ONLINE 9 _SYSSMU9$ 3 7462912 ONLINE 10 _SYSSMU10$ 3 13754368 ONLINE 11 rows selected. 二. UNDO 损坏的情况 了解了第一部分的补充知识后,我们在来看一下undo 损坏的情况。 出现这种情况,大多数是因为异常宕机,在启动的时候报的错误。DB 不能启动。 比如:ORA-00600: internal error code, arguments: [4194], 对于Undo 损坏的情况,能用备份恢复最好,如果不能,就只能通过一些特殊的方法来恢复。 2.1 方法一,使用system segment。在Blog: Oracle undo 表空间管理 http://blog.csdn.net/tianlesoftware/archive/2010/07/11/5689558.aspx 提到了一种方法,就是使用SYSTEM 的回滚段, 步骤如下: (1)用spfile 创建pfile,然后修改参数:#*.undo_tablespace='UNDOTBS1'#*.undo_management='AUTO'#*.undo_tablespace#*.undo_retentionundo_management='MANUAL'rollback_segments='SYSTEM' (2)用修改之后的pfile,重启DBSQL> 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 表空间,在切换一下。 (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种处理方法。 三. 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点:(1)使用了_allow_resetlogs_corruption 参数(2)这种情况下,可能会报ORA-600[2662](SCN有关)和 ORA-600[4000](回滚段有关)的错误。 使用_allow_resetlogs_corruption参数,强制的打开数据库,可能会导致逻辑的坏块,从而影响数据字典。 所以,即使使用该参数正常打开后,也需要做的一个操作:逻辑导出数据。 重建实例,导入实例。 消除逻辑坏块的可能性。 如果使用_allow_resetlogs_corruption参数启动报了undo segment的错误而无法启动,处理方法参考第二节中undo 的处理情况。 只要DB 能正常open,就导出数据,重建实例,在导入。
Current online Redo 和 Undo 损坏的处理方法
来源:这里教程网
时间:2026-03-03 21:46:24
作者:
编辑推荐:
- Current online Redo 和 Undo 损坏的处理方法03-03
- oracle中java类的使用03-03
- physical standby(DATAGUARD)环境的ORA-28000 account unlock问题03-03
- 【转】rman-2020703-03
- impdp导入报权限问题03-03
- In-Memory测试03-03
- 实操Oracle 23c中实现数据脱敏03-03
- 实操Oracle 23C中加密和审计03-03
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- oracle中java类的使用
oracle中java类的使用
26-03-03 - oracle加密函数或存储过程代码的两种方式
oracle加密函数或存储过程代码的两种方式
26-03-03 - oracle数据库wrap加密
oracle数据库wrap加密
26-03-03 - Oracle SQL 执行计划分析与优化指南
Oracle SQL 执行计划分析与优化指南
26-03-03 - 古老的Oracle TPCC工具-Hammerora
古老的Oracle TPCC工具-Hammerora
26-03-03 - 记一次防火墙策略设置不当导致连接异常
记一次防火墙策略设置不当导致连接异常
26-03-03 - 19c&21c单机/RAC手工清理标准化文档
19c&21c单机/RAC手工清理标准化文档
26-03-03 - 记一次19C统计信息引发的数据库卡顿问题
记一次19C统计信息引发的数据库卡顿问题
26-03-03 - AWR报告暗藏的致命误区,90%的DBA还在踩坑!
AWR报告暗藏的致命误区,90%的DBA还在踩坑!
26-03-03 - AI的SQL优化能力,取决于你问问题的能力!
AI的SQL优化能力,取决于你问问题的能力!
26-03-03
