一直以为”alter database recover”和”recover database”这两个命令除了前者是SQL命令后者是SQL*PLUS命令之外，其它都是相同的，实际上却有所出入。

在所有需要的归档日志都存在的相同前提下。alter database recover命令无法继续。

SQL> ALTER DATABASE recover USING backup controlfile until cancel;
ALTER DATABASE recover USING backup controlfile until cancel
*
ERROR at line 1:
ORA-00279: CHANGE 10402260063 generated at 10/31/2009 01:30:52 needed FOR
thread 1
ORA-00289: suggestion : /xf_arch1/log9565_1.arc
ORA-00280: CHANGE 10402260063 FOR thread 1 IS IN sequence #9565

但是recover database命令却可以让DBA继续输入log file的名称。

SQL> recover DATABASE USING backup controlfile until cancel;
ORA-00279: CHANGE 10402260063 generated at 10/31/2009 01:30:52 needed FOR
thread 1
ORA-00289: suggestion : /xf_arch1/log9565_1.arc
ORA-00280: CHANGE 10402260063 FOR thread 1 IS IN sequence #9565
 
 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/xf_arch1/log9565_1.arc
ORA-00279: CHANGE 10402260063 generated at 10/30/2009 23:24:14 needed FOR
thread 2
ORA-00289: suggestion : /xf_arch1/log10763_2.arc
ORA-00280: CHANGE 10402260063 FOR thread 2 IS IN sequence #10763
 
 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/xf_arch1/log10763_2.arc
ORA-00279: CHANGE 10402782605 generated at 10/31/2009 06:21:30 needed FOR
thread 1
ORA-00289: suggestion : /xf_arch1/log9566_1.arc
ORA-00280: CHANGE 10402782605 FOR thread 1 IS IN sequence #9566
ORA-00278: log file '/xf_arch1/log9565_1.arc' no longer needed FOR this
recovery
 
 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.
SQL> 
SQL> ALTER DATABASE open resetlogs;
 
DATABASE altered.

在上例中如果要想alter database recover成功，需要如下的语法：

ALTER DATABASE RECOVER automatic DATABASE 
until CHANGE 10404040058 USING backup controlfile;

或者：

ALTER DATABASE recover logfile '/xf_arch1/log9565_1.arc' USING backup controlfile;

a) use ALTER DATABASE if you want to do the recoverying step by step, manually — issueing each and every single solitary command to recover the database (apply logfiles).
b) use the SQLPLUS ‘recover’ command to have sqlplus automate the steps in a) for you.

更加详细的描述可以参看AskTOM的解释。

在创建ASM Diskgroup的时候出现如下图报错。

检查当前系统裸设备的设置。

partition> p
Current partition table (original):
Total disk cylinders available: 53154 + 2 (reserved cylinders)
 
Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       0                0         (0/0/0)              0
  1       swap    wu       0                0         (0/0/0)              0
  2     backup    wu       0 - 53153        1.99TB    (53154/0/0) 4269595050
  3 unassigned    wm       0                0         (0/0/0)              0
  4 unassigned    wm       0                0         (0/0/0)              0
  5 unassigned    wm       0                0         (0/0/0)              0
  6        usr    wm       0 - 53153        1.99TB    (53154/0/0) 4269595050
  7 unassigned    wm       0                0         (0/0/0)              0

注意到被使用的裸设备d0s6的扇区划分是从0开始的，这在Solaris操作系统中将会导致Oracle无法读取该裸设备，因此引发了上面的错误。

解决方法是分配出一小部分空间给其它分区。比如分配100M给d0s3。

partition> p
Current partition table (unnamed):
Total disk cylinders available: 53154 + 2 (reserved cylinders)
 
Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       0                0         (0/0/0)              0
  1       swap    wu       0                0         (0/0/0)              0
  2     backup    wu       0 - 53153        1.99TB    (53154/0/0) 4269595050
  3 unassigned    wm       0 -     2      117.66MB    (3/0/0)         240975
  4 unassigned    wm       0                0         (0/0/0)              0
  5 unassigned    wm       0                0         (0/0/0)              0
  6        usr    wm       3 - 26112     1000.06GB    (26110/0/0) 2097285750
  7 unassigned    wm       0                0         (0/0/0)

