Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
Microsoft SQL Server Administration
- The DBA Survival Guide: The 10 Minute SQL Server Overview
- Preparing (or Tuning) a Windows System for SQL Server, Part 1
- Preparing (or Tuning) a Windows System for SQL Server, Part 2
- Installing SQL Server
- Upgrading SQL Server
- SQL Server 2000 Management Tools
- SQL Server 2005 Management Tools
- SQL Server 2008 Management Tools
- SQL Azure Tools
- Automating Tasks with SQL Server Agent
- Run Operating System Commands in SQL Agent using PowerShell
- Automating Tasks Without SQL Server Agent
- Storage – SQL Server I/O
- Service Packs, Hotfixes and Cumulative Upgrades
- Tracking SQL Server Information with Error and Event Logs
- Change Management
- SQL Server Metadata, Part One
- SQL Server Meta-Data, Part Two
- Monitoring - SQL Server 2005 Dynamic Views and Functions
- Monitoring - Performance Monitor
- Unattended Performance Monitoring for SQL Server
- Monitoring - User-Defined Performance Counters
- Monitoring: SQL Server Activity Monitor
- SQL Server Instances
- DBCC Commands
- SQL Server and Mail
- Database Maintenance Checklist
- The Maintenance Wizard: SQL Server 2000 and Earlier
- The Maintenance Wizard: SQL Server 2005 (SP2) and Later
- The Web Assistant Wizard
- Creating Web Pages from SQL Server
- SQL Server Security
- Securing the SQL Server Platform, Part 1
- Securing the SQL Server Platform, Part 2
- SQL Server Security: Users and other Principals
- SQL Server Security – Roles
- SQL Server Security: Objects (Securables)
- Security: Using the Command Line
- SQL Server Security - Encrypting Connections
- SQL Server Security: Encrypting Data
- SQL Server Security Audit
- High Availability - SQL Server Clustering
- SQL Server Configuration, Part 1
- SQL Server Configuration, Part 2
- Database Configuration Options
- 32- vs 64-bit Computing for SQL Server
- SQL Server and Memory
- Performance Tuning: Introduction to Indexes
- Statistical Indexes
- Backup and Recovery
- Backup and Recovery Examples, Part One
- Backup and Recovery Examples, Part Two: Transferring Databases to Another System (Even Without Backups)
- SQL Profiler - Reverse Engineering An Application
- SQL Trace
- SQL Server Alerts
- Files and Filegroups
- Full-Text Indexes
- Read-Only Data
- SQL Server Locks
- Monitoring Locking and Deadlocking
- Controlling Locks in SQL Server
- SQL Server Policy-Based Management, Part One
- SQL Server Policy-Based Management, Part Two
- SQL Server Policy-Based Management, Part Three
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Last updated Mar 28, 2003.
SQL Server 2000 and 2005 both use a "cost-based" optimizer to quickly locate data in its databases. I've mentioned the Query Processor in another tutorial, and in this tutorial I'll explain one of the tools it uses to find the fastest way to your data.
I've also explained how SQL Server uses indexes to locate data. Indexes are actually internal tables, and work like the index in a book – it contains a list of the terms you've indicated should be tracked and lists where those terms can physically be found. If the index is current, and if the data is large, the SQL Server engine makes a determination to use the index — sometimes. At times it's actually quicker for the engine to read all of the rows in a table to find the one it's looking for (called a scan) or take some other path to the data.
The "cost" in the cost-based optimizer is based on many factors. One factor is a set of information that is actually another set of indexes. These indexes are called "statistics." The system can generate these indexes, so you don't have to specify the columns that it uses, although you can. You can specify when the statistics are created, and you can specify when they are updated.
By default, SQL Server automatically creates and updates statistics for you. If you leave these setting on, the system will create an index whenever you perform certain operations against tables. You can change this behavior to a manual setting if the creation and updates on these indexes becomes a performance issue. Whenever the system creates or updates the indexes, it takes time, memory, storage and other resources. Most of the time the performance you gain by having these statistics current outweighs the cost of letting the system create and maintain them.
But sometimes it's more advantageous to take control of the statistics yourself. In a moment I'll show you how to find out if the statistics are being used, and when you should turn them off and on.
Automatic and Manual Statistics
First, let's take a look at how you can determine the setting for the statistics. They are either created manually or automatically, and they can be updated manually or automatically. In other words, you have several combinations you can use — you can have the system automatically create the statistics and you can maintain them yourself, you can create the statistics and have the system maintain them, or you can do it all manually or let the system decide. As I mentioned, normally it's best to let the system decide on both choices, unless you determine that it's becoming a system impact.
So what kind of information does SQL Server use to determine when the statistics need to be updated? Many types of data are used to make the decision to create a statistic index or to update it:
- The last time that the statistics were updated
- The average length of keys in a particular column
- The number of rows and pages occupied by a table’s data
- A histogram that displays the distribution of data
- String summaries created when performing LIKE queries on character data
- Index or key columns in your tables
You can see that you'll have to think long and hard about deciding to take this on yourself.
You can check to see what the setting for your database is turned on or off by right-clicking the database in either Enterprise Manager (SQL Server 2000) or SQL Server Management Studio (SQL Server 2005) and selecting "Properties" from the menu that appears, in the "Options" area. A simple click there turns the creation and the maintenance on and off.
You can also use a query to find the same information using the sp_dboption stored procedure. This sample query shows the setting for the AdventureWorks database in a SQL Server 2005 instance:
/* Show whether statistics are enabled for a database */ EXEC sp_dboption AdventureWorks,’auto update statistics’; GO You can use that same stored procedure to turn the automatic setting on (True) or off (False): /* Turn on automatic statistics */ EXEC sp_dboption AdventureWorks, ’auto update statistics’, ’TRUE’; GO
There's another stored procedure, called sp_autostats that also controls the statistics. It just needs the database name and the state you want:
/* Turn on automatic statistics - use OFF to turn them off*/ EXEC sp_autostats AdventureWorks, ’ON’; GO
If you turn that setting off, you can create the statistics manually with the CREATE STATISTICS command. There several options with this command, which you can read more about in Books Online. The primary parts are the table name for the index, the columns to include in the index, and importantly, how many rows to sample for the index, using a PERCENT or FULLSCAN option. This last part is important because if it is a really big table, this can take some time. If you're doing this manually, then the odds are that you did so for performance reason.
There's a tradeoff here, just like many performance tuning decisions. If you don't sample enough rows, the statistical index won't be as useful. If you sample more rows, or all of them using the FULLSCAN option, it can impact performance again.
Here's the general syntax — as I mentioned, you can find the full syntax in Books Online:
CREATE STATISTICS statistical index name ON table or view ( column 1, column 2, etc. ) WITH FULLSCAN or SAMPLE number of PERCENT or number of ROWS
Once you create the statistics, you can also manually update them. Remember, you can have SQL Server automatically update statistics, even if you created them manually.
/* Update statistics on a table – replace tablename with your table's name */ UPDATE STATISTICS tablename; GO /* or you can update statistics on all tables */ EXEC sp_updatestats; GO
Statistics Meta Data
Now that you know how the statistics are created, you can start finding out about them. You can use the sp_helpstats stored procedure. It takes one parameter — the name of the object the statistics are on:
USE AdventureWorks; GO EXEC sp_helpstats [Sales.Customer]; GO
That will get you the statistics for an object. But what if you don't know the name? Well, you can go at the system tables for the names that Microsoft uses that start with an underscore character. Unfortunately, not all statistics are named this way:
/* Show the statistics by table – 2000, if named with an underscore */ SELECT a.name, b.name FROM sysindexes a INNER JOIN sysobjects b ON a.id = b.id WHERE a.name LIKE ’[_]%’ ORDER BY b.name; GO
For 2005, it's a bit simpler, and has :
/* Show statistics from SQL Server 2005 */ SELECT a.name AS ’Statistic’, b.name AS ’Table’ FROM sys.stats a INNER JOIN sys.sysobjects b ON a.object_id = b.id WHERE a.auto_created = 1 or a.user_created = 1 ORDER BY b.name; GO /* This stored procedure shows statistics per table */ EXEC sp_helpstats ’Production.Product’; GO
Are these statistics even being used? You can find out in two places: in the Query Analyzer or SQL Server Management Studio Query windows using the Showplan tool that I described here. A red line on a query output will show you that the statistics are out of date and you can right-click that line to update them.
Also, SQL Server Profiler can show you that Hash warnings or that a column is missing statistics. Once you use one of these two tools you can find more information about them using these scripts:
/* Find out when statistics were last updated for SQL 2K5 */ SELECT name AS ’Statistic’, STATS_DATE(object_id, index_id) AS ’Last Updated’ FROM sys.indexes WHERE object_id = OBJECT_ID(’Production.Product’); GO -- Can use this for 2K DBCC SHOW_STATISTICS (’Person.Address’, AK_Address_rowguid); GO
The upshot is this — it's often best just to leave the statistics automatically set and maintained by SQL Server. If you do change this setting, use these techniques to work with them.
InformIT Articles and Sample Chapters
If you're using SQL Server version 7, the statistics work in a similar way, but you maintain them differently. You can read more here.
If you really want to know more, go here.