最近我将我的开发机器升级到了 Windows 10 和 SQL Server 2014 SP1 Express (12.0.4213)。
然后我注意到我的应用程序有时会因超时异常而崩溃。它是一个非常小的 .NET 应用程序，具有 100MB 的数据库和每秒很少的简单查询。该应用程序与服务器运行在同一台机器上，并通过共享内存进行连接。
当又一次超时发生时，我尝试使用 SSMS 连接到服务器，发现整个服务器都没有响应。仅仅登录就进行了几次尝试，由于超时，我无法启动活动监视器。然后我尝试重新启动服务器，花了大约 1 分钟才停止。
该问题每天发生数次。有时它会在超时后继续正常工作，有时我必须重新启动服务器并快速重新启动，有时它在重新启动期间挂起一段时间。
即使在冻结期间，服务器也不会消耗超过 5% 的 CPU 和 300 MB 内存。通常有几百 MB 的可用 RAM 和几 GB 的交换空间可用。
问题发生时事件日志中没有错误或警告。上周几乎没有错误：17300、17312、28709。不确定它们是否对应于这些超时之一。这些都没有发生在过去 2 天内，但问题继续出现。
同一个应用程序在 Windows 7 上使用 SQL Server 2012 SP1 Express 时从未遇到任何问题。
如何解决这个问题？
更新
应用程序数据库启用了自动关闭，我禁用了它。此外，我不得不删除一些数据，因此数据库现在大约为 20 MB。
现在应用程序的超时发生频率降低（大约每天 1 次）。但是，SSMS 中的活动监视器几乎总是超时。查看数据库属性等操作的执行速度也非常缓慢（大约需要 20 秒）。
sp_readerrorlog除了启动信息外，该命令不显示任何内容。例子。
当我在活动监视器中超时并且磁盘负载低于 20% 时，我还监视了磁盘活动。
如何使用无限循环的 plperl 函数终止会话？
双方pg_terminate_backend并pg_cancel_backend没有任何影响。kill -1 pid什么也没做，kill -9 pid服务器崩溃了。
我有一个奇怪的情况，mysql OPTIMIZE 查询永远不会结束。Killinh 后，它仍处于“killed”状态。
重现场景：
我有一个包含 40MB 数据和 1500 条记录的表。当 myisam_repair_threads 设置为 1 时，OPTIMIZE 将在一秒钟内完成。将 myisam_repair_threads 设置为 2 需要很长时间才能完成。终止查询后，它仍处于“已终止”状态（在撰写本文时已经 3 小时了）。看来这是mysql的一个bug。
然而，最大的问题是：我怎样才能强制终止这个查询？它当前持有表元数据的锁，因此某些进程无法执行，因为它们正在等待该锁。
任何建议表示赞赏！
我在我的 ldf 文件中收到错误 833，而且我收到了很多错误。
请参阅以下内容。发生这种情况时，我的应用程序已经挂起。
我知道错误 833 已被多次报告，但是如果它始终指向我无法访问的 LDF 文件，这意味着什么？是不是因为LDF文件已经很大了？
我在 Windows 2008 环境中使用 SQL Server 2008 R2。数据库处于无响应状态，重启是唯一删除挂起 I/O 的方法。一旦开始，它还没有结束。
对此有什么可能的解释？请查看 sql 错误日志中的日志文件。
可能也是因为这个错误吗？
http://support.microsoft.com/kb/2708012
顺便说一句，sql server 一直没有响应，这发生在夜间。只有重新启动才能使服务器再次响应。
01/21/2013 12:22:09,spid3s,Unknown,SQL Server has encountered 19 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [E:\MSSQL.1\MSSQL\DATA\test_database_log.LDF] in database [test_database] (6). The OS file handle is 0x00000000000008B8. The offset of the latest long I/O is: 0x00001028a8ac00
01/21/2013 12:15:29,spid3s,Unknown,SQL Server has encountered 17 occurrence(s) of I/O requests taking longer than …