再次重新创建ASM磁盘组，成功。

SQL> DROP
Online pharmacy tramadol Insurance car Online internet casino Lasix Flowers Phentermine buy online Buy fioricet Xanax Brand Viagra cialis levitra Buy viagra online Buy lortab Weight Loss Online casino slot Order meridia online Online stock trading Cancer treatment clinic Buy propecia online Casino game Cheap phentermine Mental health Diflucan Motrin Valtrex Singulair Order xanax Online gambling Forex currency trading Clopidogrel Pharmacies Tramadol 180 Doxycycline Alprazolam Online auto insurance quotes Order soma Health care Tramadol sale Unsecured debt Allstate car insurance Life insurance lead Pharmacy online Debt consolidation company Cheapest airline ticket Food Auto insurance online Erythromycin Buy ritalin Buy phentermine online Debt consolidation Savings account payday loan Cheap tramadol Cheap flights Tramadol no prescription Buy soma Carisoprodol soma Fluoxetine Estate Purchase viagra online Debt settlement Best online casino gambling Tramadol online 
 tablespace EXAMPLE INCLUDING CONTENTS;
DROP tablespace EXAMPLE INCLUDING CONTENTS
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must USE DBMS_AQADM.DROP_QUEUE_TABLE TO DROP queue TABLES

EXAMPLE表空间是Oracle的示例表空间，通常保存着诸如OE, SH, IX, HR等示例用户的表数据，在尝试删除这个表空间的时候遇到上述的错误。

实际上错误是由于IX用户下的高级队列表对象引起的，高级队列表对象无法使用常规的drop命令删除，无论是删除包含AQ的表空间还是用户，都会报ORA-24005错误。

SQL> DROP user IX cascade;
DROP user IX cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must USE DBMS_AQADM.DROP_QUEUE_TABLE TO DROP queue TABLES
 
SQL> SELECT table_name,tablespace_name  FROM dba_tables WHERE owner='IX';
 
TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
SYS_IOT_OVER_53828             EXAMPLE
AQ$_ORDERS_QUEUETABLE_S        EXAMPLE
SYS_IOT_OVER_53842             EXAMPLE
AQ$_STREAMS_QUEUE_TABLE_S      EXAMPLE
ORDERS_QUEUETABLE              EXAMPLE
STREAMS_QUEUE_TABLE            EXAMPLE
AQ$_STREAMS_QUEUE_TABLE_T
AQ$_STREAMS_QUEUE_TABLE_I
AQ$_STREAMS_QUEUE_TABLE_H
AQ$_STREAMS_QUEUE_TABLE_G
AQ$_STREAMS_QUEUE_TABLE_C
AQ$_ORDERS_QUEUETABLE_T
AQ$_ORDERS_QUEUETABLE_I
AQ$_ORDERS_QUEUETABLE_H
AQ$_ORDERS_QUEUETABLE_G

常规的方法是按照提示，使用DBMS_AQADM.DROP_QUEUE_TABLE存储过程来完成。

SQL> conn ix/ix
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE('ORDERS_QUEUETABLE',true);
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE('STREAMS_QUEUE_TABLE',true);

在某些时候运行完上述存储过程，用户下仍然还会存在一些AQ$表，此时仍然无法正常删除用户或者表空间。

SQL> SELECT table_name,tablespace_name  FROM dba_tables WHERE owner='IX';
 
TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
AQ$_STREAMS_QUEUE_TABLE_C

此时需要通过10851 event来进行手工删除，操作顺序如下，更加详细的步骤可以参看Metalink Note 203225.1。

