通常我们安装Oracle9i RAC都是使用tar好的软件包，然后手动创建需要的目录结构，再用脚本手动创建数据库。 这样就完全不牵涉到任何GSD的配置，所以这样的RAC数据库安装完毕之后是无法使用srvctl来管理的。 那么如何在这样安装完毕的数据库中手动配置srvctl呢？ 1. 在环境参数中添加Service Config盘的文件路径 export SRVM_SHARED_CONFIG=/var/opt/oracle/srvConfig.loc 2. 编辑srvConfig.loc 在文件中指定Service信息存储盘的位置，这个存储盘必须是共享的，所以可以是一个裸设备，也可以是位于共享文件系统的一个文件（此处使用的是GPFS） srvconfig_loc=/dfgdbs/oraprod/proddata/rac_srvconfig 3. 手动创建rac_srvconfig文件，touch就可以了 touch /dfgdbs/oraprod/proddata/rac_srvconfig 4. 初始化配置文件 srvconfig -init 5.在两个节点启动GSD gsdctl start 6. 添加database资源 srvctl add database ….. 7. 添加instance资源，有多少instance就添加多少个 srvctl add instance ….. 好了，至此为止，就可以使用srvctl start | stop | status 等命令来管理Oracle9i RAC数据库了。
Tag: Oracle Database
5 node RAC 10g completed
昨天又干了一件大工程，搭建5节点的Oracle10g RAC，仍然是AIX 5L操作系统，盘阵是HP比较老些的XP128，不过也属于高端盘阵了，210块盘做ASM中的datagroup（用于存储数据文件），10块盘中ASM的flashgroup（用于flash recovery area），一块盘做OCR Disk，一块盘做Voting Disk。 总体安装过程简直可以用“完美”来形容，一个错误也没有发生，恩，我的意思是说实际上还是碰到了一个问题。:) 这个问题发生在10.2.0.3版本的racgvip脚本中，如果操作系统没有设置默认网关（Gateway），那么在安装完10.2.0.3补丁以后，vip资源将无法正常启动，而在之前的10.2.0.1中一切都是正常的。 老实说，实际上耗费了不少时间去找这个问题的原因，甚至修改了racgvip脚本来echo我自己需要的调试信息，这样才一步步追踪到错误信息输出之前的那步操作，是检查系统的default gateway，并且返回的变量值是null，然后询问系统管理员，得知系统确实没有设置网关。这时候，才发现原来在racgvip脚本的最开始有一个变量可以控制当系统没有默认网关时整个脚本是否还继续进行。 vi /oracle/crs/bin/racgvip 默认有一行 FAIL_WHEN_DEFAULTGW_NO_FOUND=1 需要将1修改为0 FAIL_WHEN_DEFAULTGW_NO_FOUND=0 然后再次启动crs，一切正常了。再之后就一帆风顺，平安到港。 下面最简单的描述一下在AIX 5L安装Oracle10g RAC的步骤。 1. 安装操作系统所需补丁 2. 设置存储，其中创建两个裸设备，一个给ocr disk，一个给vote disk 3. 修改所有节点中的/etc/hosts，/etc/hosts.equiv，~root/.rhosts，~oracle/.rhosts，这是给rsh用的 4. 修改所有节点中的~oracle/.profile，这是设置环境变量 5. 安装CRS 6. 安装Oracle 10.2.0.1 软件 7. 升级CRS和Oracle Software到10.2.0.3 8. 创建ASM实例，创建diskgroup 9. 创建数据库
Oracle 10.2.0.3 Bind Peeked Parallel Bug
昨晚11:30，客户电话，报告数据库服务器CPU负载陡然上升到95%以上，并且报ORA-4031错误。12:00赶到现场。 查看故障发生期间的AWR报告。 1. 最高的等待事件是“latch: library cache lock”和“latch: library cache” 2. Shared Pool Memory Usage 达到了98% (Shared Pool Size: 4,096M) 3. SQL ordered by Elapsed Time部分显示一条SQL占用了91.9%的总时间 4. SQL ordered by CPU Time 部分显示同样这条SQL占用了91.9%的CPU时间 5. SQL ordered by Sharable Memory部分，大批Executions=N/A的SQL，并且最高的一条SQL已经消耗了将近2G的Sharable Memory 6. SQL ordered by Version Count部分，刚才那句占用了将近2G缓存的SQL有高达77,237的Version Count 至此，大概可以猜测整个问题的发生原因了。因为过度的Version Count导致Shared Pool消耗殆尽，在Library Cache中开始频繁获取空闲空间以parse新进的SQL，于是产生大量的library cache latch，最终Shared Pool中再也无法找到足够解析一个SQL的空闲空间，于是报ORA-4031。整个系统全线崩溃。 那么现在问题就在于为什么会有如此巨大的Version Count？…