物理数据库体系结构

物理数据库体系结构 1.页和区 SQL Server 中数据存储的基本单位是页。为数据库中的数据文件(.mdf 或 .ndf)分配的磁盘空间可以从逻辑上划分成页(从 0 到 n 连续编号)。磁盘 I/O 操作在页级执行。也就是说，SQL Server 读取或写入所有数据页。 区是八个物理上连续的页的集合，用来有效地管理页。所有页都存储在区中。 在 SQL Server 中，页的大小为 8 KB。这意味着 SQL Server 数据库中每 MB 有 128 页。每页的开头是 96 字节的标头，用于存储有关页的系统信息。此信息包括页码、页类型、页的可用空间以及拥有该页的对象的分配单元 ID。 1.1.页的类型 下表说明了 SQL Server 数据库的数据文件中所使用的页类型。 页类型 内容 当 text in row 设置为 ON 时，包含除 text、 ntext、image、nvarchar(max)、Data varchar(max)、varbinary(max) 和 xml 数据之外的所有数据的数据行。 Index 索引条目。 大型对象数据类型: text、 ntext、image、nvarchar(max)、varchar(max)、varbinary(max) 和 xml 数据。 Text/Image 数据行超过 8 KB 时为可变长度数据类型列: varchar、nvarchar、varbinary 和 sql_variant Global Allocation Map 有关区是否分配的信息。 Shared Global Allocation Map Page Free Space 有关页分配和页的可用空间的信息。 Index Allocation Map 有关每个分配单元中表或索引所使用的区的信息。 有关每个分配单元中自最后一条 BACKUP LOG 语句之后的大容量操作所修改的区Bulk Changed Map 的信息。 Differential Changed Map 有关每个分配单元中自最后一条 BACKUP DATABASE 语句之后更改的区的信息。 数据页上，数据行紧接着标头按顺序放置。页的末尾是行偏移表，对于页中的每一行，每个行偏移表都包含一个条目。每个条目记录对应行的第一个字节与页首的距离。行偏移表中的条目的顺序与页中行的顺序相反。 1.2.大型行支持 Microsoft SQL Server 2005 中引入了 max 说明符。此说明符增强了 varchar、nvarchar 和 varbinary 数据类型的存储能力。varchar(max)、nvarchar(max) 和 varbinary(max) 统称为大值数据类型。您可以使用大值数据类型来存储最大为 2^31-1 个字节的数据。 当 sp_tableoption 存储过程的 'large value types out of row' 选项设置为 OFF 时，大值类型的行内存储限制为 8000 个字节。当此选项设置为 ON 时，只在行内存储 16 字节的根。 在 SQL Server 2005 中，行不能跨页，但是行的部分可以移出行所在的页，因此行实际可能非常大。页的单个行中的最大数据量和开销是 8,060 字节 (8 KB)。但是，这不包括用 Text/Image 页类型存储的数据。在 SQL Server 2005 中，包含 varchar、nvarchar、varbinary 或 sql_variant 列的表不受此限制的约束。当表中的所有固定列和可变列的行的总大小超过限制的 8,060 字节时，SQL Server 将从最大长度的列开始动态将一个或多个可变长度列移动到 ROW_OVERFLOW_DATA 分配单元中的页。每当插入或更新操作将行的总大小增大到超过限制的 8,060 字节时，将会执行此操作。将列移动到 ROW_OVERFLOW_DATA 分配单元中的页后，将在 IN_ROW_DATA 分配单元中的原始页上维护 24 字节的指针。如果后续操作减小了行的大小，SQL Server 会动态将列移回到原始数据页。 一个表中的每一行最多可以包含 8,060 字节。在 SQL Server 2005 中，对于包含 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型列的表，可以放宽此限制。这些列中每一列的长度仍然必须在每行 8000 字节的限制内，但它们的合并宽度可以超过 8060 字节的限制。 当合并每行超过 8060 字节的 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列时，请注意下列事项: 超过 8060 字节的行大小限制可能会影响性能，因为 SQL Server 2005 Database Engine 仍保持每页 8 KB 的限制。当合并 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列超过此限制时，数据库引擎将把最大宽度的记录列移动到 ROW_OVERFLOW_DATA 分配单元的另一页上，而在原始页上保留一个 24 字节指针。如果更新操作使记录变长，大型记录将被动态移动到另一页。如果更新操作使记录变短，记录可能会移回 IN_ROW_DATA 分配单元中的原始页。此外，执行查询和其他选择操作(例如，对包含行溢出数据的大型记录进行排序或合并)将延长处理时间，因为这些记录将同步处理，而不是异步处理。 因此，当要 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 的表中包含多个 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列时，请考虑可能溢出的行的百分比，以及可能查询这些溢出数据的频率。如果可能需要经常查询行溢出数据中的许多行，请考虑对表格进行 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 化处理，以使某些列移动到另一个表中。然后可以在异步 JOIN 操作中执行查询。 对于 varchar、nvarchar、varbinary、sql_variant 或 CLR 用户定义类型的列，单个列的长度仍然必须在 8000 字 节的限制之内。只有它们的合并长度可以超过表的 8060 字节的行限制。 聚集索引的索引键不能包含在ROW_OVERFLOW_DATA 分配单元中具有现有数据的 varchar 列。如果对 varchar 列创建了聚集索引，并且在 IN_ROW_DATA 分配单元中存在现有数据，则对该列执行的将数据推送到行外的后续插入或更新操作将会失败。有关分配单元的详细信息，请参阅表组织和索引组织。 1.3.区 区是管理空间的基本单位。一个区是八个物理上连续的页(即 64 KB)。这意味着 SQL Server 数据库中每 MB 有 16 个区。 为了使空间分配更有效，SQL Server 不会将所有区分配给包含少量数据的表。SQL Server 有两种类型的区: A、统一区，由单个对象所有。区中的所有 8 页只能由所属对象使用。 B、混合区，最多可由八个对象共享。区中八页的每页可由不同的对象所有。 通常从混合区向新表或索引分配页。当表或索引增长到 8 页时，将变成使用统一区进行后续分配。如果对现有表创建索引，并且该表包含的行足以在索引中生成 8 页，则对该索引的所有分配都使用统一区进行。 2.物理数据库文件和文件组 2.1.文件类型 SQL Server 2005 将数据库映射为一组操作系统文件。数据和日志信息从不混合在相同的文件中，而且各文件仅在一个数据库中使用。文件组是命名的文件集合，用于帮助数据布局和管理任务，例如备份和还原操作。 SQL Server 2005 数据库具有三种类型的文件: 1、主数据文件，是数据库的起点，指向数据库中的其他文件。每个数据库都有一个主数据文件。主数据文件的推荐文件扩展名是 .mdf。 2、次要数据文件，除主数据文件以外的所有其他数据文件都是次要数据文件。某些数据库可能不含有任何次要数据文件，而有些数据库则含有多个次要数据文件。次要数据文件的推荐文件扩展名是 .ndf。 3、日志文件，包含着用于恢复数据库的所有日志信息。每个数据库必须至少有一个日志文件，当然也可以有多个。日志文件的推荐文件扩展名是 .ldf。 在 SQL Server 2005 中，数据库中所有文件的位置都记录在数据库的主文件和 master 数据库中。大多数情况 下，数据库引擎 使用 master 数据库中的文件位置信息。 2.2.数据文件页 SQL Server 2005 数据文件中的页按顺序编号，文件的首页以 0 开始。数据库中的每个文件都有一个唯一的文件 ID 号。若要唯一标识数据库中的页，需要同时使用文件 ID 和页码。下例显示了包含 4-MB 主数据文件和 1-MB 次要数据文件的数据库中的页码。 每个文件的第一页是一个包含有关文件属性信息的文件的页首页。在文件开始处的其他几页也包含系统信息(例如分配映射)。有一个存储在主数据文件和第一个日志文件中的系统页是包含数据库属性信息的数据库引导页。 2.3.文件大小 SQL Server 2005 文件可以从它们最初指定的大小开始自动增长。在定义文件时，您可以指定一个特定的增量。每次填充文件时，其大小均按此增量来增长。如果文件组中有多个文件，则它们在所有文件被填满之前不会自动增 长。填满后，这些文件会循环增长。 每个文件还可以指定一个最大大小。如果没有指定最大大小，文件可以一直增长到用完磁盘上的所有可用空间。如果 SQL Server 作为数据库嵌入某应用程序，而该应用程序的用户无法迅速与系统管理员联系，则此功能就特别有用。用户可以使文件根据需要自动增长，以减轻监视数据库中的可用空间和手动分配额外空间的管理负担。 3.空间分配和重新使用 3.1.管理区分配和可用空间 3.1.1.管理分配区 SQL Server 使用两种类型的分配映射表来记录区的分配: 全局分配映射表 (GAM) ，GAM 页记录已分配的区。每个 GAM 包含 64,000 个区，相当于近 4 GB 的数据。GAM 用一个位来表示所涵盖区间内的每个区的状态。如果位为 1，则区可用;如果位为 0，则区已分配。 共享全局分配映射表 (SGAM) ，SGAM 页记录当前用作混合区且至少有一个未使用的页的区。每个 SGAM 包含 64,000 个区，相当于近 4 GB 的数据。SGAM 用一个位来表示所涵盖区间内的每个区的状态。如果位为 1，则区正用作混合区且有可用页。如果位为 0，则区未用作混合区，或者虽然用作混合区但其所有页均在使用中。 3.1.2.跟踪可用空间 页可用空间 (PFS) 页记录每页的分配状态，是否已分配单个页以及每页的可用空间量。PFS 对每页都有一个字节，记录该页是否已分配。如果已分配，则记录该页是为空、已满 1% 到 50%、已满 51% 到 80%、已满 81% 到 95% 还是已满 96% 到 100%。 将区分配给对象后，数据库引擎 将使用 PFS 页来记录区中的哪些页已分配或哪些页可用。数据库引擎 必须分配新页时，将使用此信息。保留的页中的可用空间量仅用于堆和 Text/Image 页。数据库引擎 必须找到一个具有可用空间的页来保存新插入的行时，使用此信息。索引不要求跟踪页的可用空间，因为插入新行的点是由索引键值设置的。 在数据文件中，PFS 页是文件头页之后的第一页(页码为 1)。接着是 GAM 页(页码为 2)，然后是 SGAM 页(页码为 3)。第一个 PFS 页之后是一个大小大约为 8,000 页的 PFS 页。在第 2 页上，第一个 GAM 页之后是一个有 64,000 个区的 GAM 页;在第 3 页上，第一个 SGAM 页之后是一个有 64,000 个区的 SGAM 页。下图显示了数据库引擎分配和管理区所用的页的顺序。 3.2.管理对象使用的空间 索引分配映射 (IAM) 页映射分配单元使用的数据库文件的 4 GB 部分中的区。分配单元有下列三种类型: IN_ROW_DATA:用于存储堆分区或索引分区。 LOB_DATA:用于存储大型对象 (LOB) 数据类型，例如 xml、varbinary(max) 和 varchar(max)。 ROW_OVERFLOW_DATA:用于存储超过 8,060 字节行大小限制的 varchar、nvarchar、varbinary 或 sql_variant 列中存储的可变长度数据。 堆或索引的每个分区至少包含一个 IN_ROW_DATA 分配单元。根据堆或索引的架构，可能还包含一个 LOB_DATA 或 ROW_OVERFLOW_DATA 分配单元。 一个 IAM 页在文件中的范围为 4 GB，与 GAM 或 SGAM 页的范围相同。如果分配单元包含来自多个文件的区，或者超过一个文件的 4 GB 范围，那么一个 IAM 链中将链接多个 IAM 页。因此，每个分配单元在有区的每个文件中至少有一个 IAM 页。如果分配给分配单元的文件中的区的范围超过了一个 IAM 页能够记录的范围，一个文件中也可能会有多个 IAM 页。 IAM 页根据需要分配给每个分配单元，在文件中的位置也是随机的。系统视图 (sys.system_internals_allocation_units) 指向分配单元的第一个 IAM 页。该分配单元的所有 IAM 页都链接到一个链中。 IAM 页有一个标头，指明 IAM 页所映射的区范围的起始区。IAM 页中还有一个大位图，其中每个位代表一个区。位图中的第一个位代表范围内的第一个区，第二个位代表第二个区，依此类推。如果某个位是 0，它所代表的区将不会分配给拥有该 IAM 页的分配单元。如果这个位是 1，它所代表的区将被分配给拥有该 IAM 页的分配单元。 当数据库引擎 需要插入新行，而当前页中没有可用空间时，它将使用 IAM 和 PFS 页查找要分配的页，或者(对于堆或 Text/Image 页)查找具有足够空间容纳该行的页。数据库引擎 使用 IAM 页查找分配给分配单元的区。对于每个区，数据库引擎 将搜索 PFS 页，以查看是否有可用的页。每个 IAM 和 PFS 页覆盖大量数据页，因此一个数据库内只有很少的 IAM 和 PFS 页。这意味着 IAM 和 PFS 页通常位于内存中的 SQL Server 缓冲池中，所以能够很快找到它们。对于索引，新行的插入点由索引键设置。在这种情况下，不会出现上述搜索过程。 只有当数据库引擎无法在现有区内快速找到具有足够空间容纳要插入的行的页时，才会为分配单元分配一个新区。数据库引擎 使用比例分配算法从文件组的可用区中分配区。如果文件组内有两个文件，而一个文件的可用空间是另一个文件的两倍，那么每从后一个文件分配一页，就从前一个文件分配两页。这意味着文件组内的每个文件应该有近似的空间使用百分比。 3.3.跟踪已修改的区 SQL Server 2005 使用两个内部数据结构跟踪被大容量复制操作修改的区，以及自上次完整备份后修改的区。这些数据结构极大地加快了差异备份的速度。当数据库使用大容量日志恢复模式时，这些数据结构也可以加快将大容量复制操作记录至日志的速度。与全局分配图 (GAM) 和共享全局分配图 (SGAM) 页相同，这些结构也是位图，其中的每一位代表一个单独的区。 1、差异更改映射表 (DCM) : 这样便可以跟踪自上次执行 BACKUP DATABASE 语句后更改过的区。如果扩展盘区的位是 1，则自上次执行 BACKUP DATABASE 语句后扩展盘区已被修改。如果位是 0，则扩展盘区没有被修改。 差异备份只读取 DCM 页便可以确定已修改的区。这样大大减少了差异备份必须扫描的页数。运行差异备份所需的时间与自上次执行 BACKUP DATABASE 语句之后修改的区数成正比，而不是与整个数据库的大小成正比。 2、大容量更改映射表 (BCM) : 跟踪自上次执行 BACKUP LOG 语句后，被大容量日志记录操作修改的区。如果某个扩展盘区的位是 1，表明自上次执行 BACKUP LOG 语句后，该扩展盘区已经被有日志记录的大容量复制操作修改。如果位是 0，则该扩展盘区未被有日志记录的大容量复制操作修改。 尽管所有数据库中都显示 BCM 页，但只有在数据库使用大容量日志记录恢复模式时，才会与 BCM 页有关。在此恢复模式中，当执行 BACKUP LOG 时，备份进程将扫描 BCM 查找已经修改的区。然后，将那些区包括在日志备份中。如果数据库从数据库备份和一系列事务日志备份恢复，便可以恢复大容量日志记录操作。在使用简单恢复模式的数据库中，BCM 页是不相关的，因为大容量日志记录操作不记入日志。在使用完整恢复模式的数据库中， BCM 页同样不相关，因为该恢复模式将大容量日志记录操作视为有完整日志记录的操作。 DCM 页和 BCM 页的间隔与 GAM 和 SGAM 页的间隔相同，都是 64,000 个区。在物理文件中，DCM 和 BCM 页位于 GAM 和 SGAM 页之后。 4.表和索引体系结构 SQL Server 2005 数据库中的对象存储为 8 KB 页的集合。本节说明如何组织、存储和访问表和索引页。 4.1.表组织和索引组织 4.1.1.表组织 下图显示了表的组织。表包含在一个或多个分区中，每个分区在一个堆或一个聚集索引结构包含数据行。堆页或聚集索引页在一个或多个分配单元中进行管理，具体的分配单元数取决于数据行中的列类型。 4.1.2.分区 在 SQL Server 2005 中，表页和索引页包含在一个或多个分区中。分区是用户定义的数据组织单元。默认情况下，表或索引只有一个分区，其中包含所有的表页或索引页。该分区驻留在单个文件组中。具有单个分区的表或索引相当于 SQL Server 早期版本中的表和索引的组织结构。 当表或索引使用多个分区时，数据将被水平分区，以便根据指定的列将行组映射到各个分区。分区可以放在数据库中的一个或多个文件组中。对数据进行查询或更新时，表或索引将被视为单个逻辑实体。 4.1.3.聚集表、堆和索引 SQL Server 2005 表使用下列两种 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 之一来组织其分区中的数据页: 1、聚集表是有聚集索引的表。 数据行基于聚集索引键按顺序存储。聚集索引按 B 树索引结构实现，B 树索引结构支持基于聚集索引键值对行进行快速检索。索引中每个级别的页(包括叶级别的数据页)链接在一个双向链接的列表中。但是，通过使用键值来执行从一个级别到另一级别的导航。 2、堆是没有聚集索引的表。 数据行不按任何特殊的顺序存储，数据页也没有任何特殊的顺序。数据页不在链接列表内链接。 索引视图与聚集表具有相同的存储结构。 当堆或聚集表具有多个分区时，每个分区都有一个堆或 B 树结构，其中包含该指定分区的行组。例如，如果一个聚集表有 4 个分区，那么将有 4 个 B 树，每个分区一个。 4.1.4.非聚集索引 非聚集索引与聚集索引有一个相似的 B 树索引结构。不同的是，非聚集索引不影响数据行的顺序。叶级别包含索引行。每个索引行包含非聚集键值、行定位符和任意包含性列或非键列。定位符指向包含键值的数据行。 4.1.5.XML 索引 可以对表中的每个 xml 列创建一个主 XML 索引和多个辅助 XML 索引。XML 索引是 xml 数据类型列中的 XML 二进制大型对象 (BLOB) 的拆分和持久化的表示形式。XML 索引以内部表的形式存储。若要查看有关 XML 索引的信息，请使用 sys.xml_indexes 或 sys.internal_tables 目录视图。 4.1.6.分配单元 分配单元是堆或 B 树内用于根据页类型管理数据的页集合。下表列出了用于管理表和索引中的数据的分配单元类型。 分配单元类型 用于管理 包含除大型对象 (LOB) 数据以外的所有数据的数据行或索引行。 IN_ROW_DATA 页的类型为 Data 或 Index。 以下列一种或多种数据类型存储的大型对象数据:text、ntext、image、xml、varchar(max)、LOB_DATA nvarchar(max)、varbinary(max) 或 CLR 用户定义类型 (CLR UDT)。 页的类型为 Text/Image。 存储在超过 8,060 字节行大小限制的 varchar、nvarchar、varbinary 或 sql_variant 列中的ROW_OVERFLOW_DATA 可变长度数据。 页的类型为 Data。 在堆或 B 树的特定分区中，每种类型只能有一个分配单元。若要查看表或索引的分配单元信息，请使用 sys.allocation_units 目录视图。 4.1.7.IN_ROW_DATA 分配单元 对于表(堆或聚集表)、索引或索引视图使用的每个分区，只有一个 IN_ROW_DATA 分配单元，它由一个数据页集合构成。此分配单元还包含其他页集合，这些集合用来实现为表或视图定义的每个非聚集索引和 XML 索引。表、索引或索引视图的每个分区中的页集合由 sys.system_internals_allocation_units 系统视图中的页指针定位。 每个表、索引和索引视图分区在 sys.system_internals_allocation_units 中有一行，该行由容器 ID (container_id) 唯一标识。容器 ID 与 sys.partitions 目录视图中的 partition_id 之间具有一对一的映射，用于维护分区中存储的表、索引或索引视图数据与用来管理分区内数据的分配单元之间的关系。 表、索引或索引视图分区的页分配由一个 IAM 页链管理。sys.system_internals_allocation_units 中的 first_iam_page 列指向 IAM 页链(用于管理分配给 IN_ROW_DATA 分配单元中的表、索引或索引视图的空间)中的第一个 IAM 页。 4.1.8.ROW_OVERFLOW_DATA 分配单元 对于表(堆或聚集表)、索引或索引视图使用的每个分区，都有一个 ROW_OVERFLOW_DATA 分配单元。此分配单元包含零 (0) 页，直到 IN_ROW_DATA 分配单元中带有可变长度列(varchar、nvarchar、varbinary 或 sql_variant)的数据行超过 8 KB 的行大小限制。达到大小限制后，SQL Server 将把最宽的列从该行中移动到 ROW_OVERFLOW_DATA 分配单元中的页中。原始页上将维护一个指向此行外数据的 24 字节指针。 ROW_OVERFLOW_DATA 分配单元中 Text/Image 页的管理方式与 LOB_DATA 分配单元中页的管理方式相同。即，使用 IAM 页链管理 Text/Image 页。 4.1.9.LOB_DATA 分配单元 当表或索引有一个或多个 LOB 数据类型时，将为每个分区分配一个 LOB_DATA 分配单元，以管理该数据的存储。LOB 数据类型包括 text、ntext、image、xml、varchar(max)、nvarchar(max)、varbinary(max) 和 CLR 用户定义类型。 4.2.堆结构 堆是不含聚集索引的表。堆的 sys.partitions 中具有一行，对于堆使用的每个分区，都有 index_id = 0。默认情况下，一个堆有一个分区。当堆有多个分区时，每个分区有一个堆结构，其中包含该特定分区的数据。例如，如果一个堆有四个分区，则有四个堆结构;每个分区有一个堆结构。 根据堆中的数据类型，每个堆结构将有一个或多个分配单元来存储和管理特定分区的数据。每个堆中的每个分区至少有一个 IN_ROW_DATA 分配单元。如果堆包含大型对象 (LOB) 列，则该堆的每个分区还将有一个 LOB_DATA 分配单元。如果堆包含超过 8,060 字节行大小限制的可变长度列，则该堆的每个分区还将有一个 ROW_OVERFLOW_DATA 分配单元。有关分配单元的详细信息，请参阅表组织和索引组织。 sys.system_internals_allocation_units 系统视图中的列 first_iam_page 指向管理特定分区中堆的分配空间的一系列 IAM 页的第一页。SQL Server 2005 使用 IAM 页在堆中移动。堆内的数据页和行没有任何特定的顺序，也不链接在一起。数据页之间唯一的逻辑连接是记录在 IAM 页内的信息。 可以通过扫描 IAM 页对堆进行表扫描或串行读操作来找到容纳该堆的页的扩展盘区。因为 IAM 按扩展盘区在数据文件内存在的顺序表示它们，所以这意味着串行堆扫描连续沿每个文件进行。使用 IAM 页设置扫描顺序还意味着堆中的行一般不按照插入的顺序返回。 下图说明 SQL Server Database Engine 如何使用 IAM 页检索具有单个分区的堆中的数据行。 4.3.聚集索引结构 在 SQL Server 中，索引是按 B 树结构进行组织的。索引 B 树中的每一页称为一个索引节点。B 树的顶端节 点称为根节点。索引中的底层节点称为叶节点。根节点与叶节点之间的任何索引级别统称为中间级。在聚集索引中，叶节点包含基础表的数据页。根节点和叶节点包含含有索引行的索引页。每个索引行包含一个键值和一个指针，该指针指向 B 树上的某一中间级页或叶级索引中的某个数据行。每级索引中的页均被链接在双向链接列表中。 聚集索引在 sys.partitions 中有一行，其中，索引使用的每个分区的 index_id = 1。默认情况下，聚集索引有单个分区。当聚集索引有多个分区时，每个分区都有一个包含该特定分区相关数据的 B 树结构。例如，如果聚集索引有四个分区，就有四个 B 树结构，每个分区中有一个 B 树结构。 根据聚集索引中的数据类型，每个聚集索引结构将有一个或多个分配单元，将在这些单元中存储和管理特定分区的相关数据。每个聚集索引的每个分区中至少有一个 IN_ROW_DATA 分配单元。如果聚集索引包含大型对象 (LOB) 列，则它的每个分区中还会有一个 LOB_DATA 分配单元。如果聚集索引包含的变量长度列超过 8,060 字节的行大小限制，则它的每个分区中还会有一个 ROW_OVERFLOW_DATA 分配单元。有关分配单元的详细信息，请参阅表组织和索引组织。 数据链内的页和行将按聚集索引键值进行排序。所有插入操作都在所插入行中的键值与现有行中的排序顺序相匹配时执行。B 树页集合由 sys.system_internals_allocation_units 系统视图中的页指针来定位。 对于某个聚集索引，sys.system_internals_allocation_units 中的 root_page 列指向该聚集索引某个特定分区的顶部。SQL Server 将在索引中向下移动以查找与某个聚集索引键对应的行。为了查找键的范围，SQL Server 将在索引中移动以查找该范围的起始键值，然后用向前或向后指针在数据页中进行扫描。为了查找数据页链的首页，SQL Server 将从索引的根节点沿最左边的指针进行扫描。 下图显式了聚集索引单个分区中的结构。 4.4.非聚集索引结构 非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点: 1、基础表的数据行不按非聚集键的顺序排序和存储。 2、非聚集索引的叶层是由索引页而不是由数据页组成。 既可以使用聚集索引来为表或视图定义非聚集索引，也可以根据堆来定义非聚集索引。非聚集索引中的每个索引行都包含非聚集键值和行定位符。此定位符指向聚集索引或堆中包含该键值的数据行。 非聚集索引行中的行定位器或是指向行的指针，或是行的聚集索引键，如下所述: 1、如果表是堆(意味着该表没有聚集索引)，则行定位器是指向行的指针。该指针由文件标识符 (ID)、页码和页上的行数生成。整个指针称为行 ID (RID)。 2、如果表有聚集索引或索引视图上有聚集索引，则行定位器是行的聚集索引键。如果聚集索引不是唯一的索引，SQL Server 2005 将添加在内部生成的值(称为唯一值)以使所有重复键唯一。此四字节的值对于用户不可见。仅当需要使聚集键唯一以用于非聚集索引中时，才添加该值。SQL Server 通过使用存储在非聚集索引的叶行内的聚集索引键搜索聚集索引来检索数据行。 对于索引使用的每个分区，非聚集索引在 index_id >1 的 sys.partitions 中都有对应的一行。默认情况下，一个非聚集索引有单个分区。如果一个非聚集索引有多个分区，则每个分区都有一个包含该特定分区的索引行的 B 树结构。例如，如果一个非聚集索引有四个分区，那么就有四个 B 树结构，每个分区中一个。 根据非聚集索引中数据类型的不同，每个非聚集索引结构会有一个或多个分配单元，在其中存储和管理特定分区的数据。每个非聚集索引至少有一个针对每个分区的 IN_ROW_DATA 分配单元(存储索引 B 树页)。如果非聚集索引包含大型对象 (LOB) 列，则还有一个针对每个分区的 LOB_DATA 分配单元。此外，如果非聚集索引包含的可变长度列超过 8,060 字节行大小限制，则还有一个针对每个分区的 ROW_OVERFLOW_DATA 分配单元。有关分配单元的详细信息，请参阅表组织和索引组织。B 树的页集合由 sys.system_internals_allocation_units 系统视图中的 root_page 指针定位。 下图说明了单个分区中的非聚集索引结构。 5.事务日志体系结构 每个 SQL Server 2005 数据库都有一个事务日志，用于记录所有事务以及每个事务对数据库所做的修改。事务日志是任何数据库的关键组成部分。本部分介绍有关事务日志体系结构的信息。要理解事务日志如何用来保证数据库的数据完整性以及如何用于数据恢复，需要了解这些信息。 5.1.事务日志基础 每个 SQL Server 2005 数据库都具有事务日志，用于记录所有事务以及每个事务对数据库所做的修改。事务日志是数据库的关键组件，如果系统出现故障，它就是近期数据的唯一源。请不要删除或移动事务日志，除非充分考虑了这样做的后果。 事务日志支持以下操作: 1、恢复个别的事务 如果应用程序发出 ROLLBACK 语句，或者数据库引擎 检测 工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训 到错误(例如失去与客户端的通信)，就使用日志记录回滚未完成的事务所做的修改。 2、SQL Server 启动时恢复所有未完成的事务。 当运行 SQL Server 的服务器发生故障时，数据库可能处于这样的状态:还没有将某些修改从缓存写入数据文件，在数据文件内有未完成的事务所做的修改。当启动 SQL Server 实例时，它对每个数据库执行恢复操作。前滚日志中记录的、可能尚未写入数据文件的每个修改。在事务日志中找到的每个未完成的事务都将回滚，以确保数据库的完整性。 3、将还原的数据库、文件、文件组或页前滚到故障点。 在硬件丢失或磁盘故障影响到数据库文件后，可以将数据库还原到故障点。首先还原上一次的完整备份和差异备份，然后将事务日志备份后续序列还原到故障点。当还原每个日志备份时，数据库引擎 重新应用日志中记录的所有修改，以前滚所有事务。当最后的日志备份还原后，数据库引擎 将使用日志信息回滚到该点未完成的所有事务。 4、支持事务复制 日志读取器代理程序监视已为事务复制配置的每个数据库的事务日志，并将已设复制标记的事务从事务日志复制到分发数据库中。 5、支持备用服务器解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 备用服务器解决方案、数据库镜像和日志传送高度依赖于事务日志。在日志传送方案中，主服务器将主数据库的活动事务日志发送到一个或多个目标服务器。每个辅助服务器将该日志还原为其本地的辅助数据库。 在数据库镜像方案中，数据库(主体数据库)的每次更新都在独立的、完整的数据库(镜像数据库)副本中立即重新生成。主体服务器实例立即将每个日志记录发送到镜像服务器实例，镜像服务器实例将传入的日志记录应用于镜像数据库，从而将其继续前滚。 下列是 SQL Server Database Engine 事务日志的特征: 1、事务日志是作为数据库中的单独的文件或一组文件实现的。日志缓存与数据页缓存分开管理，从而使数据 库引擎内的编码更简单、更快速和更可靠。 2、日志记录和页的格式不必遵守数据页的格式。 3、事务日志可以在几个文件上实现。通过设置日志的 FILEGROWTH 值可以将这些文件定义为自动扩展。这样可减少事务日志内空间不足的可能性，同时减少管理开销。 4、重用日志文件中空间的机制速度快且对事务吞吐量影响最小。 5.2.事务日志逻辑体系结构 SQL Server 2005 事务日志按逻辑运行，就好像事务日志是一串日志记录一样。每条日志记录由一个日志序列号 (LSN) 标识。每条新日志记录均写入日志的逻辑结尾处，并使用一个比前面记录的 LSN 更高的 LSN。 日志记录按创建时的串行序列存储。每条日志记录都包含其所属事务的 ID。对于每个事务，与事务相关联的所有日志记录通过使用可提高事务回滚速度的向后指针挨个链接在一个链中。 数据修改的日志记录或者记录所执行的逻辑操作，或者记录已修改数据的前像和后像。前像是执行操作前的数据副本;后像是执行操作后的数据副本。 操作的恢复步骤取决于日志记录的类型: 1、记录逻辑操作 A、若要前滚逻辑操作，请再次执行该操作。 B、若要回滚逻辑操作，请执行相反的逻辑操作。 2、记录前像和后像 A、若要前滚操作，请应用后像。 B、若要回滚操作，请应用前像。 许多类型的操作都记录在事务日志中。这些操作包括: 1、每个事务的开始和结束。 2、每次数据修改(插入、更新或删除)。这包括系统存储过程或数据定义语言 (DDL) 语句对系统表所做的更改。 3、每次分配或释放区和页。 4、创建或删除表或索引。 回滚操作也记录在日志中。每个事务都在事务日志中保留空间，以确保存在足够的日志空间来支持由显式回滚语句或遇到错误引起的回滚。保留的空间量取决于在事务中执行的操作，但通常等于用于记录每个操作的空间量。事务完成后将释放此保留空间。 日志文件中从必须存在以确保数据库范围内成功回滚的第一条日志记录到最后写入的日志记录之间的部分称为日志的活动部分，即“活动日志”。这是进行数据库完整恢复所需的日志部分。永远不能截断活动日志的任何部分。 5.3.事务日志物理体系结构 数据库中的事务日志映射在一个或多个物理文件上。从概念上讲，日志文件是一系列日志记录。从物理上讲，日志记录序列被有效地存储在实现事务日志的物理文件集中。 SQL Server Database Engine 在内部将每一物理日志文件分成多个虚拟日志文件。虚拟日志文件没有固定大小，且物理日志文件所包含的虚拟日志文件数不固定。在创建或扩展日志文件时，数据库引擎动态选择虚拟日志文件的大小。数据库引擎 尝试维护少量的虚拟文件。在扩展日志文件后，虚拟文件的大小是现有日志大小和新文件增量大小之和。管理员不能配置或设置虚拟日志文件的大小或数量。 虚拟日志文件唯一可以影响系统性能的情况是:虚拟日志文件是由较小的 size 和 growth_increment 值定义的。如果这些日志文件由于许多微小增量而增长到很大，则它们将具有很多虚拟日志文件。这会降低数据库启动以及日志备份和还原操作的速度。建议为日志文件指定一个与最终所需大小接近的 size 值和一个相对较大的 growth_increment 值。 事务日志是一种回绕的文件。例如，假设有一个数据库，它包含一个分成四个虚拟日志文件的物理日志文件。当创建数据库时，逻辑日志文件从物理日志文件的始端开始。新日志记录被添加到逻辑日志的末端，然后向物理日志的末端扩张。若进行截断操作，虚拟日志中最小恢复日志序列号 (MinLSN) 之前的日志记录会被删除。示例数据库中的事务日志的外观与下图所示相似。 当逻辑日志的末端到达物理日志文件的末端时，新的日志记录将回绕到物理日志文件的始端。 这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端。如果经常截断旧的日志记录，始终为到下一个检查点前创建的所有新日志记录保留足够的空间，则日志永远不会填满。但是，如果逻辑日志的末端真的到达了逻辑日志的始端，将发生以下两种情况之一: 1、如果对日志启用了 FILEGROWTH 设置且磁盘上有可用空间，则文件就按 growth_increment 指定的数量扩展，并且新的日志记录将添加到扩展中。有关 FILEGROWTH 设置的详细信息，请参阅 ALTER DATABASE (Transact-SQL)。 2、如果未启用 FILEGROWTH 设置，或保存日志文件的磁盘的可用空间比 growth_increment 中指定的数量少，则会出现 9002 错误。 如果日志包含多个物理日志文件，则逻辑日志在回绕到首个物理日志文件始端之前，将沿着所有物理日志文件移动。 5.4.预写事务日志 SQL Server 2005 使用预写日志 (WAL)。预写日志确保在将相关的日志记录写入磁盘后再将数据修改写入磁盘。这维护了事务的 ACID 属性。有关事务和 ACID 属性的详细信息，请参阅事务(数据库引擎)。 若要了解预写日志如何工作，知道修改后的数据如何写入磁盘很重要。SQL Server 维护一个高速缓冲存储器，当必须检索数据时，它将数据页读入这个存储器。数据修改不是直接在磁盘上进行，而是修改高速缓冲存储器中的页副本。直到数据库中出现检查点，或者必须将修改写入磁盘才能使用缓冲区来容纳新页时，才将修改写入磁盘。将修改后的数据页从高速缓冲存储器写入磁盘的操作称为刷新页。在高速缓存中修改但尚未写入磁盘的页称为脏页。 对缓冲区中的页进行修改时，将在记录修改的日志高速缓存中生成一条日志记录。在将关联的脏页从高速缓冲存储器刷新到磁盘之前，必须将这条日志记录写入磁盘。如果在写入日志记录之前刷新了脏页，脏页将在磁盘上创建修改，如果服务器在日志记录写入磁盘之前发生故障，将不能回滚该修改。SQL Server 有一个逻辑可以防止在写入关联的日志记录之前刷新脏页。日志记录将在提交事务时写入磁盘。 5.5.检查点和日志的活动部分 检查点将脏数据页从当前数据库的缓冲区高速缓存刷新到磁盘上。这最大限度地减少了数据库完整恢复时必须处理的活动日志部分。在完整恢复时，需执行两种操作: 1、前滚系统停止之前尚未刷新到磁盘上的日志记录修改信息。 2、回滚与未完成的事务(如没有 COMMIT 或 ROLLBACK 日志记录的事务)相关联的所有修改。 检查点在当前数据库中执行下列操作: 1、将记录写入标记检查点起点的日志文件。 2、将为检查点记录的信息存储在检查点日志记录链内。 检查点记录中记录的一条信息是第一条日志记录的 LSN，该 LSN 必须存在才能进行成功的数据库范围的回滚。这个 LSN 称为最小恢复 LSN (MinLSN)，它是下列 LSN 中的最小 LSN: A、检查点起点的 LSN B、最早的活动事务起点的 LSN C、尚未传递给分发数据库的最早的复制事务起点的 LSN 检查点记录中记录的另一条信息是所有已经修改数据库的活动事务的列表。 3、如果数据库使用简单恢复模式，则标记在 MinLSN 前重用的空间。 4、将所有脏日志和数据页写入磁盘。 5、将标记检查点结束的记录写入日志文件。 6、将这条链起点的 LSN 写入数据库启动页。 下列情况下将出现检查点: 1、显式执行 CHECKPOINT 语句。用于连接的当前数据库中出现检查点。 2、在数据库中执行了最小日志记录操作，例如，在使用大容量日志恢复模式的数据库中执行大容量复制操作。 3、已经使用 ALTER DATABASE 添加或删除了数据库文件。 4、对简单恢复模式的更改是此操作过程中发生的日志截断进程的一部分。 5、通过 SHUTDOWN 语句或通过停止 SQL Server (MSSQLSERVER) 服务停止了 SQL Server 实例。任一方法都将对 SQL Server 实例中的每个数据库执行检查点操作。 6、SQL Server 实例在每个数据库内定期生成自动检查点，以减少实例恢复数据库所需的时间。 7、进行了数据库备份。 8、执行了需要关闭数据库的活动。例如，AUTO_CLOSE 设置为 ON 并且关闭了数据库的最后一个用户连接，或者执行了需要重新启动数据库的数据库选项更改。 自动检查点 SQL Server Database Engine 将生成自动检查点。自动检查点之间的间隔基于使用的日志空间量以及自上一个检查点以来经历的时间。如果只在数据库中进行了很少的修改，自动检查点之间的时间间隔可能变化很大并且很长。如果修改了大量数据，自动检查点也会经常出现。 将根据 recovery interval 服务器配置选项为服务器实例上的所有数据库计算自动检查点之间的间隔。此选项指定数据库引擎 在系统重新启动时恢复数据库所用的最长时间。数据库引擎 将估计在执行恢复操作期间自己在 recovery interval 内能够处理多少条日志记录。 自动检查点之间的间隔也取决于恢复模式: 1、如果数据库使用的是完整恢复模式或大容量日志恢复模式，只要日志记录数达到数据库引擎估计在 recovery interval 选项指定的时间内能够处理的记录数，就会生成自动检查点。 2、如果数据库使用的是简单恢复模式，只要日志记录数达到下面两个值中较小的那个值，就会生成自动检查点: A、日志已满 70%。 B、日志记录数达到数据库引擎 估计在 recovery interval 选项指定的时间内能够处理的记录数。 如果数据库使用的是简单恢复模式，自动检查点将截断事务日志中没有使用的部分。但是，如果数据库使用的完整恢复模式或大容量日志恢复模式，自动检查点则不会截断日志。有关详细信息，请参阅截断事务日志。 现在，CHECKPOINT 语句提供了一个可选的 checkpoint_duration 参数，它指定完成检查点所需的秒数。 活动日志 日志文件中从 MinLSN 到最后写入的日志记录这一部分称为日志的活动部分，或者称为“活动日志”。这是进行数据库完整恢复所需的日志部分。永远不能截断活动日志的任何部分。所有的日志记录都必须从 MinLSN 之前的日志部分截断。 下图显示了具有两个活动事务的结束事务日志的简化版本。检查点记录已压缩成单个记录。 LSN 148 是事务日志中的最后一条记录。在处理 LSN 147 处记录的检查点时，Tran 1 已经提交，而 Tran 2 是唯一的活动事务。这就使 Tran 2 的第一条日志记录成为执行最后一个检查点时处于活动状态的事务的最旧日志记录。这使 LSN 142(Tran 2 的开始事务记录)成为 MinLSN。 长时间运行的事务 活动日志必须包括所有未提交事务的每一部分。如果应用程序开始执行一个事务但未提交或回滚，将会阻止数据库引擎 推进 MinLSN。这可能会导致两种问题: 如果系统在事务执行了许多未提交的修改后关闭，以后重新启动时，恢复阶段所用的时间将比 recovery interval 选项指定的时间长得多。 因为不能截断 MinLSN 之后的日志部分，日志可能变得很大。即使数据库使用的是简单恢复模式，这种情况也有可能出现，在简单恢复模式下，每次执行自动检查点操作时通常都会截断事务日志。 复制事务 日志读取器代理监视为事务复制配置的每个数据库的事务日志，并将标记为要复制的事务从事务日志复制到分发数据库中。活动日志必须包含标记为要复制但尚未传递给分发数据库的所有事务。如果不及时复制这些事务，它们可能会阻止截断日志。 5.6.截断事务日志 如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。为了减小逻辑日志的大小，应定期截断事务日志。在 SQL Server 的最早版本中，截断日志意味着将进行数据库恢复或还原不再需要的日志记录物理删除。但是，在近来的版本中，截断过程只是做标记，以便重新使用 旧日志记录使用过的空间。此空间中的日志记录将最终被新的日志记录覆盖。 重要事项:截断并不减小物理日志文件的大小。而是减小逻辑日志文件的大小并释放磁盘空间以供重新使用。 如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。为了减小逻辑日志的大小，应定期截断事务日志。在 SQL Server 的最早版本中，截断日志意味着将进行数据库恢复或还原不再需要的日志记录物理删除。但是，在近来的版本中，截断过程只是做标记，以便重新使用旧日志记录使用过的空间。此空间中的日志记录将最终被新的日志记录覆盖。 重要事项:截断并不减小物理日志文件的大小。而是减小逻辑日志文件的大小并释放磁盘空间以供重新使用。有关收缩物理日志文件大小的信息，请参阅收缩事务日志。 事务日志的活动部分(活动日志)永远不能截断。日志的活动部分是用于恢复数据库的那部分日志，必须始终存在于数据库中。日志活动部分起点处的记录由最小恢复日志序号 (MinLSN) 标识。MinLSN 之前的日志记录仅用于维护事务日志备份序列。 所选的数据库恢复模式决定了 MinLSN 之前必须有多少事务日志保留在数据库中，如下所示: 1、在简单恢复模式中，不维护事务日志序列。MinLSN 之前的所有日志记录可以随时被截断，但在处理 BACKUP 语句时除外。 2、在完全恢复模式和有日志记录的大容量恢复模式中，维护事务日志备份序列。直到备份完事务日志后才能截断 MinLSN 之前的逻辑日志部分。 截断日志的操作 日志截断在下列情况下发生: 1、在未指定 NO TRUNCATE 的 BACKUP LOG 语句完成之后。 2、在每次处理检查点时(如果数据库使用的是简单恢复模式)。其中包括 CHECKPOINT 语句产生的显式检查点和系统生成的隐式检查点。例外情况是如果检查点发生在 BACKUP 语句仍活动时，则不截断日志。 日志截断示例 事务日志在内部分成若干部分，称为“虚拟日志文件”。虚拟日志文件是可以重新使用的空间的单位。截断事务日志后，将覆盖包含 MinLSN 的虚拟日志文件之前的日志记录，同时生成新的日志记录。 下图显示一个有四个虚拟日志的事务日志。创建数据库后没有截断过日志。逻辑日志从第一个虚拟日志的前端开始，而且从未使用过虚拟日志 4 中超过逻辑文件末端的部分。 下图说明日志截断后的情形。包含 MinLSN 记录的虚拟日志的始端之前的空间已标记为重新使用。 5.7.收缩事务日志 在下列情况下，日志文件的物理大小将减小: 1、执行 DBCC SHRINKDATABASE 语句时 2、执行引用日志文件的 DBCC SHRINKFILE 语句时 3、自动收缩操作发生时 首先，可通过日志截断操作收缩日志。日志截断不会减小物理日志文件的大小。但是，它却能减小逻辑日志的大小，并将不包含任何逻辑日志的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。 减小是以虚拟日志文件为单位进行的。例如，如果有一个 600 MB 的日志文件分为六个 100 MB 的虚拟日志，则该日志文件的大小只能按 100 MB 递减。文件可以减小为 500 MB 或 400 MB，但不能减小为 433 MB 或 525 MB。 注意:日志文件的大小是由数据库引擎在创建或扩展日志文件时动态选择的。 包含逻辑日志的虚拟日志文件不能释放。如果某个日志文件中的所有虚拟日志文件均包含逻辑日志，则直到截断操作在物理日志的末端将虚拟日志标记为不活动时，才能收缩该文件。 在收缩任何文件时，必须从文件的末端开始释放空间。在收缩事务日志文件时，将从日志文件的末端释放足够的虚拟日志文件，以便将日志减小到用户所要求的大小。用户指定的 target_size 将圆整为下一个最大的虚拟日志文件边界。例如，如果用户为包含 100 MB 虚拟日志文件的 600 MB 的示例文件指定 325 MB 的 target_size，则最后两个虚拟日志文件将删除，新的文件大小为 400 MB。 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 操作会立即尝试将物理日志文件收缩为所要求的大小。 如果虚拟日志文件中的逻辑日志未超出 target_size 标记，则释放 target_size 标记之后的虚拟日志文件，并成功完成 DBCC 语句，不显示任何信息。 如果虚拟日志中的逻辑日志超出了 target_size 标记，SQL Server Database Engine 将释放尽可能多的空间并显示一个信息性消息。该消息告诉您必须执行什么操作来从文件尾部的虚拟日志中删除逻辑日志。执行完该操作后，可以重新发出 DBCC 语句以释放剩余的空间。 例如，当运行 target_size 为 275 MB 的 DBCC SHRINKFILE 语句时，假设有一个包含六个虚拟日志文件的 600 MB 日志文件，其中有一个逻辑日志从第 3 个虚拟日志开始，到第 4 个虚拟日志结束，则: 第 5 个和第 6 个虚拟日志文件将立即释放，因为它们不包含逻辑日志。但是，若要符合指定的 target_size，还应释放第 4 个虚拟日志文件，但由于它包含了逻辑日志的尾部，所以不能释放。在释放了第 5 个和第 6 个虚拟日志文件之后，数据库引擎 将用虚记录填充第 4 个虚拟日志文件的剩余部分。这会强制地使日志文件的尾部成为第 1 个虚拟日志文件的尾部。在大多数系统中，第 4 个虚拟日志文件中的所有事务都将在数秒内提交。这意味着日志的整个活动部分将移动到第 1 个虚拟日志文件。现在该日志文件类似于: DBCC SHRINKFILE 语句还显示一个信息性消息，指出它不能释放所要求的全部空间，并告诉您可以执行 BACKUP LOG 语句来释放剩余的空间。日志的活动部分移动到第 1 个虚拟日志文件之后，BACKUP LOG 语句将截断第 4 个虚拟日志文件中的整个逻辑日志: 由于第 4 个虚拟日志文件不再包含任何逻辑日志，此时便可以运行 target_size 为 275 MB 的相同的 DBCC SHRINKFILE 语句了。第 4 个虚拟日志文件将被释放，物理日志文件的大小将减小到所要求的大小。