Performance help please!

Question

We have a problem with performance on production. As a lowly developer, I don't have much access to live but I do have a workspace separate to LIVE in which I've run some stats to try and ascertain the issue.
Running the following:
SELECT * FROM
(SELECT
sql_fulltext,
sql_id,
child_number,
disk_reads,
executions,
first_load_time,
last_load_time,
elapsed_time
FROM v$sql
ORDER BY elapsed_time DESC)
WHERE ROWNUM < 10
In a report region provides me with the top contender of:
declare rc__ number; start_time__ binary_integer; simple_list__ owa_util.vc_arr; complex_list__ owa_util.vc_arr; begin start_time__ := dbms_utility.get_time; owa.init_cgi_env(:n__,:nm__,:v__); htp.HTBUF_LEN := 63; null; null; simple_list__(1) := 'sys.%'; simple_list__(2) := 'dbms\_%'; simple_list__(3) := 'utl\_%'; simple_list__(4) := 'owa\_%'; simple_list__(5) := 'owa.%'; simple_list__(6) := 'htp.%'; simple_list__(7) := 'htf.%'; simple_list__(8) := 'wpg_docload.%'; if ((wwv_flow_epg_include_modules.authorize('f') = false) or (owa_match.match_pattern('f', simple_list__, complex_list__, true))) then rc__ := 2; else null; null; f(p=>:p); if (wpg_docload.is_file_download) then rc__ := 1; wpg_docload.get_download_file(:doc_info); null; null; null; commit; else rc__ := 0; null; null; null; commit; owa.get_page(:data__,:ndata__); end if; end if; :rc__ := rc__; :db_proc_time__ := dbms_utility.get_time - start_time__; end;
the above being the top culprit with 1,510,683 disk reads and 11,402 executions. I've looked in the forum and this looks like known behaviour when workspace references are used for image/JavaScript issues. We have none of these - they are all hard coded to the /i/ path on the app server.
Can someone please point me in the right direction to try and resolve this please? This is on Apex 3.2.1 on a Windows 10.2.0.1.0 Database. The DBA recently changed db_file_multiblock_read_count from 16 to 0 so the db would calculate the best value which has modified this to 128. He assures us this will not be the issue.
Thanks very much in advance!
Phil
Update: db_file_multiblock_read_count changed back to 16 again (without reboot)... so far no difference
Edited by: Phil UK on Nov 25, 2009 4:48 PM

Answer 1

The same SQL is shown when these are ordered afraid (ordered desc) and the results are here
Several aspects of the app have suddenly started taking 6 minutes which originally were executed in seconds. The majority seems to be working OK so it looks like the optimizer has changed the way the SQL is being parsed which is having a detrimental effect on performance. I may be barking up the wrong tree, but the thing that concerns me is that this SQL is part of Apex, not our app schema.
Thanks for looking into it for us
Phil