说到问题，真是层出不穷，自己搭建了也不少的rac的环境的，但是在本地试验的时候总是会碰到一些问题，昨晚铲掉旧环境，搭建了两遍rac环境，终于在凌晨搭建好了环境，配置好EM，看了下效果，还不错，然后就把虚拟机设为suspend状态，早上打开虚拟机发现两个节点都自动停掉了，再次重启就启动不了了。 这个时候其实问题才刚刚开始。

#问题1：节点实例无法启动 使用srvctl启动报出了下面的错误。 srvctl start database -d RACDB PRKP-1001 : Error starting instance RACDB1 on node rac1 CRS-0215: Could not start resource 'ora.RACDB.RACDB1.inst'. PRKP-1001 : Error starting instance RACDB2 on node rac2 CRS-0215: Could not start resource 'ora.RACDB.RACDB2.inst'. 自动手工尝试启动，结果就收到了ora-00600的错误。 ORA-00600: internal error code, arguments: [3716], [], [], [], [], [], [], [] 对于这个问题，查看日志也没有得到太多的信息，两个节点都是同样的问题，最后无奈查看metalink求助，刚好有一篇文章796425. 描述的刚好就是这个问题，对于这个问题的原因描述如下：

CAUSE

Just before the error occurs we see there is a Node reboot and a Oracle instance startup without proper shutdown. This might cause a missed write to Controlfile.

The error may be  reported  during alter database open due to mismatch in information in controlfile

明白了问题，解决起来就容易多了。 在节点1上这样操作。

[oracle@rac1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Sat Aug 22 10:26:43 2015

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> alter database open;

alter database open * ERROR at line 1: ORA-00600: internal error code, arguments: [3716], [], [], [], [], [], [], []

做备份文件的备份。

SQL> Alter database backup controlfile to trace ;

Database altered.

SQL> Alter database backup controlfile to '/home/oracle/ctl_bak.ctl';

Database altered.

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, Real Application Clusters, OLAP and Data Mining options [oracle@rac1 ~]$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Sat Aug 22 10:28:03 2015

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: RACDB (DBID=885985165, not open)

RMAN> List backup of controlfile ;

using target database control file instead of recovery catalog

RMAN> Shutdown immediate ;

database dismounted

Oracle instance shut down

RMAN> Startup nomount

Oracle instance started

Total System Global Area     218103808 bytes

Fixed Size                     1218604 bytes

Variable Size                 88082388 bytes Database Buffers             125829120 bytes Redo Buffers                   2973696 bytes

RMAN> Restore controlfile from '/home/oracle/ctl_bak.ctl';

Starting restore at 2015-08-22:10:30:34

using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=147 instance=RACDB1 devtype=DISK

channel ORA_DISK_1: copied control file copy

output filename=+DATA/racdb/controlfile/current.286.888368397 output filename=+DATA/racdb/controlfile/current.285.888368401 Finished restore at 2015-08-22:10:30:42

RMAN> alter database mount;

recover database;database mounted

released channel: ORA_DISK_1

Starting recover at 2015-08-22:10:30:58

Starting implicit crosscheck backup at 2015-08-22:10:30:58 allocated channel: ORA_DISK_1 Finished implicit crosscheck backup at 2015-08-22:10:30:59

Starting implicit crosscheck copy at 2015-08-22:10:30:59

using channel ORA_DISK_1 Finished implicit crosscheck copy at 2015-08-22:10:30:59

searching for all files in the recovery area

cataloging files... no files cataloged RMAN> recover database;

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 2 is already on disk as file +DATA/racdb/onlinelog/group_1.287.888368405

archive log thread 1 sequence 3 is already on disk as file +DATA/racdb/onlinelog/group_2.289.888368411 archive log thread 2 sequence 1 is already on disk as file +DATA/racdb/onlinelog/group_3.293.888368557 archive log filename=+DATA/racdb/onlinelog/group_1.287.888368405 thread=1 sequence=2 archive log filename=+DATA/racdb/onlinelog/group_3.293.888368557 thread=2 sequence=1 archive log filename=+DATA/racdb/onlinelog/group_2.289.888368411 thread=1 sequence=3 media recovery complete, elapsed time: 00:00:06 Finished recover at 2015-08-22:10:31:07

RMAN> alter database open resetlogs;

然后在节点2直接启动即可。

节点2：

SQL> startup nomount

...... SQL> alter database mount;

Database altered.

SQL> alter database open;

Database altered.

对于这个问题的解决就告一段落，然后这次为了保险，把虚拟机关了，然后吃完饭再次打开，发现又有问题，这次的情况是节点2能够启动，但是节点1无论如何都启动不了。

#问题2：1个节点实例无法启动 查看日志提示是MMAN进程停掉了，然后尝试了各种对比的测试方法，节点1就是启动不了。 对于这个问题，竟然在metalink还是找到了帮助信息，

Oracle Crash After Ora-7445 ORA-822 (文档 ID 1422003.1)

文章中的描述更多是说swap设置过小，或者是调整sga_target，一看到这些字眼，我就马上明白了，其实还是内存资源不足导致了节点1无法启动，使用free -m一看还剩30M左右的内容资源，总共就开了800M的内存，crs+asm+em内存基本都被耗完了，这个时候额外多加了点内存资源，问题就迎刃而解了。

当然了，问题到此还没有完，再次搭建rac的时候，crs,asm的配置i还算基本顺利，错误和问题都在控制之中，但是最后一步使用dbca建库的地方竟然还是抛出了错，而且还不能ignore，

#问题3：dbca建库失败

错误信息如下：

DBCA_PROGRESS : 2%

ORA-00119: invalid specification for system parameter REMOTE_LISTENER ORA-00132: syntax error or unresolved network name 'LISTENER_RACDBTEST' ORA-01078: failure in processing system parameters

这个问题还比较诡异，因为使用dbca的部分，参数我也使用默认的，没有做其它修改。

对于这个问题，确认让自己长了见识，因为之前也没碰到过。查看了Metalink

ORA-119, ORA-132 ORA-1078 Received From DBCA (文档 ID 433817.1)

里面的思路是在dbca建库的时候把对应的参数给取消勾选就可以了，在最后的那几个步骤里面。这样修改确实能够解决这个问题，但是我们也不能盲目，因为至少目前为止，创建数据库实例，默认的参数还没有碰到过问题。需要手工屏蔽，其实问题的原因也相对简单。

我们查看crs的时候查看listener的时候有下面这么一段内容。可以看到两个节点上的listener部分由Unknown的字样，这个如果展开来说，其实还是在清理rac环境的时候，没有合理清楚oc的信息导致的。

我们可以创建新的Listener或者把这部分过旧的内容删除。

[oracle@rac1 ~]$ crs_stat -t|grep lsnr

ora....C1.lsnr application    ONLINE    UNKNOWN   rac1        ora....C1.lsnr application    ONLINE    ONLINE    rac1        ora....C2.lsnr application    ONLINE    UNKNOWN   rac2        ora....C2.lsnr application    ONLINE    ONLINE    rac2 

这个问题修复这个，3个rac节点的问题总算得到了初步的解决。

所以以上三个问题，明白了原委，其实解决起来就会容易的多。但是说实在的，这几个问题都算比较特殊，只能说本地测试环境千变万化，还是需要我们好好利用。