查看Oracle是哪个Oracle_home 下启动的
[root@rac1 ~]# ps -ef|grep smon
root 413 24903 0 22:30 pts/0 00:00:00 grep --color=auto smon
root 27165 1 0 22:11 ? 00:00:09 /u01/app/19.0.0/grid/bin/osysmond.bin
grid 27784 1 0 22:12 ? 00:00:00 asm_smon_+ASM1
oracle 29505 1 0 22:12 ? 00:00:00 ora_smon_cdb1
[root@rac1 ~]# gdb -q -x print_environment.gdb a.out 29505
a.out: No such file or directory.
Attaching to process 29505
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/bin/oracle...(no debugging symbols found)...done.
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/lib/libodm19.so...(no debugging symbols found)...done.
Loaded symbols for /u01/app/oracle/product/19.0.0/db_1/lib/libodm19.so
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/lib/libofs.so...(no debugging symbols found)...done.
Loaded symbols for /u01/app/oracle/product/19.0.0/db_1/lib/libofs.so
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/lib/libcell19.so...done.
Loaded symbols for /u01/app/oracle/product/19.0.0/db_1/lib/libcell19.so
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/lib/libskgxp19.so...(no debugging symbols found)...done.
Loaded symbols for /u01/app/oracle/product/19.0.0/db_1/lib/libskgxp19.so
Reading symbols from /u01/app/oracle/product/19.0.0/db_1/lib/libskjcx19.so...(no debugging symbols found)...done.
Loaded symbols for /u01/app/oracle/product/19.0.0/db_1/lib/libskjcx19.so
-- Problem Statement:
On 10.2.0.1 in Production:
When attempting to connect AS SYSDBA to an open Oracle database,
the following message is received:
MESSAGE
-------------------
Connected to an idle instance.
However, the database was indeed up, running, and open.
CAUSE
The session's $ORACLE_HOME was not the same as that the instance was started with.
The Oracle instance was started with a trailing slash in $ORACLE_HOME: /opt/oracle/10gR2/
The session's $ORACLE_HOME was: /opt/oracle/10gR2 (without the trailing slash).
SOLUTION
From Note 373303.1, "How to Check the Environment Variables for an Oracle Process":
1. Determine the pid of the process at OS level, eg for the smon process:
ps -ef | grep smon
2. Get the environment of the process:
SOLARIS:
pargs -e <pid from above> | grep ORACLE
(See Note 373303.1 for syntax on other platforms.)
3. Modify ORACLE_HOME in the session environment to match this string.
Or, restart the instance using the ORACLE_HOME that matches that of the session environment.
There are cases when a database was started from an environment that did not have all the variables set correctly and this can cause troubles afterwards. Typical examples are :
- starting a database from an environment where ORACLE_HOME has a path with a final forward slash ( "/u01/oracle/12.1.0.1/db_1/" rather than "/u01/oracle/12.1.0.1/db_1")
- starting the database from an environment that points with the TNS_ADMIN parameter to the wrong sqlnet configuration files
- starting the database with the incorrect value for LD_LIBRARY_PATH (LIBPATH for AIX or SHLIB_PATH for HP)
- starting the database from an environment that does not have the ORACLE_UQNAME variable set, although this is used to derive the path to a TDE( or SSL ) wallet.
This note presents the methods to be used to find out the values of the environment variables used by the database processes.
SOLUTION
1. Determine the pid of the process at OS level, eg for the smon process:
ps -ef | grep smon
2. Get the environment of the process:
SOLARIS:
pargs -e <pid from above> | grep ORACLE
LINUX:
cat /proc/<pid from above>/environ
AIX:
ps eauwww <pid from above>
HP-UX:
On this Unix flavor there is no command to grasp the process environment directly. This can only be extracted using a debugger from the _environ structure. This procedure can be used on the other Unix flavors, as follows:
gdb smon <pid from above>
This attaches gdb to the pid mentioned above. The smon name is just an indication that the process we attach to is smon, but the only parameter that matters is the pid.
After attaching to the process, the following command extracts the information from the _environ list:
p ((char**)_environ)[0]@30
which would list the first 30 environment variables. If more are defined, just increase the parameter after @.
As well, the list can be extracted one item from the list at a time, using an iterator like:
p ((char**)_environ)[i]
which would extract element #i+1.
Alternatively you can do this :
1) Create the following script called print_environment.gdb:
set $v = (char**)environ
while $v[0]
print $v[0]
set $v = $v+1
end
detach
quit
2) Get the PID of one background server process :
ps -ef | grep smon
3) Call print_environment.gdb to display the variable ( SHLIB_PATH in this case ) :
gdb -q -x print_environment.gdb a.out <pid from above> | grep SHLIB_PATH
Windows:
To get the information on Windows, 2 things are needed:
1. check the registry for the ORACLE_* keys used to start the Oracle process. These keys are in:
HKEY_LOCAL_MACHINE/Software/Oracle/HOME<x>
(before 10g)
HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/KEY_<home name>
from 10g on.
2. check the environment variables that were used by the oracle process at startup.
For this, one would need the process explorer utility from sysinternals, which can be found at:
www.sysinternals.com
(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)
After starting the procexp utility, find the oracle process you want to check in the process list, right click on it, then select Properties. The Environment tab should indicate all the environment variables used when the process was started (even if dynamically in command line).
The utility also displays the key values from registry, but being so many it's difficult to look for them.
The most used application of this document is when dealing with the "Connected to an idle instance" scenario for a bequeath sysdba connection. This error indicates that ORACLE_SID and ORACLE_HOME in the current session do not match the same environment variables that were used when the database is started (ORACLE_SID and ORACLE_HOME are the strings used to uniquely identify the shared memory segment of the instance when a connection is done). Check the ORACLE_SID and ORACLE_HOME of the background process and compare them with the ones in the current session to find the mismatch.