ora-600 4194错
客户电话说一个测试库报ora-600 4194错误，着急用，所以跑过去看情况。
windows虚拟机环境
测试库
10.2.0.3版本
alert日志发现大量的：
ora-27300
ora-27301
ora-27302
报错，google了解到这是一个bug，可以通过修改操作系统参数或者打补丁方式解决，我的账号过期，也没法去mos查看确定下
日志什么没法带出来，客户性质决定，凭记忆写下处理过程，在断电后有个ora-600 [k~~]的报错，了解到确实是断电导致的，估计断电停开机没人关注到这个测试库吧。
数据库可以启动到mount状态，我recover databse一下，然后alter database open居然可以打开，几秒钟又断了，再连接打开还是报错。
网上有资料说这是实例打开而数据库并没有真正打开，说实话我不是很理解。
在库打开的短暂时候我查询了回滚段的内容，
show parameter undo ——回滚段使用的是undotbs1
select segment_name,tablespace_name,status from dba_rollback_segs；——（11,12,13是offline状态，其余都是在线状态）
注：4194错误产生原因是undo有坏块
决定使用隐含参数跳过有问题的回滚段
1.SQL>startup mount
SQL>create pfile="d:\a.ora" from spfile ——习惯在路径外创建一个自己的pfile
SQL>shutdown immediate
2.修改pfile（d:\a.ora，写字板打开）
undo_management=MANUAL
_corrupted_rollback_segments=(_SYSSMU11$,_SYSSMU12$,_SYSSMU13$），我只是把offline的段给屏蔽了
保存_SYSSMU11$
3.SQL>startup pfile=="d:\a.ora"
数据库成功启动了
开始想是不是删除那几个offline的段就解决了呢，
我就drop了(_SYSSMU11$,_SYSSMU12$,_SYSSMU13$（命令：SQL> DROP ROLLBACK SEGMENT "_SYSSMU11$";），
呵呵~重启库还是不行，一样的报错，再次尝试短暂打开结果_SYSSMU1$——_SYSSMU10$全部都offline了。。有时间需要好好看看
4.我就重新设置pfile中_corrupted_rollback_segments参数中的值为从段1到段10
_corrupted_rollback_segments='_SYSSMU1$','_SYSSMU2$','_SYSSMU3$','_SYSSMU4$','_SYSSMU5$','_SYSSMU6$','_SYSSMU7$','_SYSSMU8$','_SYSSMU9$','_SYSSMU10'
使用修改后的pfile打开库
重建undo
SQL>create undo tablespace undotbs2 datafile 'D:/ORACLE/ORADATA/ORCL/UNDOTBS2.DBF' size 10M;
SQl> alter system set undo_tablespace=undotbs2;
此时有个报错，是说必须在AUTO的模式下才能做此操作，大概这个意思
我把库关了，重新修改我的pfile文件，
undo_management=MANUAL
设置为
undo_management=AUTO
再次使用修改后的pfile文件打开库
此时再执行
SQl> alter system set undo_tablespace=undotbs2;
没有问题
然后 SQL> drop tablespace undotbs1 including contents and datafiles;
ok，好了，现在关库，重新打开看下
此时我重新打开还是用我自己的pfile，没问题
但是当用系统pfile直接SQL>startup时候
实例强制断开
打开alert有个3多少的报错，知道肯定是pfile问题啦
用我的a.ora再次打开库
SQL>create spfile from pfile;
之前系统的spfile已经被我删掉了，好啦，我再次启动应该没问题吧
SQl>startup
结果错误依旧，和之前一样，想了下，看来创建的时候不是依据我启动数据库的pfile内容创建的spfile，我用写字板打开spfile，看到信息依旧是使用undotbs1，不是我新更新后的undotbs1。确认这点，我直接把dbs路径下得pfile删掉，把我的拷贝过去，重新命名。
再次启动，ok，没问题了。