BUG: Apex4/Anychart5 - memory leak?

Question

We are running into a pretty serious problem with resources. It seems that there is some kind of interaction between Apex and Anychart5 that is causing a pretty serious memory leak. For example, in one dashboard I am building, I have 9 charts on a page. When I click through a chart to a second page, I have three charts and an Interactive report.
None of the sql is really all that complex. But I will include one of the queries singled out by one of our DBAs as being involved in consuming over 20 GB of data (values slightly modified for security). The query:
SELECT CASE
WHEN quarter = 'Q1'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,1:'
WHEN quarter = 'Q2'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,2:'
WHEN quarter = 'Q3'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,3:'
WHEN quarter = 'Q4'
THEN
'/pls/apex/f?p=108:3:1111111111111111::::P3_YEAR1,P3_YEAR2,P3_CLICK_VAL,P3_QUARTER:2009,2008,2009,4:'
END
link,
quarter label,
so_ext_price Sales_2009
FROM ( SELECT SUM (v.so_ext_price) so_ext_price,
('Q' || TO_CHAR (v.cal_qtr_num)) quarter
FROM owner.materialized_view_mv@db_link_name v
WHERE v.cal_year = TO_CHAR (2009)
AND v.account_number IN
(SELECT *
FROM TABLE(user_pkg.get_customer_numbers (
'APP_USER',
'USER_PROPERTY',
'CUSTOMER_NAME'
-- THE ABOVE SUBQUERY SELECTS FROM A PIPELINE FUNCTION TO RETURN A LIST OF STRINGS
GROUP BY v.cal_qtr_num
ORDER BY v.cal_qtr_num)
As you would expect, this query returns 4 records reflecting sales by quarter. The query takes about four seconds to run. Explain plan cost is just under 14K. The pipeline function literally returns a single column of about six values using a simple select distinct where the parameters passed are filters in the where clause. The pipeline function returns in approximately 1 second. The largest result set it ever returns is six rows. The pipeline function is innocuous on its own but I am suspicious that it may be where we're running into issues. We weren't seeing these problems (or at least they weren't as noticeable) until we needed to use pipline functions. 'Don't use pipeline functions' is not an acceptable work around in our case. While I can figure out a way around it in the charts by returning SQL from a function, I cannot do so in the interactive reports.
What our DBAs found is that the code pasted below is what was sucking down 22 GB of ram, then after clicking through to the second page the same code (for a different chart query) was consuming 17 GB of ram almost depleting our 48 GB of ram on our server in less than ten minutes. I disabled the chart running each 'offending' query and we had the same results with a different chart but the same underlying code below.
I don't know where in Apex this lives but it's the killer. Can I get some feedback? Anyone else having similar issues?
declare
rc__ number;
simple_list__ owa_util.vc_arr;
complex_list__ owa_util.vc_arr;
begin
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('apex_util.flash') = false) or (owa_match.match_pattern(p_string =>
'apex_util.flash'
/* */,p_simple_pattern =>
simple_list__
,p_complex_pattern =>
complex_list__
,p_use_special_chars =>
false)))
then
rc__ := 2;
else
null;
null;
apex_util.flash(p=>:p,XMLCallDate=>:XMLCallDate);
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;
If we are barking up the wrong tree, I'd be VERY happy. I'd rather it was something I could fix.
Edited by: WannaRock on Aug 24, 2010 9:53 AM

Answer 1

Thanks for looking at this post. We have resolved the issue for ourselves by working with our DBAs to narrow down where the problem actually started. We found that the particular SQL we were looking at was not the issue. In a chart on a subsequent page (via a click through), we were actually running into where apex was starting to consuming memory but we were catching it later.
What we found was that when we had a chart query that was SQL containing a pipeline function, the memory usage went up. And within 10 minutes, the server would crawl to a halt. To release the memory, the DBAs would have to bounce the Apex instance. When I changed the query to be a function returning SQL, the problem stopped. I don't know what the correlation was between SQL and moving to a PL/SQL function returning SQL.
I am not even 100% positive of the pipeline function being the cause. I only know that this started happening about the same time as when I implemented the pipeline function. I understand you are leery of a one-second function/query running up that kind of utilization. No one here believed me either (including me really). We figured it HAD to be a coincidence. But once I changed the query from SQL to a function returning PL/SQL, our problem went away.
Thanks to all who looked at and thought about this.
Walter