在自动UNDO管理模式下，我们有时仍然想手动删除UNDO段。比如某个UNDO段出现了逻辑坏块。
下面首先来看看，直接删除UNDO段能不能成功。
SQL> drop rollback segment "_SYSSMU9$";
drop rollback segment "_SYSSMU9$"
*
ERROR 位于第 1 行:
ORA-30025: 不允许 DROP 段 '_SYSSMU9$' (在撤消表空间中)
看来是行不通的。那么怎么样才能删除呢？试试下面的办法：
SQL> alter session set "_smu_debug_mode"=4;
会话已更改。
SQL> drop rollback segment "_SYSSMU9$";
drop rollback segment "_SYSSMU9$"
*
ERROR 位于第 1 行:
ORA-01545: 指定的回退段'_SYSSMU9$'不可用
还是不行。下面我们看看UNDO段的状态：
SQL> select segment_name,status from dba_rollback_segs;
SEGMENT_NAME STATUS
------------------------------ ----------
SYSTEM ONLINE
_SYSSMU1$ ONLINE
_SYSSMU2$ ONLINE
_SYSSMU3$ ONLINE
_SYSSMU4$ ONLINE
_SYSSMU5$ ONLINE
_SYSSMU6$ ONLINE
_SYSSMU7$ ONLINE
_SYSSMU8$ ONLINE
_SYSSMU9$ ONLINE
_SYSSMU11$ OFFLINE
发现这个要删除的UNDO状态为ONLINE。下面我们将UNDO段置为OFFLINE状态，再删除：
SQL> alter rollback segment "_SYSSMU9$" offline;
回退段已变更。
SQL> drop rollback segment "_SYSSMU9$";
回退段已删除。
可以看到UNDO段已经被删除。这里首先把UNDO段OFFLINE，然后再DROP。值得注意的是，在没有修改"_smu_debug_mode"的情况下，UNDO段是不能OFFLINE的。
总结：
要在UNDO自动管理模式下删除UNDO段，需要三个步骤：
-
执行alter session set "_smu_debug_mode"=4;
-
执行 alter rollback segment "undo-segment-name" offline;
-
执行 drop rollback segment "undo-segment-name" ;
undo
一套运行在Linux下的Oracle 9.2.0.4的库，出现了大量的ORA-600[4042]错误。
ORA-00600: internal error code, arguments: [4042], [31760], [], [], [], [], [], []
关于ORA-600错误，第一个参数，也就是第一个方括号中的标识，通常可以用来定位Oracle错误发生的内部模块。（可以参考Metalink Doc ID 146580.1：What is an ORA-600 Internal Error？）如果是数字，最高位通常是指一个大的模块，而接下来的一位是小的模块。比如这里[4042]，4000，最高位是4，是Transaction Layer（事务层），而次高位是0，Transaction Undo（详见Metalink Doc ID ： 175982.1 ORA-600 Lookup Error Categories）。
针对这个错误，很明显是跟事务有关。在处理的时候，第一反应肯定是检查TRACE文件：
ORA-00600: internal error code, arguments: [4042], [31760], [], [], [], [], [], []
Current SQL statement for this session:
INSERT INTO XXX .....
....
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+269 call ksedst()+0 0 ? 0 ? 0 ? 0 ? BFFF90A4 ?
A16D886 ?
ksfdmp()+14 call ksedmp()+0 3 ? BFFF91B0 ? 98585B4 ?
AD58FA0 ? 3 ? A4B929C ?
kgeriv()+188 call ksfdmp()+0 AD58FA0 ? 3 ?
kgeasi()+108 call kgeriv()+0 AD58FA0 ? AD9AFC0 ? FCA ? 1 ?
BFFF91EC ?
ktugusc()+787 call kgeasi()+0 AD58FA0 ? AD9AFC0 ? FCA ? 2 ?
1 ? 4 ? 7C10 ?
ktuswr()+2049 call ktugusc()+0 BFFF9394 ? D ? 1 ? 0 ? 0 ?
0 ? 0 ? 0 ?
ktusmous_online_und call ktuswr()+0 D ? 0 ? 0 ? 0 ? 0 ? 1 ?
oseg()+898
ktusmaus_add_us()+3 call ktusmous_online_und 1 ? 1 ? BFFF94F8 ? 1 ?
27 oseg()+0
ktubnd()+7646 call ktusmaus_add_us()+0 BFFF9CEC ? 0 ?
ktuchg()+581 call ktubnd()+0 BFFF9678 ? 8468F4F0 ?
BFFF9CEC ? 0 ?
ktbchg2()+318 call ktuchg()+0 2 ? 89E91A08 ? 1 ? B7BC3484 ?
B7BC348C ? AD7BECC ?
BFFF9CEC ? AD7BE38 ? 0 ? 0 ?
kdtchg()+1406 call ktbchg2()+0 0 ? 89E91A08 ? B7BC3484 ?
B7BC348C ? AD7BECC ?
BFFF9CE4 ? AD7BE38 ? 0 ? 0 ?
kdtwrp()+2272 call kdtchg()+0 B7BA8638 ? B7BC3484 ?
B7BC348C ? AD7BECC ?
AD7BE38 ? 1 ? 1C6 ?
kdtInsRow()+1724 call kdtwrp()+0 B7BA8638 ? B7BA0000 ?
60DD40A4 ? B7BC31AC ? C ?
2C88E28 ?
insrow()+275 call kdtInsRow()+0 B7BA8638 ? 89E95354 ?
89E950EC ? B7BA8418 ?
9840000 ? AD589E8 ?
insdrv()+2566 call insrow()+0 B7BA8638 ? BFFF9FEC ? 0 ?
insexe()+1665 call insdrv()+0 B7BA8638 ? 89E950EC ? 0 ?
B7BA8418 ? 0 ? 0 ?
opiexe()+10831 call insexe()+0 89E95354 ? BFFFA220 ?
opipls()+6068 call opiexe()+0 4 ? 3 ? BFFFA98C ?
opiodr()+5238 call kjxsupd()+987 66 ? 6 ? BFFFB64C ?
rpidrus()+140 call opiodr()+0 66 ? 6 ? BFFFB64C ? 5 ?
skgmstack()+211 call rpidrus()+0 BFFFB028 ? 10 ? BFFFB040 ?
BFFFB3E4 ? BFFFB028 ?
899782A ?
rpidru()+93 call skgmstack()+0 BFFFB040 ? AD5A760 ? F618 ?
899782A ? BFFFB028 ?
rpiswu2()+777 call rpidru()+0 BFFFB3E4 ? 40 ? 40 ? 0 ?
40C ? A4B929C ?
rpidrv()+1452 call rpiswu2()+0 837327D8 ? 40 ? BFFFB4E8 ?
2 ? BFFFB508 ? 40 ?
psddr0()+113 call rpidrv()+0 5 ? 66 ? BFFFB64C ? 3A ?
AD5907C ? BFFFB7F8 ?
psdnal()+173 call psddr0()+0 5 ? 66 ? BFFFB64C ? 30 ? 20 ?
B7BBB6B8 ?
pevm_EXECC()+458 call psdnal()+0 BFFFC844 ? BFFFC834 ?
AD53500 ? B7BBB6B8 ?
856EA21C ? 856EA21C ?
pfrrun()+31877 call pevm_EXECC()+0 B7BBF19C ? AD9E4C0 ? 20 ?
peicnt()+291 call pfrrun()+0 B7BBF19C ? 0 ? AD9E31C ?
ADA0464 ? AD5907C ?
BFFFCC10 ?
kkxexe()+451 call peicnt()+0 BFFFC844 ? B7BBF19C ? 2 ?
AD9954C ? 5001AA24 ? 0 ?
opiexe()+12624 call kkxexe()+0 B7BBD068 ? B7BB022C ?
AD53504 ? B7BBD068 ? 0 ? 0 ?
opiall0()+4435 call opiexe()+0 4 ? 3 ? BFFFD064 ?
opial7()+441 call opiall0()+0 3E ? 22 ? BFFFD164 ?
BFFFDC0C ? BFFFD1EC ? 0 ?
opiodr()+5238 call kjxsupd()+987 47 ? F ? BFFFDC0C ?
ttcpip()+2124 call opiodr()+0 47 ? F ? BFFFDC0C ? 1 ?
Cannot find symbol in /lib/tls/libc.so.6.
opitsk()+1635 call ttcpip()+0 AD53500 ? 47 ? BFFFDC0C ? 0 ?
BFFFE4E4 ? BFFFE4E0 ?
opiino()+602 call opitsk()+0 0 ? 0 ? AD53500 ? AD8D7B8 ?
83 ? 0 ?
opiodr()+5238 call kjxsupd()+987 3C ? 4 ? BFFFF8B0 ?
opidrv()+517 call opiodr()+0 3C ? 4 ? BFFFF8B0 ? 0 ?
sou2o()+25 call opidrv()+0 3C ? 4 ? BFFFF8B0 ?
main()+182 call sou2o()+0 BFFFF894 ? 3C ? 4 ?
BFFFF8B0 ? 1 ? 0 ?
00622DE3 call main()+0 2 ? BFFFF954 ? BFFFF960 ?
5FBC66 ? 734FF4 ? 0 ?
从SQL来看，是个简单的INSERT语句，那么就涉及到事务处理了。
从call stack来看，在stack顶端，下面的几行表明错误应该是跟回滚段有关。
# ktugusc()+787 call kgeasi()+0 AD58FA0 ? AD9AFC0 ? FCA ? 2 ?
# 1 ? 4 ? 7C10 ?
# ktuswr()+2049 call ktugusc()+0 BFFF9394 ? D ? 1 ? 0 ? 0 ?
# 0 ? 0 ? 0 ?
# ktusmous_online_und call ktuswr()+0 D ? 0 ? 0 ? 0 ? 0 ? 1 ?
# oseg()+898
# ktusmaus_add_us()+3 call ktusmous_online_und 1 ? 1 ? BFFF94F8 ? 1 ?
# 27 oseg()+0
这一步的分析其实很快，基本上凭call stack中的函数名字来判断。由于当时有其他的事情在处理，同时也不在这套库的现场，就让DBA重新创建了一个UNDO表空间，并将UNDO_TABLESPACE参数设置为新的UNDO表空间名字，错误就不在出现。
其实这个故障的处理，类似于去年处理的一个案例，详见记一次并行恢复问题导致Oracle数据库Crash故障的处理
一个简单的故障处理过程，记录下来，供朋友们参考。
trouble