Open dtseiler opened 11 years ago
I accidentally left an extra debug line in there.
Also, FYI, I do get this output when I try to run on standby, but only in verbose mode. The check itself returns cleanly.
Wed Apr 24 15:00:19 2013: fetchrow_array: select dbms_utility.port_string,sys_context('userenv', 'session_user'),i.thread#,i.parallel, i.instance_name, d.name FROM dual, v$instance i, v$database d Wed Apr 24 15:00:19 2013: args: $VAR1 = [];
bumm Can't call method "execute" on an undefined value at /usr/local/nagios/libexec/check_oracle_health_dts line 5004. DBD::Oracle::Server::Connection::Dbi bumm ORA-00904: "DBMS_UTILITY"."PORTSTRING": invalid identifier (DBD ERROR: error possibly near <> indicator at char 8 in ' select <_>dbms_utility.port_string,sys_context('userenv', 'session_user'),i.thread#,i.parallel, i.instance_name, d.name FROM dual, v$instance i, v$database d ') DBD::Oracle::Server::Connection::Dbi
You could use v$database.platform_name on standby to get the OS platform, but that's only available in 10g or higher. The output is somewhat different so you'd need to handle the if/else statements that check the values.
Or you could draw the hard line and and say future versions of check_oracle_health only work for 10g or higher (at least for standby support). I think at this point in time, cutting off 8i/9i support in future versions isn't a horrible idea.
The latest release of check_oracle_health did not work for SYSDBA connections because the code was setting the username to "sysdba" when it needs to be null.
I have a patch to correct this as well as use the ora_session_mode keywords instead of the hex constant for easier readability and in case those constants change.