Re: In a BIND again...

Hi

I am not sure about Trace Analyzer havent used it for a while, I am writing for something else.

Is your application using JDBC? I suspect yes and you have a problem with JDBC. When you pass Java Timestamp variables to Oracle 9.0+ JDBC, this will not convert it to date as JDBC 8 because from 9i Timestamp datetype is supported so you see the binds for your quoteExpirationDate like:

 bind 5: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0 offset=120

   bfp=40759cbc bln=11 avl=07 flg=01
   value=
Dump of memory from 0x40759CBC to 0x40759CC3

40759CB0                            0C0A6B78              [xk..]
40759CC0 00010101                             [....]

dty=180 is Timestamp, this would cause index not being used as Optimizer does a to_date in this column, to revert this to JDBC 8 behaviour you have to add v8compatible in your JDBC properties.

Thanks

--
LSC



On 10/12/07, Sweetser, Joe <JSweetser_at_icat.com> wrote:


>

>  Thanks.  Indeed, the values are in there.  And the 6th value (bind 5) is

> NULL so maybe the throws off Trace Analyzer.

>

> Anyone know for sure?

>

> thanks again,

> -joe

>

> BINDS #3:

>  bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=292

> offset=0

>    bfp=40759c44 bln=22 avl=03 flg=05

>    value=172

>  bind 1: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0

> offset=24

>    bfp=40759c5c bln=22 avl=01 flg=01

>    value=0

>  bind 2: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0

> offset=48

>    bfp=40759c74 bln=22 avl=01 flg=01

>    value=0

>  bind 3: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0

> offset=72

>    bfp=40759c8c bln=22 avl=01 flg=01

>    value=0

>  bind 4: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0

> offset=96

>    bfp=40759ca4 bln=22 avl=01 flg=01

>    value=0

>  bind 5: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=03 oacfl2=0 size=0

> offset=120

>    bfp=40759cbc bln=11 avl=07 flg=01

>    value=

> Dump of memory from 0x40759CBC to 0x40759CC3

> 40759CB0                            0C0A6B78              [xk..]

> 40759CC0 00010101                             [....]

>  bind 6: dty=1 mxl=32(15) mal=00 scl=00 pre=00 oacflg=03 oacfl2=10 size=0

> offset=132

>    bfp=40759cc8 bln=32 avl=05 flg=01

>    value="1362%"

>  bind 7: dty=1 mxl=128(99) mal=00 scl=00 pre=00 oacflg=03 oacfl2=10 size=0

> offset=164

>    bfp=40759ce8 bln=128 avl=33 flg=01

>    value="icat.external.icat_at_woodsrb#com#.%<icat.external.icat_at_woodsrb#com%23.%25>

> "

>

>  ------------------------------

> *From:* Allen, Brandon [mailto:Brandon.Allen_at_OneNeck.com]

> *Sent:* Friday, October 12, 2007 10:35 AM

> *To:* Sweetser, Joe; oracle-l_at_freelists.org

> *Subject:* RE: In a BIND again...

>

>  Take a look at the BIND section of the raw trace file and see what they

> look like there.  Maybe some of them were NULL so trace analyzer doesn't

> show them.  I'm not sure since I haven't played with the trace analyzer

> much.  I usually get by with just the raw trace file, tkprof and manually

> looking up the relevant table/index stats.

>

> Regards,

> Brandon

>

>

>

> Privileged/Confidential Information may be contained in this message or

> attachments hereto. Please advise immediately if you or your employer do not

> consent to Internet email for messages of this kind. Opinions, conclusions

> and other information in this message that do not relate to the official

> business of this company shall be understood as neither given nor endorsed

> by it.

>


--
http://www.freelists.org/webpage/oracle-l