For systems that do not have a full-time DBA, one of the easiest methods for managing statistics is the Update Statistics Task.\u00a0 This task can be configured for all databases or certain databases, and you can determine what statistics it updates:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n You might think you want to update All existing statistics.\u00a0 If you just had a plan with just this task, that might<\/em> be true.\u00a0 But what I see most often is that someone configures the Rebuild Index task, and then has the Update Statistics task as the next step.\u00a0 In that case, if you are running SQL Server 2014 and below, you want to update Column statistics only.\u00a0 When you run the Rebuild Index task in SQL Server 2014, you rebuild all indexes, and when you rebuild an index, its statistic is updated with a fullscan.\u00a0 Therefore, there is no need to update Index statistics after you rebuild all your indexes, but you do need to update column statistics.<\/p>\n This is a bit more complicated in SQL Server 2016.\u00a0 The Rebuild Index task has more options in SQL Server 2016, which is nice for that specific task, but it makes providing guidance about statistics updates a bit trickier.\u00a0 In SQL Server 2016 you can configure the Rebuild Index task so that it only rebuilds an index if a certain level of fragmentation exists.\u00a0 Therefore, some of your indexes will rebuild (and thus have statistics updated) and some will not (and not have updated statistics).\u00a0 How do you manage that with the Update Statistics task?\u00a0 Well, in that case you probably select All existing statistics and update some statistics for a second time, which is really a waste.\u00a0 Therefore, if you’re on SQL Server 2016, you probably want to look at more intelligent updates.<\/p>\n One method, which I would not say is intelligent, but it is an option, is to use sp_updatestats in a scheduled job that runs on a regular basis.\u00a0 This command is one you run for a database, not for a specific statistic or index or table.\u00a0 The sp_updatestats command will only update statistics if data has changed.\u00a0 That sounds good, but the caveat is that only one (1) row has to have changed.\u00a0 If I have a table with 2,000,000 rows, and only 5 rows have changed, I really don’t need to update statistics.<\/p>\n The other method is to use UPDATE STATISTICS in a scheduled job.\u00a0 The UPDATE STATISTICS command can be run for individual statistics or for a table (updating all statistics for a table).\u00a0 You can<\/em> develop an intelligent method to use this command, which is what I recommend.\u00a0 Rather than a blanket update to all statistics, or statistics where one row has changed, I prefer to update statistics that are outdated based on the amount of data that has changed.\u00a0 Consider the aforementioned table with 2,000,000 rows.\u00a0 If I let SQL Server update statistics automatically, I would need 400,500 rows to change.\u00a0 It’s quite possible that with a table of that size I would want to statistics to update sooner – say after 200,000 rows had changed, or 10% of the table.<\/p>\n We can programmatically determine whether we need to update statistics using the sys.dm_db_stats_properties<\/a> DMF.\u00a0 This DMF tracks modifications, and also tells us how many rows were in the table when statistics were last updated, and the date statistics were updated. For example, if I update some rows in Sales.SalesOrderDetail, and then look at the output from the DMF, you can see that the modification counter matches the number of rows I changed* for the ProductID index:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n *You’re correct, I technically didn’t change ProductID to a new value, but SQL Server doesn’t know that.\u00a0 Also, there’s a foreign key on that column which is why I can’t easily change it a random number.<\/em><\/p>\n Armed with this type of data, we can intelligently decide whether we should update statistics because a percentage of rows (rather than just a fixed number of rows) have changed.\u00a0 In the example above, only 8% of data changed – probably not enough to require me to update statistics.\u00a0 It’s quite possible that some statistics need to be updated daily because there is a high rate of change, and other statistics only need to be updated weekly or monthly because data doesn’t change much at all.<\/p>\n Ultimately, when it comes to scheduled updates of statistics, you can go the sledgehammer route (Update Statistics task or sp_updatestats) or the selective update route (UPDATE STATISTICS and sys.dm_db_stats_properties).\u00a0 Using the Update Statistics task or sp_updatestats is easier if you’re not familiar with SQL Server and if you have the maintenance window and resources for it to run.\u00a0 To be perfectly clear: if you’re a system administrator and want to update statistics, I’d rather you use this approach than nothing at all.\u00a0 Presumably, if you don’t have a full-time DBA, you also don’t need the system to be available 24×7, so you can take the performance hit at night or on the weekend while all statistics update.\u00a0 In that situation I’m ok with the approach.<\/p>\n But, if you are a DBA and you know how to write T-SQL, then you can absolutely write some code that programmatically looks at your statistics and decides what to update and what to skip.\u00a0 Whatever method you use, just make sure your updates are scheduled to run regularly through an Agent Job, and make sure you have Auto Update Statistics enabled just in case the job doesn’t run and you don’t get notified for some reason (this would be Plan B, because it’s always good for DBAs to have a Plan B!).<\/p>\n Additional Resources<\/p>\n In last week’s post I discussed the basics of how automatic updates to statistics occur in SQL Server.\u00a0 This week I want to talk about scheduled (aka manual) updates, because as you might remember, we really want to control when statistics are updated. In terms of updating statistics you have multiple options, including: Update Statistics […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[47,17],"tags":[],"yoast_head":"\n![\"Update](\"https:\/\/www.sqlskills.com\/blogs\/erin\/wp-content\/uploads\/2017\/03\/stats.jpg\")
<\/a>\r\nUSE [AdventureWorks2012];\r\nGO\r\n\r\nUPDATE [Sales].[SalesOrderDetail]\r\nSET [ProductID] = [ProductID]\r\nWHERE [ProductID] IN (921,873,712);\r\nGO\r\n\r\nSELECT\r\n[so].[name] [TableName],\r\n[ss].[name] [StatisticName],\r\n[ss].[stats_id] [StatisticID],\r\n[sp].[last_updated] [LastUpdated],\r\n[sp].[rows] [RowsInTableWhenUpdated],\r\n[sp].[rows_sampled] [RowsSampled],\r\n[sp].[modification_counter] [NumberOfModifications]\r\nFROM [sys].[stats] [ss]\r\nJOIN [sys].[objects] [so] ON [ss].[object_id] = [so].[object_id]\r\nCROSS APPLY [sys].[dm_db_stats_properties] ([so].[object_id], [ss].stats_id) [sp]\r\nWHERE [so].[name] =\u00a0 N'SalesOrderDetail';\r\nGO\r\n<\/pre>\n
<\/a>\n