前些时间做的项目，一直没有时间整理。现在好些，就整理一下过程文档。
这个项目基本情况如下：
原有2台IBM M85小机，Fastt500 盘柜，Oracle RAC数据库服务。
新增加一台IBM P5 550小机放在2KM外的电信机房，增加2台HDS的盘柜，分别放在公司机房和电信机房，实现HDS的trueCopy.新项目改造后要求，3台小机实现Oracle的RAC数据库服务。
开始我一直担心异地的HACMP对Oracle的RAC是否存在问题，由于没有先例和把握，只好做一步是一步了。后来证明这个担心是多余的。
要求计划整个项目计划2个星期内完成。
说明：
公司机房－－本地机房
电信机房－－远程机房
本地机房小机2台M85：A机，B机 2cpu 4G 16G×2
远程机房小机P5 550：C机 4CPU 8G 146G×2
实施过程基本分为以下部分:
我没有记录详细的安装步骤如AIX，HACMP，Oracle RAC安装流程等，但是碰到的问题都有记录，并有解决过程。
1. 项目准备
项目准备的主要工作是基本物料的准备和实施方案的确定。
基本物料准备包括：机房条件检查，线缆统计和购买，相关介质准备。
在机房检查过程中，发现远程机房UPS零地电压竟然70多，提出整改；由于本地机房和远程机房距离较远，中间是通过单模的光纤来连接的，因此需要配置单模的光纤跳线。
实施方案确定：
1.1 由于业务系统白天不能停，3台小机安装系统，配置HA，配置磁盘柜，安装OracleRAC这么多内容不可能在一个晚上完成。因此，必须考虑一套临时的过渡数据库。经过讨论，决定将临时库安装在新配置的C机上。即需要在c机上安装2套Oracle数据库，一套临时的单实例版本，另外一套RAC版本。（主要是c机的配置较高）
1.2 由于本地机房和远程机房距离约2KM，无法实现串口的心跳线，因此只能通过IP网络或者磁盘心跳。出于这个考虑，决定使用AIX 5204和HACMP 5.1版本，HACMP通过共享磁盘来实现心跳。规划IP地址等。
1.3 由于原有的Oracle数据下有20多个用户，总约15G数据量，约300个连接数。而且数据分布也不合理，在system表空间中有用户数据，因此只能通过全库级别的exp/imp来实现数据迁移（懒人的方法）。Oracle 版本定于Oracle 9201（这是一个严重的失误，导致后来项目延期，问题多多）。（没有做物理备份）
1.4 磁盘规划：盘柜中有2个LUN给Oracle RAC使用，大小都为100G，即总200G，全部配置为RAW设备，AIX中分别属于oravg1,oravg2.
1.5 表空间设计：我看了一下原来的oracle，20多个用户中，数据主要集中在2个用户user1和user2。我就吧user1的表空间放在oravg1,user2 的表空间放在oravg2。（后来证明这里犯了一个错误，导致IO出现瓶颈），同时对重要的表空间做LV的Mirror处理。
2. 临时数据库系统准备和数据备份
根据方案c机安装完成AIX和HACMP后，建立一个ora用户以及划分50G空间给Ora用户，安装Oracle，建库，从A机exp全库，然后c机全库导入。比较顺利，一个晚上完成了，检查数据完整性后，第二天将业务就切换到了临时库上。
3. 3台小机的AIX安装和HACMP配置
A机、B机的AIX安装和HACMP安装配置基本没有什么大的问题，HDS的盘柜也非常顺利。
AIX补丁：AIX 5204
HACMP：最新
HACMP5.1的配置还是安替换IP的方法配置，即IP替换而不是别名，由于做ORACLE 的RAC，相对来说HACMP比较简单，因为不需要配置应用切换，只需要配置资源组共享就可以了。我建立了2个VGravg1,oravg2都是concurrent模式。只有一个资源组，包括了service ip，oravg1,oravg2.
HACMP的心跳需要注意就是必须是ConCurrentVg的VG，此VG可以存放数据，也就是说可以和Oracle RAC存放的VG公用,我配置了oravg1。
HACMP同步，测试启动HA，检查资源是否正常：
lsvg -o （三机相同）
rootvg
oravg1
oravg2
netstat -in (service ip是否在线，每台机器都需要检查)
正常后继续。
这部分做了1天。
HDS的TRUECOPY有HDS的工程师完成。
4. Oracle RAC 安装和建库
终于要开始安装Oracle RAC了，再次检查HACMP后开始安装Oracle。安装Oracle非常顺利，但是在建库的时候碰到了一些问题。
建库LV准备：
由于用户较多，因此需要的表空间也多，相对需要的LV也较多。LV建完成后将所有的Lv改Owner为Oracle
#chown -R oracle:dba /dev/r_*
#chown -R oracle:dba /dev/rr_*
问题1:
创建LV失败，告诉我说LV的名字超长。(小于12字符？忘记了)只好重新修改LV的脚本，重新建立LV。
问题2：
建库的时候，跳出个窗口告诉我PRKR－1064错误，说是共享的srvconfig设备无法访问。我试着在Oracle用户下执行srvconfig -init,报错，什么JAVA无法访问Rawdevices 如下：
$srvconfig -init -f
oracle.ops.mgmt.rawdevice.RawDeviceException: PRKR-1064 : General Exception in OCR
at oracle.ops.mgmt.rawdevice.RawDeviceUtil.
at oracle.ops.mgmt.rawdevice.RawDeviceUtil.
接着，我用dd命令测试：dd if=/dev/r_srvmconf of=/dev/null bs=8192
分别在三台机器上执行，其中有一台报错，我一看属性，原来/var/opt/oracle/srvConfig.loc
文件的属性错误，用chmod 777 srvConfig.loc后问题解决。
小结：
4.1 最好通过脚本文件来做LV，这样万一出现问题，重做比较方便快捷。同时也减少出错的机会。
4.2 另外，需要注意就是LV的名称长度有限制，最好推荐使用Oracle例子的命名方式：如r_user01_1G,方便理解。
4.3 一定要多做几个备用的LV，以备不时之需和以后扩表空间用。
4.4 redo log文件一定要在建库的时候把相关的参数定好，如文件大小，每组有几个文件，一共多少组，否则会很麻烦。
4.5 注意每一个步骤，必须得每台机器上都做。
这样，折腾了我2个晚上。
5. Oracle 数据库迁移
第二次数据迁移很痛苦。一直EXP失败，后来发现buffer开得太（我开了1000000000）。
IMP后导入成功，但是发现其它问题。
这个折腾了我3个晚上。
6. 出现问题，问题解决
6.1 发现其中的A服务器CPU经常在100%，严重影响系统运行。检查了N多，都没有发现异常，最后A机重启后居然好了。没有办法解释。
6.2 发现其中所有大表（500万）条记录只有只能在一个Node操作。现象如下：
如果A机操作过A表，那么在B机或C机上查询一条A表得记录，得10多个小时（我狂倒），也就是更本无法查询A表。
经过多方查证，基本确定是Oracle的一个BUG，于是下载9204,安装Patch。可是在安装Patch 9204到最后一步执行脚本root.sh得时候，其中A机
执行了1个多小时还有完成，只好人工取消。（结果这里又留下隐患）。Patch完成，发现问题解决。
6.3 升级到9204后，系统运行正常，回家。第三天客户报告说这2天得EXP导出都没有成功。网上一查，发现说使一个SQL得包没有正常运行。而且，运行那个包必须在特种模式下(migrate),也就是说必须得停库，只有晚上做。
第二天晚上，我安说明，shutdown 库，startup migrate结果报错，说是RAC系统无法启动到Migrate下。没有办法，只好修改参数，cluster_database＝false和PARALLEL_SERVER=false,然后：
1. shutdown immedaite
2. startup migrate
3 @rdbms/admin/catpatch
4. shutdown immedaite
5. startup
启动成功后将cluster_database＝true和PARALLEL_SERVER=true
6.4 发现磁盘IO非常不均，oravg1在Hdisk1经常100％，而oravg2在得hdisk2空得很，检查后发现user1的业务量远大于user2,虽然数据量差不多。所以说开始的时候设计出现问题了。还好，我在oravg2上有部分备用的LV，把它加了4G到user1的表空间，并把user1的数据重新导出，导入后发现好多了。
到这里，项目基本稳定了，但是其实事情还有很多，如数据备份、带库、FAST T500等。
项目后感：
第一条：做事一定要仔细，最好每一部都有记录，下破坏性的命令前一定要考虑后果；我用的是SecureCRT，我一般都会做Log记录，方便查询。
第二条：碰到问题不要荒，其实现在这个信息这么发达的时代，我们碰到的大部分的问题都有解决方法，只是看怎么找到它。
第三条：2个人出差比一个人好，尤其是后半夜，至少可以有个商量的人，有时候其实问题很简单，但是一个人容易走进死胡同（因为后半夜基本没有办法打电话）。当然老板不会那么好，每次都派2个人去。呵呵。
第四条：碰到奇怪问题，如果真的穷途末路（黔驴技穷）了，那么restart机器或者数据库等，也许有意外的收获，因为实事证明有一些问题是 没有道理的也无法解释的，但是重启可以解决的。