SQL> conn ix/ix
SQL> SELECT object_name, object_type FROM user_objects WHERE object_name LIKE '%STREAMS_QUEUE_TABLE%';
 
OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------
AQ$_STREAMS_QUEUE_TABLE_C                TABLE
AQ$_STREAMS_QUEUE_TABLE_Y                INDEX
 
SQL> ALTER SESSION SET EVENTS '10851 trace name context forever, level 2';
 
Session altered
 
SQL> DROP TABLE AQ$_STREAMS_QUEUE_TABLE_C cascade constraints;
 
TABLE dropped
 
SQL> SELECT object_name, object_type FROM user_objects WHERE object_name LIKE '%STREAMS_QUEUE_TABLE%';
 
OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------
 
SQL> DROP user ix cascade;
 
User dropped
 
SQL> DROP tablespace example;
 
Tablespace dropped

在我的安装中，使用的是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-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，不错的选择。

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

可以参看官方文档。

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

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

参看官方文档。

1.9.2.5 Segment Creation on Demand

The initial segment creation for nonpartitioned tables and indexes can be delayed until data is first inserted into an object.

Several prepackaged applications are delivered with large schemas containing many tables and indexes. Depending on the module usage, only a subset of these objects are really being used. With delayed segment creation, empty database objects do not consume any space, reducing the installation footprint and speeding up the installation.

详细的测试可以参看Christian Antognini的文章。

1. Database安装盘变为了2张，之前的版本一直只有1张，11gR1的安装盘容量为1.8G，而11gR2已经超过2G。解压两个zip文件到同一个database目录下，再运行runInstaller进行数据库安装。

2. Client安装盘比以前容量更大了，但是可以认为基本上变化不大。

3. Grid Infrastructure安装盘应该就是之前的Oracle Clusterware安装盘，但是容量明显增加，从之前的300M到现在900M，我自己还没有下载完毕，所以具体增加了哪些内容还不知道，有已经安装了的给些注解吧。在之前需要用dbca创建的ASM实例功能，已经挪动到Grid Infrastructure安装中，也同时包括了Oracle Clusterware以及ASMFS等群集相关软件的安装。

4. Examples安装盘就是以前的Companion，内容也应该就是之前的Oracle Express的那些内容。

5. Gateways安装盘基本上没有变化。

6. De-install Utility安装盘是全新的内容，从字面上看应该卸载安装的一些工具，莫非将Universal Installer做了专门的产品？具体内容等下载完毕再见分晓。

Update@2009-09-28
对于De-install Utility，在Oracle11gR2的Installation Guide中有如下一段介绍。

Deinstallation Tool
Oracle Universal Installer no longer removes Oracle software. Use the new Deinstallation Tool (deinstall) available on the installation media before installation as well as in the Oracle home directory after installation.

Run this tool from ORACLE_HOME first. It is located in:
$ORACLE_HOME/deinstall.

An error occurs if there are any missing files and the tool prompts you to download the standalone version available in the deinstall directory on the installation media.

实际上在安装完Oracle Software之后，$ORACLE_HOME/deinstall就已经存在了，基本上是一个字符界面的完全删除安装的工具，按照提示运行完deinstall将会删除包括ASM、database instance、software、oraInventory以及oraInst.loc在内的所有内容，基本上是一次非常干净的反安装。

之前也有略略提过11gR2的新功能，那么对于企业级用户比较关心的RAC选件上来说，11gR2又有哪些具体的增强呢？

Oracle在这个新版本中给我们的一个最主要印象是，Oracle Clusterware、ASM、RAC这三者泾渭分明的进化为三个独立的产品，在今后Oracle Clusterware就是一个全功能性的集群软件，将跟IBM的HACMP和HP的Service Guard分庭抗礼，ASM或者说ACFS将是一个全功能性的集群文件系统，跟IBM的GPFS和Veritas的VxFS直接竞争，RAC则是构筑在集群环境中的数据库解决方案。至此，Oracle对于企业级集群环境的一揽子解决方案(Total Solution)基本上已经成型。

