DB links, Bind variables & APEX reports performance

Question

Hello,
So the problem is simply that I have two databases:
A : Has table T1
B : (APEX database)
I have an APEX report that simply does the following
Select col1, col2.. from A@dblink
This is abviously straighforward, however, I start having considrable performance issues if I have any filters applied to this query using APEX items ( bind variables) :
Select col1, col2.. from T1@dblink_A_B
where col1 > :PX_item
I ran the explain plan and noticed that using the bind variables forces the query to be done on database B, not A which is causing the performance issues.
I am sure that many of you ran into this issue before, but does anyone know how to resolve this issue ? I am thinking about using Pipelined functions, but am not sure if that will work well if I have a lot of records returned by the query or if this will resolve the issue at all.... your thoughts are appreciated..
Thanks,
Sam

Answer 1

I've always been able to work around my DB link issues in Apex. As suggested, driving_site hint should be tried. Oracle documentation on it isn't great, but I follow this:
- don't bother including other hints together with driving_site, as they get stripped out when your sql is passed to the remote DB (as per driving_site hint).
- if you have have subqueries - specifiy driving_site hint in that section of the SQL too. I don't have any proof that this is really required - but it doesnt hurt.
- include driving_site hint even if all tables are remote. Careful of refs to pseudo cols like sysdate, user etc. I think they are taken as local refs - not remote. I havent tested this properly to confirm.
- dumb down your test case to eliminate refs to sysdate, subqueries etc.
- remember that items are text, so you'd need to do to_number(), to_date() on them where appropriate on them in your SQL at the least.
Seeing as you control the content of your items, SQL injection is a reduced risk. Assuming that's not your top concern anyway, don't get carried away with the bind-variable vs literals debate. Apex does lots of nasty inefficient stuff like IR searches. I'd never use an IR in something that really needs to be scalable anyway. Soo... construct SQL with littlerals based on your items (assuming item refs are the cause of your issue).
region type=SQL Query (PL/SQL function body returning SQL query)
begin
  return 'SELECT /*+ DRIVING_SITE(a) */ a.empno,a.ename,a.job,a.mgr,a.loc
        FROM emp@MY_DBLNK A
       WHERE  a.empno = '||:P123_EMPNO||'
       ORDER BY 1,2,3';
end;Assuming your queries are expensive to execute (local or remote) and dont return too many records (else collection table can get really big), then caching the resultset in a collection gives you nice fast pagination, when using a PPR report. Keep a watch on the size of the collection table - truncate it manually if you accidentally populate it with a big cartesean product etc, else performance could degrade.
Do main query to populate collection before header. PPR pagination doesnt reload the page, so before-header process only runs once. In my case it works like:
-- reload button to re-load page, to force a query re-run. The html_Submit_Progress thing loads an 'busy processing' image.
<input type="button" value="Run query" onclick="javascript:this.disabled=true;this.value='Running...';html_Submit_Progress(this);"  id="SUBMIT"  />
-- On Load - before header process to populate collection (call in a regular region to see errors, until ironed out)
declare
  q varchar2(4000);
  v_t0   PLS_INTEGER := DBMS_UTILITY.get_time;
begin
   :P0_QSEC := '0';
  IF APEX_COLLECTION.COLLECTION_EXISTS(P_COLLECTION_NAME=> 'Q1')
  THEN
    APEX_COLLECTION.DELETE_COLLECTION(P_COLLECTION_NAME=>'Q1');
  END IF;
  if (:P0_DBLNK is not null) then
    q:= 'SELECT /*+ DRIVING_SITE(a) */ a.empno,a.ename,a.job,a.mgr,a.loc
        FROM emp@'||:P0_DBLNK||' a
       WHERE a.job like "M%"
        AND a.empno = #EMPNO#
       ORDER BY 1,2,3';
    q:= replace(q, '"', '''');
    q:= replace(q, '#EMPNO#', :P123_EMPNO);
    -- bulk
    APEX_COLLECTION.CREATE_COLLECTION_FROM_QUERY_B(
        P_COLLECTION_NAME => 'Q1',
        P_QUERY => Q);
   -- record count
   -- APEX_COLLECTION.collection_member_count
  end if;
  -- display in page footer or whatever
  :P0_QSEC := TO_CHAR ((DBMS_UTILITY.get_time - v_t0) / 100, '000.00') || ' sec';
exception
  when others then
  raise_application_error(-20501, :P0_DBLNK||'< br >'||sqlerrm||'< br >'||q );
end;
-- then PPR report is just like
Select C001, C002, C003, C004, C005
From apex_collections
Where collection_name = 'Q1'
order by seq_id;Edited by: maceyah on Sep 7, 2011 9:26 AM
Useful link on bind variables for CREATE_COLLECTION_FROM_QUERY_B ==> https://forums.oracle.com/forums/thread.jspa?threadID=2305634&tstart=0
Edited by: maceyah on Mar 2, 2012 3:18 PM