ORA-01033
操作系统版本：AIX 61009
数据库版本：11.2.0.3.11(RAC)
二：错误描述
今天业务反应他们应用突然报错，报错为ORA-01033，我查看了数据库的监听和实例状态是正常的，alert日志中也没有任何报错。商用库今天也没人作任何变动！
三：错误原因及解决方法
在MOS上搜到如下两篇 NOTE：(根据下面两篇NOTE知道了问题在哪里)
ORA-01033 is Thrown When Connecting to the Database Via Scan Listener (Doc ID 1446132.1)
Intermittent ORA-12541 when Connecting via SCAN listener in RAC (Doc ID 1547757.1)
在第一篇NOTE中有如下内容：
$lsnrctl services LISTENER_SCAN1
LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 31-MAR-2012 05:50:03
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))
Services Summary...
Service "DBM" has 2 instance(s).
Instance "DBM1", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
REMOTE SERVER
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<name of the other host>)(PORT=1521)))
From the above entry it can be seen that a database running on another host was registered with the SCAN listener.
Due to this the connection was going to this remote database which was in MOUNT stage , hence the error:
ORA-01033: ORACLE initialization or shutdown in progress##意思是说有其他主机上的处于mount状态的数据库被注册到了我们该商用数据库的SCAN listener里。
查看商用数据库的三个SCAN listener 发现果然注册了一个停用的库的RAC数据库(注目前的商用库就是从该套停用的RAC数据库恢复过来的，两套库的service_name，和实例名一致。停用的数据库库监听已经被停掉)的vip。这下问题就清楚了，今天早上准备把停用的库给删掉所以把库给启动到了mount状态(drop database 所以把实例启动到mount状态)，然后应用那边就发现报错了。
问题分析到这会有两个疑问：
第一：这个停用的库的vip怎么会在商用库的SCAN LISTENER中被注册?？
第二：之前停用的库一直处于open状态(但是 本地监听被停掉了)，为什么应用一直没有报ORA-12541错(老库的本地监听停掉了，那么被diverted到老库的连接不都是应该报错)？
第三：为什么在把老库的启动到mount状态，应用就会报ORA-01033
关于第一个疑问，查看一下停用库的remote_listener参数被指定为商用库scan ip的域名(数据库迁移后scan ip所有域名未变)，所以停用库的vip会在商用库的SCAN LISTENER中注册
关于第二个问题，这个我们做个实验就可以看到该现象，把RAC第一个节点的本地监听停掉，然后在tnsnames.ora文件中配置一个使用scan ip域名的连接串，使用该连接串连接数据库，我们发现连接不会报错，每次连接的都是第二个实例。因为我们商用库和老库的service_name是一样的所以即使老库的监听被停掉了，使用scan_ip域名的连接串，连接数据库是不会报错的(就想一个四个节点的RAC 停掉其中两个实例的本地监听，通过scan_ip连接数据库一样是正常的)。如果两个库的service_name不一样的话，可能就会报ORA-12541了
关于第三个问题，ORA-01033 is Thrown When Connecting to the Database Via Scan Listener (Doc ID 1446132.1)里已经解释了，我就不再解释了。