Sdo_geometry bind variables in trace file

If I run trace on oracle spatial queries, how can I get the detailed information of the sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
Thanks!

Hi Rob
Haven't checked the bind variable issue specifically here, but just a by-pass-reflex-of-fixed-implementations, have you tried passing the geometry as WKT?
Obviously, this can also have some constraints on the varchar2 length etc, but depending on the type of geometries (and consequent length of the WKT) it might help you working around it.
Check this section for the appropriate sdo_geometry constructor based on a WKT input.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14255/sdo_objrelschema.htm#CBBFGHAE
Just a thought
Luc

Similar Messages

Memory Dump for Bind Variable included in 10046 trace file

A curious thing I've seen today. While looking through an extended Oracle Trace file, I see the following:
=====================
PARSING IN CURSOR #26 len=88 dep=0 uid=28 oct=6 lid=28 tim=2667421262 hv=3259943383 ad='4bbb4ad8'
UPDATE V_QRTZ_TRIGGERS SET JOB_DATA = :1 WHERE TRIGGER_NAME = :2 AND TRIGGER_GROUP = :3
END OF STMT
PARSE #26:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2667421260
BINDS #26:
bind 0: dty=113 mxl=3876(3876) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=3876 offset=0
bfp=0cd99aa4 bln=3876 avl=86 flg=05
value=
Dump of memory from 0x0CD99AA4 to 0x0CD99AFA
*CD99AA0 01005400 00002C01 00000100 [.T...,......]*
*CD99AB0 00000100 EB23EF03 581D0000 571D0000 [......#....X...W]*
*CD99AC0 0F000F00 00000000 0F005920 0E14E12F [........ Y../...]*
*CD99AD0 CDE21ADA 00000000 737E06D9 0400FB09 [..........~s....]*
*CD99AE0 07000F00 800387E6 A17B3F20 0000000E [........ ?{.....]*
*CD99AF0 571D0000 EE56CF00 00001500 [...W..V.....]*
bind 1: dty=1 mxl=128(45) mal=00 scl=00 pre=00 oacflg=03 oacfl2=10 size=256 offset=0
bfp=0cd99984 bln=128 avl=15 flg=05
value="EC-MHM Retrieve"
bind 2: dty=1 mxl=128(96) mal=00 scl=00 pre=00 oacflg=03 oacfl2=10 size=0 offset=128
bfp=0cd99a04 bln=128 avl=32 flg=01
value="2BBDE87AF15D4B5E867AB6482D7D58C8"
BINDS #9:
bind 0: dty=1 mxl=32(18) mal=00 scl=00 pre=00 oacflg=03 oacfl2=1 size=192 offset=0
bfp=0c2de90c bln=32 avl=18 flg=05
value="EC_SCHEDULE_PIN_TO"
bind 1: dty=1 mxl=128(15) mal=00 scl=00 pre=00 oacflg=13 oacfl2=1 size=0 offset=32
bfp=0c2de92c bln=128 avl=15 flg=01
value="EC-MHM Retrieve"
bind 2: dty=1 mxl=32(32) mal=00 scl=00 pre=00 oacflg=13 oacfl2=1 size=0 offset=160
bfp=0c2de9ac bln=32 avl=32 flg=01
value="2BBDE87AF15D4B5E867AB6482D7D58C8"
EXEC #9:c=15625,e=1060,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=2667424863
FETCH #9:c=0,e=95,p=0,cr=4,cu=0,mis=0,r=1,dep=1,og=1,tim=2667425091
FETCH #9:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=0,tim=2667425236
Is this normal and is it caused by size of Bind Variable?
Kind regards,
TRONd

It's normal and and happens due to bind variable datatype. In your case this is blob, (there are a couple of other datatypes - timestamp among other) which will be represented that way in the trace file.
Best regards
Maxim

Trace files showing bind variables value=""

10g on solaris
Hi All,
We have an issue with an informatica workflow issuing an update statment to Oracle in trems of performace.
I switched the tracing on using DBMS_SUPPORT with binds set to TRUE. It has captured the trace files accordingly against a controlled set of data. Twot trace files were produced.
The first trace files shows the SELECT statment being issues that identifies the records that will be updated.
The 2nd trace file shows the actual UPDATE statment being issued as a PL/SQL loop to do the update.
There were 20 records that the users have rigged to updated and the update statment shows 20 cases where updates took place. All updates took place succesfully after checking the post results. However my issue is why the trace files are showing the bind vaules as being set to ""?..any ideas appreciated!
an extract of the trace file...
PARSING IN CURSOR #1 len=123 dep=0 uid=1482 oct=6 lid=1482 tim=994827916280 hv=3649357857 ad='8b5b98f0'
UPDATE /*+ index(FCT_TASK IDX_FCT_TASK_CASE_SBL_ROW_ID)*/ FCT_TASK SET DWH_LAST_UPD_DT = SYSDATE WHERE CASE_SBL_ROW_ID = :1
END OF STMT
PARSE #1:c=10000,e=980,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=994827916264
=====================
PARSING IN CURSOR #5 len=227 dep=1 uid=0 oct=3 lid=0 tim=994827919231 hv=2190775527 ad='8e622670'
select u.name,o.name, t.update$, t.insert$, t.delete$, t.enabled from obj$ o,user$ u,trigger$ t where t.baseobject=:1 and t.obj#=o.obj# and o.owner#=u.user# and bitand(property,16)=0 and bitand(property,8
)=0 order by o.obj#
END OF STMT
PARSE #5:c=0,e=1310,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=994827919223
BINDS #5:
bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0001 size=24 offset=0
bfp=ffffffff7c058d98 bln=22 avl=04 flg=05
value=425212
EXEC #5:c=10000,e=9476,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=994827928883
FETCH #5:c=0,e=104,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=994827929051
STAT #5 id=1 cnt=0 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=1 pr=0 pw=0 time=172 us)'
STAT #5 id=2 cnt=0 pid=1 pos=1 obj=0 op='NESTED LOOPS (cr=1 pr=0 pw=0 time=110 us)'
STAT #5 id=3 cnt=0 pid=2 pos=1 obj=0 op='NESTED LOOPS (cr=1 pr=0 pw=0 time=105 us)'
STAT #5 id=4 cnt=0 pid=3 pos=1 obj=79 op='TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=1 pr=0 pw=0 time=103 us)'
STAT #5 id=5 cnt=0 pid=4 pos=1 obj=123 op='INDEX RANGE SCAN I_TRIGGER1 (cr=1 pr=0 pw=0 time=78 us)'
STAT #5 id=6 cnt=0 pid=3 pos=2 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)'
STAT #5 id=7 cnt=0 pid=6 pos=1 obj=36 op='INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)'
STAT #5 id=8 cnt=0 pid=2 pos=2 obj=22 op='TABLE ACCESS CLUSTER USER$ (cr=0 pr=0 pw=0 time=0 us)'
STAT #5 id=9 cnt=0 pid=8 pos=1 obj=11 op='INDEX UNIQUE SCAN I_USER# (cr=0 pr=0 pw=0 time=0 us)'
BINDS #1:
bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
value=""
EXEC #1:c=8390000,e=8740989,p=55593,cr=55610,cu=3,mis=1,r=1,dep=0,og=1,tim=994836657483
BINDS #1:
bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
value=""
EXEC #1:c=7980000,e=7962369,p=55591,cr=55608,cu=1,mis=0,r=1,dep=0,og=1,tim=994844621479
BINDS #1:
bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
value=""
ect ect ect...
Regards
Satnam

spliffer wrote:
Having investigated on the comment of NVARCHAR2 not allowing bind variables to be displayed in the trace file... I checked the datatype of the table/column being used in the index and its is defined as VARCHAR2(15)... ? so Im still not sure as to why we are still getting this.. could it be to do with the clinet application and the way in which it passes the bind vlaues to the oracle update statment?
any ideas appreciated?
regards
SatnamHere is a very brief demonstration.
The script:
VARIABLE V1 VARCHAR2
VARIABLE V2 NVARCHAR2
EXEC :V1:='A'
EXEC :V2:='A'
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'FIND_ME';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';
SELECT
FROM
(SELECT
    ROWNUM COUNTER,
    CHR(MOD(ROWNUM-1,26)+65) CHARACTER
FROM
    DUAL
CONNECT BY
    LEVEL<=100)
WHERE
CHARACTER= :V1;
SELECT
FROM
(SELECT
    ROWNUM COUNTER,
    CHR(MOD(ROWNUM-1,26)+65) CHARACTER
FROM
    DUAL
CONNECT BY
    LEVEL<=100)
WHERE
CHARACTER= :V2;
SELECT SYSDATE FROM DUAL;
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';In the script we have two bind variables defined, the first a VARCHAR2 and the second a NVARCHAR2. The output of the script looks like this in both cases:
   COUNTER C
         1 A
        27 A
        53 A
        79 AThe 10046 trace file looks like this:
PARSING IN CURSOR #3 len=152 dep=0 uid=31 oct=3 lid=31 tim=2874162497 hv=2898495116 ad='a5259590'
SELECT
FROM
(SELECT
    ROWNUM COUNTER,
    CHR(MOD(ROWNUM-1,26)+65) CHARACTER
FROM
    DUAL
CONNECT BY
    LEVEL<=100)
WHERE
CHARACTER= :V1
END OF STMT
PARSE #3:c=0,e=128,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874162493
BINDS #3:
kkscoacd
Bind#0
oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=178 siz=32 off=0
kxsbbbfp=0f176c88 bln=32 avl=01 flg=05
value="A"
EXEC #3:c=0,e=498,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874163947
WAIT #3: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164058
FETCH #3:c=0,e=68,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=2874164215
WAIT #3: nam='SQL*Net message from client' ela= 299 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164657
WAIT #3: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164903
FETCH #3:c=15625,e=359,p=0,cr=0,cu=0,mis=0,r=3,dep=0,og=1,tim=2874165155
WAIT #3: nam='SQL*Net message from client' ela= 1162 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874166774
STAT #3 id=1 cnt=4 pid=0 pos=1 obj=0 op='VIEW (cr=0 pr=0 pw=0 time=76 us)'
STAT #3 id=2 cnt=100 pid=1 pos=1 obj=0 op='COUNT (cr=0 pr=0 pw=0 time=50 us)'
STAT #3 id=3 cnt=100 pid=2 pos=1 obj=0 op='CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=47 us)'
STAT #3 id=4 cnt=1 pid=3 pos=1 obj=0 op='FAST DUAL (cr=0 pr=0 pw=0 time=4 us)'
WAIT #0: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874167438
WAIT #0: nam='SQL*Net message from client' ela= 3939 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874171452
=====================
PARSING IN CURSOR #2 len=152 dep=0 uid=31 oct=3 lid=31 tim=2874171761 hv=2346424803 ad='a597e190'
SELECT
FROM
(SELECT
    ROWNUM COUNTER,
    CHR(MOD(ROWNUM-1,26)+65) CHARACTER
FROM
    DUAL
CONNECT BY
    LEVEL<=100)
WHERE
CHARACTER= :V2
END OF STMT
PARSE #2:c=0,e=155,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874171757
BINDS #2:
kkscoacd
Bind#0
oacdty=01 mxl=32(02) mxlc=01 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=02 csi=2000 siz=32 off=0
kxsbbbfp=0f176c88 bln=32 avl=02 flg=05
value=""
EXEC #2:c=0,e=489,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874173190
WAIT #2: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874173300
FETCH #2:c=0,e=68,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=2874173453
WAIT #2: nam='SQL*Net message from client' ela= 326 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874173906
WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874174137
FETCH #2:c=0,e=334,p=0,cr=0,cu=0,mis=0,r=3,dep=0,og=1,tim=2874174398
WAIT #2: nam='SQL*Net message from client' ela= 1052 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874175570
STAT #2 id=1 cnt=4 pid=0 pos=1 obj=0 op='VIEW (cr=0 pr=0 pw=0 time=76 us)'
STAT #2 id=2 cnt=100 pid=1 pos=1 obj=0 op='COUNT (cr=0 pr=0 pw=0 time=46 us)'
STAT #2 id=3 cnt=100 pid=2 pos=1 obj=0 op='CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=43 us)'
STAT #2 id=4 cnt=1 pid=3 pos=1 obj=0 op='FAST DUAL (cr=0 pr=0 pw=0 time=4 us)'
WAIT #0: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874176119
WAIT #0: nam='SQL*Net message from client' ela= 998 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874177197
...Notice that the value for the bind variable defined as VARCHAR2 printed in the trace file, while the value for the bind variable defined as NVARCHAR2 did not print in the trace file.
If I had set the STATISTICS_LEVEL to ALL (or used a GATHER_PLAN_STATISTICS hint) I could retrieve the actual execution plan for the above SQL statements like this (if not, replace ALLSTATS LAST with TYPICAL):
SET PAGESIZE 1000
SET LINESIZE 160
SELECT /*+ LEADING(S) */
T.PLAN_TABLE_OUTPUT
FROM
(SELECT
    SQL_ID,
    CHILD_NUMBER
FROM
    V$SQL
WHERE
    SQL_TEXT LIKE '% CHARACTER= :V_') S,
TABLE(DBMS_XPLAN.DISPLAY_CURSOR(S.SQL_ID,S.CHILD_NUMBER,'ALLSTATS LAST +COST')) T;The output of the above looks like this:
SQL_ID 33wwr3kqc71nc, child number 0
SELECT   * FROM   (SELECT     ROWNUM COUNTER,     CHR(MOD(ROWNUM-1,26)+65) CHARACTER   FROM
    DUAL   CONNECT BY     LEVEL<=100) WHERE   CHARACTER= :V1
Plan hash value: 761049541
| Id | Operation                      | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   |
|* 1 | VIEW                          |      |      1 |      1 |     2   (0)|      4 |00:00:00.01 |
|   2 |   COUNT                        |      |      1 |        |            |    100 |00:00:00.01 |
|   3 |    CONNECT BY WITHOUT FILTERING|      |      1 |        |            |    100 |00:00:00.01 |
|   4 |     FAST DUAL                  |      |      1 |      1 |     2   (0)|      1 |00:00:00.01 |
Predicate Information (identified by operation id):
   1 - filter("CHARACTER"=:V1)
SQL_ID 7qzd4aq5xr6g3, child number 0
SELECT   * FROM   (SELECT     ROWNUM COUNTER,     CHR(MOD(ROWNUM-1,26)+65) CHARACTER   FROM
    DUAL   CONNECT BY     LEVEL<=100) WHERE   CHARACTER= :V2
Plan hash value: 761049541
| Id | Operation                      | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   |
|* 1 | VIEW                          |      |      1 |      1 |     2   (0)|      4 |00:00:00.01 |
|   2 |   COUNT                        |      |      1 |        |            |    100 |00:00:00.01 |
|   3 |    CONNECT BY WITHOUT FILTERING|      |      1 |        |            |    100 |00:00:00.01 |
|   4 |     FAST DUAL                  |      |      1 |      1 |     2   (0)|      1 |00:00:00.01 |
Predicate Information (identified by operation id):
   1 - filter(SYS_OP_C2C("CHARACTER")=:V2)Notice in the Predicate Information section of the second execution plan, a function is applied to the column - that SYS_OP_C2C function will likely prevent a normal (non-function based) index from helping to improve the execution performance.
To answer your question, it is the client application that must correctly define the bind variable types.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

In trace file and output file showing bind variable instead of value

Hi,
database 9i
optimizer = choose(for cost based)
In my trace file and output file showing bind variable instead of value.
in my trace file 20 queries.
I alse set this parameter in session level.
alter session set events '10046 trace name context forever, level 4';
but still showing traceoutput file bind variable.
Pls help its very urgent

Can you post the query for which the bind variable values are not being shown and the trace output for the same?
Probably it is listed down somewhere when you actually executed the query among the others. Try completely analyzing your trace file..

Record type variables in the SQL database trace file

Hi,
I turned on the trace with binds and waits in a ebusiness form and captured the database SQL trace file. It lists the values for the generic datatypes for the call, but does not list the values of record type variables. Is there a way to identify the values of record type variables? The below section lists the procedure call and the values passed. Thanks in advance.
RPC CALL:PROCEDURE APPS.HZ_PARTY_SEARCH.FIND_PARTY_DETAILS(P_INIT_MSG_LIST IN VARCHAR2, P_RULE_ID IN NUMBER, P_PARTY_SEARCH_REC IN PARTY_SEARCH_REC_TYPE, P_PARTY_SITE_LIST IN PARTY_SITE_LIST, P_CONTACT_LIST IN CONTACT_LIST, P_CONTACT_POINT_LIST IN CONTACT_POINT_LIST
, P_RESTRICT_SQL IN VARCHAR2, P_MATCH_TYPE IN VARCHAR2, P_SEARCH_MERGED IN VARCHAR2, X_SEARCH_CTX_ID OUT NUMBER, X_NUM_MATCHES OUT NUMBER, X_RETURN_STATUS OUT VARCHAR2, X_MSG_COUNT OUT NUMBER, X_MSG_DATA OUT VARCHAR2);
RPC BINDS:
bind 0: dty=1 bfp=2ae5927c13c8 flg=08 avl=01 mxl=01 val="T"
bind 1: dty=6 bfp=2ae5927c13f0 flg=00 avl=02 mxl=22 val=8
bind 2: dty=118 bfp=2ae593432e48 flg=00 avl=00 mxl=00 val=00
bind 3: dty=251 bfp=2ae5929ac0b8 flg=00 avl=1944 mxl=00 val=00
bind 4: dty=251 bfp=2ae592d85548 flg=00 avl=5336 mxl=00 val=00
bind 5: dty=251 bfp=2ae592d84d58 flg=00 avl=4984 mxl=00 val=00
bind 6: dty=1 bfp=2ae5927c1550 flg=08 avl=125 mxl=2000 val="exists (select 'x' from hz_parties where party_id =stage.party_id and party_type = 'ORGANIZATION') and party_id <>1002277174"
bind 7: dty=1 bfp=2ae5927c1d50 flg=0a avl=00 mxl=00 val=""
bind 8: dty=1 bfp=2ae5927c1d80 flg=08 avl=01 mxl=01 val="I"
bind 9: dty=6 bfp=2ae5927c1da8 flg=02 avl=00 mxl=22 val=00
bind 10: dty=6 bfp=2ae5927c1de0 flg=02 avl=00 mxl=22 val=00
bind 11: dty=1 bfp=2ae5927c1e28 flg=0a avl=00 mxl=01 val=""
bind 12: dty=6 bfp=2ae5927c1e50 flg=02 avl=00 mxl=22 val=00
bind 13: dty=1 bfp=2ae5927c1e98 flg=0a avl=00 mxl=2000 val=""

Hello,
From the sounds of it, when you are adding a child the application is not maintaining the Company's reference to it. For instance, in a 1:M and M:1 relationship, the application seems to be setting only the M:1 part (child to parent) which will cause the database to be updated, but both sides need to be set to keep the cache in synch with the database.
Setting the cache type to be none is not a good idea - it prevents any caching, which will hurt performance and object identity. What instead is recommended is disabling the shared cache using the
toplink.cache.shared.<ENTITY>=false property. This still might not help though if the Company's reference to the child hasn't been set as mentioned above if you are reading Company from the same context you are adding the child.
The Cache is described for TopLink Essentials in the blog at:
http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t.html
Best Regards,
Chris

Bind value truncated in trace file

Hi,
I ran a level 12 trace, but it looks like the display of the bind variable values in the trace file is limited to about 255 characters. Is there any setting I can change to get it to dump the entire value?
Thanks!

I can't find any related information as to why this limitation is there but I guess it is only to keep the trace file readable (with parameter "avl" indicating the actual value length in the trace file).

Bind values for complex datatype in Oracle trace file

If I run trace on oracle spatial queries, how can I get the detailed information of the bind variable value for sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
For example, in the query, SRID, SDO_ELEM_INFO_ARRAY, and SDO_ORDINATE_ARRAY are bind variables. For SRID, I can find its value (number), but for sdo_elem_info_array and sdo_ordinate_array, I only got something like:
BINDS #1:
bind 0: dty=23 mxl=32(16) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0 size=32 offset=0
bfp=0c0521dc bln=32 avl=16 flg=05
value=
Dump of memory from 0xC0521DC to 0xC0521EC
C0521D0 9E2362B1 [.b#.]
C0521E0 479F3EB7 8B3F2BA9 A1441E4C [.>.G.+?.L.D.]
I also tried to look at v$sql, v$sql_bind_data, v$sql_bind_capture views and haven't been able to find the values.
Thanks!

If I run trace on oracle spatial queries, how can I get the detailed information of the bind variable value for sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
For example, in the query, SRID, SDO_ELEM_INFO_ARRAY, and SDO_ORDINATE_ARRAY are bind variables. For SRID, I can find its value (number), but for sdo_elem_info_array and sdo_ordinate_array, I only got something like:
BINDS #1:
bind 0: dty=23 mxl=32(16) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0 size=32 offset=0
bfp=0c0521dc bln=32 avl=16 flg=05
value=
Dump of memory from 0xC0521DC to 0xC0521EC
C0521D0 9E2362B1 [.b#.]
C0521E0 479F3EB7 8B3F2BA9 A1441E4C [.>.G.+?.L.D.]
I also tried to look at v$sql, v$sql_bind_data, v$sql_bind_capture views and haven't been able to find the values.
Thanks!

Passing shell script variable to sql file by reference (bind variable)

Hi All,
I need to import around 50 files every 15 minutes into my target table.
I am using shell script and call procedure to do transform.
I used crontab to do this automate task.
Here is my shell script and sql file:
shell script:
#!/bin/sh
export ORACLE_HOME=/u01/app/oracle/product/9.2.0.4.0
export PATH=$ORACLE_HOME/bin
find /path_rawfile/rawfile -iname raw\*.in > myfile.lst
nfile=1
while [ true ]
do
read iFile #read a line
if [ $? -ne 0 ] #Break if EOF
then
break
fi
#$PATH/sqlplus -s /NOLOG @load_raw.sql $iFile
#/bin/mv -f $iFile /path_rawfile/rawfile/done/
done < myfile.lst
sql file:
connect test/test@evn1
set serveroutput on
variable filename varchar2(50)
begin
:filename := '&1';
exec my_tranform(:filename);
dbms_output.put_line(:filename);
end;
exit;
Even I used bind variable pass to procedure my_transform...
But when i query in sys.v_$sqlarea, the :filename:='&1' still hard parse to sqlarea.
One filename one statement and keep increasing ..
Could everyone help me to change it to bind varialbe(soft parse)?
I would like to incresae my database performance.
Thanks in advance.
Cheer
Message was edited by:
lux

It is the procedure.
It's my fault.
Here is my SQL file again:
conn test/test@evn1
variable filename varchar2(500);
exec :filename:='&1';
exec my_transform(:filename);
exit;
I call this sql file from shell script and call in loop due to i need to load all file one time.
Once i use <<EOF it raise error that's why when I deleted it.
Anyway, what I need to do here is to use bind variable (soft parse).
Since I need to load around 50 files every 15 minutes.
exec :filename:='&1'; this statmet have found hard parse in v_$sqlarea.
I would like to change this to bind varialbe.
Thanks again for your help.

Report Performance with Bind Variable

Getting some very odd behaviour with a report in APEX v 3.2.1.00.10
I have a complex query that takes 5 seconds to return via TOAD, but takes from 5 to 10 minutes in an APEX report.
I've narrowed it down to one particular bind. If I hard code the date in it returns in 6 seconds, but if I let the date be passed in from a parameter it takes 5+ minutes again.
Relevant part of the query (an inline view) is:
,(select rglr_lect lect
,sum(tpm) mtr_tpm
,sum(enrols) mtr_enrols
from ops_dash_meetings_report
where meet_ev_date between to_date(:P35_END_DATE,'DD/MM/YYYY') - 363 and to_date(:P35_END_DATE,'DD/MM/YYYY')
group by rglr_lect) RPV
I've tried replacing the "to_date(:P35_END_DATE,'DD/MM/YYYY') - 363" with another item which is populated with the date required (and verified by checking session state). If I replace the :P35_END_DATE with an actual date the performance is fine again.
The weird thing is that a trace file shows me exactly the same Explain Plan as the TOAD Explain where it runs in 5 seconds.
Another odd thing is that another page in my application has the same inline view and doesn't hit the performance problem.
The trace file did show some control characters (circumflex M) after each line of this report's query where these weren't anywhere else on the trace queries. I wondered if there was some sort of corruption in the source?
No problems due to pagination as the result set is only 31 records and all being displayed.
Really stumped here. Any advice or pointers would be most welcome.
Jon.

Don't worry about the Time column, the cost and cardinality are more important to see whther the CBO is making different decisions for whatever reason.
Remember that the explain plan shows the expected execution plan and a trace shows the actual execution plan. So what you want to do is compare the query with bind variables from an APEX page trace to a trace from TOAD (or sqlplus or whatever). You can do this outside APEX like this...
ALTER SESSION SET EVENTS '10046 trace name context forever, level 1';Enter and run your SQL statement...;
ALTER SESSION SET sql_trace=FALSE;This will create a a trace file in the directory returned by...
SELECT value FROM v$parameter WHERE name = 'user_dump_dest' Which you can use tkprof to format.
I am assuming that your not going over DB links or anything else slightly unusual?
Cheers
Ben

Bind variables and Dynamic sql

I have this function which works only when i'm not passing bind variables. The moment i add bind variables it is not able to execute the function.
Oracle Db Version: 8.1
Thanks
Source Code
FUNCTION TestFunction( In_Test_id in Number,
In_Asof in Date )
Return ScoreType
IS
LvScore ABC.LV_SCORE.SCORE%TYPE;
DVScore ABC.LV_SCORE.SCORE%TYPE;
Begin
EXECUTE IMMEDIATE
'SELECT SCORE,DVSCORE
FROM
SELECT SCORE,DVSCORE
DENSE_RANK() OVER (PARTITION BY TEST_ID ORDER BY ASOF_DT DESC) AS score_RANK
FROM ABC.LV_SCORE
WHERE TEST_ID = :x
AND ASOF_DT <= :y
) WHERE score_RANK = 1'
INTO LvScore,DVScore
USING In_tEST_ID,In_Asof;
Return ScoreType( LvScore,
DVScore);
End;

It just keeps on executing for sometime and then disconnects itself from database What was the indication that told you that it disconnected? Was there a visible indication of this disconnect?
Did you get ORA-03113?
===========================================
ORA-03113: end-of-file on communication channel
Cause: The connection between Client and Server process was broken.
Action: There was a communication error that requires further investigation. First, check for network problems and review the SQL*Net setup. Also, look in the alert.log file for any errors. Finally, test to see whether the server process is dead and whether a trace file was generated at failure time.

SLOW report performance with bind variable

Environment: 11.1.0.7.2, Apex 4.01.
I've got a simplified report page where the report runs slowly compared to running the same query in sqldeveloper. The report region is based on a pl/sql function returning a query. If I use a bind variable in the query inside apex it takes 13 seconds to run, and if I hard code a string it takes only a few hundredths of a second. The query returns one row from a table which has 1.6 million rows. Statistics are up-to-date and the columns in the joins and where clause are indexed.
I've run traces using p_trace=YES from Apex for both the bind variable and hard coded strings. They are below.
The sqldeveloper explain plan is identical to the bind variable plan from the trace, yet the query runs in 0.0x seconds in sqldeveloper.
What is it about bind variable syntax in Apex that is causing the bad execution plan? Apex Bug? 11g bug? Ideas?
tkprof output from Apex trace with bind variable is below...
select p.master_id link, p.first_name||' '||p.middle_name||' '||p.last_name||' '||p.suffix personname,
p.gender||' '||p.date_of_birth g_dob, p.master_id||'*****'||substr(p.ssn,-4) ssn, p.status status
from persons p
where
   p.person_id in (select ps.person_id from person_systems ps where ps.source_key like LTRIM(RTRIM(:P71_SEARCH_SOURCE1)))
order by 1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.01          0          1         27           0
Fetch        2     13.15      13.22      67694      72865          0           1
total        4     13.15      13.23      67694      72866         27           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 62 (ODPS_PRIVACYVAULT)   (recursive depth: 1)
Rows     Row Source Operation
      1 SORT ORDER BY (cr=72869 pr=67694 pw=0 time=0 us cost=29615 size=14255040 card=178188)
      1   FILTER (cr=72869 pr=67694 pw=0 time=0 us)
      1    HASH JOIN RIGHT SEMI (cr=72865 pr=67694 pw=0 time=0 us cost=26308 size=14255040 card=178188)
      1     INDEX FAST FULL SCAN IDX$$_0A300001 (cr=18545 pr=13379 pw=0 time=0 us cost=4993 size=2937776 card=183611)(object id 68485)
1696485     TABLE ACCESS FULL PERSONS (cr=54320 pr=54315 pw=0 time=21965 us cost=14958 size=108575040 card=1696485)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (ORDER BY)
      1    FILTER
      1     HASH JOIN (RIGHT SEMI)
      1      INDEX   MODE: ANALYZED (FAST FULL SCAN) OF
                 'IDX$$_0A300001' (INDEX)
1696485      TABLE ACCESS   MODE: ANALYZED (FULL) OF 'PERSONS' (TABLE)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file scattered read                       1276        0.00          0.16
db file sequential read                       812        0.00          0.02
direct path read                             1552        0.00          0.61
********************************************************************************Here's the tkprof output with a hard coded string:
select p.master_id link, p.first_name||' '||p.middle_name||' '||p.last_name||' '||p.suffix personname,
p.gender||' '||p.date_of_birth g_dob, p.master_id||'*****'||substr(p.ssn,-4) ssn, p.status status
from persons p
where
   p.person_id in (select ps.person_id from person_systems ps where ps.source_key like LTRIM(RTRIM('0b')))
order by 1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.02       0.04          0          0          0           0
Execute      1      0.00       0.00          0          0         13           0
Fetch        2      0.00       0.00          0          8          0           1
total        4      0.02       0.04          0          8         13           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 62 (ODPS_PRIVACYVAULT)   (recursive depth: 1)
Rows     Row Source Operation
      1 SORT ORDER BY (cr=10 pr=0 pw=0 time=0 us cost=9 size=80 card=1)
      1   FILTER (cr=10 pr=0 pw=0 time=0 us)
      1    NESTED LOOPS (cr=8 pr=0 pw=0 time=0 us)
      1     NESTED LOOPS (cr=7 pr=0 pw=0 time=0 us cost=8 size=80 card=1)
      1      SORT UNIQUE (cr=4 pr=0 pw=0 time=0 us cost=5 size=16 card=1)
      1       TABLE ACCESS BY INDEX ROWID PERSON_SYSTEMS (cr=4 pr=0 pw=0 time=0 us cost=5 size=16 card=1)
      1        INDEX RANGE SCAN IDX_PERSON_SYSTEMS_SOURCE_KEY (cr=3 pr=0 pw=0 time=0 us cost=3 size=0 card=1)(object id 68561)
      1      INDEX UNIQUE SCAN PK_PERSONS (cr=3 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 68506)
      1     TABLE ACCESS BY INDEX ROWID PERSONS (cr=1 pr=0 pw=0 time=0 us cost=2 size=64 card=1)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      1   SORT (ORDER BY)
      1    FILTER
      1     NESTED LOOPS
      1      NESTED LOOPS
      1       SORT (UNIQUE)
      1        TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF
                   'PERSON_SYSTEMS' (TABLE)
      1         INDEX   MODE: ANALYZED (RANGE SCAN) OF
                    'IDX_PERSON_SYSTEMS_SOURCE_KEY' (INDEX)
      1       INDEX   MODE: ANALYZED (UNIQUE SCAN) OF 'PK_PERSONS'
                  (INDEX (UNIQUE))
      1      TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF
                 'PERSONS' (TABLE)

Patrick, interesting insight. Thank you.
The optimizer must be peeking at my bind variables with it's eyes closed. I'm the only one testing and I've never passed %anything as a bind value. :)
Here's what I've learned since my last post:
I don't think that sqldeveloper is actually using the explain plan it says it is. When I run explain plan in sqldeveloper (with a bind variable) it shows me the exact same plan as Apex with a bind variable. However, when I run autotrace in sqldeveloper, it takes a path that matches the hard coded values, and returns results in half a second. That autotrace run is consistent with actually running the query outside of autotrace. So, I think either sqldeveloper isn't really using bind variables, OR it is using them in some other way that Apex does not, or maybe optimizer peeking works in sqldeveloper?
Using optimizer hints to tweak the plan helps. I've tried both /*+ FIRST_ROWS */ and /*+ index(ps pk_persons) */ and both drop the query to about a second. However, I'm loath to use hints because of the very dynamic nature of the query (and Tom Kyte doesn't like them either). The hints may end up hurting other variations on the query.
I also tested the query by wrapping it in a select count(1) from ([long query]) and testing the performance in sqldeveloper and in Apex. The performance in that case is identical with both bind variables and hard coded variables for both Apex and SqlDeveloper. That to me was very interesting and I went so far as to set up two bind variable report regions on the same page. One region wrapped the long query with select count(1) from (...) and the other didn't. The wrapped query ran in 0.01 seconds, the unwrapped took 15ish seconds with no other optimizations. Very strange.
To get performance up to acceptable levels I have changed my function returning query to:
1) Set the equality operator to "=" for values without wildcards and "like" for user input with wildcards. This makes a HUGE difference IF no wildcard is used.
2) Insert a /*+ FIRST_ROWS */ hint when users chose the column that requires the sub-query. This obviously changes the optimizer's plan and improves query speed from 15 seconds to 1.5 seconds even with wildcards.
I will NOT be hard coding any user supplied values in the query string. As you can probably tell by the query, this is an application where sql injection would be very bad.
Jeff, regarding your question about "like '%' || :P71_SEARCH_SOURCE1 || '%'". I've found that putting wildcards around values, particularly at the beginning will negate any indexing on the column in question and slows performance even more.
I'm still left wondering if there isn't something in Apex that is breaking the optimizer "peeking" that Patrick describes. Perhaps something in the way it switches contexts from apex_public_user to the workspace schema?

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

Viewing Bind variable values in TKPROF output

DB Version:10gR2
After tracing a Stored proc , i can see the bind variable values in the raw trace file. But the TKPROF output of this trace file doesn't show Bind variable values. Is there a way i could see Bind variable values in TKPROF output?

I guess when you think about it, TKPROF is primarily intended to aggregate and summarise repeated SQLs and related statistics from raw trace files. While waits can reasonably be aggregated over multiple exeuctions of the same SQL, bind variables are explicitly associated with individual executions of an SQL and hence cannot be aggregated in the same fashion.

Do you know Timmings for trace files generated?

Hi,
I have done some sql traceing using DBMS_MONITOR package.
We can also enable SQL traceing using DBMS_SESSION.
I want to generate sql trace file for "particuler part of application".
When i did that i got some sql trace files,, now that "particuler part of application" was over application was idle..
but as time goes these files are still populating in size means they are still sql traceing going on...
My question is when and how trace files are generated?
Do you have idea???
Thanks and Regards,
Rushang Kansara
Message was edited by:
Rush

also what content of my sql trace file should i
consider for exacly tracing that "particuler part of
application".
Rushang
Parse Count To Execute Ratio
Take the numbers of parse count and divide it by numbers of time execute count if it is 1 then it means you are parsing the same statment everytime,If this ratio is 1 then it will latch the shared SQL area which will degrade the overall performance.Like if you execute a query which is using bind variable and this query is at yours front end level trigger (Forms) POST_QUERY then it will show you (parse count=execute count) which shows you are parsing for every triggering event which is bad ,for that you should put this seqeuel within PL/SQL procedure which cache the cursor and will turn in (parse count<Execute Count).
Large Diffrence Between Elasped Time And CPU Time
If this diffrence (Elapsed time[b]-CPU time)>1 then it means you are spending yours time in for waiting resources this waiting resources will in turn wait events e.g some one updated the row and dont realease by COMMIT or ROLBACK and the same span of time you want to update then you will see a lock in tkprof result in wait event section.If you read the data from hard disk (as first time you issue it reads from HD and then put into buffer cache during this reading a latch is grabed and will not let you read this data until you perform the alls read from HD to buffer cache this will also show you in wait events which is cache buffers chain
Fetch Calls
If yours Fetch calls=Rows then it means you are not using Bulk fetch and yours this code will take a lot of roundtrips which will in turn jam the network.
Disk Count
If every time yours disk count=current + query mode then you are reading alls block from disk alls the time ,usually oracle read once from disk and put it into SGA and should be found in SGA second time.
And there is many more...depend on yors environemnt setup but above are common.
As you said its reproducing the tkprof again and again ,make sure you terminate the session or you explicitly turn off the tracer by
ALTER SESSION SET SQL_TRACE=FALSE Khurram

Trace file generation using oradebug

DB version : 10.2.0.4.0
OS : Solaris 5.10
I am trying to trace a session started by a Java application.
So, i've logged in as SYS. Got pid, spid from v$process. Then started the debug
SYS@MN_PROD>oradebug setospid 2523
SYS@MN_PROD>oradebug event 10046 trace name context forever, level 32and closed it using
oradebug event 10046 trace name context offWhen i type
ORADEBUG TRACEFILE_NAMEIt shows a filename in bdump directory. But i can't find this file in bdump or udump.
Is there any init.ora setting i need to do to get this file generated?

Decimal Binary Description
1       0001   Emit statistics for parse, execute, fetch, commit, and rollback database calls (standard sql_trace)
2       0010   Unknown
4       0100   Emit values for SQL bind variables (also called “placeholders”)
8       1000   Emit statistics for Oracle kernel internal function calls (also called “wait events”) listed in v$event_name
These levels can be combined as if by a bitwise or function to produce combinations of data in an Oracle trace file.
A value of 15 is just a combination of all 4 preceeding values

Sdo_geometry bind variables in trace file

Similar Messages

Maybe you are looking for