SQL 问题与解答 意外的一致性检查、内存使用量疑难解答及其他

Paul S. Randal

问题我已经注意到异常发生,因为已移动到 SQL Server 2005 数据库的某些内容。 无论何时服务器启动,看中错误日志,指示的 SQL Server 作为启动过程的一部分运行数据库一致性检查的邮件。 它实现此为某些的数据库而不是系统数据库。 检查似乎非常快速地运行,无论如何大型数据库,并每次 SQL Server 启动时,会发生。 您可以解释正在运行的内容?

答案非常少数人已被询问有关此各种联机论坛中。 下面是示例之一的错误日志消息的问题:

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

它当然会看起来运行 DBCC CHECKDB 执行数据库范围内的一致性检查) 的"母版"数据库,但它并不是实际情况。 此消息只报告统计有关数据库调用,"最后一次的正确"时间。

从开始前向 SQL Server 2005,只要 DBCC CHECKDB 完成一致性检查数据库没有找到任何一致性错误 (也就是该数据库是自由损坏),DBCC CHECKDB 完成的时间将记录在数据库 (存储有关它的关键元数据的数据库中单个页) 的启动页。

每次启动是一个数据库 (实例启动或数据库连接),查看是否有一个存储"最后一次的正确"检查启动页时间,并且因此,错误日志中报告。 遗憾的是,记录的无法查询此的值但可以使用许多未记录的命令找到它。 一个家伙 MVP,Sankar Reddy,最近 blogged 脚本 将它为您的。

存储在"最后一次的正确"基本原理时间是它可以在了解多长时间 (可能) 数据库可能已损坏灾难恢复情况下非常有用。

问题我希望能够确定 SQL Server 的内存量正在使用每个数据库。 我注意到一个 SQL Server 2005 实例,突然在服务器上使用几乎所有可用的内存,并且我担心的某个位置出现问题。 是否有可能出在此内存正在使用从 SQL Server 中?

答案的好消息是这不可能有问题。 SQL Server 2005 将使用它的能够必要时,但会响应来自以释放内存,操作系统内存压力请求的内存。 突然内存使用情况,您会看到可能是数据库的展开以允许更多,以保留在内存中缓冲池。

缓冲池 (有时称为高速缓冲存储器) 中 SQL Server 存储引擎层的一部分,负责管理的数据文件中 SQL Server 实例不同的数据库中的部分内存中的副本。 如果查询启动需要大量的数据库页读入内存 (例如一个大型表扫描或联接),缓冲池可能获取从操作系统的多个服务器内存,以便它可以展开。 这使得不必一定放弃内存中的副本的其他正在使用的其他查询的数据库页中容纳额外的页面图像在内存中。

作为一个顺便,添加更多内存使用 SQL Server 的优点之一是缓冲池中可以更大。 这意味着更多的数据可以在内存中鍦任何壒瀹氱殑鏃堕棿可能导致减少的 I/O 和更好地工作负荷的吞吐量。

实例缓存大量不同的查询计划是在另一个调用该计划缓存,但我猜测的内存区域,如果是它的最可能在缓冲池了前面描述的有的使用大量内存,SQL Server 其他可能原因。

SQL Server 2005,您可以确定每个数据库使用,动态管理视图 sys.dm_os_buffer_descriptors,正在使用什么缓冲池比例。 此简单查询将告诉您多少 8 KB 页位于缓冲池中的每个数据库:

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

介绍这稍多一些的博客张贴内容", 存储引擎内的:该缓冲区池中有什么吗?"

其他节的内存使用 SQL Server,可以使用 DBCC MEMORYSTATUS 命令监视多少内存 SQL Server 实例使用的一个整数,但它不允许将被分解为每个数据库内存使用情况。 看一看知识库文章 907877,它描述了"如何使用 MEMORYSTATUS DBCC 命令监视内存使用情况 SQL Server 2005"

问题都因此通常其中一个数据库上 SQL Server 2005 实例将成为"置疑状态。我们不能访问数据库,其状态可疑。 有时,状态显示 RECOVERY_PENDING。 我知道这由损坏的某种,引起的但您可以解释它实际上意味着什么和如何恢复呢? 我们通常最终不必从旧的备份还原并丢失不是理想的数据。

答案 存在的大量混淆这两个数据库状态意味着,但您更正它们引起某种形式的损坏。 它们都表示的内容已经使用故障恢复的错误。

如果数据库没有完全关闭 (换而言是否有未提交的事务数据库关闭时) 然后数据库重新启动设置时, 必须通过故障恢复转。 故障恢复的确保在数据库的时间已提交的所有交易记录关机过程的正确反映在数据库,并且在关闭时未提交的所有交易记录不会反映在数据库中的任何方式。

有关更深入说明恢复的工作原理,请参阅我的文章上"了解日志和恢复中 SQL Server"从 2009 年 2 月发布。

