dbhome not found

Encountered a problem where my Oracle 10g database on Solaris 9 would not automatically shutdown or startup during a reboot. The error generated is:

/etc/rc0.d/K01oracle: dbhome: not found
ORACLE_HOME = [] ?

On my server, dbhome is located in $ORACLE_HOME/bin as well as /usr/local/bin. This led me to believe the PATH for root might not have /usr/local/bin included during the UNIX system startup/shutdown process. I copied the script to /usr/bin and now the system appears to function fine during UNIX system startup/shutdown.

Strange thing is both directories are in root’s PATH during normal operation.

/usr/sbin:/usr/bin:/sbin:/usr/local/bin:
/usr/local/sbin:/usr/X/bin:/usr/lib/lvm:
/etc/lvm:/usr/sbin/osa:/usr/ccs/bin:/usr/ucb

I will need to investigate further on why /usr/local/bin is not included in the PATH of root during UNIX system startup/shutdown. Is that by system design (i.e. security) or system misconfiguration?

Another strange thing is this does not occur on my Solaris 10 server running Oracle 10g. Even more confused now.

Update (09-Jan-2008)
On Solaris 10 when running the shutdown/startup scripts manually as the root user, this problem does not occur. However, when the system is rebooted the error does occur. Found the error in /var/svc/log/milestone-multi-user:default.log.

Executing legacy init script “/etc/rc2.d/S99oracle”.
Oracle Startup/Shutdown Begins
/etc/rc2.d/S99oracle: dbhome: not found
ORACLE_HOME = [] ? /etc/rc2.d/S99oracle: test: argument expected
Legacy init script “/etc/rc2.d/S99oracle” exited with return code 1.

My resolution to this problem was to copy dbhome from /usr/local/bin to /usr/bin. The error no longer occurs during server reboot.

SID_XPT Service Generated On Listener

Created a new Oracle 10g (10.2.0.3) database on a Solaris 10 (64-bit) server this morning. I noticed when I reviewed the status of the Listener, there was a peculiar service registered that I didn’t expect.

% lsnrctl status

Services Summary…
Service “d103″ has 1 instance(s).
Instance “d103″, status READY, has 1 handler(s) for this service…
Service “d103_XPT” has 1 instance(s).
Instance “d103″, status READY, has 1 handler(s) for this service…
The command completed successfully

Searching on Metalink, I found Metalink Note 339940.1 – “How to stop the _XPT service from registering with the listener”. It explains why this service appears.

In version 10.2 of the RDBMS when an instance registers with its listeners it will register a service with the name <sid>_XPT (e.g. v102_XPT) in addition to the normal service names.

This service does not cause a problem and is intended for use within Data Guard environments.

The Note also explains how to resolve the issue.

In the init.ora file for the instance set,

__dg_broker_service_names=”

Please note that this setting begins with two underscore characters. The instance will need to be restarted for this to take effect.

As suggested, I added the parameter to my init.ora and restarted the database instance. No more XPT service registered.

% lsnrctl status

Services Summary…
Service “d103″ has 1 instance(s).
Instance “d103″, status READY, has 1 handler(s) for this service…
The command completed successfully

References
Metalink Forum ID 611575.993 – “<SID>_XPT service dynamically registered”