BMC_DEBUG contains some features which, while useful and convenient in a development environment, may cause issues if used in a live production environment.
This page details the potential issues and describes how the live deployment of BMC_DEBUG may be customised to mitigate these issues.
As you've seen in many examples up to now, it is possible to override the value of the DEBUG LEVEL and CALL STATS GROUP parameters in the parameter table by speficying the value when you call BEGINCALL e.g.
bmc_debug.begincall('TEST','TEST1',8); -- Force DEBUG LEVEL 8
There are also a couple of procedures in BMC_DEBUG which will change the DEBUG LEVEL dynamically either for the current call, or for the rest of the current session :-
SQL> BEGIN bmc_debug.begincall('PROCEDURE','TEST1',1); -- Force DEBUG LEVEL 1 bmc_debug.msg(7,'This message will not be seen'); bmc_debug.set_debug_level_for_this_call(7); -- Set the debug level to 7 bmc_debug.msg(7,'This message will be seen'); bmc_debug.set_debug_level_for_this_call(); -- Reset DEBUG LEVEL to the parameter table value bmc_debug.msg(7,'This will not be seen either'); bmc_debug.set_debug_level_for_session(9); -- Set the debug level to 9 for the session by inserting a new parameter table row bmc_debug.endcall('PROCEDURE','TEST1'); END; / DEBUG LEVEL for call changed to 7 This message will be seen DEBUG LEVEL reset to 0 DEBUG LEVEL for session changed to 9 PROCEDURE.TEST1 ends PL/SQL procedure successfully completed. SQL> select param_name,param_value,package_name,procedure_name,session_id,serial_no,comments from bmc_debug_parameter where comments like 'Added%'; PARAM_NAME PARAM_VALUE PACKAGE_NAME PROCEDURE_NAME SESSION_ID SERIAL_NO COMMENTS --------------------- ----------------- --------------------- --------------------- ---------- --------- ----------------------------------------------------------- DEBUG LEVEL 9 19 48911 Added by set_debug_level_for_session 02-FEB-2014 17:29:41
While this is very convenient for development, it can also be dangerous in a production environment. If you were to deploy some code which wrote millions of messages to the log table, and as it was overriding the DEBUG LEVEL in the parameter table there was no central way to disable it, that would be bad.
For this reason, it is possible to prevent these methods of parameter override being used in a production environment. If you examine the BMC_DEBUG package specification you'll see three declarations of begincall :- PROCEDURE begincall (in_package_name IN VARCHAR2, in_procedure_name IN VARCHAR2, in_call_info IN VARCHAR2 DEFAULT NULL); -- If you want to prevent the passing of a DEBUG LEVEL or CALL STATS GROUP to begincall via parameters, you can -- comment out the next two declarations. If you do this, and make set_debug_level_for_this_call/session private, -- you will ensure that the only way to specify these parameters is via the parameter table PROCEDURE begincall (in_package_name IN VARCHAR2, in_procedure_name IN VARCHAR2, in_call_info IN VARCHAR2, in_debug_level IN PLS_INTEGER, in_debug_inherit IN VARCHAR2 DEFAULT 'N', in_call_stats_group IN PLS_INTEGER DEFAULT NULL, in_call_stats_inherit IN VARCHAR2 DEFAULT 'N'); PROCEDURE begincall (in_package_name IN VARCHAR2, in_procedure_name IN VARCHAR2, in_debug_level IN PLS_INTEGER, in_debug_inherit IN VARCHAR2 DEFAULT 'N', in_call_stats_group IN PLS_INTEGER DEFAULT NULL, in_call_stats_inherit IN VARCHAR2 DEFAULT 'N');
You will also see the declarations of set_debug_level_for_this_call and set_debug_level_for_this_session :- -- Allow user code to change its debug levels dynamically PROCEDURE set_debug_level_for_this_call(in_debug_level IN PLS_INTEGER DEFAULT NULL, in_inherit IN VARCHAR2 DEFAULT 'N'); PROCEDURE set_debug_level_for_session(in_debug_level IN PLS_INTEGER DEFAULT NULL, in_inherit IN VARCHAR2 DEFAULT 'N');
If you want to ensure that parameter values can only be set via the parameter table, you can comment out the last two declarations of begincall, and the declarations of set_debug_level_for_this_call and set_debug_level_for_this_session, and recompile the package by running the file in sqlplus.
This will mean that the only public version of begincall is the one which accepts :- PROCEDURE begincall (in_package_name IN VARCHAR2, in_procedure_name IN VARCHAR2, in_call_info IN VARCHAR2 DEFAULT NULL);
As this might prove to be an inconvenience in your development environment, you may want to leave the original version there, and only deploy the restricted version on your staging and production platforms. It's important to do this on another platform as well as your live production one, as any code which depended on these procedures would fail to compile, and you'd want to know that before you attempted to deploy it live :)