数据库知道它是否干净地关闭向下或未 — 该信息存储在数据库引导页在第一个问题,解答我介绍。 如果需要崩溃恢复,则然后事务日志必须是可访问,为它所存储的需要重放 (提交) 事务的所有细节的并且 (提交) 交易记录必须被回滚。 如果事务日志不可用 (因为它已被删除,例如) 数据库状态将变为 RECOVERY_PENDING,故障恢复无法启动。 RECOVERY_PENDING 状态意味着故障恢复无法启动。

如果事务日志可用,崩溃恢复开始运行。 如果由于任何原因而无法完成,该数据库事务性不一致,则状态将变为可疑。 可疑状态表示恢复启动,但无法完成。

有两个恢复不能完成的原因。 第一个是本身,事务日志中的损坏导致事务日志记录不能通过 SQL Server 进行处理。 第二个是应用事务日志记录,在数据库页或反向数据库页上的事务日志记录的效果,正在尝试恢复系统时遇到的损坏中将数据文件。

另一个问题可以将数据库推入可疑的状态。 如果事务被取消由用户或应用程序,并且数据库遇到损坏时回滚事务的效果不能完成回滚后然后数据库是事务性不一致。 在这种情况下数据库将会自动脱机,并重状态将设置为可疑。

有两个常见的方法在这种情况下恢复。 第一个是从最新的备份还原。 旧备份时您可能丢失工作和数据,应重新评估备份策略与备份更经常允许恢复,而不丢失大量的数据的目标。 请参阅我的文章"了解 SQL Server 备份"在 7 月 2009年的有关的一些提示和技巧规划备份策略的 TechNet Magazine。 如果您要执行还原工艺路线,您应始终尝试尾部的-在-日志备份作为说明,本文时,这将允许您恢复到的问题进行数据库可疑的。

如果无备份可用,可以使用一种称为紧急模式修复的机制。 查看在 我全面的日志,描述了此功能的,说明其用法,显示了一些示例。

问题 有同步的数据库镜像与 SQL Server 2005 一起安装,我们注意到有时可能需要为数据库镜像故障转移时出现问题与主服务器的非常几秒钟。 我认为同步的数据库镜像使用见证方是将要提供即时故障检测。 这是怎么回事?

答案使用与数据库镜像见证服务器只允许镜像服务器自动启动故障转移。 见证同意 (或不) 镜像是否使用它可以"看到"主体服务器。 如果将见证服务器和镜像不能看到主体,镜像启动故障转移,并将成为新的主体。 见证服务器镜像配置数据库中是否存在无关如何快速故障是否检测到如何快速在发生故障转移。

即时故障检测是一种误解,故障检测到速度取决于失败的类型。 示例如下:

  1. 宕 ╂ 簝 SQL Server 实例 (宿主主体数据库)。 只要 Windows 仍在运行,并且响应,失败应最多一秒内被检测到。 每隔一秒,见证的镜像 ping 主体。 如果 SQL Server 实例不配置的 TCP 端口上侦听,Windows 知道这,并可以立即响应的 SQL Server 不存在。
  2. 整个主体服务器出现故障。 在这种情况下,Windows 不存在说 SQL Server 不正在侦听已定义的 TCP 端口,这样并没有什么没有说有什么存在。 在这种情况下失败将不会检测到直到镜像伙伴超时间隔。 这是每秒一次 ping,必须将不响应直到镜像声明主体的故障数。 默认情况下, 此数设置为 10 个 ping (和这样的 10 秒) 但如果它增加了由于任何原因而,故障检测将较长时间。
  3. 事务日志驱动器失败主体上。 最初不会在于 I/O 将开始对日志驱动器排队。 后 20 秒的时间 SQL Server 将打印在错误日志中的一个警告。 它是不是直到 40 秒经过 SQL Server 将声明 ­ 行关闭日志驱动器,并使数据库脱机以及,触发一个镜像的故障。
  4. 数据库页被损坏。 在这种情况下如果常规查询点击损坏,根本反应镜像。 但是,如果事务被回滚,如果遇到页损坏,数据库将成为可疑,我在以前回答,描述以及将立即触发一个镜像的故障。
  5. 如果文件组脱机主体数据库中,并且主文件组不受影响的企业版,部分数据库可用性将在启动然后故障不会发生。 在标准版,但是,故障将被触发。

正如您所看到一个镜像的故障检测到与速度真正取决于发生故障的类型和是否出现在镜像伙伴超时。

许多由于 Kimberly L。 用于从技术上讲查看 SQLskills.com 的 Tripp 这个月的列。

Paul S。Randal的是在管理 SQLskills.com 主管、 一个 Microsoft 区域主管和一个 SQL Server MVP。 他从事 SQL Server 存储引擎小组在 Microsoft 从 1999年 2007年。 Paul 编写 DBCC CHECKDB/修复 SQL Server 2005 但负责,核心存储引擎 SQL Server 2008 开发过程中。 Randal 灾难恢复、 高可用性和数据库维护方面的专家,常规演示者在全球范围内的会议。 他在 SQLskills.com/blogs/paul中,博客,您可以找到他在 Twitter Twitter.com/PaulRandal