Sunday, April 13, 2008

Troubleshooting the 404-not found error on XE

A few weeks ago, Patrick Wolf, Denes Kubicek and me held an advanced APEX training in Bensheim.

After the training, I helped someone from the class troubleshoot an APEX issue. He received a 404 error sporadically.

How do you find the database error which caused the Apache to show the 404-error?

Usually the error is found in the Apache error log. But you can also configure the mod_plsql to show more detailed information in the browser. This is very useful but should only used in development environments due to security reasons. Patrick wrote a nice blog posting about it.

But using Oracle Express Edition (XE) you don't have an Apache / mod_plsql configuration.
How do you find the errors here?

Since Oracle XE uses the http listener of the XMLDB, it needs to be configured through the DBMS_EPG interface. The documentation can be found here.

To see the error log similar to Apache, logon as SYSTEM via SQL*Plus and execute:

SQL>execute dbms_epg.set_global_attribute('log-level', 3);
The error log will go to the database trace file app/oracle/admin/XE/bdump/xe_s00?_????.trc.
Please ignore the bogus error message "Embedded PL/SQL Gateway: Unknown attribute 3" in the error log.

The log levels are:
To turn off the error logging, execute the following as SYSTEM:
SQL>execute dbms_epg.set_global_attribute('log-level', 0);
In order to show the error messages in the browser, you would configure parameter error-style using the DBMS_EPG.

Almost all parameters of the mod_plsql are configurable in the DBMS_EPG, too. They are just named differently (why?). You can find the mapping in the Oracle documentation.

So, how can we enable the debug style messages in XE. It is easy, just connect as SYSTEM to the database and issue the following command:
SQL>exec dbms_epg.set_dad_attribute('APEX', 'error-style', 'DebugStyle');
In order to revert to the standard message format, issue:
SQL>exec dbms_epg.delete_dad_attribute('APEX', 'error-style');
Then your browser will show the following error message instead of the standard 404-error page:

That's it.

Now I have shown how to configure the DAD for XE, but how can you see the current configuration? My next post will cover these instructions.



Patrick Wolf said...

Great to know how to do it in XE.

Thanks for sharing

Anonymous said...

Great info! Thanks a lot!

Anonymous said...

Just a tip...
When I change the log level to 7 and try to send more than 30kb of data (a comment in a application express text area) the follow happening:

Fri Dec 05 03:02:47 2008
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x389C8320] [PC:0x91FB195, sigpnmu()+281]
Errors in file /u01/app/oracle/diag/rdbms/application/application/trace/application_s004_2828.trc:
ORA-07445: exception encountered: core dump [sigpnmu()+281] [SIGSEGV] [ADDR:0x389C8320] [PC:0x91FB195] [Address not mapped to object] []
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [17147], [0x697FC0], [], [], [], [], [], []
Fri Dec 05 03:02:50 2008
found dead shared server 'S004', pid = (32, 20)

Unknown said...

Thanks for the tip.

Seems to be a bug. The problem does not occur on level 6, this seems to be a lot of information anyway.

This will give me a decent error message:
Value param too long. Length is 69330. Upper limit is 32512
DAD name: apex
PROCEDURE : wwv_flow.accept
URL : http://XDB HTTP Server:8081/apex/wwv_flow.accept

On level 7 you get an "internal server error".


Balaji Chellappa said...

Thanks a lot. It helped me a lot. In Oracle 11g where does it generates the bdump. I don't see this folder in oraclehome\diag folder.

Unknown said...


I haven't checked in 11g, but it should be somewhere here:

=> in the bdump directory, where all the trace files go.

Connect as sys and output the parameter background_dump_dest:
sys@> show parameter background_dump_dest

------------------------------------ ----------- ------------------------------
background_dump_dest string D:\ORACLEXE\APP\ORACLE\ADMIN\XE\BDUMP


Art said...

Thank you, Dietmar. This is not the first time, I've found an answer to an APEX problem on your blog. Keep up posting!


Term Papers said...
This comment has been removed by a blog administrator.
Anonymous said...

This one really helped me a lot last night to recover from a crucial situation.