A page view ID makes it easier to query debug messages. In order to obtain it, you can query the APEX_WORKSPACE_ACTIVITY_LOG as shown in the following example:

select *
  from APEX_WORKSPACE_ACTIVITY_LOG
 where application_id = <APPLICATION_ID>
   and page_id = <PAGE_ID>
 order by view_timestamp desc;

Locate and make note of the DEBUG_PAGE_VIEW_ID associated with the debug messages you are looking for.

You can query the debug messages from the APEX_DEBUG_MESSAGES view, which shows all messages logged in the current workspace. Messages can be filtered and sorted as shown in the following example:

select *
  from APEX_DEBUG_MESSAGES
 where page_view_id = <DEBUG_PAGE_VIEW_ID>
 order by message_timestamp asc;

In the previous example, <DEBUG_PAGE_VIEW_ID> is the ID you noted earlier. The messages column in the above query will contain the most relevant information for debugging purposes.

The APEX software distribution includes SQL utility scripts to aid with debugging. You can find these scripts in the apex/utilities/debug folder. To use the scripts described in this topic, you must have SYSDBA privileges.

activity.sql

activity.sql prints recent activity log entries. This script takes one parameter, which can contain a comma-separated list of settings. To see script usage instructions, execute:

SQL> @activity help

d0.sql

d0.sql toggles between disabling Debug mode and a LEVEL9 debug log. A LEVEL9 debug level logs every request and generates a substantial amount of messages. A LEVEL9 debug log will impact application performance for all users and App Builder performance for developers. For example:

-- Switch from disabled debug to LEVEL9
SQL> @d0
-- Switch from LEVEL9 debug to disabled debug
SQL> @d0

d1.sql

d1.sql displays a report of the last 30 APEX requests that had debug enabled. Use the displayed PAGE_VIEW_ID with the d2.sql script.

ds.sql

ds.sql displays a report of APEX requests with debug data for the specified APEX session. Use the displayed PAGE_VIEW_ID with the d2.sql script. For example:

SQL> @ds <SESSION_ID>

d2.sql

d2.sql saves the details for the specified PAGE_VIEW_ID into a file and opens this file in a text editor. You can define the _editor variable in SQLcl to your preferred editor. For example:

SQL> define _editor=vim
SQL> @d2 <PAGE_VIEW_ID>

Example

The following is a typical usage example of APEX debug utility scripts:

$ cd apex/utilities/debug
$ sql / as SYSDBA
SQL> alter session set current_schema=APEX_240200;
SQL> define _editor=vim
SQL> @d0
Changed debug level from "" to "9"
-- Reproduce the problem
SQL> @d0
Changed debug level from "9" to ""
SQL> @d1
 
PAGE_VIEW_ID STARTED  SECS   LVL  CNT PATH_INFO   FLOW_PAGE   SESSION_ID      WORKSPACE APEX_USER
____________ ________ ______ ___ ____ ___________ ___________ _______________ _________ _________
@d2 1002     14:02:48  10.84 WRN  261             100-4750:50 8488213505163   DEMO      DEMO
@d2 1003     14:12:22   0.87     2603 show        100:9       0-5628985429897 DEMO      DEMO
@d2 1006     14:12:23   0.75      252 ajax plugin 100:9       0-5628985429897 DEMO      DEMO
@d2 1007     14:12:41   2.04      297 ajax plugin 100:9       0-5628985429897 DEMO      DEMO
 
4 rows selected.
 
SQL> @d2 1003
 
-- This will open the editor program you defined above, in this case vim with content similar to the following:
 
SECS MESSAGE_LEVEL MESSAGE FLOW_PAGE SID_SGID APEX_USER CALL_STACK1
____ _____________ _______ _________ ________ _________ ___________
...

Alternatively, you can execute ds.sql instead of d1.sql to narrow down the search of a PAGE_VIEW_ID to a specific APEX Session ID. For example:

$ cd apex/utilities/debug
$ sql / as SYSDBA
SQL> alter session set current_schema=APEX_240100;
SQL> define _editor=vim
SQL> @d0
Changed debug level from "" to "9"
-- Reproduce the problem and obtain the APEX session ID, in this case 5628985429897
SQL> @d0
Changed debug level from "9" to ""
SQL> @ds 5628985429897
 
PAGE_VIEW_ID STARTED  SECS    CNT PATH_INFO                                FLOW_PAGE SESSION_ID      WORKSPACE APEX_USER
____________ ________ ______ ____ ________________________________________ _________ _______________ _________ _________
@d2 1003     14:12:22   0.87 2603 bar?clear=9&session=5628985429897&cs=391 100:9     0-5628985429897 DEMO      DEMO
@d2 1006     14:12:23   0.75  252 wwv_flow.ajax?p_context=sample-charts%2F 100:9     0-5628985429897 DEMO      DEMO
@d2 1007     14:12:41   2.04  297 wwv_flow.ajax?p_context=sample-charts%2F 100:9     0-5628985429897 DEMO      DEMO
@d2 1008     14:12:41   1.95  297 wwv_flow.ajax?p_context=sample-charts%2F 100:9     0-5628985429897 DEMO      DEMO
 
4 rows selected.
 
SQL> @d2 1003
 
-- This will open the editor program you defined above, in this case vim with content similar to the following:
 
SECS MESSAGE_LEVEL MESSAGE FLOW_PAGE SID_SGID APEX_USER CALL_STACK1
____ _____________ _______ _________ ________ _________ ___________
...

If you wish to share the debug output from your application for offline review, consider the following best practices:

• Enable the capture log at the appropriate level.

  For example, if you are debugging the behavior of your application, use Application Trace (LEVEL6). If you are debugging the behavior of the APEX engine, use APEX Engine Trace (LEVEL9).

  See Available Debug Utility Scripts to learn more about debug levels.

• If you are reviewing debug output at the APEX Engine Trace (LEVEL9) level, consider including the Call Stack column in the report. This is particularly useful if you are planning to share debug output with Oracle Support. If you are reviewing debug output in an interactive report, use the Actions menu to select the Call Stack column.

• Pick the appropriate Page View ID. Best practices to consider:

  • When debugging an operation that takes place during the rendering of the page, select the last page view with the Rendering page view type.

  • If the operation takes place in the submission of the page (for example, after clicking a button) select the last page view with the Processing page view type.

  • If the operation happens in-between (for example, a partial page refresh or rendering of a chart) select the last page view with the AJAX page view type.

  • Remember that modal dialogs are separate pages so when debugging dialogs, you will need to look for the dialog's page number rather than the page number of the parent page.

• You can export debug output in multiple formats. The most useful formats for offline review are the HTML format and the Excel format. If you are reviewing debug output in an interactive report, use the Actions menu, click Download, and select the HTML or Excel format.

To share debug output:

1. Find the desired Page View ID. To learn more about available debug reports, see 24.5.6 Viewing debug messages.
2. From the Actions menu of the interactive report, click Download, select the desired format, and save the debug report to your file system.
3. If App Builder is not available in your environment, use the d2.sql script to print debug output and share the resulting text file. To learn more, see 24.5.6.4 Using the Debug Utility Scripts to learn more.