连接一个运行的实例显示:"Connected to an Idle Instance"
2015-09-16 16:51
369 查看
[b]"Connected to an Idle Instance" Message when Connecting Bequeath to a Running Instance (文档 ID 435044.1)
[/b]
In this Document
Oracle Database - Enterprise Edition - Version 8.0.6.0 to 11.2.0.1.0 [Release 8.0.6 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 25-Apr-2012***
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 ps command:
$ 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 to with the informations pertaining to the startup of the operation. When a log switch was performed in the "real" test instance (within a SQL*NET connection) then the alert.log
was appended with the corresponding information. So at that point on the system there were two instances "test" running from the same 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
The issue can be caused by a wrong setting of the ORACLE_HOME environment variable used when starting up the instance. This can easily be discovered if one checks the values of the environment variables set within
the background processes of the 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;36:pi=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 double slash ("//").
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 memory segments for the SGA. When using a different ORACLE_HOME value a different ID will 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 process running on Linux. In order to get these variables for other platforms please read Note
373303.1-How to Check the Environment Variables for an Oracle Process
The same issue can be caused by wrong permissions of the oracle executable. The problem will be discovered only when the bequeath connection will be executed as another OS user than the one used to startup the database.
The correct permissions should be :
-rwsr-s--x 1 oracle oinstall 187777421 Jun 13 19:16 oracle
and they look like the following when encountering the problem:
-rwxr-xr-x 1 oracle oinstall 187777421 Jun 13 19:14 oracle
Shutdown the instance and start it up from an OS session where all the environment variables are correctly set.
Note: If the instance is to be started via SRVCTL make sure that all the CRS configuration files are using a correct value for the ORACLE_HOME (also in $ORACLE_HOME/bin/racgwrap for 10g, 11.1). To set the Oracle
Home in the cluster's registry to the right value run "srvctl modify database -d <database> -o <Oracle Home>".
-OR-
If the running instance can't be shutdown, set the ORACLE_HOME to the value found in the environment variables set o
cee3
f the running instance.
To correct the permissions of the oracle executable the following command has to be executed after stopping all the instances running from that Oracle Home :
cd $ORACLE_HOME/bin
chmod 6751 oracle
[/b]
In this Document
Symptoms |
Cause |
Solution |
References |
APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.0.6.0 to 11.2.0.1.0 [Release 8.0.6 to 11.2]Information in this document applies to any platform.
***Checked for relevance on 25-Apr-2012***
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 ps command:
$ 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 to with the informations pertaining to the startup of the operation. When a log switch was performed in the "real" test instance (within a SQL*NET connection) then the alert.log
was appended with the corresponding information. So at that point on the system there were two instances "test" running from the same 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 can be caused by a wrong setting of the ORACLE_HOME environment variable used when starting up the instance. This can easily be discovered if one checks the values of the environment variables set withinthe background processes of the 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;36:pi=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 double slash ("//").
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 memory segments for the SGA. When using a different ORACLE_HOME value a different ID will 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 process running on Linux. In order to get these variables for other platforms please read Note
373303.1-How to Check the Environment Variables for an Oracle Process
The same issue can be caused by wrong permissions of the oracle executable. The problem will be discovered only when the bequeath connection will be executed as another OS user than the one used to startup the database.
The correct permissions should be :
-rwsr-s--x 1 oracle oinstall 187777421 Jun 13 19:16 oracle
and they look like the following when encountering the problem:
-rwxr-xr-x 1 oracle oinstall 187777421 Jun 13 19:14 oracle
SOLUTION
Shutdown the instance and start it up from an OS session where all the environment variables are correctly set.Note: If the instance is to be started via SRVCTL make sure that all the CRS configuration files are using a correct value for the ORACLE_HOME (also in $ORACLE_HOME/bin/racgwrap for 10g, 11.1). To set the Oracle
Home in the cluster's registry to the right value run "srvctl modify database -d <database> -o <Oracle Home>".
-OR-
If the running instance can't be shutdown, set the ORACLE_HOME to the value found in the environment variables set o
cee3
f the running instance.
To correct the permissions of the oracle executable the following command has to be executed after stopping all the instances running from that Oracle Home :
cd $ORACLE_HOME/bin
chmod 6751 oracle
相关文章推荐
- POJ 1509 Glass Beads
- eclipse配置ant插件
- 《炉石传说》架构设计赏析(4):Asset管理
- 九大内置对象 四个作用域的区别
- Python 进行RSA私钥加密,公钥解密
- 学习笔记--多道程序的CPU调度算法
- Linux 下重新挂载分区方法
- 修改软键盘的回车键为发送键
- Nginx配置文件nginx.conf中文详解
- rabbitmq安装和运行rabbitmq-tutorials里的erlang例子
- leetcode Min Stack
- android:descendantFocusability用法简析
- __future__的使用
- .NET DES 加密
- 记录一次MySQL复制问题的处理
- Hibernate – One-to-Many example (XML Mapping)
- 判断子网掩码的合法性
- zookeeper原理
- 通知中心
- linux c 及 c++打印调用者函数caller function的方法,包括arm c平台