Insert select statement is taking ages

Question

Sybase version: Adaptive Server Enterprise/12.5.4/EBF 15432 ESD#8/P/Sun_svr4/OS 5.8/ase1254/2105/64-bit/FBO/Sat Mar 22 14:38:37 2008
Hi guyz,
I have a question about the performance of a statement that is very slow and I'd like to have you input.
I have the SQL statement below that is taking ages to execute and I can't find out how to imporve it
insert SST_TMP_M_TYPE select M_TYPE from MKT_OP_DBF M join TRN_HDR_DBF T on M.M_ORIGIN_NB=T.M_NB where T.M_LTI_NB=@Nson_lti
@Nson_lti is the same datatype as T.M_LTI_NB
M.M_ORIGIN_NB=T.M_NB have the same datatype
TRN_HDR_DBF has 1424951 rows and indexes on M_LTI_NB and M_NB
table MKT_OP_DBF has 870305 rows
table MKT_OP_DBF has an index on M_ORIGIN_NB column
Statistics for index:                   "MKT_OP_ND7" (nonclustered)
Index column list:                      "M_ORIGIN_NB"
     Leaf count:                        3087
     Empty leaf page count:             0
     Data page CR count:                410256.0000000000000000
     Index page CR count:               566.0000000000000000
     Data row CR count:                 467979.0000000000000000
     First extent leaf pages:           0
     Leaf row size:                     12.1161512343373872
     Index height:                      2
The representaion of M_ORIGIN_NB is
Statistics for column:                  "M_ORIGIN_NB"
Last update of column statistics:       Mar  9 2015 10:48:57:420AM
     Range cell density:                0.0000034460903826
     Total density:                     0.0053334921767125
     Range selectivity:                 default used (0.33)
     In between selectivity:            default used (0.25)
Histogram for column:                   "M_ORIGIN_NB"
Column datatype:                        numeric(10,0)
Requested step count:                   20
Actual step count:                      20
     Step     Weight                    Value
        1     0.00000000        <       0
        2     0.07300889        =       0
        3     0.05263098       <=       5025190
        4     0.05263098       <=       9202496
        5     0.05263098       <=       12664456
        6     0.05263098       <=       13129478
        7     0.05263098       <=       13698564
        8     0.05263098       <=       14735554
        9     0.05263098       <=       15168461
       10     0.05263098       <=       15562067
       11     0.05263098       <=       16452862
       12     0.05263098       <=       16909265
       13     0.05263212       <=       17251573
       14     0.05263098       <=       18009609
       15     0.05263098       <=       18207523
       16     0.05263098       <=       18404113
       17     0.05263098       <=       18588398
       18     0.05263098       <=       18793585
       19     0.05263098       <=       18998992
       20     0.03226340       <=       19574408
If I look at the showplan, I can see indexes on TRN_HDR_DBF are used but now the one on MKT_OP_DBF
QUERY PLAN FOR STATEMENT 16 (at line 35).
    STEP 1
        The type of query is INSERT.
        The update mode is direct.
        FROM TABLE
            MKT_OP_DBF
            M
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 32 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            TRN_HDR_DBF
            T
        Nested iteration.
        Index : TRN_HDR_NDX_NB
        Forward scan.
        Positioning by key.
        Keys are:
            M_NB  ASC
        Using I/O Size 4 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 4 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            SST_TMP_M_TYPE
        Using I/O Size 4 Kbytes for data pages.
I was expecting the query to use the index also on MKT_OP_DBF
Thanks for your advices
Simon

Answer 1

The total density number for the MKT_OP_DBF.M_ORIGIN_NB column don't look very good:
     Range cell density:           0.0000034460903826
     Total density:                0.0053334921767125
Notice the total density value is 3 magnitudes larger than the range density ... which can indicate a largish number of duplicates.  (NOTE: This wide difference between range cell and total density can be referred to as 'skew' - more on this later.)
Do some M_ORIGIN_NB values have a large number of duplicates?  What does the following query return:
=====================
select top 30 M_ORIGIN_NB, count(*)
from   MKT_OP_DBF
group by M_ORIGIN_NB
order by 2 desc, 1
=====================
The total density can be used to estimate the number of rows expected for a join (eg, TRN_HDR_DBF --> MKT_OP_DBF).  The largish total density number, when thrown into the optimizer's calculations, may be causing the optimizer to think that the volume of *possible* joins will be more expensive than a join in the opposite direction (MKT_OP_DBF --> TRN_HDR_DBF) which in turn means (as Jeff's pointed out) that you end up table scanning MKT_OP_DBF (as the outer table) because of no SARGs.
From your description it sounds like you've got the necessary indexes to support a TRN_HDR_DBF --> MKT_OP_DBF join order. (Though it wouldn't hurt to see the complete output from sp_helpindex for both tables just to make sure we're on the same sheet of music.)
Without more details (eg, complete stats for both tables, sp_help for both tables - if you decide to post these I'd recommend posting them as a *.txt attachment).
I'm assuming you *know* that a join from TRN_NDR_DBF --> MKT_OP_DBF should be much quicker than what you're currently seeing.  If this is the case, I'd probably want to start with:
=====================
exec sp_modifystats MKT_OP_DBF, M_ORIGIN_NB, REMOVE_SKEW_FROM_DENSITY
go
exec sp_recompile MKT_OP_DBF
go
-- run your query again
=====================
By removing the skew from the total density (ie, set total density = range cell density = 0.00000344...) you're telling the optimizer that it can expect a much smaller number of joins for the join order of TRN_HDR_DBF --> MKT_OP_DBF ... and that may be enough for the optimizer to use TRN_HDR_DBF to drive the query.
NOTE: If sp_modifystats/REMOVE_SKEW_FROM_DENSITY provides the desired join order, keep in mind that you'll need to re-issue this command after each update stats command that modifies the stats on the M_ORIGIN_NB column.  For example, modify your update stats maintenance job to issue sp_modifystats/REMOVE_SKEW_FROM_DENSITY for those special cases where you know it helps query performance.