How to update statistics for a database's system tables
Ola's index maintenance script has parameter SYSTEM_DATABASES
--> All system databases (master, msdb, and model)
for UpdateStatistics
--> ALL - Update index and column statistics.
that takes care of updating stats for system databases as well.
Also, refer to Statistics on system tables and query performance. I have seen it very rare to update stats on system tables unless you have very large amount of objects in them (I still use Ola's script for weekly index maint on system tables).
As a side note: since you upgraded to SQL Server 2016, are you using the new CE ? What is the compatibility mode ?, were the post upgrade steps done ?.
EDIT:
Automatic soft NUMA is beneficial - 30% gain in query performance was obtained by using Soft NUMA & proper MAX DOP setting.
A small note : Please dont use undocumented sp_MSforeachDB
. May be a dynamic sql is a much better option.
e.g.
select 'ALTER DATABASE '+quotename(name)+' SET COMPATIBILITY_LEVEL = 130;'
from sys.databases where database_id > 4 and state_desc = 'ONLINE'
If you are consistently seeing the behaviour of those system base tables getting out dated, then you should file a connect bug for it.
You can "see" the system tables without using DAC connection:
SELECT *
FROM sys.objects o
WHERE o.type = 'S'
ORDER BY o.name
From there, you could build a TSQL string of commands and execute it. (I hardcoded sys
for the schema. Presumably this will never change.):
DECLARE @TSql NVARCHAR(MAX) = ''
SELECT @TSql = @TSql + 'UPDATE STATISTICS sys.' + o.name + ' WITH FULLSCAN;' + CHAR(13) + CHAR(10)
FROM sys.objects o
WHERE o.type = 'S'
ORDER BY o.name
--Verify/test commands.
PRINT @TSql
--Uncomment and re-run when ready to proceed.
--EXEC sp_executesql @TSql
This could easily be put into a job step for a SQL Agent job. I tested this on SQL Server 2012 w/ SP3. I've also run similar code in SQL 2008 R2 and SQL 2014. I don't know for sure if it works in SQL 2016--please let us know if it does not.
Other Notes
The UPDATE STATISTICS
commands worked when I was logged in as a [sysadmin]. It also worked if the login was not a member of [sysadmin], but was the database owner. Membership in [db_owner] alone was not sufficient. (Again, this was on SQL 2012 w/ SP3. YMMV.)