TO_BINARY_DOUBLE after upgrade 9i/10g

Question

Hi all,
we encountered strange xplans after migration. I found out the issue was ODBC provided bind variable as type 101
*kkscoacd
Bind#0
oacdty=101 mxl=08(64) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=31 siz=8 off=0
No bind buffers allocated*
which I realized is new type BINARY_DOUBLE which was not there in 9i. So the optimizer transformed this select:
SELECT "ACCOUNT_ID" FROM "MDM"."ACCOUNT_ADDRESS" WHERE ("ACCOUNT_ID" = :V1 )
into
SELECT "ACCOUNT_ID" FROM "MDM"."ACCOUNT_ADDRESS" WHERE (TO_BINARY_DOUBLE("ACCOUNT_ID") = :V1 )
which determined the FULL SCAN on the table . 9i did not know about this type and did not convert the value which resulted in good index range scan.
NOW: As I'm waiting for the dev to fix it somehow I tried a workaround which is clearly a creation of FuncBasedIndex on ACCOUNT_ID named NU_AD_ACCOUNT_BNDB while NU_AD_ACCOUNT_BNDB was the original index on ACCOUNT_ID.
Running it once again I came across another strange behavior which I could not explain. The optimizer did NOT pick none of these indexes but the PK instead and did an index_full_scan on it. PK is composite index on ACCOUNT_ID plus another column which is NOT filtered in the SQL.
Please help me explain why despite the cost of NU_AD_ACCOUNT_BNDB the optmizer decided to go on the PK in FFS. Here's the 10053 trace file:
QUERY BLOCK TEXT
SELECT "ACCOUNT_ID" FROM "MDM"."ACCOUNT_ADDRESS" WHERE ("ACCOUNT_ID" = :V1 )
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=0 objn=1048639 hint_alias="ACCOUNT_ADDRESS"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using WORKLOAD Stats
CPUSPEED: 765 millions instructions/sec
SREADTIM: 0 milliseconds
MREADTIM: 5 millisecons
MBRC: 54.000000 blocks
MAXTHR: 100915200 bytes/sec
SLAVETHR: 1635328 bytes/sec
BASE STATISTICAL INFORMATION
Table Stats::
Table: ACCOUNT_ADDRESS Alias: ACCOUNT_ADDRESS
#Rows: 3564300 #Blks: 36411 AvgRowLen: 152.00
Index Stats::
Index: NU_AD_ACCOUNT Col#: 1
LVLS: 2 #LB: 4226 #DK: 3539358 LB/K: 1.00 DB/K: 1.00 CLUF: 3492510.00
Index: NU_AD_ACCOUNT_BNDB Col#: 30
LVLS: 2 #LB: 5125 #DK: 3725283 LB/K: 1.00 DB/K: 1.00 CLUF: 3665379.00
Index: PK_AA1 Col#: 1 2
LVLS: 2 #LB: 4976 #DK: 3479567 LB/K: 1.00 DB/K: 1.00 CLUF: 3426964.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Column (#30): SYS_NC00030$(BINARY_DOUBLE) NO STATISTICS (using defaults)
AvgLen: 6.00 NDV: 111384 Nulls: 0 Density: 8.9779e-06
Column (#1): ACCOUNT_ID(NUMBER)
AvgLen: 6.00 NDV: 3564300 Nulls: 0 Density: 2.8056e-07 Min: 17 Max: 4524701
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Table: ACCOUNT_ADDRESS Alias: ACCOUNT_ADDRESS
Card: Original: 3564300 Rounded: 35643 Computed: 35643.00 Non Adjusted: 35643.00
END Single Table Cardinality Estimation
Access Path: TableScan
Cost: 95348.31 Resp: 95348.31 Degree: 0
Cost_io: 55958.00 Cost_cpu: 1958683004
Resp_io: 55958.00 Resp_cpu: 1958683004
Access Path: index (index (FFS))
Index: NU_AD_ACCOUNT
resc_io: 6497.00 resc_cpu: 1527703771
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 37220.05 Resp: 37220.05 Degree: 16
Cost_io: 6497.00 Cost_cpu: 1527703771
Resp_io: 6497.00 Resp_cpu: 1527703771
Access Path: index (index (FFS))
Index: PK_AA1
resc_io: 7648.00 resc_cpu: 1509898711
ix_sel: 0.0000e+00 ix_sel_with_filters: 1
Access Path: index (FFS)
Cost: 38012.98 Resp: 38012.98 Degree: 1
Cost_io: 7648.00 Cost_cpu: 1509898711
Resp_io: 7648.00 Resp_cpu: 1509898711
kkofmx: index filter:TO_BINARY_DOUBLE("ACCOUNT_ADDRESS"."ACCOUNT_ID")=:B1
kkofmx: index filter:TO_BINARY_DOUBLE("ACCOUNT_ADDRESS"."ACCOUNT_ID")=:B1
Access Path: index (FullScan)
Index: NU_AD_ACCOUNT
resc_io: 4228.00 resc_cpu: 749064497
ix_sel: 1 ix_sel_with_filters: 1
Cost: 4079.62 Resp: 4079.62 Degree: 1
Access Path: index (AllEqGuess)
Index: NU_AD_ACCOUNT_BNDB
resc_io: 14665.00 resc_cpu: 148095035
ix_sel: 0.004 ix_sel_with_filters: 0.004
Cost: 1764.33 Resp: 1764.33 Degree: 1
Access Path: index (FullScan)
Index: PK_AA1
resc_io: 4978.00 resc_cpu: 744413457
ix_sel: 1 ix_sel_with_filters: 1
Cost: 4145.27 Resp: 4145.27 Degree: 1
****** trying bitmap/domain indexes ******
****** finished trying bitmap/domain indexes ******
Best:: AccessPath: IndexRange Index: PK_AA1
Cost: 4145.27 Degree: 1 Resp: 4145.27 Card: 35643.00 Bytes: 0

Answer 1

Thank You for your analysis.
Of course many things had changed with 10g but this is a simple one and even If I tried to tweak the optimizer to make it behave as 9i I couldnt make it work.
this select along with others on the same table and for the same filtered column used to run smoothly on 9i. As I tried to sort out why on 10g it wasn't any longer happening, I bumped into the fact the bind variable's type is declare as binary_double while the column is NUMBER...
*kkscoacd
Bind#0
oacdty=101 mxl=08(64) mxlc=00 mal=00 scl=00 pre=00
Thus all those select were running on full scan after migration because the index values wasnt matched because of the conversion forced during parse( as I spotted in trace file). That didn't occur on 9i because on that version there was no BINARY_DOUBLE so I assume the optimizer accepted the bind variable's type as simply a number. Am I wrong?
So my assumption is that ODBC value was already mistyped on 9i but luckily it kept working because it wasnt handled
Simone