第一检查grid oracle 环境变量 比如 instance_sid 等
Connected to an idle instance
oracle@node2 bin]$ export oracle_sid=RACDB
[oracle@node2 bin]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 8 03:08:59 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL>
但pl/sql中可以登陆。
select instance_name,host_name,archiver,thread#,status from gv$instance;
1 RACDB1 node2 STARTED 1 OPEN
2 RACDB2 node1 STARTED 2 OPEN
如果输入:会出现这样的报错:
[oracle@node2 bin]$ export oracle_sid=RACDB2
[oracle@node2 bin]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 8 02:45:03 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/ora10g/product/10.2.0/db_1/dbs/initRACDB2.ora'
解决的办法:
[oracle@node2 bin]$ export oracle_sid=RACDB
[oracle@node2 bin]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jul 8 18:58:34 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn system/oracle@RACDB
Connected.
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
RACDB1
其实只要
rac1-> srvctlstatus database -d devdb
能启动,说明数据库没问题.
据说这个是个BUG。
主题: "Connectedto an Idle Instance" Message when Connecting Bequeath to a RunningInstance
文档 ID: 注释:435044.1 类型: PROBLEM
上次修订日期: 23-APR-2008 状态: PUBLISHED
In this Document
Symptoms
Cause
Solution
References
--------------------------------------------------------------------------------
Applies to:
Oracle Server - Enterprise Edition - Version: 8.0.6 to 11.1.0.6
This problem can occur on any platform.
Symptoms
While connecting bequeath to a running instance the following message appears :
$ export ORACLE_SID=test
$ sqlplus "/ as sysdba"
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jun 6 12:17:14 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
The "test" instance was running and this was verified with the pscommand:
$ ps -ef | grep pmon
oracle 9714 1 0 May28 ? 00:00:07 ora_pmon_test
oracle 32635 1 0 May30 ? 00:00:01 ora_pmon_orcl115b
Furthermore the test instance can be started up:
$ export ORACLE_SID=test
$ sqlplus "/ as sysdba"
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jun 6 12:17:14 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.
Total System Global Area 866291712 bytes
Fixed Size 1302036 bytes
Variable Size 239075820 bytes
Database Buffers 620756992 bytes
Redo Buffers 5156864 bytes
SQL>
The alert.log was immediately written with the informations pertaining to thestartup of the operation. When a log switch was performed in the"real" test instance (within a SQL*NET connection) thenthe alert.log was appended with the corresponding informations. So at thatpoint on the system there were two instances "test" running from thesame Oracle Home
$ ps -ef | grep pmon
oracle 9714 1 0 May28 ? 00:00:07 ora_pmon_test
oracle 32635 1 0 May30 ? 00:00:01 ora_pmon_orcl115b
oracle 10382 1 0 12:27 ? 00:00:00 ora_pmon_test
Cause
The issue was caused by a wrong setting of the ORACLE_HOME environment variableused when starting up the instance. This can be easily discovered if one checksthe values of the environment variables set within the background processes ofthe first "test" instance started :
$ ps -ef | grep pmon
oracle 9714 1 0 May28 ? 00:00:07 ora_pmon_test
oracle 32635 1 0 May30 ? 00:00:01 ora_pmon_orcl115b
oracle 10382 1 0 12:27 ? 00:00:00 ora_pmon_test
cat /proc/9714/environ
HOSTNAME=ro-rac4
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
USER=oracle
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36i=40;33:so=00;35:bd=40;33;01:cd=40;33;01:...
ORACLE_SID=test
MAIL=/var/spool/mail/oracle
PATH=INPUTRC=/etc/inputrc
PWD=/home/oracle
LANG=en_US.UTF-8SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=1
HOME=/home/oracleLOGNAME=oracleLESSOPEN=|/usr/bin/lesspipe.sh %s
ORACLE_HOME=/u01/app/oracle/product//10.2.0/db_1
G_BROKEN_FILENAMES=1_=/u01/app/oracle/product/10.2.0/db_1/bin/sqlplus
ORA_NET2_DESC=8,11ORACLE_SPAWNED_PROCESS=1
SKGP_HIDDEN_ARGS=<FATAL/S/x0/x1/x0/x71F6487C/12621/12621/x0>0
$ORACLE_HOME of the old test instance points to"ORACLE_HOME=/u01/app/oracle/product//10.2.0/db_1" . Note the doubleslash ("//".
whereas $ORACLE_HOME of the new test instance points to"ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1"
ORACLE_SID and ORACLE_HOME are used to generate the IDs of the shared memorysegments for the SGA. When using a different ORACLE_HOME value a different IDwill get generated and since this does not match any of the existing segments'IDs it is assumed that this is a new idle instance.
The above example shows how to get the environment variables for a processrunning on Linux. In order to get these variables for other platforms pleaseread Note 373303.1-How to Check the Environment Variables for an Oracle Process
Solution
Shutdown the instance and start it up from an OS session where all theenvironment variables are correctly set. If the instance is to be started viaSRVCTL make sure that all the CRS configuration files are using a correct valuefor the ORACLE_HOME.
-OR-
If the running instance can't be shutdown set the ORACLE_HOME to the valuefound in the envrionment variables set of the running instance.
References
Note 373303.1 - How to Check the Environment Variables for an Oracle Process
Keywords
START~INSTANCE; BACKGROUND~PROCESSES; ORACLE~PROCESS; NOMOUNT; SYSDBA;BEQUEATH; SRVCTL; START~INSTANCE;
--------------------------------------------------------------------------------
Help us improve our service. Please email us your comments for this document. .
此文转自:http://blog.itpub.net/8334342/viewspace-374541/