According to our diagnostics, your server’s execution plan cache was recently erased. This can be caused by an OS restart, restarting the SQL Server service, or running DBCC FREEPROCCACHE.
Whenever you pass in a query, SQL Server has to turn your beautifully written T-SQL into an execution plan – a way of picking which indexes to use and in which order. It caches those plans in memory to reduce CPU requirements later if that T-SQL shows up again.
To improve performance, ask these questions:
Are you running any jobs to erase the plan cache or restart the server regularly? If so, we might be causing more problems than we’re solving.
Did you run an ALTER DATABASE that changed a database’s settings? If so, its execution plans will be removed from cache.
Is this server having much higher-level performance problems? Often this error shows up when we’re doing demos on underpowered laptops, for example, when we don’t have anywhere near enough memory to handle our workloads.
If you got a warning about USERSTORE_TOKENPERM, you can run one of these queries to verify, and check out this awesome round up post by sql.sasquatch to learn more about how to fix it.
|
1 2 3 4 5 6 7 8 9 10 11 |
/* 2012+ */ SELECT pages_kb / 1024.0 / 1024.0 AS pages_gb FROM sys.dm_os_memory_clerks WHERE type = 'USERSTORE_TOKENPERM' AND name = 'TokenAndPermUserStore'; /* 2008 and 2008R2 */ SELECT single_pages_kb / 1024.0 / 1024.0 AS pages_gb FROM sys.dm_os_memory_clerks WHERE type = 'USERSTORE_TOKENPERM' AND name = 'TokenAndPermUserStore'; |
For personalized help with getting the right answers for your server, we’ve got SQL Critical Care®.