Investigated behavior “database” resource with (PMON,MRP) processes.
When you try to view environment via “config”, you can see that parameters which used when you create “database” resource. As with “listener” resource some environments can set only via “setenv”, i.e. TNS_ADMIN, NLS_LANG. Some interesting thing, if you try to set ORACLE_HOME via “setenv” and you already have that parameter in “config”, then you would have two ORACLE_HOME in the environment.
strings /proc/25811/environ ORACLE_HOME=/opt/oracle/product/rdbms1123 ORACLE_SID=some_sid ORACLE_HOME=/opt/oracle/product/grid1123
And resource changed like that
crsctl status resource ora.somedb.db -f -t -init ORACLE_HOME=/opt/oracle/product/grid1123 ORACLE_HOME_OLD=/opt/oracle/product/rdbms1123 USR_ORA_ENV=ORACLE_HOME=/opt/oracle/product/grid1123
If you do not set environment TNS_ADMIN via “setenv” then processes will have that environment is empty. Be careful with that parameter, it should have correct path to “tnsnames.ora”. Some time ago, while i’m perform to switchover, “MRP” process can’t resolve “fal_server” and switchover was fail. That was happen because “database” resource haven’t had correct TNS_ADMIN.
One more feature, in environment of processes have that file, keep this in mind.
ENV_FILE=/opt/oracle/product/grid1123/crs/install/s_crsconfig_database_env.txt [root@database ~]# cat /opt/oracle/product/grid1123/crs/install/s_crsconfig_database_env.txt ### This file can be used to modify the NLS_LANG environment variable, which determines the charset to be used for messages. ### For example, a new charset can be configured by setting NLS_LANG=JAPANESE_JAPAN.UTF8 ### Do not modify this file except to change NLS_LANG, or under the direction of Oracle Support Services TZ=Europe/Moscow NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 TNS_ADMIN= ORACLE_BASE=