If you are having problems running BMC_DEBUG, or using a particular feature, there are a number of things you can try to diagnose the issue.
Installation
If you are encountering errors trying to install the packages or create their tables, please see the Detailed Installation Guide for more information on how to install the code successfully.
Global Parameter Settings
If you have changed some global parameters and the changes do not appear to be taking effect, you can use the BMC_DEBUG.DUMP_GLOBALS procedure to display or log the values of the global parameters which BMC_DEBUG has read. The easiest way to do this is to run the BMC_DEBUG procedures interactively in SQL*Plus. Open a SQL*Plus session and login as the user whose sessions are not picking up the correct parameters, then run :-
SQL> exec dbms_output.enable(100000); PL/SQL procedure successfully completed. SQL> set serveroutput on size unlimited format wrapped; SQL> exec DBG_OWNER.BMC_DEBUG.BEGINCALL('TEST','TEST1'); PL/SQL procedure successfully completed. SQL> exec DBG_OWNER.BMC_DEBUG.DUMP_GLOBALS; BMC_DEBUG version = 1.43 Oracle session id = 139 Oracle session serial# = 1184 Oracle RAC instance no = 1 Oracle client hostname = pts/1 BMC_DEBUG Start timestamp = 16-NOV-2014 13:43:07.000000000 +00:00 CALL STACK MAX SIZE = 50 MSG STORE MAX SIZE = 50 MSG STORE MAX MSG LEVEL = 9999 CLIENT INFO MAX MSG LEVEL = 9999 MAX DEBUG LOG MSGS PER SESSION = 0 MAX CLOB CHUNKS TO LOG = 25 INTERNAL DEBUG MSG LEVEL 1 = 5 INTERNAL DEBUG MSG LEVEL 2 = 10 SAVEPOINTS ENABLED = TRUE WRITE APPLICATION INFO = TRUE USE MSG STORE = TRUE RECORD INTERMEDIATE CALL STATS = TRUE MSG REPLACE UNPRINTABLE = FALSE ALLOW PARAMETER OVERRIDE = TRUE ALWAYS LOG UNHANDLED EXCEPTION = TRUE WRITE CONTEXT INFO = 0 - WRITE PACKAGE/PROCEDURE = FALSE - WRITE MSG = FALSE - WRITE CALL INFO = FALSE - WRITE USER VALUES = FALSE CONTEXT MONITOR USERNAME = CONTEXT ATTRIBUTES PERSIST = FALSE FREE USER MEMORY = FALSE RECORD TIME MODEL STATS = FALSE RECORD WAIT EVENT STATS = FALSE WRITE SESSION STATS AFTER HRS = 0 KILLSWITCH ENGAGE = FALSE PL/SQL procedure successfully completed.
NOTE - The user will need EXECUTE privilege on the BMC_DEBUG package, and you'll need to include the name of the schema in which BMC_DEBUG is installed in the calls (here it is DBG_OWNER) unless the user has a synonym to it.
As soon as BMC_DEBUG.BEGINCALL is invoked in the session, the global parameter table will be read and the parameter settings for the session established. The call to DUMP_GLOBALS will display the values which BMC_DEBUG has read for the session. If any of these are incorrect, first check the BMC_DEBUG_GLOBAL_PARAMETER table for spelling mistakes. The values in PARAM_NAME should be uppercase, with the words separated by spaces, not underscores or other punctuation.
If you are still having problems, you can try to diagnose the issue by using internal debugging. There is a hidden global parameter called INTERNAL DEBUG ENABLED which can be set to TRUE to cause BMC_DEBUG to log many of its internal operations. However, I need to say one thing before proceeding - DO NOT ENABLE THIS ON A PRODUCTION SYSTEM, as it will cause a huge number of log messages to be written. If possible, copy the global parameter table entries you are having problems with to a development system and experiment with them there.
If you're OK with that, you can enable the internal debugging by inserting a new global parameter row from the BMC_DEBUG owner user. For super-safely, we should specify the user whose sessions we want the global parameter to apply to as the USERNAME (e.g. FRED) :-
SQL> INSERT INTO bmc_debug_global_parameter (param_name,param_value,username) VALUES ('INTERNAL DEBUG ENABLED','TRUE','FRED'); 1 row created. SQL> commit; Commit complete.
If you then disconnect from the session you ran DUMP_GLOBALS in, and reconnect and just run the BEGINCALL again, you will see
SQL> exec dbms_output.enable(100000); PL/SQL procedure successfully completed. SQL> set serveroutput on size unlimited format wrapped; SQL> exec DBG_OWNER.BMC_DEBUG.BEGINCALL('TEST','TEST1'); DBG:PACKAGE:BMC_DEBUG 1.43 package initialization DBG:READ_GLOBAL_PARAMETER2:WHEN OTHERS reading MSG STORE MAX SIZE : ORA-01722: invalid number DBG:READ_GLOBAL_PARAMETER3:WHEN OTHERS reading CONTEXT SESSION PREFIX : ORA-01403: no data found DBG:READ_GLOBAL_PARAMETER3:WHEN OTHERS reading CONTEXT MONITOR USERNAME : ORA-01403: no data found ERR:PACKAGE:BMC_ERROR 1.12 package initialization ERR:READ_GLOBAL_PARAMETER2:WHEN OTHERS reading USER EXCEPTION LOG MSG LEVEL : ORA-01403: no data found ERR:READ_GLOBAL_PARAMETER2:WHEN OTHERS reading MSG STORE MAX SIZE : ORA-01722: invalid number ERR:READ_GLOBAL_PARAMETER2:WHEN OTHERS reading EXCEPTION MSGS TO LOG : ORA-01403: no data found DBG:READ_PARAMETER:Got value DEBUG LEVEL=0 from bmc_debug_parameter (param sequence 18) DBG:READ_PARAMETER:Got value CALL STATS GROUP=0 from bmc_debug_parameter (param sequence 18) DBG:READ_PARAMETER:Got value PROFILE STATS GROUP=0 from bmc_debug_parameter (param sequence 18) DBG:READ_PARAMETER:Got value SESSION STATS GROUP=0 from bmc_debug_parameter (param sequence 18) DBG:TEST1:TEST.TEST1 begins DBG:TEST1:Created SAVEPOINT SP01_00139_135238174136000 PL/SQL procedure successfully completed.
So now errors which are returned by reading the global parameters are logged. ORA-1403 errors are not important, as it means that the SELECT for a particular parameter did not return a row, but if this is the case BMC_DEBUG will use its hard coded defaults. More interesting are the ORA-1722 errors for MSG STORE MAX SIZE, which indicate that a value in the parameter table which was expected to be a number was not.
Once you have identified the problem, remember to remove the internal debug parameter entry :-
SQL> DELETE FROM bmc_debug_global_parameter WHERE param_name = 'INTERNAL DEBUG ENABLED'; 1 row deleted. SQL> commit; Commit complete.
Parameter Table Entries Not Taking Effect
If you have added entries to the BMC_DEBUG_PARAMETER table and they do not appear to be taking effect, there are a couple of things you can do to find out why.
If the parameters are setting stats groups into a named package/procedure, you can run BMC_DEBUG.BEGINCALL in SQL*Plus as the user who usually runs the instrumented procedure, and pass the package and procedure names as command line parameters, along with a high setting for DEBUG LEVEL. For example :-
SQL> exec bmc_debug.begincall('ORDERING','PROCESS_ORDER',15); Using passed DEBUG LEVEL parameter 15 Using CALL STATS GROUP 0 from parameter table Using PROFILE STATS GROUP 0 from parameter table Using SESSION STATS GROUP 0 from parameter table ORDERING.PROCESS_ORDER begins (Forced debug level 15) Created SAVEPOINT SP01_00139_142405265564000 PL/SQL procedure successfully completed.
So this will show the values for each parameter which has been set, and where the value was retrieved from.
If the parameter value you are having an issue with is the DEBUG LEVEL, you can use the internal debug method as detailed in the Global Parameter Settings section at the top of this page, as that will show where each of the parameter table entries is read from.