Install GI and DB PSU 11.2.0.2.5 Failed in VirtualBox

Oracle的Apply Patchset的方法一直是为人诟病的,其实步骤复杂倒也罢了,怕的是Oracle总在不停地修改Apply Patch的方法,Oracle的原意是让Apply Patch的语法越来越简单,但是各种各样的Patch,各种不同的命令,特别是很大的Bundle Patch,如果不仔细阅读Readme,千万不要轻易出手。

这次尝试在自己的VirtualBox虚拟机OEL6中给之前安装的GI(Oracle Restart)+ ASM + Oracle Database安装最新的11.2.0.2.5 PSU,遇到各种问题。

1. Patch解压的目录必须是grid用户和oracle用户拥有写权限的,如果没有写权限,会报错:

Opatch version check failed for oracle home  /u01/app/oracle/product/11.2.0/dbhome_1
Opatch version  check failed
update the opatch version for the failed homes and retry

安装需求是使用root用户来安装(这是我第一次看到在安装PSU的时候要求使用root用户),而我的虚拟机中由于没有足够的磁盘空间,所以将Mac中的下载目录作为Shared Folder映射到虚拟机中,因此改目录的属主是root,用户组是vboxsf,而且并不允许使用chmod直接修改。因此出现了权限问题。我的解决方法是将grid用户和oracle用户都加入vboxsf组中。

建议:在真实环境中,Patch解压目录应该属于dba用户组。

2. 我的Patch是解压在/media/sf_PSU目录下,解压以后生成了p13343447_112020_Linux-x86-64目录,其下有两个目录分别是13343424(这是DB PSU)和13343447(这是GI PSU),整个目录结构如下所示:

 |-media
 |--sf_PSU
 |---p13343447_112020_Linux-x86-64
 |-----13343424
 |-----13343447

按照Readme文档中描述的,opatch的命令应该写为:

opatch auto 

此处的UNZIPPED_PATCH_LOCATION按照文档描述应该就是/media/sf_PSU目录,因为这是解压目录,但是实际上这份文档是有问题的(注:这是我个人造成的问题,我在操作系统中双击解压zip包,自动生成了p13343447_112020_Linux-x86-64目录,而如果命令行下用unzip解压,则不会出现此目录,因此Oracle文档中的描述并没有问题,但是这里主要吐槽下面的报错信息),如果opatch命令写为:

opatch auto /media/sf_PSU -ocmrf /home/grid/ocm.rsp

其中的-ocmrf是另外一个问题,这个OCM的配置文件,根据Readme文档中描述的方法创建即可。

运行以上命令会报错:

Opatch version check failed for oracle home  /u01/app/oracle/product/11.2.0/dbhome_1
Opatch version  check failed
update the opatch version for the failed homes and retry

是的,你没有看错,我也没有贴错,确实报了一模一样的错误(虽然这两个错误都完全不是opatch版本的问题),所以,opatch的报错信息是不可信的,我们必须要去提示的log文件中仔细查看最后的错误信息。

 ZOP-49: Not able to execute the prereq. OPatch cannot inform if the patch satisfies minimum version requirement.
 PatchObject constructor: Input file "/media/sf_PSU/p13343447_112020_Linux-x86-64/etc/config/actions" or "/media/sf_PSU/p13343447_112020_Linux-x86-64/etc/config/inventory" does not exist.

因此,正确的opatch命令应该是:

opatch auto /media/sf_PSU/p13343447_112020_Linux-x86-64 -ocmrf /home/grid/ocm.rsp

3. Oracle软件所在的文件系统剩余空间必须要大于3G,如果不足,会报错:

patch /media/sf_PSU/p13343447_112020_Linux-x86-64/13343447  apply  failed  for home  /u01/app/grid/product/11.2.0/grid
ACFS-9459: ADVM/ACFS is not supported on this OS version: 'error: file /etc/SuSE-release: No such file or directory

可以看到,又是一次很无稽的报错信息,/etc/SuSE-release?拜托,这里只有/etc/redhat-release。

那么,仔细检查log文件,会发现如下的报错:

 Prerequisite check "CheckSystemSpace" failed.
 The details are:
 Required amount of space(3154696080) is not available.
 UtilSession failed: Prerequisite check "CheckSystemSpace" failed.
 Log file location: /u01/app/grid/product/11.2.0/grid/cfgtoollogs/opatch/opatch2012-01-27_18-23-48PM.log

 OPatch failed with error code 73

到此为止,我放弃了在虚拟机中安装PSU 11.2.0.2.5(如果要增加虚拟机中的文件系统剩余空间是非常麻烦的事情),但是我认为解决了磁盘空间问题之后,后面应该不会再有太多问题了。另外,如果在真实环境中这些问题可能都不存在,因为真实环境中文件系统的剩余空间应该远远不止3G,也应该不会有Shared Folder权限的问题,不过目录位置的问题应该还是会遇到,希望这里遇到的问题对将要在产品环境中Apply 11.2.0.2.5 PSU的朋友有帮助。

如果你成功Apply了该版本的Patch,那么也可以留言告诉我你遇到了什么障碍。

Update@2012-02-09
在另外一台测试的Solaris机器中成功apply了最新的11.2.0.3.1 PSU,包括GI和DB的,由于命令跟本文描述的11.2.0.2.5 PSU的更新方法一样,所以记录在此。如果没有本文描述的上述错误,opatch auto还是很简便的。

# export PATH=$PATH:/u02/app/oracle/product/11.2.0/grid/OPatch
# opatch auto /home/oracle/gi_psu_11.2.0.3.1 -ocmrf /home/grid/ocm.rsp
Executing /usr/bin/perl /u02/app/oracle/product/11.2.0/grid/OPatch/crs/patch112.pl -patchdir /home/oracle -patchn gi_psu_11.2.0.3.1 -ocmrf /home/grid/ocm.rsp -paramfile /u02/app/oracle/product/11.2.0/grid/crs/install/crsconfig_params
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2149.
        (Maybe you should just omit the defined()?)
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2149.
        (Maybe you should just omit the defined()?)
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2227.
        (Maybe you should just omit the defined()?)
opatch auto log file location is /u02/app/oracle/product/11.2.0/grid/OPatch/crs/../../cfgtoollogs/opatchauto2012-02-09_01-37-59.log
Detected Oracle Restart install
Using configuration parameter file: /u02/app/oracle/product/11.2.0/grid/crs/install/crsconfig_params
patch /home/oracle/gi_psu_11.2.0.3.1/13348650/custom/server/13348650  apply successful for home  /u01/app/oracle/product/11.2.0/db_1
patch /home/oracle/gi_psu_11.2.0.3.1/13343438  apply successful for home  /u01/app/oracle/product/11.2.0/db_1
Successfully unlock /u02/app/oracle/product/11.2.0/grid
patch /home/oracle/gi_psu_11.2.0.3.1/13348650  apply successful for home  /u02/app/oracle/product/11.2.0/grid
patch /home/oracle/gi_psu_11.2.0.3.1/13343438  apply successful for home  /u02/app/oracle/product/11.2.0/grid
ACFS-9459: ADVM/ACFS is not supported on this OS version: 'Solaris 11 11/11 X86'
CRS-4123: Oracle High Availability Services has been started.

PSU补丁应用完毕以后,数据库会自动启动,接下来需要继续为数据库运行catbundle.sql。

cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SQL> @catbundle.sql psu apply

检查PSU补丁情况。

