Using bind variables in additional pl/sql code

How do you retrieve the a bind variable in the addition pl/sql
code portion of the report wizard?
I try something like
declare
v_test varchar2(40);
begin
select lastname into v_test from wvgsemp
where username = :binduser;
htp.bold('Report generated by:
'||v_test);
end;
but it say PLS-00049: bad bind variable 'BINDUSER'
However this is exactly the way I declared it in step one
of the wizard?

Hi,
You cannot have bind variables in additional plsql code.
Thanks,
Sharmila

Similar Messages

ORA-01006 Using Bind Variables In A Dynamic SQL Contains Query

I have the following dynamic SQL query :-
declare
TYPE typ_sql IS REF CURSOR;
ltyp_sql typ_sql;
lv_sql VARCHAR2(100);
begin
lv_sql := 'SELECT arx_id FROM arx WHERE CONTAINS ';
lv_sql := lv_sql || (arx_full,''(:b1) WITHIN ui'') > 0';
open ltyp_sql FOR v_sql USING ln_id;
fetch ......
close ......
end;
When the code tries to open the cursor it gives the above error. I presume it is the way Oracle is expanding the bind variable but I cannot find anything in the docs to say why this is happening or whether you can do this or not using bind variables ( CONTAINS query ). Any help would be appreciated, thanks,
Stuart.

lv_sql || '(arx_full, :b1 || '' within ui'') > 0';

Using collections / Bind variables with a PL/SQL functio returning a query

I have this code, which is supposed to assign collection variables as column names
FOR i in 1 .. Collection_count -1
LOOP
SELECT c002 into :P341_M1 FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=i;
SELECT c002 into varholder FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=i;
vQuery:= vQuery || 'SUM(decode(label, ''Aware'', product_'|| i || ', ''Expert'', product_' || i || ', ''Proficient'', product_' || i || ', ''Advanced(Demo)'', product_' || i || ' )) as ';
vQuery:=vQuery || varholder || ', ' ;
END LOOP;
I've tried &P341_M1. , :P341_M1, ':P341_M1', varholder
When I try '&P341_M1' it returns the whole SUM(decode... line as the label
Basically Im having a hard time using bind variables with the PL/SQL returning a query...anybody?

Ok so working through this problem more I have realized that the problem is using the for loop i as an index value
This will get a value:
SELECT c002 into :P341_M1 FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=2;
But this won't
SELECT c002 into :P341_M1 FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=i;
I'm in the for loop, and use the i variable in other places within this loop...Is there a reason why I can't compare seq_id to i?
My new code as follows:
FOR i in 1 .. Collection_count -1 --apex_application.g_f01.COUNT - 1
LOOP
varholder:=i;
SELECT c002 into :P341_M1 FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=2;
SELECT c002 into varholder FROM APEX_collections WHERE collection_name = 'MA_SKILLS' AND seq_id=4;
vQuery:= vQuery || 'SUM(decode(label, ''Aware'', product_'|| i || ', ''Expert'', product_' || i || ', ''Proficient'', product_' || i || ', ''Advanced(Demo)'', product_' || i || ' )) as f';
vQuery:=vQuery || :P341_M1 ||i||', ' ;
END LOOP;

How to use bind variables in this procedure

Hi Experts,
How to use bind variables in this procedure for static queries.
PROCEDURE DELETE_MER_PROC (M_id IN NUMBER)
IS
BEGIN
V_date DATE;
SELECT PD_DATE INTO v_date FROM PD_MAINTAIN;
    DELETE FROM MER_CLEAR
    WHERE MER_DT < v_date
    AND ID = M_ID;
COMMIT;
END;
How to use v_date and m_id as bind variables in this procedure to avoid hard parsing.
Please help me.
Thanks.

976208 wrote:
How to use v_date and m_id as bind variables in this procedure to avoid hard parsing.
You cannot avoid hard parsing - as the 1st time a SQL statement (like the SELECT or DELETE statements in your code) is encountered, it does not reside in the server's Shared Pool, and needs to be added into the pool via a hard parse.
Bind variables does not prevent hard parsing. Hard parsing happens when the SQL statement (with or without bind variables) is a brand new statement encountered by the server.
Bind variables enables the same SQL cursor to be reused, by simply changing the bind variable value.
Not using bind variables means that each SQL statement is unique and not shareable - as the value is hardcoded into the statement and cannot be changed via a bind value. This typically means LOTS of different SQL statements (where the only difference is the changed value in the statement) are created - with each statement being a new statement not seen before in the Shared Pool and needing to be hard parsed.
One does not design one's code not to be hard parsed. There ALWAYS will be a hard parse in order to get a SQL statement into the Shared Pool. One designs one's code to REUSE cursors in the Shared Pool.

How to use bind variables in desc flexfields in OA pages?

Use case: In EBS 11i we have a DFF on po_vendors and one of the segment has a table validated value set that is referencing a forms variable i.e :VENDORS.VENDOR_ID. Now after upgrading to R12 this won't work as the vendor pages moved to OA framework. Is there any way to reference the vendor_id column in OA framework?

976208 wrote:
How to use v_date and m_id as bind variables in this procedure to avoid hard parsing.
You cannot avoid hard parsing - as the 1st time a SQL statement (like the SELECT or DELETE statements in your code) is encountered, it does not reside in the server's Shared Pool, and needs to be added into the pool via a hard parse.
Bind variables does not prevent hard parsing. Hard parsing happens when the SQL statement (with or without bind variables) is a brand new statement encountered by the server.
Bind variables enables the same SQL cursor to be reused, by simply changing the bind variable value.
Not using bind variables means that each SQL statement is unique and not shareable - as the value is hardcoded into the statement and cannot be changed via a bind value. This typically means LOTS of different SQL statements (where the only difference is the changed value in the statement) are created - with each statement being a new statement not seen before in the Shared Pool and needing to be hard parsed.
One does not design one's code not to be hard parsed. There ALWAYS will be a hard parse in order to get a SQL statement into the Shared Pool. One designs one's code to REUSE cursors in the Shared Pool.

Using Bind variables in SQL PLUS Report

using Bind variables in SQL PLUS Report. This report gets the arguments from the application concurrent program. Now my need is to convert the start_date and end_date to bind Variables to improve the performance. I have commented the original code in 'prompt List of Unapproved Adjustments' and used my Bind Variable but it is giving an error
error: Bind Variable "ENDING_DATE" not declared
Report Date and Time:
26-OCT-2010 15:44:13
List of Unapproved Adjustments
Bind Variable 'ENDING_DATE" not declared
Please see below the code for the sql plus report:
define p_org_id = '&1'
define p_fy_begin_date = '&2'
define p_start_date = '&3'
define p_end_date = '&4'
define p_conversion = '&5'
declare
variable begin_date date;
exec :begin_date := p_start_date;
variable ending_date date;
exec :ending_date := p_end_date;
/* Begin
:begin_date := to_date('&p_start_date','YYYY/MM/DD HH24:MI:SS');
:ending_date := to_date('&p_end_date','YYYY/MM/DD HH24:MI:SS');
End; */
set newpage none
set termout off
set pagesize 55
set linesize 180
set heading on
set feedback off
set wrap off
set space 1
set heading on
begin
dbms_application_info.set_client_info('&p_org_id');
end;
prompt
prompt Report Date and Time:
prompt ----------------------
select to_char(sysdate,'DD-MON-YYYY HH24:MI:SS')
from dual ;
prompt
prompt List of Unapproved Adjustments
prompt -------------------------------
select b.trx_number,
a.adjustment_number,
f.user_name created_by
from apps.ar_adjustments a,
apps.ra_customer_trx b,
apps.fnd_user f
where a.customer_trx_id = b.customer_trx_id
and a.status <> 'A'
and a.created_by = f.user_id
and a.creation_date between :begin_date
and :ending_date
-- and a.creation_Date between to_date('&p_start_date','YYYY/MM/DD HH24:MI:SS')
-- and to_date('&p_end_date','YYYY/MM/DD HH24:MI:SS')
order by
b.trx_number ;

Hi
Please go to customization part of the report and verify..You have set a default value out there ..And also verify your lov and look at the values ..If it is again giving you the problem ..pl delete the report and develop it again from the scratch it will be solved...
vishnu
null

Using bind variables with sql statements

We connect from a VB 6.0 program via OO4O to an Oracle 8.1.7 database, using bind variables in connection with select statements. Running ok, but performance again by using bind vars not as good as expected!
When looking into the table v$sqlarea, we were able to detect the reason. We expected that our program submits the sql statement with bind vars, Oracle parses this once, and with each select statement again, we do not have a reparse. But: It seems that with each new session Oracle reparses the sql statement, that is, Oracle is not able to memorize or cache bind vars and statements. Even more worrying, this kind of behaviour was visible with each new dynaset, but the same database/session.
Is there anybody our there with an idea of what is happening here?
Code snippet:
Dim OraSession As OracleInProcServer.OraSessionClass
Dim OraDatabase As OracleInProcServer.OraDatabase
Set OraSession = CreateObject("OracleInProcServer.XOraSession")
Set OraDatabase = OraSession.OpenDatabase(my database", "my connect", 0&)
OraDatabase.Parameters.Add "my_bind", 0, ORAPARM_INPUT
OraDatabase.Parameters("my_bind").DynasetOption = ORADYN_NOCACHE
OraDatabase.Parameters("my_bind").serverType = ORATYPE_NUMBER ' Bind Var Type
Dim RS As OracleInProcServer.OraDynaset
strSQLstatement= "Select * from my_table where igz= [my_bind] "
Set RS = OraDatabase.CreateDynaset(strSQLstatement, &H4)
OraDatabase.Parameters("my_bind").Value = myValue
RS.Refresh
Cheers and thanks a lot :)
Michael Sonntag

We connect from a VB 6.0 program via OO4O to an Oracle 8.1.7 database, using bind variables in connection with select statements. Running ok, but performance again by using bind vars not as good as expected!
When looking into the table v$sqlarea, we were able to detect the reason. We expected that our program submits the sql statement with bind vars, Oracle parses this once, and with each select statement again, we do not have a reparse. But: It seems that with each new session Oracle reparses the sql statement, that is, Oracle is not able to memorize or cache bind vars and statements. Even more worrying, this kind of behaviour was visible with each new dynaset, but the same database/session.
Is there anybody our there with an idea of what is happening here?
Code snippet:
Dim OraSession As OracleInProcServer.OraSessionClass
Dim OraDatabase As OracleInProcServer.OraDatabase
Set OraSession = CreateObject("OracleInProcServer.XOraSession")
Set OraDatabase = OraSession.OpenDatabase(my database", "my connect", 0&)
OraDatabase.Parameters.Add "my_bind", 0, ORAPARM_INPUT
OraDatabase.Parameters("my_bind").DynasetOption = ORADYN_NOCACHE
OraDatabase.Parameters("my_bind").serverType = ORATYPE_NUMBER ' Bind Var Type
Dim RS As OracleInProcServer.OraDynaset
strSQLstatement= "Select * from my_table where igz= [my_bind] "
Set RS = OraDatabase.CreateDynaset(strSQLstatement, &H4)
OraDatabase.Parameters("my_bind").Value = myValue
RS.Refresh
Cheers and thanks a lot :)
Michael Sonntag

PL SQL using bind variables

I am very much new to PL/SQL to pardon my neivte.
I would like to have some PL/SQL code that uses
bind variables for insert statements and than issue
commit's after a specific number of inserts.
For example.
desc xxx.taba
a number
b varchar2(20)
I want to do someting like this:
declare
l_start number default dbms_utility.get_time;
create or replace procedure insert_xxx(commit in number)
begin
for i in 1 .. 1000
loop
:a:=i;
:b:=dbms_random.string('P', 20);
intert into xxx :a :b;
if i/mod=(number passed into to proc)
commit
end loop;
dbms_output.put_line
(round((dbms_utility.get_time-l_start)/100, 2) ||
' Seconds...' );
end;
end;
Can somebody help me out with the correct syntax
as I know it's incorrect.

A few remarks
- procedures don't have hidden variables defined in the outside world, as procedures are black boxes, which communicate only with the outside world
using the actual parameter list
- procedures don't commit. The caller should always commit!!!
- procedures don't commit every <n> records. A commit finalizes a logical unit of work, not a technical one.
If I would have been your supervisor and you would have presented this code, I would have fired you on the spot.
Committing inside a loop also increases the likelihood of ora-1555 errors.
So: remove the current parameter
a and b should be formal parameters of the procedure
Inside the procedure it should read
insert into xxx values (a, b)
Sybrand Bakker
Senior Oracle DBA

ORA-01722: invalid number caused with SQL using bind variable

Hi,
Im am hoping that someone can help me resolve a problem thats only just services and is being experienced on quite a few clients.
our application uses C++ exes and makes OCI calls to the database.
what has happened in the last week or so, there has been quite a few invalid number errors being received on a prod server but strangly enough we cannot reproduct the error on our UAT system.
The sql is using bind variables and the information in the trace file shows that a number is being used for the bind variable, here is an extract from one trace file:
for some schemas, the bind variable value is some currupted value, i think:
oacdty=01 mxl=32(21) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=9a8d62b8 bln=32 avl=03 flg=05
value="Â*d"
but on another schema, the value used is:
Bind#0
oacdty=01 mxl=32(32) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=c5f92718 bln=32 avl=04 flg=05
value="2101"
however both produce invalid number errors.
I am relatively inexperienced as a DBA so would appreciate as much help as i can get.

Could you post your sql statement that is being run.
Also post the query plan from your uat system and the one from your production system (They are likely to be different)
You can export the stats from your production system and run them in your uat system. If you do this, then the execution plans should be the same on both systems(dbms_stats) and if you have the same data you should run into the same problem on uat as in production.
The root cause of this type of problem is having a column in a table which holds values which are of different datatypes. Typically there is a condition in the where clause which indicates that for example only numeric columns should be retrieved from the column which holds multiple data types. However since the optimizer is free to rewrite the query any way it sees fit, (It does not necessarily execute in the order the sql statement is written) it does not filter this data first, and therefore you hit non-numeric data and run into the invalid number error.
You can use little techniques like using an inline view with rownum in the column list, to perform the first filter. This ensures that the inline view is executed on its own, rather than being merged (materialized) with the rest of the query.
A quick temporary solution is to use a comparison like to_char(column_name) = variable
Make sure your comparisons are correct and it doesn't negatively impact on performance of the query

How to obtain SQL that don't use bind variables

Hi,
I'm trying to identify the SQL that should benefit from using bind variables.
First, I tried to obtain the common signature from all those sql calls, by using:
select * from (
select force_matching_signature, count(1) from v$sql where force_matching_signature<>0 group by force_matching_signature order by 2 desc
) where rownum < 50;Then, I copied those values to clipboard and executed: select sql_text from v$sql where force_matching_signature=<<<copied_signature_value>>>;Now I want to make it automatically, and get just 1 occurrence of each SQL that is similar to others by using a query.
I've tried this:
select sql_text from
select sql_text, force_matching_signature, row_number() over (partition by force_matching_signature order by sql_text desc)rn from v$sql where force_matching_signature <>0
)where rn <2 and rownum < 10 order by force_matching_signature descBut this is not returning results by attending to the count(1) of the first query I used. How can I modify this so I get the results in order of 'importance'?
Thanks

And I said. First use order by, then use rownum. I didn't mention row_number. Also there should be no need to add any more columns.
Did you try it? Why didn't it work?
untested example
select * from (
   select sql_text from (select sql_text, force_matching_signature, row_number() over (partition by force_matching_signature order by sql_text desc) rn from v$sql where force_matching_signature != 0)
   where rn = 1
   order by force_matching_signature desc /* add any ordering you like here */
where rownum < 10 /* then filter on the first 10 results */If you want to order it in such a way that the statement that is found most times comes first then say so. However I do not see how to group in your case.
maybe like this
tested example
select * from (
   select cnt, sql_text
   from (select sql_text, force_matching_signature, row_number() over (partition by force_matching_signature order by sql_text desc) rn , count(*) over (partition by force_matching_signature) cnt
         from v$sql
         where force_matching_signature != 0)
   where rn = 1
   order by cnt desc, force_matching_signature desc /* add any ordering you like here */
where rownum < 10 /* then filter on the first 10 results */
;Edited by: Sven W. on Oct 11, 2012 2:49 PM
Edited by: Sven W. on Oct 11, 2012 2:51 PM
Edited by: Sven W. on Oct 11, 2012 2:56 PM -- added count column to the output

Correct Way to use Bind variables when using an MS SQL server backend

Hey,
I'm having some trouble figuring out how to use bind variables in a view when using an MS SQL server backend. For some reason when I'm using an ApplicationModule that has a MS SQL Server JDBC library loaded and I attempt to click OK when editing the following query:
SELECT kit_status, component_id
FROM numbered_inv
WHERE trialname = :1
I get an error stating that "SQL Query Error Message Incorrect Syntax near ':'". Is JDeveloper compatible with SQL server for bind variables because this query runs just fine if I replace the :1 with a say "Testing testing".
Thanks in advance
Edited by: NullCheck on Dec 15, 2010 2:06 PM

Gotcha. I had tried %1% %0% ?0 and ?1 and various other permutations none of which worked. Got it working by setting the query to:
SELECT kit_status, component_id
FROM numbered_inv
WHERE trialname = ?
ORDER BY kit_status
And then adding a bind variable with "Bind position" set to 0.
Thanks again Shay!

Report Using Bind Variables

Hey Everyone,
I'm having a bit of trouble creating a report. I need the FROM part of the code to use bind variables. I have come up with this peice of code below but im getting the following error:
failed to parse SQL query:
ORA-06550: line 1, column 8:
PLS-00103: Encountered the symbol "" when expecting one of the following:
begin function package pragma procedure subtype type use
form
current cursor
The symbol "" was ignored.
ORA-06550: line 2, column 24:
PLS-00103: Encountered the symbol "" when expecting one of the following:
begin function package pragma procedure subtype type use
form
current
Can anyone see where im going wrong?
Thanks in advance,
-N.S.N.O.
Code*
DECLARE
x VARCHAR2 (4000);
BEGIN
x := x || 'select *';
x := x || 'from ';
x := x || :p13_schema;
x := x || '.ddl_log@';
x := x || :p13_db_name;
x := x || '_DBAAPEX.TNTEWW.COM';
RETURN (x);
END;

Hey Roel and Daylocks,
After getting frustrated for a while i deleted the page and started again. I put in the exact same code and it worked just how i wanted in the first place :S
The only thing i did different is when i was creating the report region the first time around i used a normal SQL query, For Example:
select sysdate from dual;
Then i modified it to
DECLARE
x VARCHAR2 (4000);
BEGIN
x := x || 'select ';*
x := x || 'from ';
x := x || :p14_schema;
x := x || '.ddl_log@';
x := x || :p14_db_name;
x := x || '_DBAAPEX.TNTEWW.COM';
RETURN (x);
END;
Whereas on the second attempt i used the peice of code in question straight away. Its been a bit of a frustrating morning because i used a similar peice of code for a different application, nevermind tho :)
Thanks for your replys, much appreciated.
-N.S.N.O.

Query don't use the right index when using bind variables

Hi people !
I need some help because I have an issue with a query that don t use the right Indexes as it should
First of all, I have mainly three tables :
ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
with quantity of packages prepared for each product (approximately 10 000 000 Records)
PRODUCT : Tables that contains the products (approximately 50 000 Records)
When I launch the query with hard coded values, it brings back response very fast
because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
(with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
Here is the correct explain plan when I execute the query with hard coded values :
SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = 'ADIDAS'
AND PRODUCT.CODE = 1234
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
4 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
4 TABLE ACCESS BY INDEX ROWID ORDER
777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
Now the problem is when the query is used in a Cursor with bind variables.
It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
to actually filter on a short period of time (only one day).
So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
Here is the bad explain plan :
Rows Row Source Operation
1 SORT AGGREGATE
2 NESTED LOOPS
722 NESTED LOOPS
2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
2 TABLE ACCESS BY INDEX ROWID ORDER
1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
Now I have found two solutions to this problem :
1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
For example :
QUERY :=
'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
FROM ORDER_MVTS, PRODUCT, ORDER
WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
AND ORDER.CUSTOMER_CODE = :CUSTOMER
AND PRODUCT.CODE = :CODE ';
These two solutions work but Number 1 is bad in theory because it uses a Hint
and Number 2 may be difficult to code.
So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
Thank you very much for support
Edited by: remaï on Apr 1, 2009 4:08 PM

What version of oracle you have? CBO work is different in 9i and 10g.
Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
(As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
Edited by: JustasVred on Apr 1, 2009 10:10 AM

Using BIND VARIABLES in REF CURSOR(s)

Hello I am having trouble making my pl/sql program work using bind variables.
here is a little snipit from my code:
declare
type ref_type is REF CURSOR;
ref_cursor ref_type;
summation_table varchar2(4000);
begin
summation_table := 'table_sum tsum';
open ref_cursor for
select * from :summation_table
where tsum.revenue = 1000
USING summation_table;
end;
The Error that I get is
"bad bind variable 'summation_table'"
could someone please help? I think the way 'tsum' is used could be a problem, but I don't know.

SQL> CREATE TABLE TABLE_SUM(REVENUE NUMBER(10),
2                         OTHER   NUMBER(10));
Table created.
SQL> INSERT INTO TABLE_SUM VALUES(1000,1);
1 row created.
SQL> INSERT INTO TABLE_SUM VALUES(1000,2);
1 row created.
SQL> variable alpha refcursor
SQL> INSERT INTO TABLE_SUM VALUES(2000,3);
1 row created.
SQL> DECLARE
2     summation_table varchar2(30) := 'table_sum tsum';
3     PROCEDURE MYTEST(p_out out sys_refcursor)
4     IS
5     BEGIN
6       OPEN p_out for 'select * from '||summation_table||
7                      ' where tsum.revenue = :val' using 1000;
8     END;
9 BEGIN
10     MYTEST(:alpha);
11 END;
12 /
PL/SQL procedure successfully completed.
SQL> print alpha
   REVENUE      OTHER
      1000          1
      1000          2
SQL>

Query taking too long when using bind variable

Hi All,
There is a query in our prod DB which runs very slow (approx 2 hours) when it uses Bind Variables (using JDBC thin client), and when i try passing the variable using TOAD/SQL developer it runs fine.
Explain Plan for running Query
SELECT STATEMENT ALL_ROWSCost: 146 Bytes: 379 Cardinality: 1
     21 SORT ORDER BY Cost: 146 Bytes: 379 Cardinality: 1
          20 NESTED LOOPS Cost: 145 Bytes: 379 Cardinality: 1
               17 HASH JOIN Cost: 22 Bytes: 42,558 Cardinality: 123
                    15 MERGE JOIN CARTESIAN Cost: 15 Bytes: 8,910 Cardinality: 27
                         12 FILTER
                              11 NESTED LOOPS OUTER Cost: 9 Bytes: 316 Cardinality: 1
                                   8 NESTED LOOPS OUTER Cost: 8 Bytes: 290 Cardinality: 1
                                        5 NESTED LOOPS Cost: 6 Bytes: 256 Cardinality: 1
                                             2 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 4 Bytes: 28 Cardinality: 1 Partition #: 9 Partition access computed by row location
                                                  1 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 3 Cardinality: 1
                                             4 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 228 Cardinality: 1
                                                  3 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1
                                        7 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 2 Bytes: 34 Cardinality: 1
                                             6 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 1 Cardinality: 1
                                   10 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 1 Bytes: 26 Cardinality: 1
                                        9 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 0 Cardinality: 1
                         14 BUFFER SORT Cost: 14 Bytes: 448 Cardinality: 32
                              13 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 6 Bytes: 448 Cardinality: 32
                    16 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144
               19 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1 Bytes: 33 Cardinality: 1
                    18 INDEX UNIQUE SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 0 Cardinality: 1
Explain Plan for Slow Query
Plan
SELECT STATEMENT ALL_ROWSCost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728
     21 SORT ORDER BY Cost: 11,526,226 Bytes: 119,281,912 Cardinality: 314,728
          20 HASH JOIN Cost: 11,510,350 Bytes: 119,281,912 Cardinality: 314,728
               2 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_PORTFOLIOS Cost: 1,741 Bytes: 177,540 Cardinality: 5,380
                    1 INDEX FULL SCAN INDEX (UNIQUE) GDP.PORTFOLIOS_KEY Cost: 14 Cardinality: 5,380
               19 HASH JOIN Cost: 11,507,479 Bytes: 87,932,495,360 Cardinality: 254,140,160
                    3 TABLE ACCESS FULL TABLE GDP.GDP_AREAS Cost: 6 Bytes: 2,304 Cardinality: 144
                    18 MERGE JOIN CARTESIAN Cost: 11,506,343 Bytes: 18,602,733,930 Cardinality: 56,371,921
                         15 FILTER
                              14 HASH JOIN RIGHT OUTER Cost: 3,930,405 Bytes: 556,672,868 Cardinality: 1,761,623
                                   5 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_COUNTERPARTIES Cost: 6,763 Bytes: 892,580 Cardinality: 34,330
                                        4 INDEX FULL SCAN INDEX (UNIQUE) GDP.PK_CPTY Cost: 63 Cardinality: 34,330
                                   13 HASH JOIN OUTER Cost: 3,923,634 Bytes: 510,870,670 Cardinality: 1,761,623
                                        10 HASH JOIN Cost: 2,096,894 Bytes: 450,975,488 Cardinality: 1,761,623
                                             7 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE GDP.GDP_FX_DEALS_INCREMENTOR Cost: 2,763 Bytes: 52,083,248 Cardinality: 1,860,116 Partition #: 14 Partition access computed by row location
                                                  6 INDEX RANGE SCAN INDEX GDP.GDP_FX_DEALS_INC_IDX_01 Cost: 480 Cardinality: 334,821
                                             9 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,734,205 Bytes: 8,320,076,820 Cardinality: 36,491,565
                                                  8 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838
                                        12 TABLE ACCESS BY INDEX ROWID TABLE GDP.GDP_FX_DEALS Cost: 1,733,836 Bytes: 1,331,145,696 Cardinality: 39,151,344
                                             11 INDEX FULL SCAN INDEX (UNIQUE) GDP.GDP_FX_DEALS_KEY Cost: 104,335 Cardinality: 39,200,838
                         17 BUFFER SORT Cost: 11,499,580 Bytes: 448 Cardinality: 32
                              16 TABLE ACCESS FULL TABLE GDP.GDP_CITIES Cost: 4 Bytes: 448 Cardinality: 32
How can I avoid that.
Thanks

Hello
Could you reformat your execution plans because they aren't particularly readable. The forums allow you to preserve the formatting of code or output by putting the symbol {noformat}{noformat} before and after the section of text you want to preserve formatting for.
If you write
{noformat}select * from v$version
{noformat}
it will be displayed asselect * from v$version
So can you run this above statement and post the output here so we know the full oracle version you are working with? And finally, it would be really helpful to see the query you are running. When you say it runs fine in Toad, is that when you replace the bind variables with the values or are you also using bind variables in Toad?
Cheers
David

Using bind variables in additional pl/sql code

Similar Messages

Maybe you are looking for