I have a question regarding the APEX tracing section on page 60 of The Method R Guide to Mastering Oracle Trace Data.
"Many great window-on-data applications these days are developed with Oracle Application Express (APEX). Tracing is easy in APEX. The simplest tracing operation, tracing a single page execution, is trivially easy to do: simply append &p_trace=YES to the page’s URL."
I do not work with APEX a lot, but needed to trace APEX applications (APEX 4.x) from time to time. Unfortunately it never worked out with the URL extension even if I did the exact same procedure you described in the book. Later on I discovered that maybe the debug mode must be activated as well to get this running (slide 13: http://www.aioug.org/sangam12/Presentations/20157.pdf). However I always needed to edit the APEX header and footer page to enable/disable tracing.
Any idea what I am missing here? Is debug mode needed even if not mentioned in the book?
Thank you.
Regards
Stefan
P.S.: In addition maybe you guys also know an extension or clever way to implement DBMS_PROFILER on APEX pages to get the complete hierarchy (https://www.freelists.org/post/oracle-l/Oracle-APEX-4x-Looking-for-clever-ways-to-implement-DBMS-PROFILER)?
The additional debug mode information is present in The Method R Guide to Mastering Oracle Trace Data, 2nd Edition printings with a revised date of August 4, 2016 or later.
The following answer comes from our colleague Doug Gault.
To enable the &P_TRACE appended to the URL, the following things need to be true:
Trace must be enabled at the APEX instance level.
Debug must be enabled at the application level.
In early versions of APEX, debugging being enabled was not a prerequisite for tracing. This was added somewhere in the lifecycle of APEX 4 to protect against someone writing scripts to append that to every call and filling up your file system.
I do know that in certain versions of 4.X, there were issues where this did not work as expected. The issues were addressed (I believe) in 4.2.5 and should be available and working from that point forward.
A little known fact of the P_TRACE parameter is that there are actually three settings available: YES, TRACE, and HPROF.
The first two basically do the same thing—turn on event 10046 tracing. However, if you use HPROF as the value of the parameter, APEX will use the Hierarchical Profiler.
There is also an instance level parameter HPROF_DIRECTORY that can be set by a DBA by calling apex_instance_admin.set_parameter.
At least this was the missing piece for me:
I suspected that internally Apex creates the .trc file by using
ALTER SESSION SET EVENTS '10046 trace name context forever, level xx';
Depending on how the Schema (that Apex is working with) has been created this priv is missing. I was able to let Oracle write a trc file by granting the schema the "alter session" priv...
grant alter session to apex_demo;
Hope that helps.
Best,
Jonas
Related
I'm having an issue with a prompt in OBIEE 10g, such that it displays old database value due to the prompt query being serviced from cursor cache (presentation service). For example, if the prompt drop-down shows 1 value initially since there is 1 database row and when i delete this row from database, the prompt still shows the same database value unless i manually delete the cursor cache through analytics
Setting > Administration > Manage sessions > clear cache/cursors
Tried checking OBIEE presentation service config file instanceconfig.xml, however there is no such parameter to permanently disable this cache. I referenced the following link, OBIEE 10G/11G - Presentation Service (Query|Result|Cursor) Cache
Resetting these parameters didn't seem to have any impact on the cursor cache, these are still getting generated and are not cleared after the timeouts set. (I have restarted the OBIEE services after changing these parameters). Am I missing something here.
Would appreciate any pointers to get this done i.e. getting cursor cache cleared/disabled without manual intervention as mentioned above (through Settings > Administration).
At some point I also faced that issue. The presentation cache in OBIEE is a bit shady sometimes.
What I did is to add some dummy comparison on the query of the prompt, involving sysdate with enough precision so it makes each query different to the cache.
It's a bit shabby, but at least you don't need any manual intervention... Maybe it can help you.
Good luck!
You may see this issue if using a Presentation variable as well, rather than a Prompt built using a SQL query.
The problem may be due to shared Presentation Services Query Cache, which means
that even when the user logs out, the query cursor cache is still being shared by other users, so it does not refresh the new data after the user logs in again.
The cache file is in
ORACLE_INSTANCE/tmp/OracleBIPresentationServices/coreapplication_obipsn/obis_temp
See this document for more detail.
You can configure the Virtual Private Database option in the repository
physical database object and mark session variables as Security Sensitive in
the repository to make the query cache not shared among users. See this
documentation for more detail.
I'm working on migrating some reports from Oracle Discoverer to OBIEE. I've already exported the layouts from discoverer to OBIEE. I have all I need in the OBIEE Admin tool now, but when I try to perform this operation:
I got this message:
I've read in many forums that this is because of the query (enter link description here) but I've executed the query in SQL Developer and all is fine.
Any idea?
Thanks,
I can see from the icon on your object that it is an Opaque View that your trying to run View Data on.
This is probably because of a syntax issue in your opaque view. Make sure the code in the opaque view doesn't end with a semi-colon or slash, that will cause problems. Try eliminating any blank lines, if there are any. However, without knowing exactly the syntax of the code it's impossible to say exactly what the cause is.
It's also possible that there is a connection script attached to the connection pool you are using to View Data, running on connection or before execution with bad syntax.
Otherwise have a look in the Admin Tool log to see if there's more information about what is causing the error. It will usually contain more detailed information than is passed back through the GUI.
Afternoon everyone,
I currently have a Oracle DB issue. I have Oracle Auditing on (AUDIT_TRAIL set to db). However the only information being captured is the System Events (log on, off).
From the Oracle 10g2 documenation (http://www.oracle-base.com/articles/10g/Auditing_10gR2.php) I notice that there are 3 audit options, however I cannot figure out how to turn the other 2 on.
Does anyone know how?
I don't know the answer to your question, but I know that the link you describe as "the Oracle documentation" is a third-party advice site. This is the Oracle 10g documentation. Specifically, here is the documentation on auditing. There you will find the answers you seek (at least I assume you will).
Is there a tool (that already comes with Oracle) for tracing SQLs that have been executed? In DB2 there is something called an 'event monitor' which I use to track the tables that have been updated. Is there an equivalent tool in Oracle?
I plan to
enable tracing
go on the website (that uses the db) and change an entry
disable tracing
see output file and record which table has been updated.
There is a table I am looking that should be updated when the entry is changed. I do not know what the name of the table is (and there are many tables), and so I need to trace the SQL executed to find out.
I have tried:
ALTER SESSION SET sql_trace = true;
-- go on website and change an entry
ALTER SESSION SET sql_trace = false;
tkprof the_trace_file.trc file.out EXPLAIN=system/manager SYS=no
However when following those steps above, no SQLs were recorded.
Is there a tool that Oracle provides? (I would like to avoid downloading external software)
There is a table I am looking that
should be updated when the entry is
changed. I do not know what the name
of the table is (and there are many
tables), and so I need to trace the
SQL executed to find out.
I'm thinking you are using the word "trace" here with another meaning than what is usually meant in the Oracle world.
You basically hit some button in the app, and by looking at what SQL queries are running, you want to find what table that code was referencing? Did I get it right?
In that case, you could have a look at v$sql, and look at columns SQL_TEXT and SQL_FULLTEXT.
The ALTER SESSION commands work at the session level (ie your current connection).
The website will use a different session (probably from a connection pool).
You can enable tracing for all sessions using the ALTER SYSTEM SET sql_trace = true;
The main reason you didn't get anything in the trace file is because you didn't do anything in the session where trace was enabled.
If you'd have done:
alter system set sql_trace = true;
-- fiddle around with the website
alter system set sql_trace = false;
You'd have gotten one or more trace files, one for each session which had activity while you were fiddling with the website.
The problem is that if the website uses connection pooling, your user activity may have been spread across several connections, and may be intermingled with other concurrent user activity.
Maybe Oracle Audit will help you.
Here is a good explanation: http://www.oracle-base.com/articles/10g/Auditing_10gR2.php
You have to enable audit by setting the parameter AUDIT_TRAIL.
That is at server level. You can audit at client level using a third party sql tracer for OCI:
http://sourceforge.net/projects/ocimonitor/
I find the Enterprise Manager the most useful tool for this. As has already been noted you have to alter the session that the web site is using and not your own. If you set your connection pool limit to 1 connection, you can easily find the session in the enterprise manager and then turn on the tracing. Usually a find the the top queries display in the enterprise manager tells me what queries are taking too long without having to trace anything.
I have an Access application with a SQL server back-end, mixed with quite a few DB objects local to the Access app. I've tried running SQL Profiler, but I got very little except a cryptic sp_execute 2,4288,4289,4290,4291,4292,4293,4294,4295,4296,4297.
I would like a trace tool that is local to the Access DB, so I also pick up any activity that doesn't go back to the SQL server.
As far as I know there is no such facility within Access but, depending on your case, you could try these few things:
Write a wrapper against SQL executables: that would mean replacing all calls to Execute, OpenRecordset etc within your VBA to an alternative version that would log the query.
This isn't going to catch everything obviously but it could help.
Move your local tables to another database and use ODBC to relink them to your original Access application. You can then use ODBC's logging facilities.
This could be the best altenative as it's fairly easy to setup for debugging.
It's not the best solution for a production environment though as all your calls to local tables will in fact go through ODBC, but again, it's a temporary solution for debugging.
Use ShowPlan and ISAMStats to view how Jet/ACE interprets your queries and get other database activity stats.
It's easy to setup by writing a key to the registry and you'll end-up with a log describing how your queries are analysed.
It's more useful for optimisation than logging but again, it could help.
Use Flextracer, a shareware, free for 30 days or so. My colleague here has just found this for us as we were going through a similar situation. Problem solved.
http://www.geardownload.com/development/flextracer-download.html
[]s,
Pedro Carneiro Jr.
pedrokarneiro#hotmail.com