$ opatch lsinventory | grep "Patch Set Update"
Patch Description:  "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Patch Description:  "Grid Infrastructure Patch Set Update : 11.2.0.3.1 (13348650)"

$ sqlplus / as sysdba
SQL> select action,comments from registry$history;

ACTION                         COMMENTS
------------------------------ ------------------------------
APPLY                          PSU 11.2.0.3.1

How to use Database File System (DBFS) in Oracle 11gR2

简单的来说,DBFS就是Oracle数据库11gR2中提供的能够在Linux操作系统中将Oracle数据库当成文件系统来使用的功能。在DBFS内部,文件是以SecureFiles LOBs(对比与以前的BasicFiles LOBs)的形式存储在数据表中。

本文简单介绍在Oracle11gR2中使用DBFS的方法。
参考文档:Oracle® Database SecureFiles and Large Objects Developer’s Guide 11g Release 2 (11.2) – 6 DBFS File System Client

本文使用的数据库是Oracle 11.2.0.1,操作系统是Oracle Enterprise Linux 5.3:

$ cat /etc/enterprise-release
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
$ uname -r
2.6.18-128.el5

1. 首先需要安装kernel-devel和FUSE包。实际上现在最新的FUSE版本是2.8.5,但是为了防止有兼容性问题,仍然按照文档所述选择了2.7.4版本。kernel-devel包在OEL的安装光盘中就可以找到,如果你的Linux系统中已经安装过,无需再次安装。

# rpm -qa| grep kernel-devel
kernel-devel-2.6.18-128.el5

安装FUSE也同样很简单。
将下载成功的fuse-2.7.4.tar.gz文件解压,生成fuse-2.7.4目录。

# ./configure --prefix=/usr --with-kernel=/usr/src/kernels/`uname -r`-`uname -p`
# make
# make install
# /sbin/depmod
# /sbin/modprobe fuse
# chmod 666 /dev/fuse
# echo "/sbin/modprobe fuse" >> /etc/rc.modules
# chmod +x /etc/rc.modules

2. 在数据库中创建文件系统。创建文件系统的数据库用户至少需要拥有以下权限。

SQL> grant connect, create session, resource, create table, 
create procedure, dbfs_role to kamus;

在$ORACLE_HOME/rdbms/admin目录中执行dbfs_create_filesystem.sql来创建文件系统。其中mytbs为文件系统所在的表空间,dbfs_area为文件系统的名称。

cd $ORACLE_HOME/rdbms/admin
sqlplus kamus
SQL> @dbfs_create_filesystem.sql mytbs dbfs_area

通过观察屏幕显示,可以知道dbfs_create_filesystem.sql实际上是调用了一些package,创建了DBFS文件系统。而这种默认方式对于Securefile LOB的一些特性都是没有启用的,比如压缩,去重,分区,加密等,如果要启用这些特性,可以使用dbfs_create_filesystem_advanced.sql。

--------
CREATE STORE:
begin dbms_dbfs_sfs.createFilesystem(store_name => 'FS_DBFS_AREA', tbl_name =>
'T_DBFS_AREA', tbl_tbs => 'users', lob_tbs => 'users', do_partition => false,
partition_key => 1, do_compress => false, compression => '', do_dedup => false,
do_encrypt => false); end;
--------
REGISTER STORE:
begin dbms_dbfs_content.registerStore(store_name=> 'FS_DBFS_AREA', provider_name
=> 'sample1', provider_package => 'dbms_dbfs_sfs'); end;
--------
MOUNT STORE:
begin dbms_dbfs_content.mountStore(store_name=>'FS_DBFS_AREA',
store_mount=>'dbfs_area'); end;
--------
CHMOD STORE:
declare m integer; begin m := dbms_fuse.fs_chmod('/dbfs_area', 16895); end;

3. 将数据库文件系统mount到操作系统中。

--添加一个新的库目录到库文件加载路径中
# echo "/usr/local/lib" >> /etc/ld.so.conf.d/usr_local_lib.conf
--将必须的库文件link到该目录中
# export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
# cd /usr/local/lib 
# ln -s $ORACLE_HOME/lib/libclntsh.so.11.1 
# ln -s $ORACLE_HOME/lib/libnnz11.so
# ln -s /usr/lib/libfuse.so
--创建运行时动态库链接
# ldconfig

如果不执行以上步骤,则运行dbfs_client将会报错。

dbfs_client: error while loading shared libraries: libclntsh.so.11.1: cannot open shared object file: No such file or directory

实际上到此为止,DBFS已经可以正常运转了,即使我们不将DBFS挂载到操作系统中的某个目录下,也同样可以通过dbfs_client程序来创建目录,copy文件。

比如用dbfs_client来列出初始的DBFS目录结构。

$ dbfs_client dbfs@localhost:1521/orcl --command  ls -a -R dbfs:/dbfs_area
Password:
dbfs:/dbfs_area/.sfs
dbfs:/dbfs_area/.sfs/content
dbfs:/dbfs_area/.sfs/RECYCLE
dbfs:/dbfs_area/.sfs/snapshots
dbfs:/dbfs_area/.sfs/tools
dbfs:/dbfs_area/.sfs/attributes

创建新目录。

$ dbfs_client dbfs@localhost:1521/orcl --command mkdir dbfs:/dbfs_area/dir1

copy文件。

$ dbfs_client dbfs@localhost:1521/orcl --command cp test.txt dbfs:/dbfs_area/dir1/
Password:
test.txt -> dbfs:/dbfs_area/dir1/test.txt

可以通过以下方式从数据字典中查看DBFS的目录结构和属性。

SQL> select * from table(dbms_dbfs_content.listmounts);
SQL> select * from table(dbms_dbfs_content.listallcontent);
SQL> select * from dbfs_content;
SQL> select * from dbfs_content_properties;

不过为了更加方便使用,我们将DBFS挂载到/dbfs目录中。

--创建挂载点目录,修改目录属主
# mkdir /dbfs
# chown oracle:dba /dbfs
--以oracle用户挂载DBFS文件系统
# su - oracle
$ dbfs_client kamus@dbserver:1521/orcl -o rw,user,direct_io /dbfs

以上命令并没有使用在后台mount DBFS,因此在执行完最后命令的时候,要求输入数据库用户kamus的密码,之后并不会回到命令行状态,这是正常的。

$ dbfs_client kamus@dbserver:1521/orcl -o rw,user,direct_io /dbfs
Password:

如果要以后台的方式mount,则需要执行以下命令,其中pwd.f中保存数据库用户的密码:

$ nohup dbfs_client kamus@dbserver:1521/orcl -o rw,user,direct_io /dbfs < pwd.f &

更安全的方法是使用wallet,方法如下。

--创建wallet目录,该目录位置随意
mkdir $ORACLE_HOME/wallet
--创建Oracle wallet,回车以后会要求指定wallet的密码,要求至少为8个字符。
mkstore -wrl $ORACLE_HOME/wallet -create
--更新$ORACLE_HOME/network/admin/sqlnet.ora文件,添加wallet的位置。
vi $ORACLE_HOME/network/admin/sqlnet.ora
--添加如下行
WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/product/11.2.0/dbhome_1/wallet)
     )
   )
SQLNET.WALLET_OVERRIDE = TRUE
--将密码证书添加到wallet中。其中orcl为tnsnames.ora中的条目,kamus为用户名,oracle为密码。
mkstore -wrl $ORACLE_HOME/wallet -createCredential orcl kamus oracle
--添加成功以后,可以通过如下命令查看密码证书
mkstore -wrl $ORACLE_HOME/wallet -listCredential
--挂载DBFS文件系统
dbfs_client -o wallet /@orcl /dbfs

