Large companies often have multiple environments and servers. And sometimes its just easier to just open the database connection to check something in stead of going to APEX and search for a (debug) session.


If you use APEX_DEBUG.ERROR(p_message) in your code you will force debug messages to be written, even when the debug is not used. Also, if you use APEX_DEBUG.ENABLE(p_level) you will start the debugger for every session that invokes this plsql code.

Checking your debug logs

You can of course open your APEX application and look up the session for your user to view the debug logs, but APEX is build on the APEX user in Oracle, so if you know where to look, you can find 2 views; APEX_WORKSPACE_ACTIVITY_LOG and APEX_DEBUG_MESSAGES.


Everything a user does in your application to render someting, is logged in this table. In a way “it is proof” a user did of didn’t do something. You can see what pages where opened, and what was rendered.

SELECT apex_user
, application_id
, page_id
, view_date --or view_timestamp if you want to be more specific
, elapsed_time
, page_view_type
, request_value
, apex_session_id
, debug_page_view_id
WHERE application_id <> 4000
--AND page_id = 1 --Search for a specific page
--… etc
--AND debug_page_view_id is not null --use this if you know there is a debug message!
ORDER BY view_date desc


This displays all APEX debug messages that are enabled (or errors that were forced).

You can join both views;

SELECT awal.apex_user
, awal.application_id
, awal.page_id
, awal.view_date --or view_timestamp if you want to be more specific
, awal.elapsed_time
, awal.page_view_type
, awal.request_value
, apdm.message_timestamp
, apdm.execution_time
, apdm.message
, apdm.call_stack

JOIN APEX_DEBUG_MESSAGES apdm on awal.debug_page_view_id = apdm.page_view_id