Server可疑数据库-一周内2次

Question

也许这不适合在这里，但我会张贴，有人可以建议在其他地方。抱歉这么多角色..。

这周我们有过两次同样的数据库被怀疑，(我很想明天去度假！)发生在同样的过程中..。即使是在大约。同时，一旦恢复，DBCC就可以很好地完成。- Server 2008 R2 (SP2) -700 db db。-相同的查询(从暂存表合并)- PAGELATCH_EX的相同等待类型超时(缓冲区锁存-排他)

我整个星期都在看这个--我不知道该去哪儿。该查询是对价值2.5年的数据进行全面扫描，更新3天。它可以使用WHERE子句来限制所涵盖的内容，但是读取您不希望在合并中这样做。在好的一天，这个负载通常在早上7:30结束，但是直到晚上7:30才收集数据，所以我把工作移到了早上8:30。

在失败时，查询正在等待“PAGELATCH_EX”。它等待了5:00分钟(早上6:35-6:40)，然后超时。

之后，Server标记了不一致性并试图撤消。它们使用的是TF610，我看到它用于批量/最小日志记录操作。它无法恢复，然后经历了逻辑损坏，我们选择恢复时间限制(vs DBCC重建w/损耗)。

我对这个角色还很陌生，所以我在找一把冒烟的枪，却找不到。这里的另一个DBA建议增加服务器上的RAM。我雇了我们的仓库管理员，他说他没看到什么不寻常的事。有人有建议吗？

到目前为止我们所做的：

1.将最大内存增长到50 to (从28 to使应用程序与供应商规范相一致)

2.将数据文件的空闲空间分别增长了(30 of )(包括完整的3年数据集，并试图避免数据文件动态增长)

。

3.修补到SP3

的实例

下面是日志的一个片段：

============================================：上午6:34分: 610，服务器进程ID 51。这只是一条信息性消息；不需要用户操作。(这样做的想法是，当您插入大量数据时，您不想创建大量的事务日志-但是可能会导致问题--从而导致跟踪延迟通知。)上午6时40分:等待缓冲区锁存时出现超时--类型4，bp 000003B2FE9440，第5页:14263304，stat 0xc8800b，数据库id: 6，分配单元Id: 72057947483930624，任务0x0000000005C13288 : 0，等待时间300，标志0x1000001a，拥有任务0x0000000005C13288。不会再等下去了。上午6:40: ex_raise2:异常引发，major=52，minor=43，state=4，severity=22，试图在早上6:40创建症状转储:在内部操作中检测到不一致。请与技术支持联系。上午6时40分:在撤消数据库'DAX_BI‘中的日志操作时，日志记录ID (2375509:95987:341)出现错误。通常，以前会将特定的故障记录为Windows事件日志服务中的错误。从备份中还原数据库或文件，或修复数据库。上午6:43分:由于例程'XdesRMReadWrite::RollbackToLsn‘中的5243错误，数据库DAX_BI被关闭。在所有到数据库的连接中止后，将尝试重新启动非快照数据库。上午6点43分:数据库“DAX_BI”的日志不可用。检查事件日志中是否有相关错误消息。解决任何错误并重新启动数据库。上午6:43分:在撤消数据库'DAX_BI‘中的日志操作时，日志记录ID (2375509:96089:161)出现错误。通常，以前会将特定的故障记录为Windows事件日志服务中的错误。从备份中还原数据库或文件，或修复数据库。上午6点43分:数据库“DAX_BI”的日志不可用。检查事件日志中是否有相关错误消息。解决任何错误并重新启动数据库。上午6:43分:在撤消数据库'DAX_BI‘中的日志操作时，日志记录ID (2375505:16336:11)出现错误。通常，以前会将特定的故障记录为Windows事件日志服务中的错误。从备份中还原数据库或文件，或修复数据库。上午6点43分:启动数据库'DAX_BI‘。上午6:43分:数据库'DAX_BI‘(6)的恢复完成率为0% (大约还有728秒)。3的第二阶段，这是一条信息性的消息。不需要用户操作。上午6:43分:数据库'DAX_BI‘(6)的恢复完成率为0% (约425秒)。3的第二阶段，这是一条信息性的消息。不需要用户操作。上午6:43分:数据库'DAX_BI‘(6)的恢复完成率为0% (约425秒)。第三阶段，这是一条信息信息。不需要用户操作。上午6:47分:在恢复过程中发生错误，防止数据库'DAX_BI‘(数据库ID 6)重新启动。诊断恢复错误并修复它们，或者从已知的良好备份恢复。如果错误没有得到纠正或预期，请与技术支持联系。============================================

Answer 1

您是否检查了windows日志，以确定在采样时间内是否还发生了其他事情？这可能会引导你去做进一步的调查。

此外，请检查代理程序(或可能涉及的任何其他调度程序)在事件发生时作业是否正在运行，这可能会导致某些奇怪的行为。

服务器上有防病毒软件吗？(然后您应该尝试排除数据库文件)。

另外，它可能实际上是您正在为Server运行的SP/CU中的一个bug，您可以更新到最新的SP/CU吗？