通过wallet方式,如果要挂载不同数据库用户下的DBFS,则需要mkstore -createCredential命令添加多个密码证书,通过不同的tnsnames条目来区分。

--添加scott用户的密码证书
mkstore -wrl $ORACLE_HOME/wallet -createCredential orcl_scott scott tiger
--在tnsnames.ora中添加orcl_scott条目
--挂载DBFS文件系统
dbfs_client -o wallet /@orcl_scott /dbfs

如果要卸载文件系统,则使用:

$ fusermount -u /dbfs

4. 检查文件系统是否已经mount成功。

$ ls -l /dbfs
total 0
drwxrwxrwx 5 root root 0 Apr 12 00:21 dbfs_area

可以看到之前创建的名称为dbfs_area的文件系统已经以目录的形式存在于挂载点/dbfs中了。

5. 创建一个测试目录,直接往目录中copy文件。

$ cd /dbfs/dbfs_area
$ mkdir test
$ echo "A great user experience" > test/dbfs.txt

6. 在数据库中查看该文件是如何存储的。这里我们使用SQL Devloper来更方便地查看LOB数据。

可以注意到:表T_DBFS_AREA是Oracle自动创建的,该表的PATHNAME为文件系统路径,FILEDATA字段为LOB类型,存储真正的文件内容,并且在SQL Developer中也可以看到我们刚才在操作系统中直接echo进dbfs.txt文本文件中的内容了。

再测试一个图片文件。

7. 创建一个新文件系统。

cd $ORACLE_HOME/rdbms/admin
sqlplus kamus/oracle
SQL> @dbfs_create_filesystem.sql mytbs dbfs_pics

8. 新文件系统会立刻以目录的形式出现在操作系统中。

$ ls -l /dbfs
total 0
drwxrwxrwx 4 root root 0 Apr 12 02:20 dbfs_area
drwxrwxrwx 3 root root 0 Apr 12 00:42 dbfs_pics

9. 远程使用sftp从本地机器中上传一个jpg图片,上传到/dbfs/dbfs_pics目录中。

$ ls -l /dbfs/dbfs_pics/
total 33
-rw-r--r-- 1 oracle dba 33565 Apr 12 00:42 zombie2.jpg

10. 在SQL Developer中查看该图片。

11. 查看用户LOB视图,确实是以SecureFile LOBs的形式存储的。

SQL> select table_name,column_name,segment_name,securefile from user_lobs;

TABLE_NAME           COLUMN_NAME          SEGMENT_NAME                   SEC
-------------------- -------------------- ------------------------------ ---
T_DBFS_AREA          FILEDATA             LOB_SFS$_FST_1                 YES
T_DBFS_PICS          FILEDATA             LOB_SFS$_FST_17                YES

至此,完成了最基本的DBFS测试,这是很奇妙的用户体验,不是吗?

【备注1】
在DBFS被使用的时候,也仍然可以正常关闭数据库,这一点与ACFS不同,毕竟这仅仅是通过FUSE框架展现出来的用户接口而已。在关闭数据库以后,再次尝试读取DBFS中的内容,将报IO错误。

$ pwd
/dbfs/dbfs_area/test
$ ls
ls: .: Input/output error

【备注2】
如果在Linux X86-64操作系统中使用dbfs_client,需要额外打上一些Critical Patches,具体参看MOS Note 1150157.1

【备注3】
更多的资料请阅读:

How to resize ACFS and change the mountpoint

关于如何创建ACFS,参看我的上一篇文章:How to create ASM filesystem(ACFS) in Oracle 11gR2

在创建完ACFS之后如果想更改挂载点(mountpoint)以及修改卷的大小,该如何操作呢?

–检查当前ACFS文件系统状态。ACFSDG是ACFS所在的磁盘组,总大小614400M,还有409491M空闲。

$ asmcmd lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512   4096  1048576    614400   409491                0          409491              0             N  ACFSDG/
MOUNTED  EXTERN  N         512   4096  1048576      4886     4490                0            4490              0             Y  CRSDG/
MOUNTED  EXTERN  N         512   4096  1048576    488288    90536                0           90536              0             N  DATADG/
MOUNTED  EXTERN  N         512   4096  1048576    223623   221834                0          221834              0             N  FRADG/

–检查ACFSDG上的卷(Volume)。Volume Device是挂载时要指定的设备名称,Usage和Mountpoint仅仅是描述,并不是表明其真正用途和真正的挂载点。
–可以使用asmcmd volset来修改usagestring和mountpath。

$ asmcmd volinfo -G ACFSDG -a
Diskgroup Name: ACFSDG

         Volume Name: ACFSDGVOL1
         Volume Device: /dev/asm/acfsdgvol1-57
         State: ENABLED
         Size (MB): 204800
         Resize Unit (MB): 256
         Redundancy: UNPROT
         Stripe Columns: 4
         Stripe Width (K): 128
         Usage: To Store RMAN backupsets
         Mountpath: We should mount this volume as /backup

–检查ACFS挂载点,可以看到当前Mount Point并不是/backup而是/acfsmounts/acfsdg_acfsdgvol1,后面我们就要修改这个挂载点。

# acfsutil registry -l /dev/asm/acfsdgvol1-57
Device : /dev/asm/acfsdgvol1-57 : Mount Point : /acfsmounts/acfsdg_acfsdgvol1 : Options : none : Nodes : all : Disk Group : ACFSDG : Volume : ACFSDGVOL1 

–创建新的挂载点

# mkdir /backup

–先尝试用asmcmd volresize命令修改卷大小,报ORA-15476错误,实际上这里的意思是说,在卷处于mount状态时,是无法用volresize命令修改卷大小的,必须用acfsutil size命令。volresize命令只能在文件系统被卸载之后才能使用。

ASMCMD> volresize -G acfsdg -s 614400M ACFSDGVOL1
ORA-15032: not all alterations performed
ORA-15476: ACFS volumes must be resized with the 'acfsutil size' operating system command. (DBD ERROR: OCIStmtExecute)

–卸载当前已经挂载的文件系统

# umount -a -t acfs

–修改ACFS Registry,修改这个信息并不会自动挂载文件系统,而只是为了让下次Oracle Clusterware重启的时候可以自动地将文件系统挂载到正确路径下。

# acfsutil registry -d /dev/asm/acfsdgvol1-57
acfsutil registry: successfully removed ACFS volume /dev/asm/acfsdgvol1-57 from Oracle Registry
# acfsutil registry -a /dev/asm/acfsdgvol1-57 /backup
acfsutil registry: mount point /backup successfully added to Oracle Registry
# acfsutil registry -l /dev/asm/acfsdgvol1-57
Device : /dev/asm/acfsdgvol1-57 : Mount Point : /backup : Options : none : Nodes : all : Disk Group : ACFSDG : Volume : ACFSDGVOL1

–在文件系统被卸载之后,尝试使用volresize命令修改大小。报ORA-15041错误,因为我们尝试指定之前在asmcmd lsdg命令中显示的该磁盘组的Total_MB,但是由于ADVM Volume在创建时会有额外的空间开销,因此报空间不足。当然,如果这里我们将大小降低1G左右,volresize命令是可以运行成功的。本例中在后面选择使用acfsutil size来修改大小。

