我有一个每晚完整的备份，以及一个2小时的事务日志。 完整的备份还会在运行时收缩并检查数据库的完整性。
除了syspolicy_purge_history作业之外，似乎没有任何其他作业运行，我相信这是SQL自动创build的作业。
谢谢
一些事情。
1）closuresAUTO SHRINK。 它的邪恶，可能是长期性能问题的来源，因为它可能导致文件级碎片。
2）如上所述，它看起来像自动closures打开。 你需要把它关掉，因为这是另一个不利于良好performance的。 为什么？ 每次closures最后一个连接时，SQL Server都试图closures自己，这导致清除过程和数据caching。 这两个是通过减less从磁盘读取数据的需要来支持良好的性能，这比从内存中读取更昂贵。 而生成执行计划是一个cpu密集型的过程，你的sql服务器必须从自动closures回来后生成计划。 现在，你知道它在做什么，继续并closuresAUTO CLOSE。
3）SQL Server实际上并不是在执行DBCC CHECKDB，而是在读取存储最后一次运行DBCC CHECKDBdate的启动文件后显示一条消息。 它只是写入日志文件，而不是真的在这里运行CHECKDB。 看起来你运行CHECKDB已经有2个多月的时间了，并且你可以定期运行CHECKDB。
http://technet.microsoft.com/en-us/magazinebeta/2009.10.sqlqa.aspx
我会检查你的数据库是否启用了Auto_Close。 启用后，一旦最后一个用户退出连接，数据库将closures并释放资源。 当新用户来使用数据库时，它重新打开。 如果你的数据库每次打开数据库都运行checkdb，那么这可能是你的问题。
以下查询将检查所有数据库上的Auto_Close：
SELECT * FROM sys.databases
WHERE is_auto_close_on = 1
当我没有任何计划时，我有一个类似的奇怪的DBCC CHECKDBs运行。 一些小的挖掘将我带到了我们的一位服务器工程师，他们被指示使用赛门铁克备份数据库（这些是Sharepoint dbs）。 就在他的备份之前，Symantec工具被configuration为运行DBCC CHECKDB。 在这种情况下赛门铁克保持连接，所以活动监视器帮我弄清楚了。
感谢这篇文章，我只是修复了3个数据库，通过禁用自动closures和自动收缩来摆脱那些“启动数据库…”和“检查数据库”消息每隔5分钟
And possible errors caused by them 27/08/2010 10:09:01 SQL Server has encountered 3 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations. 27/08/2010 10:09:01 SQL Server has encountered 3 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to some database maintenance or reconfigure operations. 27/08/2010 10:09:00 SQL Server has encountered 3 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.