问题来源于项目的现网服务器的oracle服务异常宕掉，手动重启后运行一段时间再次宕掉。还好系统未正式投入使用，有充分的时间解决问题。由于是客户的现网服务器出现的问题，不敢轻易操作。经过仔细分析并请oracle的高手来帮助，最终使问题得以顺利解决，未造成不良影响。现记录下来为以后工作中的类似问题提供借鉴。
关键字：oracle 00600: 4193 undo
一、问题发现
环境：RHEL6.0/ORACLE10g
时间：2013.05.20
原因：数据库服务器发生断电。
现象：oracle服务频繁自动宕掉，可手动重启，重启后不足半个小时即宕掉，运行时oracle进程的系统资源占用率持续偏高。
二、问题分析
经过网络搜索，分析此现象可能原因
- Oracle数据文件损坏；
- 系统资源耗尽将oracle进程停掉；
- Oracle版本问题，oracle的bug，需要升级补丁；
- 系统Bug导致；
- 磁盘损坏。
逐一排查：由于系统已经运行了一段时间，之前未发生过此情况，除服务器发生过一次掉电，未做过其他操作；首先考虑4的可能性较小。对于2需要继续了解系统资源耗尽的原因，进一步判断。经过分析，1和3的可能性较大，同时1和3也可能导致2的出现。如果是5问题就相当悲催了。分析原因当然要从日志入手了。
确定oracle版本
安装的版本是10.2，未打过补丁，不能排除此原因。
> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 – Production
通过日志分析
主要通过alert_sid.log分析，查看/app/oracle/admin/test/bdump/alert_uetap.log发现报错信息。
Errors in file /app/oracle/admin/test/bdump/test_smon_12220.trc:
ORA-00600: internal error code, arguments: [4193], [5158], [5162], [], [], [], [], []
问题判定
通过日志‘ORA-00600: internal error code, arguments: [4193] ’分析，4193错误通常是因为恢复时redo与undo不一致所导致，目前解决方法是重建undo表空间，期待问题可以解决。
三、问题解决
查看磁盘空间使用情况
$ df –h
文件系统 容量 已用 可用 已用%% 挂载点
/dev/sda2 145G 120G 18G 88% /
tmpfs 1.8G 100K 1.8G 1% /dev/shm
/dev/sda1 97M 27M 66M 29% /boot
/dev/sda5 1.6T 46G 1.4T 4% /data
df: "/root/.gvfs": 权限不够
查询数据文件的存储位置
$ ls -lh /data/oradata/test/
总用量 45G
-rw-r----- 1 oracle oinstall 5.1G 5月 22 15:04 sysaux01.dbf
-rw-r----- 1 oracle oinstall 11G 5月 22 15:05 system01.dbf
-rw-r----- 1 oracle oinstall 21G 5月 11 06:00 temp01.dbf
-rw-r----- 1 oracle oinstall 4.9G 5月 22 14:59 test.dbf
-rw-r----- 1 oracle oinstall 21G 5月 22 15:04 undotbs01.dbf
-rw-r----- 1 oracle oinstall 5.1G 5月 22 14:59 users01.dbf
查询当前的undo配置参数
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
数据备份
发现问题应第一时间进行数据备份。
注：在操作之前做好备份是很关键的，否则出现问题后果不堪设想。
重做undo表空间过程
1.停止业务程序
2.重建undo表空间
$ su - oracle
$ sqlplus / as sysdba
SQL>create undo tablespace undotbs2 datafile '/data/oradata/test/undotbs2.dbf' size 21504m;
SQL>alter system set undo_tablespace=undotbs2 scope=both;
SQL>shutdown immediate;
SQL>startup;
SQL>show parameter undo ----执行结果如下，成功创建的新的undo表空间。
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS2
3.删除原有的undo表空间
SQL>drop tablespace undotbs1 including contents and datafiles;
4.启动业务程序
5.观察数据库运行是否正常
查询日志，不再出现ORA-00600: internal error code, arguments: [4193]的错误了，运行也正常了，非常感谢王工程师的帮助和支持，使问题得以快速的定位并顺利解决。
Ps：断电的危害很大，如果预知要断电，一定要正确的方式关机来避免悲剧的发生。
附录
1. undo和redo
- 什么是REDO？
REDO记录transaction logs，分为online和archived。以恢复为目的。
比如，机器停电，那么在重起之后需要online redo logs去恢复系统到失败点。
比如，磁盘坏了，需要用archived redo logs和online redo logs区恢复数据。
比如，truncate一个表或其他的操作，想恢复到之前的状态，同样也需要。
- 什么是UNDO？
REDO是为了重新实现你的操作，而UNDO相反，是为了撤销你做的操作，比如你得一个TRANSACTION执行失败了或你自己后悔了，则需要用ROLLBACK命令回退到操作之前。回滚是在逻辑层面实现而不是物理层面，因为在一个多用户系统中，数据结构，blocks等都在时时变化，比如我们INSERT一个数据，表的空间不够，扩展了一个新的EXTENT，我们的数据保存在这新的EXTENT里，其它用户随后也在这EXTENT里插入了数据，而此时我想ROLLBACK，那么显然物理上讲这EXTENT撤销是不可能的，因为这么做会影响其他用户的操作。所以，ROLLBACK是逻辑上回滚，比如对INSERT来说，那么ROLLBACK就是DELETE了。
2.undo配置信息释义
SQL> show parameter undo
NAME TYPE VALUE
----------------------------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
Undo配置参数含义
-UNDO_MANAGEMENT undo的管理模式，分自动和手动
-UNDO_TABLESPACE 当前正在被使用的undo表
-UNDO_RETENTION 规定多长时间内，数据不能被覆盖。
-----------------------------------------
AUTO 表示undo 为自动管理模式。
900 表示在900秒内，undo上的数据不能被覆盖。
UNDOTBS1 是当前正在使用的undo表空间。