I submitted this and it has been approved as an enhancement request--I don't know when it will show up in the code.
Bug 17258100 : NEED A WAY TO MONITOR ACTIVITY IN THE DATA BASE BY USER
Even though this is approved for a future release, I have tampered with a essential part of OTM's guts--the VPD package.
Just a tweak.
We have tested thoroughly and have had this in production for quite a while now with zero issues, but until it is part of the OTM distribution, use at your own risk--I had to say that.
It's a simple change, but you need to the DBAs help to install.
ALLWAYS install on a test environment first and test, test, test, before promoting to prod.
Here is the change:
1. The application has to be shut down completely. The change is to the VPD package so any application interaction will have the packaged locked in memory and will prevent compilation.
2. BACKUP the original VPD package so that you can recover it if needed.
3. In the VPD package, locate the set_user_r procedure:
PROCEDURE set_user_r (p_gl_user_gid VARCHAR2,
p_user_role_gid varchar2 default null,
p_exec_as_gl_user varchar2 default null,
p_policy_group varchar2 default 'UNKNOWN') AS
3. At the bottom of the procedure add one line (plus the optional comment explaining it):
Before:
set_ctx(p_gl_user_gid,
v_exec_as_gl_user,
v_current_domain_name,
v_vpd_profile_gid,
v_vpd_context_gid,
v_vpd_domain_name,
v_use_insert_user_rule,
v_use_external_predicate_rule,
v_vpd_policy_group,
v_user_role_gid);
EXCEPTION
when no_data_found then
raise_application_error(-20000,'Invalid GL_USER');
WHEN OTHERS THEN
RAISE;
end set_user_r;
After:
set_ctx(p_gl_user_gid,
v_exec_as_gl_user,
v_current_domain_name,
v_vpd_profile_gid,
v_vpd_context_gid,
v_vpd_domain_name,
v_use_insert_user_rule,
v_use_external_predicate_rule,
v_vpd_policy_group,
v_user_role_gid);
/* This line is added by dknapp 2013/06/18
* it provides posting of the gl_user_gid to the client_info
* column that appears in v$sessions. This is very helpful
* in tracking down problem UI queries. The call to
* DBMS_APPLICATION_INFO.SET_CLIENT_INFO seems to be very
* efficient (1,000,000 calls in 850ms on the workbench)
*/
DBMS_APPLICATION_INFO.SET_CLIENT_INFO( p_gl_user_gid );
EXCEPTION
when no_data_found then
raise_application_error(-20000,'Invalid GL_USER');
WHEN OTHERS THEN
RAISE;
end set_user_r;
4. Recompile the package body.
5. Restart the application.
6. Use Toad or SQLDeveloper to examine v$sessions, you will see the OTM user id in the client_info column.
If you include Last_call_ET and filter on active sessions only, then you have a quick view into who is doing what, and for how long.
Now you can tell what users are initiating the long running activity and can improve processes or educate users. . . . or. . . whatever.
Comments or improvements are welcomed!!
Bug 17258100 : NEED A WAY TO MONITOR ACTIVITY IN THE DATA BASE BY USER
Even though this is approved for a future release, I have tampered with a essential part of OTM's guts--the VPD package.
Just a tweak.
We have tested thoroughly and have had this in production for quite a while now with zero issues, but until it is part of the OTM distribution, use at your own risk--I had to say that.
It's a simple change, but you need to the DBAs help to install.
ALLWAYS install on a test environment first and test, test, test, before promoting to prod.
Here is the change:
1. The application has to be shut down completely. The change is to the VPD package so any application interaction will have the packaged locked in memory and will prevent compilation.
2. BACKUP the original VPD package so that you can recover it if needed.
3. In the VPD package, locate the set_user_r procedure:
PROCEDURE set_user_r (p_gl_user_gid VARCHAR2,
p_user_role_gid varchar2 default null,
p_exec_as_gl_user varchar2 default null,
p_policy_group varchar2 default 'UNKNOWN') AS
3. At the bottom of the procedure add one line (plus the optional comment explaining it):
Before:
set_ctx(p_gl_user_gid,
v_exec_as_gl_user,
v_current_domain_name,
v_vpd_profile_gid,
v_vpd_context_gid,
v_vpd_domain_name,
v_use_insert_user_rule,
v_use_external_predicate_rule,
v_vpd_policy_group,
v_user_role_gid);
EXCEPTION
when no_data_found then
raise_application_error(-20000,'Invalid GL_USER');
WHEN OTHERS THEN
RAISE;
end set_user_r;
After:
set_ctx(p_gl_user_gid,
v_exec_as_gl_user,
v_current_domain_name,
v_vpd_profile_gid,
v_vpd_context_gid,
v_vpd_domain_name,
v_use_insert_user_rule,
v_use_external_predicate_rule,
v_vpd_policy_group,
v_user_role_gid);
/* This line is added by dknapp 2013/06/18
* it provides posting of the gl_user_gid to the client_info
* column that appears in v$sessions. This is very helpful
* in tracking down problem UI queries. The call to
* DBMS_APPLICATION_INFO.SET_CLIENT_INFO seems to be very
* efficient (1,000,000 calls in 850ms on the workbench)
*/
DBMS_APPLICATION_INFO.SET_CLIENT_INFO( p_gl_user_gid );
EXCEPTION
when no_data_found then
raise_application_error(-20000,'Invalid GL_USER');
WHEN OTHERS THEN
RAISE;
end set_user_r;
4. Recompile the package body.
5. Restart the application.
6. Use Toad or SQLDeveloper to examine v$sessions, you will see the OTM user id in the client_info column.
If you include Last_call_ET and filter on active sessions only, then you have a quick view into who is doing what, and for how long.
Now you can tell what users are initiating the long running activity and can improve processes or educate users. . . . or. . . whatever.
Comments or improvements are welcomed!!