1. Grid Plug and Play
即插即玩，冏。。。好吧，让我们跳过语意上的幻想，实际上Oracle一直在致力于提高整个Grid环境搭建配置的简便性，不可否认确实一直在进步，但是可惜的是，至少从文档中还看不出11gR2的Plug and Play比11gR1中就已经提供的Clusterware、ASM、RAC的clone功能有何种进步。
打包已经安装的程序文件，分发到其他节点上，然后运行clone.pl脚本，再运行root.sh完成增加节点的工作，目前看来还是这样的Play体验。

2. Role-separated management
前面说过，Oracle Clusterware已经独立为一个全功能性的集群软件，那么很明显在一个集群环境中将允许运行多个数据库应用，通过角色的控制提高了安全性的需求，每个DBA将只可以管理属于自己的那个数据库。

3. OCR performance enhancements
当集群环境中某些节点出现问题的时候，存取OCR的速度大幅提高，现在OCR可以存储在ASM中了，并且最多允许5份备份（之前是2份）。

4. SRVCTL support for single-instance database
仍然是再次提醒大家Oracle Clusterware将是独立的集群软件了，在11gR2中即使是单实例数据库也可以加入到集群环境中让Oracle Clusterware来监控数据库实例的状态，在必要的时候通过Oracle Restart来重新启动数据库实例。

5. Zero downtime for patching Oracle RAC
无论是给Clusterware还是给RAC打patch都不需要将整个集群环境全部关闭了。

6. ODVM and ACFS
Oracle Dynamic Volume Manager和Oracle Automatic Storage Management Cluster File System是11gR2的重头戏，并不是三言两语可以概述的，总而言之，Oracle现在有自己的集群文件系统了，允许存储除了Oracle Datafile之外的所有其它企业应用程序文件。ACFS同样是跟RAC无关的，无论是选用RAC数据库还是单实例数据库都可以使用ACFS文件系统。

收到的邀请邮件中对于此次访谈有这样的描述。

本次访谈的形式是四至五人参加的圆桌讨论，由甲骨文公司产品战略部总监刘松担任主持人。围绕主持人的提问，大家可以各抒己见，畅谈对企业信 息基础架构的看法，分享成功经验，探讨具体技术实现，展望Oracle数据库解决方案帮助企业实现业务创新和管理创新的前景。

本次访谈摄像、剪辑等工作均由专业视频制作团队完成，录制好的视频时长约一个小时。 完成录制之后，访谈视频将会在搜狐、新浪、凤凰等门户网站，以及 CIO360、51CTO、计世网、IT168等信息化专业论坛的视频访谈版块发布，并由专业的传媒公司负责后期推广。相信会引发网友热议，并对相关解决方案和客户品牌起到很好的宣传推广作用。

访谈的整个过程很轻松，就像是在跟朋友畅谈Oracle数据库从古至今的发展演变以及让大家期待的Oracle11gR2新功能对于企业级IT应用框架将产生的影响与帮助。

录制结束以后，Oracle的赠品 – 一把扇子很有诗情画意。

在扇子背脊上的“Oracle 甲骨文”字样显得颇有中国古风。

录制完毕，又正好赶上老万在Oracle人寿大厦Office举办的DBA Round Table结束，谢谢老万请客，欢迎老万再次回到北京生活，并预祝新工作顺利。

备注：如果看不到上面的图片，那么就是Picasa Web Album还未被解封，请看官在自己机器的hosts文件中添加如下字样。（hosts文件通常位于C:\WINDOWS\system32\drivers\etc目录下）

203.208.39.104 picasaweb.google.com
203.208.39.99 lh1.ggpht.com
203.208.39.99 lh2.ggpht.com
203.208.39.99 lh3.ggpht.com
203.208.39.99 lh4.ggpht.com
203.208.39.99 lh5.ggpht.com
203.208.39.99 lh6.ggpht.com