Welcome to

SqlServer-QA.net

Sign in | Join | Help

SQL Server Storage Engine & Tools (SSQA.net)

SQL Server Tools includes storage engine that includes a complete set of graphical tools and command prompt utilities that allow users, programmers, and administrators. SSMS, SSRS, SSIS & SSAS are most commonly used tools.
Indexes and UPDATE STATISTICS differences and undocumented options - SQL Server 2005

During an Usergroup meeting one user asked the question that why my query is affected with slow performance when the statistics are upto-date? When asked about the indexes the reply was why do you need indexes when you have updated statistics on all the tables? So here is bit of explanation for such opinion differences  and awareness of the subject.

In SQL Server index is classed as a physically implemented structure in the database (clustered and non-clustered indexes) and whereas statistics are a set of values that help the optimizer during the execution plan formation stages to decide whether to use an index or not. There is no direct relationship between Statistics and Indexes but having the right combination together can help the optimizer to perform the query execution far better. On the topic have a thorough read on this Technet-QueryStats article.

 

The default behaviour of SQL Server Query Optimization process occurs in multiple stages, this can take care about various stages of optimization that are only entered when the estimated cost of the query is sufficiently high, in order to avoid wasting precious CPU cycles against simple queries that do not need that level of sophistication anyway. Taken an example of a query when you create 2 tables whereby creating unique index on one of the columns in a table1 and compare the estimated execution plan between these 2 queries. Depending upon the statistics information the plan will drastically change from a clustered index seek operation and an index scan operation to a clustered index scan and an index scan operator with parallelism. In any case it is better to look at the “EstimateRows” column that will deliver the difference between the values. Also I have seen that referring to EstimateIO and the EstimateCPU numbers will also give indepth lead to see that how badly query is affected due to the mismatch of statistics or indexes.

 

Talking in depth about multiple optimization stages are a mean to produce efficient query plans without consuming excessive amounts of CPU. Typically, in order to make the Optimizer “think” a lot and enter these later stages it is necessary to have big tables with a large number of rows and pages, which in turn take time and space to populate. Using ROWCOUNT and PAGECOUNT allows us to exercise these code paths with relatively simple scripts that do not require an extremely complex setup phase. The above 2 options within UPDATE STATISTICS statement are undocumented which means you will not find much information or examples in the BOL.

 

Similar to this action if you read the Books Online page describing the UPDATE STATISTICS command, you will see that there are some undocumented options.

 

UPDATE STATISTICS table | view
    [
        {
            { index | statistics_name }
          | ( { index |statistics_name } [ ,...n ] )
                }
    ]
    [    WITH
        [
            [ FULLSCAN ]
            | SAMPLE number { PERCENT | ROWS } ]
            | RESAMPLE
            | <update_stats_stream_option> [ ,...n ]
        ]
        [ [ , ] [ ALL | COLUMNS | INDEX ]
        [ [ , ] NORECOMPUTE ]
    ] ;

<update_stats_stream_option> ::=
    [ STATS_STREAM = stats_stream ]
    [ ROWCOUNT = numeric_constant ]
    [ PAGECOUNT = numeric contant ]

 

<update_stats_stream_option>

    This syntax is for internal use only and is not supported. Microsoft reserves the right to change this syntax at any time.

Previously when asked more about these options to the SQL Development team in Microsoft the explanation was a good reason why these options are undocumented, which means they are left for testing and debugging only which are frequently used by MS PSS (CSS).  As these 2 options are very much prone to alter the metadata in the table or index which is read by the Query Optimizer when processing queries that access the table and/or index in question.  Much information on statistics and indexes can be found about Transferring table statistics between the servers blog post, also you should make sure to make use of best execution plans. How you can do it means, by analyzing and looking at the frequently executed queries to make sure that

values within cost are changing as the data volume changes. Frequent visits to the indexes and statistics on the tables are volatile will help to attain the optimum performance as the cost is growing significantly with the data volume changes, then it will be an indication of tuning the queries or adding/modifying indexes.

 

Posted: Friday, January 16, 2009 12:32 AM by SQL Master

Comments

Other SQL Server Blogs around the Web said:

During an Usergroup meeting one user asked the question that why my query is affected with slow performance

# January 16, 2009 2:37 AM
Anonymous comments are disabled