$ asmcmd volresize -G acfsdg -s 614400M ACFSDGVOL1
ORA-15032: not all alterations performed
ORA-15041: diskgroup "ACFSDG" space exhausted (DBD ERROR: OCIStmtExecute)

–手动挂载文件系统到新目录下。

# mount -v -t acfs /dev/asm/acfsdgvol1-57 /backup
mount.acfs: volume: /dev/asm/acfsdgvol1-57, mount point: /backup
mount.acfs: options: rw
mount.acfs: verbose option specified
mount.acfs: command string: /bin/mount -i -t acfs -o ,rw /dev/asm/acfsdgvol1-57 /backup -v.
/dev/asm/acfsdgvol1-57 on /backup type acfs (rw)

–修改挂载点属主

# chown oracle:oinstall /backup 

–acfsutil size命令可以在文件系统仍然被使用的时候进行扩容,+/-符号表示要在当前基础上增加或者减少多少,这比volresize命令更灵活。

# acfsutil size +400000M /backup
acfsutil size: new file system size: 634312982528 (604928MB)
# acfsutil size +8000M /backup
acfsutil size: new file system size: 642902917120 (613120MB)
# acfsutil size -3000M /backup
acfsutil size: new file system size: 639950127104 (610304MB)

Install 11.2.0.2 RAC on OEL5.5 x86-64 (root.sh issue on second node)

在安装11.2.0.2 RAC的时候,第一步安装Grid,在第二个节点上运行root.sh的时候,报错如下:

Start of resource "ora.ctssd" failed
CRS-2672: Attempting to start 'ora.ctssd' on 'xsh-server2'
CRS-2674: Start of 'ora.ctssd' on 'xsh-server2' failed
CRS-4000: Command Start failed, or completed with errors.
Cluster Time Synchronisation Service  start in exclusive mode failed at /u01/app/11.2.0/grid/crs/install/crsconfig_lib.pm line 6455.
/u01/app/11.2.0/grid/perl/bin/perl -I/u01/app/11.2.0/grid/perl/lib -I/u01/app/11.2.0/grid/crs/install /u01/app/11.2.0/grid/crs/install/rootcrs.pl execution failed

从报错信息上看是ctssd进程启动失败(在这之前会显示cssd进程启动成功,这与MOS上的其它一些第二节点运行root.sh失败的情形是不一样的,那些场景在cssd进程启动的时候就失败了),查看ctssd进程的启动log(位于$GRID_HOME/log/ctssd目录下),发现如下错误信息。

2010-11-12 18:55:46.132: [    GIPC][2424495392] gipcCheckInitialization: possible incompatible non-threaded init from [prom.c : 687], original from [clsss.c : 5325]
[ default][2424495392]Failure 4 in trying to open SV key SYSTEM.version.localhost

[ default][2424495392]procr_open_key error 4 errorbuf : PROCL-4: The local registry key to be operated on does not exist.

2010-11-12 18:55:46.135: [    CTSS][2424495392]clsctss_r_av2: Error [3] retrieving Active Version from OLR. Returns [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392](:ctss_init16:): Error [19] retrieving active version. Returns [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392]ctss_main: CTSS init failed [19]
2010-11-12 18:55:46.138: [    CTSS][2424495392]ctss_main: CTSS daemon aborting [19].
2010-11-12 18:55:46.138: [    CTSS][2424495392]CTSS daemon aborting

从crsctl命令中也可以看出ora.cssd启动成功,但是ora.ctssd是OFFLINE状态。

 $ crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
      1        OFFLINE OFFLINE                                                   
ora.cluster_interconnect.haip
      1        OFFLINE OFFLINE                                                   
ora.crf
      1        OFFLINE OFFLINE                                                   
ora.crsd
      1        OFFLINE OFFLINE                                                   
ora.cssd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.cssdmonitor
      1        ONLINE  ONLINE       xsh-server2                                  
ora.ctssd
      1        ONLINE  OFFLINE                                                   
ora.diskmon
      1        ONLINE  ONLINE       xsh-server2                                  
ora.drivers.acfs
      1        OFFLINE OFFLINE                                                   
ora.evmd
      1        OFFLINE OFFLINE                                                   
ora.gipcd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.gpnpd
      1        ONLINE  ONLINE       xsh-server2                                  
ora.mdnsd
      1        ONLINE  ONLINE       xsh-server2   

此时如果用此命令查看第一个节点的状况会发现所有资源都是正常ONLINE的。继续检查cssd.log(位于$GRID_HOME/log/cssd目录中),显示在发现ASM磁盘的时候报错。

2010-11-12 13:44:30.505: [   SKGFD][1087203648]UFS discovery with :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]OSS discovery with :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Discovery with asmlib :ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so: str :ORCL:VOL*:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL1:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL2:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]Fetching asmlib disk :ORCL:VOL3:

