症状
假设你有一个在 Microsoft SQL Server 2008 或 SQL Server 2008 R2 中启用了透明数据加密(TDE)的数据库,针对该数据库的任何写操作都将在 WRITELOG 或 LOGBUFFER 上永久等待。 当数据库处于完整恢复模式并且计划的日志备份定期执行时,在问题被点击后,SQL Server 错误日志中的第一个和最后一个日志序列号(LSN)数字同样适用于后续日志备份。 在此时间范围内,仍建议确认是否需要任何用户活动。 LSN 数字可能不会更改,因为缺少用户活动不会导致写入操作。 相关的 SQL Server 错误日志条目如下所示:
日志已备份。 数据库: <DataBaseName>,创建日期(time): <日期><时间>,第一个 lsn:76383:11154:1,最后一个 lsn: 76383:11154:1 ...。 这只是一条信息性消息。 无需用户操作。日志已备份。 数据库: <DataBaseName>,创建日期(time): <日期><时间>,第一个 lsn:76383:11154:1,最后一个 lsn: 76383:11154:1 ...。 这只是一条信息性消息。 无需用户操作。
此问题并非特定于数据库在完全恢复模式下,具有其他恢复模式的数据库也容易遇到相同问题。 此外,你还可能在系统表 sysprocesses中看到回退状态的 SPID。
原因
出现此问题的原因是围绕 TDE 的一些基础异常。
解决方案
在 SQL Server 的以下累积更新中,此问题首先已修复。 应用此修补程序后,当你遇到此问题(而不是无限期地等待 WRITELOG 或 LOGBUFFER)时,SQL Server 会使数据库脱机,而无需重新启动 SQL Server 服务即可使数据库恢复联机状态。 在某些情况下,数据库将由 SQL Server 自动重新联机,无需任何人为干预。 相关信息将记录在 SQL Server 错误日志中。此修复程序将不会完全解决此问题。 但是,当再次出现问题时,其他诊断信息(基于类型和错误严重性)可能会记录在 SQL Server 错误日志中。 你必须标识实际异常并使用可在应用修补程序后检索的其他诊断信息的帮助来修复它。
SQL Server 2008 R2 SP2 的累积更新13 /en-us/help/2967540
SQL Server 2008 SP3 的累积更新17 /en-us/help/2958696
SQL Server 的每个新的累积更新均包含以前的累积更新中包含的所有修补程序和所有安全修补程序。 查看 SQL Server 的最新累积更新:
状态
Microsoft 已确认这是在“适用范围”部分中列出的 Microsoft 产品存在的问题。