DBCollect/Detection: Difference between revisions

From Dirty Cache Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 38: Line 38:
* No logons: <code>$ORACLE_HOME/bin/sqlplus -S -L / as sysdba</code>
* No logons: <code>$ORACLE_HOME/bin/sqlplus -S -L / as sysdba</code>
* Logons: <code>$ORACLE_HOME/bin/sqlplus -S -L <logon></code>
* Logons: <code>$ORACLE_HOME/bin/sqlplus -S -L <logon></code>
The connection attempt may fail for all kinds of reasons. If the reason is <code>ORA-01017 (logon denied)</code> or <code>ORA-01034 (Oracle not available)</code> then a warning is issued and {{dbcollect}} will try to connect using the next ORACLE_HOME candidate, until all candidates are attempted and all of them failed, resulting in DBC-E027 (no valid connection).
Specifically for <code>ORA-01017</code>, {{dbcollect}} will try to read <code>$ORACLE_HOME/rdbms/lib/config.c</code> to check for the correct OSDBA group membership, and issue warning DBC-W011 with a message about the correct DBA group.

Revision as of 15:12, 31 August 2025


Instance detection

This page describes how dbcollect detects (running) Oracle instances and their correct ORACLE_HOMEs.

Running instances

  • If a logons file is provided (using --logons), dbcollect will NOT automatically detect instances, but only connect to the services listed in the logons file.
  • If no logons file is specified, dbcollect runs the command ps -eo pid,user,group,args to find all running processes on the OS.
  • Running instances are matched if the args match ora_pmon_<oracle_sid>
  • If the --included option is given, only instances that are explicitly included will be processed (a warning message is given for non-included instances)
  • If the --excluded option is given, only instances that are not explicitly excluded will be processed (a warning message is given for excluded instances)

ORACLE_HOME

dbcollect uses SQL*Plus to connect to databases. As of Oracle 19, there is no clean, consistent way to find the correct ORACLE_HOME for a running instance. Older versions would have a hc_<sid>.dat file where the most recent timestamp on these files was used to figure out which ORACLE_HOME is the correct one. In Oracle 19, the DBS directory is moved from $ORACLE_HOME/dbs to $ORACLE_BASE/dbs which is shared by multiple ORACLE_HOMEs and therefore can no longer be used to identify the correct directory.

Therefore, the instance detection part has been rewritten in version 1.18.0 as follows:

Finding candidates

  • If the --orahome option is used, try the ORACLE_HOMEs given by this parameter first
  • Next, try to locate the instance in oratab. The ORACLE_HOME given for the instance will be tried
  • Finally, try the ORACLE_HOMEs found via processing the Oracle Inventory (inventory.xml)

The Oratab and Inventory parts can be skipped (for troubleshooting purpuses) with the --no-oratab and --no-orainv options.

Validating ORACLE_HOME

  • Each ORACLE_HOME directory must have an executable sqlplus binary in $ORACLE_HOME/bin/sqlplus
  • Each ORACLE_HOME directory must NOT have an executable crsctl binary in $ORACLE_HOME/bin/sqlplus (this means it is a GRID_HOME and not used for database connections)

Trying SQL connection

For each valid ORACLE_HOME candidate, dbcollect will try to connect to the database, either as SYSDBA (if no logons file is used) or using the provided logon definition.

  • No logons: $ORACLE_HOME/bin/sqlplus -S -L / as sysdba
  • Logons: $ORACLE_HOME/bin/sqlplus -S -L <logon>

The connection attempt may fail for all kinds of reasons. If the reason is ORA-01017 (logon denied) or ORA-01034 (Oracle not available) then a warning is issued and dbcollect will try to connect using the next ORACLE_HOME candidate, until all candidates are attempted and all of them failed, resulting in DBC-E027 (no valid connection).

Specifically for ORA-01017, dbcollect will try to read $ORACLE_HOME/rdbms/lib/config.c to check for the correct OSDBA group membership, and issue warning DBC-W011 with a message about the correct DBA group.