Oracle11gR2的安装界面跟之前版本比较起来有很大的不同，整体界面更加清新，更加简洁了，比较引人注意的是新的fixup脚本，在安装过程中，安装程序将会检查推荐的操作系统内核参数设置以及必须的软件包，对于不符合要求的部分将会自动生成runfixup.sh，安装人员只需要手动以root用户运行该脚本即可，不再需要像以前那样按照安装手册去自行调整了。

在我的安装中，使用的是Oracle Enterprise Linux 5 U3，安装完操作系统之后，没有做任何修改的检查结果如下图。

点击”Fix & Check Again”按钮之后，弹出的窗口显示了runfixup.sh的生成位置。

在以root用户运行runfixup.sh。

[root@dbserver CVU_11.2.0.1.0_oracle]# ./runfixup.sh 
Response file being used is :./fixup.response
Enable file being used is :./fixup.enable
Log file location: ./orarun.log
Setting Kernel Parameters...
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
uid=501(oracle) gid=501(dba) groups=501(dba)

之后点击上面窗口的“OK”按钮，安装程序重新检查后的结果。

这些可以忽略，点击“Ignore All”之后，继续安装，一直到包括创建数据库，都不会出现任何问题。

客户的数据库系统在下午突然报错，作为报表系统的数据是从主生产库通过物化视图刷新的方式定期更新的，但是在错误发生以后，每次物化视图的快速刷新都会产生ORA-600错误。

ORA-12012: error on auto execute of job 467
ORA-20999: HD_GT_DEXM_HYMX refresh failed:-600
ORA-00600: internal error code, arguments: [kghfrf1], [0x000000000], [], [], [], [], [], []
ORA-06512: at "user.REFRESH_ALL_SNAPSHOT", line 31
ORA-06512: at line 1

在Metalink中搜索[kghfrf1]，虽然有相关文章，但是浏览之后发现跟客户的情况都不匹配。首先是症状不相同，并没有任何一个案例是在物化视图刷新的时候报错的；其次是数据库版本不同，客户数据库为Oracle 9208 RAC，在这个版本中并没有任何已知的未修复的bug会导致ORA-600 [kghfrf1]错误；最后通过查看客户trace文件中堆栈信息，也跟Metalink文章中并不匹配。

对于此ORA-600错误的解释是：

@ We are attempting to free a freeable chunk of space and generate this
@ exception trying to free a NULL pointer.
@
@ This is a memory corruption with no data corruption

在系统不繁忙期，让客户尝试执行以下命令用以清理Shared Pool。

ALTER SYSTEM FLUSH SHARED_POOL;

幸运的是，执行完这条命令之后一切错误都消失了。

梳理一下解决的流程。
1. 检查alertlog，以及发生ORA-600错误时候产生的trace文件，在trace文件中查看是否有Current SQL记录（查找Current SQL statement for this session字样），对过比对确认具体是什么操作引起了ORA-600错误。在本例中，显示为物化视图刷新。

begin dbms_mview.refresh('HD_GT_DEXM_HYMX','f');end;

2. 查询Metalink，明确发生该错误的原因以及可能有的解决方法，在解决方法不确定的时候，继续查看是否有类似的bug，每一份bug报告里面通常都有stack信息，跟trace文件中“—– Call Stack Trace —– ”部分做比较，如果堆栈信息完全匹配，那么基本上可以认定是相同的bug，之后再继续查看该bug是否有解决方法或者是相应的Patch。

3. 如果找不到相应的bug或者是解决方法，那么根据ORA-600的错误原因，运用自己的troubleshooting知识来尝试几种方法，比如本例中清理共享池的提议。或者，重启数据库也是值得尝试的。

4. 仍然无法解决，那么首先需要在Metalink中提交一份SR，别管有用没用，别管响应时间有多长，至少做了该做的本份，其次是寻求Oracle官方支持，如果客户足够大牌，那么可能可以要求Oracle单独为此客户发布一个补丁。

4. 如果都不行，此错误也无可避免，而该错误又将严重影响到生产系统，并且错误发生频率还不低，那么这恐怕是该升级数据库版本的时机了，11gR2，不错的选择。

在Oracle11gR2中，推出了强劲的ACFS文件系统。

那么目前ASM支持哪些文件类型，而ACFS又支持哪些文件类型呢？

可以参看官方文档。

简单地说，ASM仍旧着眼于支持所有Oracle Database需要的文件，包括数据文件、控制文件、归档日志文件、spfile、RMAN备份文件、Change Tracking文件、数据泵Dump文件以及OCR文件等。

而ACFS和Oracle ADVM延展了ASM的支持范围，可以存储告警日志、跟踪文件、BFILEs大对象、还有影像、图片以及其它应用的普通文件。