2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted
)
2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted
)
2010-11-12 13:44:30.505: [   SKGFD][1087203648]ERROR: -15(asmlib ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so op asm_open error Operation not permitted

值得注意的是,这样的报错在第一个节点上也同样存在,但是第一个节点上所有的资源包括ASM磁盘组却都是正常运行的。

对于以上cssd.log中的错误,按照MOS Note [1050164.1]处理,修改/etc/sysconfig/oracleasm-_dev_oracleasm文件,指定ASMLib在发现磁盘的时候需要忽略的盘和需要检查的盘。在我们的环境中是使用了Multipath来对多块磁盘做多路径处理,因此需要包括dm开头的磁盘,而忽略sd开头的磁盘。这样的问题也应该只会发生在使用了Multipath的磁盘上。

# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

可以通过以下方法来确认是否遭遇了此问题。

# ls -l /dev/oracleasm/disks
brw-rw---- 1 oracle dba 3, 65 May 14 12:08 CRSVOL
# cat /proc/partitions
  3 65 4974448 sda
253  1 4974448 dm-1

在上面可以看到CRSVOL这个用oracleasm创建的ASM磁盘的major和minor号分别是3,65,而这正是/dev/sda的号,并不是/dev/dm-1的号,所以表示在创建ASM磁盘组的时候并没有使用到Multipath设备。通常情况下,在节点1上是正确的,而在节点2上不正确的,因此出现了问题。

在处理完以上问题以后,必须要对grid环境做deconfig再reconfig,而不能只是在失败节点上重新运行root.sh(我在这里耗费了大量时间),重新配置grid的步骤可以参考MOS Note [942166.1] – How to Proceed from Failed 11gR2 Grid Infrastructure (CRS) Installation。之后root.sh顺利在第二节点上运行成功。

在错误解决以后,回顾之前的安装信息,可以发现虽然第一个节点显示所有资源都正常,但是和正常的root.sh运行信息相比则缺少了几行显示。

正常的信息如下:

# $GRID_HOME/root.sh
Running Oracle 11g root script...

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /u01/app/11.2.0/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
OLR initialization - successful
Adding daemon to inittab
ACFS-9200: Supported
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9307: Installing requested ADVM/ACFS software.
ACFS-9308: Loading installed ADVM/ACFS drivers.
ACFS-9321: Creating udev for ADVM/ACFS.
ACFS-9323: Creating module dependencies - this may take some time.
ACFS-9327: Verifying ADVM/ACFS devices.
ACFS-9309: ADVM/ACFS installation correctness verified.
CRS-2672: Attempting to start 'ora.mdnsd' on 'xsh-server1'
CRS-2676: Start of 'ora.mdnsd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'xsh-server1'
CRS-2676: Start of 'ora.gpnpd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'xsh-server1'
CRS-2672: Attempting to start 'ora.gipcd' on 'xsh-server1'
CRS-2676: Start of 'ora.cssdmonitor' on 'xsh-server1' succeeded
CRS-2676: Start of 'ora.gipcd' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'xsh-server1'
CRS-2672: Attempting to start 'ora.diskmon' on 'xsh-server1'
CRS-2676: Start of 'ora.diskmon' on 'xsh-server1' succeeded
CRS-2676: Start of 'ora.cssd' on 'xsh-server1' succeeded

ASM created and started successfully.

Disk Group CRSDG created successfully.

clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Successful addition of voting disk 67463e71af084f76bf98b3ee55081e40.
Successfully replaced voting disk group with +CRSDG.
CRS-4266: Voting file(s) successfully replaced
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   67463e71af084f76bf98b3ee55081e40 (ORCL:VOL1) [CRSDG]
Located 1 voting disk(s).

CRS-2672: Attempting to start 'ora.asm' on 'xsh-server1'
CRS-2676: Start of 'ora.asm' on 'xsh-server1' succeeded
CRS-2672: Attempting to start 'ora.CRSDG.dg' on 'xsh-server1'
CRS-2676: Start of 'ora.CRSDG.dg' on 'xsh-server1' succeeded
ACFS-9200: Supported
ACFS-9200: Supported
CRS-2672: Attempting to start 'ora.registry.acfs' on 'xsh-server1'
CRS-2676: Start of 'ora.registry.acfs' on 'xsh-server1' succeeded
Preparing packages for installation...
cvuqdisk-1.0.9-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

而之前的信息则缺少了以下4行。

LOCAL ADD MODE 
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
OLR initialization - successful

Oracle显然不会承认这是bug,好吧,解决问题就好。

11.2.0.2 Patch Set? Really a Patch Set?

Oracle最新为Linux x86和x86-64平台发布了Oracle 11.2.0.2 patch set [Patch set ID: 10098816],这个庞大的patch set拥有5G的超大容量。所以几乎全世界的人都在问,这真的是一个补丁集吗?不仅仅是体积庞大,甚至还一改往日补丁集仅仅是作为Bug修复的角色,在11.2.0.2中还包含了很多New Feature

Oracle专门为此补丁写了一篇文章-Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2 [ID 1189783.1],着重提到了几点。

1. Oracle 11.2.0.2 patch set是一个完整的安装包,以后Oracle也会如此发布后续的补丁包。所以在以后如果要安装新数据软件,不再需要安装一个Base版本然后再打补丁集到最新版本,而是直接使用最新补丁集安装包即可。
2. Oracle建议今后的补丁集安装都安装在一个与当前环境目录不同的全新目录下(Out-of-place upgrade),在安装完成以后再通过此份软件启动数据库实例。实际上以后安装补丁集的过程就等同于从一个版本升级到一个新版本的过程。
3. 为什么做这种改变,是因为Oracle认为Out-of-place upgrade是最佳实践,比较安全。当然这实际上符合Oracle的作风,他认为合理且最好的通常都会武断地改变并且说服客户去接受。
4. Oracle仅仅计划在11.2.0.2中提供一些新功能,今后的补丁集仍然会以修复bug为首要任务。

我个人承认确实Out-of-place upgrade是更加安全的,但是至少这种做法目前存在两点缺陷:
1. 补丁尺寸急剧增加,下载2G的补丁和下载5G的补丁还是有很大区别,但是这不是大问题。当然,由于需要安装在新Oracle Home中,在打补丁时需要额外的硬盘空间,但是不到10G的空间需求也不是大问题。
2. 由于在打完补丁以后,Oracle Home路径实际上发生了变化,那么在脚本中,服务定义中牵涉到的原ORACLE_HOME路径必须都要做相应改动。这是个大问题。不过,可以将老目录rename成一个新名字,再将新目录rename成原目录。

今后的补丁集发布计划可以参看Release Schedule of Current Database Releases [ID 742060.1]

How to create ASM filesystem(ACFS) in Oracle 11gR2

本文描述如何创建ACFS文件系统,前提要求:
1. Oracle 11gR2数据库。
2. 如果是11.2.0.1数据库那么操作系统只支持Linux和Windows,如果是11.2.0.2数据库那么增加支持的操作系统有AIX和Solaris。
3. 已经安装Grid Infrastructure,单机即可(但是ACFS在Oracle Restart环境中会有些限制,详见【备注1】)。
4. 已经创建了ASM实例以及ASM磁盘组,实例中ASM实例名为+ASM,磁盘组为ORADG。

[sourcecode language=”sql”]SQL> alter diskgroup oradg add volume acfsvol size 1G;
alter diskgroup oradg add volume acfsvol size 1G
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15221: ASM operation requires compatible.asm of 11.2.0.0.0 or higher[/sourcecode]

如上的错误表示如果要在ASM磁盘组上创建ACFS Volume,必须要求ASM磁盘组的属性COMPATIBLE.ASM在11.2以上。
如果ASM磁盘组是使用asmca图形化工具创建的,那么compatible.asm默认设置就已经为11.2,但如果是使用CREATE DISKGROUP这个SQL命令创建的,那么默认设置则为10.1,需要手动修改。

[sourcecode language=”sql” toolbar=”false”]SQL> alter diskgroup oradg set attribute ‘COMPATIBLE.ASM’=’11.2’;[/sourcecode]

如果要创建ACFS Volume,还必须要求ASM磁盘组的COMPATIBLE.ADVM属性也在11.2以上,此属性默认为空。

[sourcecode language=”sql”]SQL> alter diskgroup oradg set attribute ‘compatible.advm’=’11.2’;
alter diskgroup oradg set attribute ‘compatible.advm’=’11.2’
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15242: could not set attribute compatible.advm
ORA-15238: 11.2 is not a valid value for attribute compatible.advm
ORA-15477: cannot communicate with the volume driver

SQL> host oerr ora 15477
15477, 00000, "cannot communicate with the volume driver"
// *Cause: An attempt was made to communicate with the volume driver.
// *Action: Check that the ASM volume driver is loaded. If so, check the alert
// log to identify the reason for failure and take necessary action
// to prevent such failures in the future.
//[/sourcecode]

如上的错误表示ASM volume driver没有加载。需要使用root用户手工加载。

# /app/grid/bin/acfsload start -s

然后再次修改ASM磁盘组的COMPATIBLE.ADVM属性,并创建ACFS Volume。

[sourcecode language=”sql”]SQL> alter diskgroup oradg set attribute ‘compatible.advm’=’11.2′;

Diskgroup altered.

SQL> alter diskgroup oradg add volume acfsvol size 1G;

Diskgroup altered.

SQL> select VOLUME_DEVICE from V$ASM_VOLUME where VOLUME_NAME=’ACFSVOL’;

VOLUME_DEVICE
——————————————————————————–
/dev/asm/acfsvol-351[/sourcecode]

创建并注册文件系统,然后使用mount.acfs命令挂载文件系统,以下命令需要用root用户执行。

# mkdir -p /app/oracle/acfsmounts/oradg_acfsvol 
# /sbin/mkfs -t acfs -n ACFSVOL1 /dev/asm/acfsvol-351
mkfs.acfs: version                   = 11.2.0.1.0.0
mkfs.acfs: on-disk version           = 39.0
mkfs.acfs: volume                    = /dev/asm/acfsvol-351
mkfs.acfs: volume size               = 1073741824
mkfs.acfs: Format complete.
# /sbin/acfsutil registry -a -f /dev/asm/acfsvol-351 /app/oracle/acfsmounts/oradg_acfsvol
acfsutil registry: mount point /app/oracle/acfsmounts/oradg_acfsvol successfully added to Oracle Registry
# mount.acfs -o all
#df -k | grep acfs
/dev/asm/acfsvol-351   1048576     39192   1009384   4% /app/oracle/acfsmounts/oradg_acfsvol
# chown oracle:dba /app/oracle/acfsmounts/oradg_acfsvol 

创建成功以后,可以用oracle用户在该文件系统下创建测试文件。

$ dd if=/dev/zero of=/app/oracle/acfsmounts/oradg_acfsvol/testfile bs=8192 count=100
100+0 records in
100+0 records out
819200 bytes (819 kB) copied, 0.0270009 seconds, 30.3 MB/s
$ ls -l /app/oracle/acfsmounts/oradg_acfsvol/testfile
-rw-r--r-- 1 oracle dba 819200 Aug 12 19:18 /app/oracle/acfsmounts/oradg_acfsvol/testfile

查看ACFS文件系统信息。

# /sbin/acfsutil info fs 
/app/oracle/acfsmounts/oradg_acfsvol
    ACFS Version: 11.2.0.1.0.0
    flags:        MountPoint,Available
    mount time:   Thu Aug 12 19:06:33 2010
    volumes:      1
    total size:   1073741824
    total free:   968667136
    primary volume: /dev/asm/acfsvol-351
        label:                 ACFSVOL1
        flags:                 Primary,Available,ADVM
        on-disk version:       39.0
        allocation unit:       4096
        major, minor:          252, 179713
        size:                  1073741824
        free:                  968667136
        ADVM diskgroup         ORADG
        ADVM resize increment: 268435456
        ADVM redundancy:       unprotected
        ADVM stripe columns:   4
        ADVM stripe width:     131072
    number of snapshots:  0
    snapshot space usage: 0

在ASM卷被打开的时候,无法直接shutdown ASM实例,会报ORA-15487错误。

[sourcecode language=”sql” toolbar=”false”]SQL> shutdown immediate
ORA-15487: cannot shutdown the ASM instance with an open ASM volume[/sourcecode]

可以使用umount命令卸载ACFS文件系统。

# /bin/umount -t acfs -a

如果挂载文件系统时报错,那么可能是因为ACFS Volume没有激活,Volume的状态可以从V$ASM_VOLUME.STATE字段获得,显示为“ENABLED”才表示已激活。

# mount.acfs /dev/asm/acfsvol-351 /app/oracle/acfsmounts/oradg_acfsvol
mount.acfs: CLSU-00100: Operating System function: open64 (/dev/asm/acfsvol-351) failed with error data: 2
mount.acfs: CLSU-00101: Operating System error message: No such file or directory
mount.acfs: CLSU-00103: error location: OOF_1
mount.acfs: ACFS-02017: Failed to open volume /dev/asm/acfsvol-351. Verify the volume exists.

如果Volume状态显示为DISABLE,可以使用如下命令,激活Volume。
[sourcecode language=”sql” toolbar=”false”]SQL>alter diskgroup ORADG enable volume ‘ACFSVOL’;[/sourcecode]

本文创建使用的是SQL命令行方式创建ACFS卷,用asmcmd也可以完成,可以参看官方文档 | Surachart的文章

而如果选用图像化界面的话,可以用asmca或者OEM来完成,下图是asmca界面,在其中查看命令行写法也很方便。

【备注1】
在当前版本的Oracle Restart环境(也就是Standalone Grid Infrastructure)中,以下操作不会自动运行。
1. 加载Oracle ACFS drivers
2. 加载存在于ACFS mount registry中的Oracle ACFS文件系统

应对于第一个问题,我们可以通过以下方法让操作系统在启动的时候自动加载Oracle ACFS drivers。

创建/etc/init.d/acfsload文件,让其在操作系统启动时自动运行。

# cat /etc/init.d/acfsload
#!/bin/sh
# chkconfig: 2345 30 21
# description: Load Oracle ACFS drivers at system boot
/app/grid/bin/acfsload start -s

# chmod u+x /etc/init.d/acfsload
# chkconfig --add  acfsload
# chkconfig --list  acfsload   
acfsload        0:off   1:off   2:on    3:on    4:on    5:on    6:off

对于第二个问题,由于ACFS文件系统能够正确加载,必须要求ASM实例启动成功,并且相应的ASM磁盘组正确加载,这份依赖性在集群环境中是通过创建Oracle ACFS registry resource (ora.registry.acfs)来实现的,但是在Standalone环境中,我们无法保证这份依赖性,因此只能通过创建以下脚本用root用户手动挂载ACFS文件系统(如果你们有更好的方法请告诉我)。

# cat /usr/local/sbin/mountacfs 
su - grid -c "asmcmd volenable -G oradg -a"
mount.acfs -o all

Installing Oracle11gR2 on Solaris10

实际上Oracle11gR2真的在安装上花了不少心思,虽然目前在除了Linux平台的其它操作系统上都还有这样那样的小问题,但是确实已经很方便了。

如果要在Solaris10中安装Oracle11gR2的单机数据库,只需要以下简单的步骤。

1. 保证/tmp文件系统大于1G
在Soalris10中默认/tmp使用的是swap空间,因此在安装操作系统的时候给swap足够大的空间,比如4G或者8G

2. 添加组和用户(只需要最简单的dba组)

# groupadd dba
# useradd -g dba -d /export/home/oracle -m oracle

3. 修改操作系统内核参数(只需要修改shmmax,这里修改为4G)

# projadd -U oracle -K \
  "project.max-shm-memory=(priv,4096MB,deny)" user.oracle

4. 使用磁盘c1t1d0和c1t2d0创建zfs文件系统(ZFS非常方便,自动mount,不再需要修改vfstab文件)

# zpool create orapool c1t1d0 c1t2d0
# zfs set mountpoint=/oracle orapool

5. runInstaller

6. 安装完毕以后再去设置oracle用户的.profile环境变量

Tips for Installing Oracle11gR2 RAC on AIX 6.1

不准备写一篇完整的Installation Guide,安装光盘中自带的pdf文档已经足够。本文只是总结一些在安装过程中碰到的问题或者说应该要注意的要点。

1. 如下命令的软件包需要配全,通常在安装完操作系统以后就应该已经都有了。

lslpp -l bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat \
 bos.perf.perfstat bos.perf.proctools rsct.basic.rte rsct.compat.clients.rte xlC.aix61.rte

2. 安装文档中提到的fix即使不存在也不影响安装。

# instfix -i -k "IZ41855 IZ51456 IZ52319"
    There was no data for IZ41855 in the fix database.
    All filesets for IZ51456 were found.
    There was no data for IZ52319 in the fix database.

3. 11gR2 RAC自带CTSS时间同步服务,因此安装文档中要求禁用NTP,但是在安装过程中最后检查的时候,仍然会报NTP服务无法使用,可以直接忽略。

4. 11gR2 RAC安装中对于用户和用户组的建议可以说比以前复杂很多,不再仅仅是oinstall和dba这两个用户组。为了方便我们仍然可以只创建oinstall和dba这两个用户组,但是建议按照安装文档中描述的那样创建grid和oracle这两个用户,用grid用户安装Grid Infrastructure,用oracle用户安装RAC。

5. 11gR2中OCR和Voting是可以放置在ASM磁盘组中,因此实际上在整个数据库环境中,应该会存在至少三个ASM Disk Group,也就是crsdg(用于GRID使用)、datadg(数据库数据文件)、fradg(闪回区)。这里需要特别注意,所有磁盘组都是用grid用户执行asmca来创建的(当然你可以用create diskgroup命令创建),而最后数据库实例是以oracle用户启动的,也就是oracle用户也必须有读写磁盘组中disk的权限。

假设我们的环境中有rhdisk2、rhdisk3、rhdisk4三个LUN分别对应crsdg、datadg和fradg,那么建议做如下的权限设置:

chown grid:oinstall /dev/rhdisk2
chown grid:oinstall /dev/rhdisk3
chown grid:oinstall /dev/rhdisk4
chmod 660 /dev/rhdisk3
chmod 660 /dev/rhdisk4

# ls -l /dev/rhdisk*
crw-------    1 grid     oinstall     23,  3 Jun 01 16:23 /dev/rhdisk2
crw-rw----    1 grid     oinstall     23,  4 Jun 01 16:13 /dev/rhdisk3
crw-rw----    1 grid     oinstall     23,  2 Jun 01 16:13 /dev/rhdisk4

6. 新增的SCAN VIP其实可有可无,特别对于不会频繁增删数据库节点的环境,个人觉得几乎无用。而且实际上,SCAN VIP和SCAN VIP LISTENER的切换操作十分缓慢,在我的测试中relocate scan的操作大概需要花费2分钟才能完成,不确认是不是我个人的配置问题。

SCAN VIP也同样是绑定在RAC环境中的某个节点上。如下SCAN VIP则是绑定在dbserver2中的public网卡上,可以看到public网卡上总共有3个IP,一个是实IP,一个是VIP,一个是SCAN VIP。

# crs_stat -t|grep scan
ora....N1.lsnr ora....er.type ONLINE    ONLINE    dbserver2 
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    dbserver2 

# srvctl config scan_listener
SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

# srvctl config scan
SCAN name: crs-scan.cnrmall.com, Network: 1/192.168.255.0/255.255.255.0/en0
SCAN VIP name: scan1, IP: /crs-scan.cnrmall.com/192.168.255.250

# netstat -in
Name  Mtu   Network     Address           ZoneID    Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2      0.21.5e.48.e4.60       -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.225        -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.235        -    96331     0    47140     0     0
en0   1500  192.168.255 192.168.255.250        -    96331     0    47140     0     0
en1   1500  link#3      0.21.5e.48.e4.61       -   342409     0   293503     0     0
en1   1500  172.16      172.16.0.2             -   342409     0   293503     0     0
lo0   16896 link#1                             -   103667     0   103678     0     0
lo0   16896 127         127.0.0.1              -   103667     0   103678     0     0
lo0   16896 ::1                                0   103667     0   103678     0     0

7. SCAN VIP在Oracle安装文档的建议中是需要配置在DNS服务器中,实际上也可以使用/etc/hosts文件,并且除却SCAN VIP之外的public ip、vip、private ip也仍然都是可以跟以前一样,配置在/etc/hosts文件中。

8. 安装11gR2 RAC要求必须配置ssh用户对等性,以前配置rsh的方式现在已经无法通过安装检查。OUI中提供了自动配置ssh用户对等性的按钮,因此无需再事先手动配置。

需要注意的是:该功能完全针对Linux环境进行的开发,因此在AIX环境中,需要事先作如下操作:

ln -s /usr/bin/ksh /bin/bash
mkdir -p /usr/local/bin
ln -s /usr/bin/ssh-keygen /usr/local/bin/ssh-keygen

在配置对等性时,OUI会使用/bin/bash,而AIX默认是没有bash的,因此需要将ksh软链接到bash(当然你也可以安装bash包)。
同样,OUI会使用/usr/local/bin/ssh-keygen产生对等性密钥,而AIX中在安装了OpenSSH以后,ssh-keygen命令默认是存储在/usr/bin中,因此也需要做link。

9. 在成功安装完Grid Infrastructure之后,运行cluvf命令可能会报错。

# cluvfy comp nodeapp -verbose

ERROR: 
CRS is not installed on any of the nodes
Verification cannot proceed

并且,在碰到这样的错误之后,也无法安装RAC,会碰到如下错误:

[INS-35354] The system on which you are attempting to install Oracle RAC is not part of a valid cluster.

也就是无论是cluvf命令还是OUI,都认为这个机器上没有安装CRS,并不是在一个集群环境中。但是实际上运行crsctl check crs命令是完全正常的。

这个错误的解决方法可以参看Metalink Note [ID 798203.1],大体上来说就是在安装Grid Infrastructure的时候,inventory.xml文件中丢掉了CRS=”true”字样,这无疑是安装程序的bug。需要手工detachHome再attachHome。

10. 11gR2 RAC在CRS资源部分做了很多改动,创建完RAC数据库以后的默认资源比以前多了不少。

# crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.CRSDG.dg   ora....up.type ONLINE    ONLINE    dbserver1   
ora.DATADG.dg  ora....up.type ONLINE    ONLINE    dbserver1   
ora.FRADG.dg   ora....up.type ONLINE    ONLINE    dbserver1   
ora....ER.lsnr ora....er.type ONLINE    ONLINE    dbserver1   
ora....N1.lsnr ora....er.type ONLINE    ONLINE    dbserver2   
ora.asm        ora.asm.type   ONLINE    ONLINE    dbserver1   
ora.dbcnr.db   ora....se.type ONLINE    ONLINE    dbserver2   
ora....SM1.asm application    ONLINE    ONLINE    dbserver1   
ora....R1.lsnr application    ONLINE    ONLINE    dbserver1   
ora....er1.gsd application    OFFLINE   OFFLINE               
ora....er1.ons application    ONLINE    ONLINE    dbserver1   
ora....er1.vip ora....t1.type ONLINE    ONLINE    dbserver1   
ora....SM2.asm application    ONLINE    ONLINE    dbserver2   
ora....R2.lsnr application    ONLINE    ONLINE    dbserver2   
ora....er2.gsd application    OFFLINE   OFFLINE               
ora....er2.ons application    ONLINE    ONLINE    dbserver2   
ora....er2.vip ora....t1.type ONLINE    ONLINE    dbserver2   
ora.eons       ora.eons.type  ONLINE    ONLINE    dbserver1   
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE               
ora....network ora....rk.type ONLINE    ONLINE    dbserver1   
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    dbserver2   
ora.ons        ora.ons.type   ONLINE    ONLINE    dbserver1   
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    dbserver2 

启动数据库实例以后,可以看到11gR2的后台进程已经增加到了43个,说实话,我很怀念简单的Oracle8i。

# ps -ef|grep ora_ | grep -v grep
  oracle  364656       1   0 17:01:17      -  0:00 ora_mark_dbcnr1 
  oracle  540722       1   0 17:01:17      -  0:03 ora_mmnl_dbcnr1 
  oracle  561184       1   0 18:07:34      -  0:00 ora_q003_dbcnr1 
  oracle  643244       1   0 17:01:17      -  0:01 ora_mmon_dbcnr1 
  oracle  651360       1   0 17:01:16      -  0:00 ora_asmb_dbcnr1 
  oracle  655494       1   0 17:01:16      -  0:00 ora_rbal_dbcnr1 
  oracle  663680       1   1 17:01:13      -  0:06 ora_lmd0_dbcnr1 
  oracle  667794       1   0 17:01:12      -  0:00 ora_pmon_dbcnr1 
  oracle  671832       1   0 17:01:12      -  0:01 ora_diag_dbcnr1 
  oracle  675932       1   0 17:01:16      -  0:00 ora_smon_dbcnr1 
  oracle  679962       1   0 17:01:12      -  0:00 ora_gen0_dbcnr1 
  oracle  696414       1   0 17:01:16      -  0:00 ora_dbw0_dbcnr1 
  oracle  708790       1   0 17:02:33      -  0:00 ora_qmnc_dbcnr1 
  oracle  716930       1   0 17:01:17      -  0:04 ora_lck0_dbcnr1 
  oracle  721124       1   0 17:01:16      -  0:00 ora_mman_dbcnr1 
  oracle  725186       1   0 17:02:32      -  0:00 ora_gtx0_dbcnr1 
  oracle  729102       1   0 17:01:15      -  0:00 ora_lmhb_dbcnr1 
  oracle  737358       1   0 17:01:16      -  0:00 ora_reco_dbcnr1 
  oracle  745554       1   0 17:02:34      -  0:00 ora_q001_dbcnr1 
  oracle  749762       1   0 17:01:16      -  0:00 ora_lgwr_dbcnr1 
  oracle  753716       1   0 17:01:12      -  0:00 ora_ping_dbcnr1 
  oracle  766014       1   0 17:01:13      -  0:00 ora_psp0_dbcnr1 
  oracle  790688       1   0 17:01:13      -  0:00 ora_acms_dbcnr1 
  oracle  794780       1   0 17:01:12      -  0:02 ora_vktm_dbcnr1 
  oracle  815252       1   0 17:01:12      -  0:00 ora_dbrm_dbcnr1 
  oracle  819350       1   1 17:01:15      -  0:16 ora_lms1_dbcnr1 
  oracle  827642       1   0 17:02:36      -  0:01 ora_cjq0_dbcnr1 
  oracle  848054       1   0 17:02:30      -  0:00 ora_arc0_dbcnr1 
  oracle  856270       1   0 17:01:15      -  0:00 ora_rms0_dbcnr1 
  oracle  868590       1   0 17:25:42      -  0:00 ora_q002_dbcnr1 
  oracle  872622       1   0 17:01:15      -  0:16 ora_lms0_dbcnr1 
  oracle  901314       1   0 17:02:32      -  0:00 ora_arc3_dbcnr1 
  oracle  921600       1   0 18:07:17      -  0:00 ora_pz98_dbcnr1 
  oracle  925926       1   0 17:01:18      -  0:00 ora_rsmn_dbcnr1 
  oracle  929980       1   0 17:07:35      -  0:00 ora_smco_dbcnr1 
  oracle  942286       1   0 18:07:17      -  0:00 ora_pz99_dbcnr1 
  oracle  950274       1   0 17:02:32      -  0:00 ora_rcbg_dbcnr1 
  oracle  958498       1   0 17:02:31      -  0:00 ora_arc2_dbcnr1 
  oracle  974876       1   0 18:07:38      -  0:00 ora_w000_dbcnr1 
  oracle 1011914       1   0 17:01:16      -  0:01 ora_ckpt_dbcnr1 
  oracle 1052884       1   1 17:01:13      -  0:06 ora_lmon_dbcnr1 
  oracle 1069246       1   1 17:01:13      -  0:33 ora_dia0_dbcnr1 
  oracle 1110056       1   0 17:02:31      -  0:00 ora_arc1_dbcnr1 
# ps -ef|grep ora_ | grep -v grep | wc -l
      43
#

Exp Empty Table in Oracle11gR2

先来看一下例子。我们创建一张表T2。

[sourcecode language=”sql” light=”true”]SQL> create table t2 (n number);

Table created.

SQL> desc t2
Name Null? Type
—————————————– ——– —————————-
N NUMBER[/sourcecode]

尝试使用exp将此表导出。

D:\Temp>exp kamus/oracle tables=t2

Export: Release 11.2.0.1.0 - Production on Fri Apr 16 18:11:51 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.


Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, Oracle Label Security, Data Mining and Real Application Testing opt
ions
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set

About to export specified tables via Conventional Path ...
EXP-00011: KAMUS.T2 does not exist
Export terminated successfully with warnings.

报错说这张表并不存在。这是让很多客户费解的地方,在测试库中创建应用的表结构,然后再将表结构exp到产品库中去,这是很多客户常用的方法,但是在11gR2中如果这些表是新创建的没有插入过任何一条记录,那么将会碰到上面这样的错误。

原因在于11gR2中的新功能 – Deferred Segment Creation(延迟段创建),默认情况下这个功能是启用的。

[sourcecode language=”sql” light=”true”]SQL> show parameter DEFERRED_SEGMENT_CREATION

NAME TYPE VALUE
———————————— ——————– ——————–
deferred_segment_creation boolean TRUE[/sourcecode]

延迟段创建的含义是当此新创建一个可能会有Segment的对象时(比如表、索引、物化视图等),如果这个对象中还没有任何记录需要消耗一个Extent,那么将不会在创建对象时自动创建Segment,这样做的好处无疑是在创建对象时大大提高了速度。

对于上例中的T2表,我们在创建结束就立刻检查DBA_SEGMENTS视图,会发现没有任何记录。

[sourcecode language=”sql” light=”true”]SQL> select segment_name from user_segments where segment_name=’T2′;

no rows selected[/sourcecode]

而对于exp程序而言,当仅仅存在Object的定义而没有相应的Segment时,就会报出EXP-00011对象不存在的错误。

解决方法就很简单了,以下方法任选其一。

1. 设置DEFERRED_SEGMENT_CREATION为FALSE,这样创建对象时就会自动创建Segment

2. 在创建对象时,明确指定立刻创建Segment
[sourcecode language=”sql” light=”true”]create table t2 (n number) SEGMENT CREATION IMMEDIATE;[/sourcecode]

3. 使用expdp替代exp(Datapump本身就是Oracle10g以后的推荐工具)

D:\Temp>expdp kamus/oracle tables=t2

Export: Release 11.2.0.1.0 - Production on Fri Apr 16 18:14:41 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, Oracle Label Security, Data Mining and Real Application Testing opt
ions
Starting "KAMUS"."SYS_EXPORT_TABLE_01":  kamus/******** tables=t2
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "KAMUS"."T2"                                    0 KB       0 rows
Master table "KAMUS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for KAMUS.SYS_EXPORT_TABLE_01 is:
  D:\ORACLE\ADMIN\ORCL\DPDUMP\EXPDAT.DMP
Job "KAMUS"."SYS_EXPORT_TABLE_01" successfully completed at 18:15:10

Update@2012-05-29
在最新的11.2.0.3中,该问题已经不再存在,即使没有segment,用exp也仍然可以正常导出。

SQL> host exp kamus/oracle tables=t_test

Export: Release 11.2.0.3.0 - Production on Tue May 29 14:56:21 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses UTF8 character set (possible charset conversion)

About to export specified tables via Conventional Path ...
. . exporting table                         T_TEST          0 rows exported
Export terminated successfully without warnings.

SQL> select segment_name from user_segments where segment_name='T_TEST';

no rows selected