When you deploy BMC_DEBUG to your live environment, there are a number of parameter table values you should use to minimise the impact of instrumentation on your live applications.
BMC_DEBUG_PARAMETER entries
The BMC_DEBUG_PARAMETER table in your live environment should initially contain these entries :-
SQL> SELECT param_name,param_value,inherit,package_name,procedure_name,sid,serial#,username,comments FROM bmc_debug_parameter; PARAM_NAME PARAM_VALUE INHERIT PACKAGE_NAME PROCEDURE_NAME SID SERIAL# USERNAME COMMENTS ------------------- ----------- ------- -------------------- --------------------- --- ------- -------- ----------------------------------- DEBUG LEVEL 0 Y Default DEBUG LEVEL CALL STATS GROUP 0 Y Default CALL STATS GROUP PROFILE STATS GROUP 0 Y Default PROFILE STATS GROUP SESSION STATS GROUP 0 Y Default SESSION STATS GROUP
These are slightly different to the default entries which are created by the installation scripts, as the value of the INHERIT flag for all of these entries is Y rather than N. The purpose of this is to reduce the number of times the parameter table is read, as only top-level calls to instrumented procedures will read their parameters from the parameter table. All instrumented procedures and functions which those procedures call will inherit their parameter values from their parent, and will not require SELECTs to be run against the parameter table.
There is one disadvantage to creating the default parameter table entries in this way. If you were to INSERT an additional row to, for example, implement a higher DEBUG LEVEL for a procedure which was not producing the correct results, the parameter setting would not take effect if the problematic procedure was not a top-level call. This is because the procedure which called the problematic one would have INHERIT=Y for its DEBUG LEVEL, so the value would be inherited rather than being read from the newly inserted parameter table entry.
To solve this problem, you would either need to modify the default DEBUG LEVEL entry to temporarily have INHERIT=N, or add a new parameter table entry which sets INHERIT=N for the calling procedure, as long as that was not itself called by an instrumented procedure.
BMC_DEBUG_GLOBAL_PARAMETER entries
There are several global parameters whose values it is important to set correctly in a live production environment. They are :-
ALLOW PARAMETER OVERRIDE - This controls whether parameter values such as DEBUG LEVEL are used if they are passed as parameters to BEGINCALL. It is important to set this value to FALSE in a live environment, as if code which forces a particular DEBUG LEVEL or CALL STATS LEVEL is deployed to your live environment, you would want these values to be ignored and to be read from the parameter table.
MAX DEBUG LOG MSGS PER SESSION - This sets a limit on the number of rows which a session can insert into the BMC_DEBUG_LOG table. The default is 0 which means unlimited, but you might want to set this to a value such as 5000 to prevent a session logging a large number of messages if its DEBUG LEVEL were to be raised.
ALWAYS LOG UNHANDLED EXCEPTION - This controls whether details of unhandled exceptions are written to the log table if the user has exceed the number of messages they can write, as set by the MAX DEBUG LOG MSGS PER SESSION parameter. If this is TRUE, unhandled exception details will always be written, but if you have an application which frequently raises unhandled exceptions, you might find that it causes a large number of rows to be written to the log table, and you'd have no way to limit them. If this is set to FALSE, unhandled exceptions will not be logged if the user has reached their log table limit, although this could lead to important application failures not being recorded.