CN109891402B

CN109891402B - 可撤销和在线模式转换

Info

Publication number: CN109891402B
Application number: CN201780066957.8A
Authority: CN
Inventors: P·安拓诺波洛斯; A·T·特兰
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2016-10-28
Filing date: 2017-10-23
Publication date: 2023-03-28
Anticipated expiration: 2037-10-23
Also published as: US10769134B2; WO2018080945A1; EP3532950A1; US20180121494A1; CN109891402A

Abstract

从用户接收用于修改已有数据结构或创建新数据结构的数据库命令。数据库命令用于构造被提供给查询优化器组件的查询，其中所述查询被转换为包括使操作状态持久化的操作的第一查询执行计划。查询中指定的一些数据被接收，并且新数据结构中的一些通过执行第一查询计划中的一些来被构造。在接收查询中指定的数据中的一些并构造新数据结构中的一些时，执行操作状态被持久化。当第一查询计划的执行的中断发生时，使用持久化操作状态来生成经更新的查询计划。在中断之前或之后，但在执行经更新的查询计划之前，外部更新会发生。外部更新被事务地验证。

Description

可撤销和在线模式转换

背景技术

计算机和计算系统几乎影响了现代生活的每个方面。计算机通常涉及工作、娱乐、医疗保健、交通、娱乐、家庭管理等。

计算系统可用于实现可被查询并且结果被取回的数据库系统。如果查询和取回操作有任意类型的失败，则丢弃为查询和取回操作执行的所有工作。同样，对于大型表，数据库的索引构建操作可能需要数小时才能完成并消耗大量资源。目前，它们的持续时间取决于许多参数，并且任意故障（故障转移、崩溃等）都将导致整个操作被放弃并从头开始重新开始。此外，索引构建通常在单个事务中执行，从而生成某些架构可能无法处理的大量日志。

本文要求保护的主题不限于解决任意缺点或仅在诸如上述那些环境中操作的实施例。相反，提供该背景技术仅用于说明可以实践本文描述的一些实施例的一个示例性技术领域。

发明内容

本文示出的一个实施例包括可以在数据库计算环境中实践的方法。该方法包括用于生成新数据结构的动作。该方法包括从用户接收用于修改已有数据结构或创建新数据结构的数据库命令；构造将执行数据库命令的查询并且将查询提供给查询优化器组件；在查询优化器组件处，将查询转换为第一查询执行计划，其中第一查询执行计划包括使第一查询计划的执行的操作状态持久化的一个或多个操作；接收在查询中被指定的数据的至少一部分，并且通过执行第一查询计划的至少一部分来构造新数据结构的至少一部分；在接收在查询中被指定的数据的至少一部分并且构造新数据结构的至少一部分的同时，使第一查询计划的执行的操作状态持久化；确定第一查询计划的执行的中断已经发生；作为确定第一查询计划的执行的中断已经发生的结果，使用第一查询计划的执行的被持久化的操作状态来生成经更新的查询计划，使得新查询计划能够被执行而无需完全重新开始接收数据和构造新数据结构；通过执行经更新的查询计划来恢复接收数据并且构造新数据结构；在数据作为第一查询计划的执行的结果而被接收的同时或者在第一查询计划的执行被中断的同时，接收对新数据结构的外部更新；以及结合执行经更新的查询计划来事务性地验证外部更新。

提供本发明内容是为了以简化的形式介绍一些概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附加的特征和优点将在下面的描述中阐述，并且部分地将从描述中显而易见，或者可以通过本文的教导的实践来学习。借助于所附权利要求中特别指出的仪器和组合，可以实现和获得本发明的特征和优点。从以下描述和所附权利要求，本发明的特征将变得更加明显，或者可以通过下文所述的本发明的实践来学习。

附图说明

为了描述可以获得上述和其他优点和特征的方式，将通过参考附图中示出的特定实施例来呈现上面简要描述的主题的更具体的描述。应理解，这些附图仅描绘了典型的实施例，因此不应认为是限制其范围，将通过附图的使用用附加特征和细节来描述和解释实施例，在附图中：

图1示出了数据库和索引数据库中的表的两个不同索引；

图2示出了用于创建或更改数据结构的过程流程和组件；

图3示出了用于恢复数据结构的创建或更改的过程流程；

图4示出了中止数据结构的创建或更改；

图5示出了当发生故障时创建操作正在运行时源和目标数据结构的状态；

图6示出了用于可恢复数据结构创建的反物质状态机；以及

图7示出了生成新数据结构的方法。

具体实施方式

本文示出的实施例可以实现数据库操作，包括索引构建操作或其他操作，其可以在系统故障之后以最小的工作损失恢复。一些实施例可以由用户手动暂停和恢复。附加地或替代地，实施例可以消除对单个长时间运行的事务的需要，该事务导致基于云的数据库和内部部署数据库的日志外问题（由于与数据大小相比较小的日志大小）。

可以从华盛顿州雷蒙德市的微软公司获得的SQL Server®或Azure SQLServer®的上下文中描述实施例。然而，本领域技术人员将理解，这些概念通常可以应用于其他数据库产品，或者通常实际上应用于其他数据存储和/或数据处理产品。

此外，注意，下面示出的示例被绘制到索引构建操作，但是应当理解，该原理可以应用于几乎任意基于事务的数据结构生成。

例如一些实施例可以包括实现以下中的一项或多项的功能：

-暂停/恢复索引构建操作。例如这可以完成，以允许在维护窗口期间执行索引构建操作。

-在故障转移和系统故障之后的恢复索引构建操作。

-即使在只有小的日志大小可用时，也构建大型索引。

以下句法提供了这如何向用户公开的示例：

ALTER INDEX {index_name | ALL } ON {table_name} REBUILD

WITH (ONLINE = ON, RESUMABLE = { ON | OFF} )

ON-索引操作将在故障时暂停，并且必须手动恢复。

OFF-无法暂停和恢复操作。这也是默认值。

注意，可以实现相同的选项以应用于SQLServer®中的T-SQL CREATE INDEX语句和其他数据库系统中的类似语句。

一旦可恢复操作已经开始，在一个示例实施例中，用户可以使用以下命令来控制它：

ALTER INDEX {index_name | ALL} ON {table_name} { RESUME | ABORT}

PAUSE - 暂停正在运行的索引操作。

RESUME - 恢复手动暂停或由于故障暂停的索引操作。

ABORT - 中止索引操作。它会影响正在运行或暂停的索引构建操作。

例如现在参考图1。图1示出了数据库102。数据库可以具有与其相关联的索引104。然而，用户可能希望在数据库102中创建数据项的新索引106。因此，用户可以发起使得数据库102中的数据项的新索引106在诸如硬件存储器或磁盘的存储介质中被创建的操作。用户可以在正创建新索引106时继续使用旧索引104来查找数据项以访问数据库102。替代地或另外地，即使在创建新索引时，也可以结合使用旧索引104和新索引106。

可以理解，在新索引106的创建期间，可能希望暂停新索引106的创建。例如索引创建操作通常需要大量的计算能力。因此，在一些实施例中，当其他操作需要处理能力时，可以暂停新索引106的索引创建。例如在一些实施例中，可以在数据库102正在经历低使用或者以其他方式空闲的时间段期间创建新索引106。

替代地或另外地，在一些实施例中，在新索引106的创建过程期间，操作可能失败。本文示出的实施例能够标识成功的索引创建过程的部分，该部分允许重新开始索引创建而无需执行成功的索引创建操作中的一些。

图2示出了用于以可恢复的方式执行索引构建的工作流程以及所涉及的组件。

如在202处所示，用户200发起指示要创建和/或更改索引的操作。如204所示，操作将由解析器206和执行引擎208解析和编译，类似于传统的在线索引构建，但是数据定义语言（DDL）事务将被改变为只读事务。解析器206是查询编译器组件，其检查字符串并将其转换为抽象句法树。

在执行中，如在210处所示，执行引擎208和元数据组件212确认没有开始用户事务，并且实施例开始事务T1，其负责创建和持久化所有所需元数据并初始化索引构建操作。元数据组件存储有关数据库中所有对象的模式的信息。

在执行所有所需检查之后，执行引擎208创建新索引对象，并如在216处所示，调用存储引擎（SE）214以创建将它们附加到新创建的索引的所需行集。在可从华盛顿州雷蒙德市的微软公司获得的SQLServer®中，这是负责管理数据的物理存储的组件。在此完成之后，实施例将新索引的元数据持久化到持久存储和索引构建操作的选项（例如要构建的分区等），使得实施例可以在潜在故障之后取回所有内容。此时操作变得可恢复。

如在218处所示，实施例开始版本化事务，其将获取表上的S锁并建立版本化。如在220处所示，实施例现在开始只读事务T2，其将负责整个在线索引构建（OIB）操作。此事务负责快照扫描。为了在整个操作期间允许日志截断，在一些实施例中，该事务是只读的。插入操作在经常提交的独立事务中执行。注意：如稍后所述，某些索引构建算法可能不需要快照，但它仍可用于改进并发性。

如222处所示，索引构建阶段现在可以开始并且将作为特殊的INSERT...SELECT查询来执行。此数据操作语言（DML）在内部调用索引构建查询处理器（QP）224迭代器，这些迭代器将被扩展以递增地执行操作并提交进度，以便实施例可以以最少量的工作从任意故障中恢复。此时，如226处所示，提交版本化事务和T1。在此之前的任意故障都将导致操作的完全回滚。

在一些实施例中，与当前索引构建操作相反，如果例如对于新索引创建需要排序，实施例不执行表的完整排序，而是逐渐对大批行进行排序并将它们插入到新索引。这允许以可接受的性能递增地执行操作。然而，如果没有完整的排序，实施例不能正确填充导致碎片化的新索引的页面。这在下面更详细地说明。

一旦已经对一批行进行了排序（如果需要），如在228处所示，实施例现在可以开始将行插入到目标索引中，如在230处所示。用于插入的批次将更小以最小化阻塞。

一旦实施例移动到下一行集合，实施例通过如232所示持久化诸如在磁盘上或在非易失性存储器中的持久存储装置中处理的最后一行的键来更新进度。如果对行进行了排序，则实施例更新进度处理移动到要排序的新批次行，而不是在插入的个体批次期间。这意味着在发生故障的情况下可以对特定行进行两次处理。但是，如下所述，这可以解释。

当索引构建过程完成时，实施例创建短期内部事务T3，其将持久化指示索引填充已完成的状态，如234处所示。

一旦索引构建过程完成，实施例创建最终内部事务T4，其将采用最终模式修改（SCH-M）锁并最终化所有元数据和索引并提交整体操作，再次如在234处所示。

基于上述架构：

–不存在在操作正在运行时阻止日志截断或者在故障的事件中可以导致整个操作被回滚的未完成的事务。

-如果操作失败，则释放所有资源，允许操作在大量时间内保持在“暂停”状态。如以下描述中更详细描述的，唯一的警告是DML必须在操作暂停时维护新索引并且表处于特殊状态，该状态不允许任意可以修改表的模式的操作。

现在参考图3，示出了用于恢复暂停的索引构建操作的工作流300。一旦可恢复索引构建操作被挂起，或者因为用户手动暂停它或者由于某些故障，用户可以使用特殊命令在任意时间点恢复操作，如在302处所示。

图3示出了用于恢复挂起的索引构建操作的工作流300。RESUME操作与原始索引构建操作非常相似，除了它不是在初始阶段设置索引构建操作之外，它是简单地取回已有索引选项和元数据以及操作停止的起始点，如在304处所示。

图4示出了用于中止可恢复索引构建操作的工作流400。鉴于本文所示的可恢复索引构建被设计为经受故障，简单地取消命令，杀死会话等将不允许用户完全中止这样的操作。因此，实施例实现用于中止未完成的索引构建的特殊命令。图4演示了中止可恢复索引构建操作的工作流。该操作通常在单独的专用线程上运行。

该操作将首先杀死该表上正在进行的OIB操作并将其耗尽，如在402处所示。这可以通过请求当前存在的特殊OIB锁来完成。然后，如在404处所示，它将清理新索引的元数据并强制重新编译，以便任意新DML停止使用新索引。最后，它将排出表上的所有DML以清理行集，如在406处所示。

以下示出了可以在一些实施例中使用的新DDL句法。为了向后兼容，可以在ONLINE选项是可应用的CREATE、ALTER和DROP索引语句的新选项下实现使索引构建操作可恢复。例如ALTER INDEX的句法可能如下：

ALTER INDEX { index_name | ALL } ON <object>

{

REBUILD [ WITH ( <rebuild_index_option> [ ,...n ] ) ]

…

}

rebuild_index_option > ::=

{

…

| ONLINE = { ON | OFF }

| RESUMABLE = { ON | OFF}

…

}

其中：

MANUAL-索引操作将在失败或注意时暂停，并且必须手动恢复

OFF-默认-不能暂停和恢复操作

在一些实施例中，CREATE和DROP INDEX的句法是完全相同的，因此在此省略。

另外，一些实施例扩展ALTER INDEX DDL（或其他适当的数据结构更改语句）语句以允许可以RESUME或ABORT未完成的可恢复索引操作的两个新动作。例如请考虑以下：

ALTER INDEX { index_name | ALL } ON <object>

{

REBUILD [ WITH ( <rebuild_index_option> [ ,...n ] ) ]

| DISABLE

| REORGANIZE [ PARTITION = partition_number ] [ WITH ( <reorganize_option>)

]

| SET ( <set_index_option> [ ,...n ] )

| RESUME

| ABORT

}

其中：

RESUME - 恢复手动暂停或由于故障暂停的索引操作

ABORT- 中止索引操作。它会影响正在运行或暂停的索引构建/重建

ABORT命令用于可恢复操作，因为注意（取消）、杀死SPID或切断连接将仅暂停操作并且不完全回滚。显式命令是用户可以用来完全放弃未完成的可恢复操作的。

对于可恢复的索引构建操作，在一些实施例中，DDL将执行如下：

-如果存在明确的用户事务，则实施例使DDL失败，因为实施例想要在内部处理事务并且想要给出干净的事务语义。

-对于可恢复操作，实施例将DDL事务改变为只读事务，并执行需要在父DDL事务的子事务中写入的所有工作。

-实施例开始内部事务T1，其将处理在线索引的创建，创建必要的行集以及将所有元数据持久化到盘。

-在执行所有所需检查之后，实施例持久化针对新索引的元数据。

-实施例另外存储用于索引构建操作的选项（例如要构建的分区等），因此实施例可以在潜在故障之后取回所有内容。由于可能期望在新动态管理视图（DMV）（用户可以查询以取回有关系统的信息的系统视图，在本示例中，该系统视图是关于取回关于进行中的任意可恢复操作的信息）中公开针对可恢复操作的DDL命令，实施例还将DDL语句本身存储在元数据中。实施例还可以利用这一点来避免为将来添加的每个新索引构建选项扩展元数据。不是将所有选项显式存储在元数据中并在RESUME上取回它们，RESUME可以简单地解析和编译存储的DDL语句以取回指定的所有选项。对于允许表达式的选项，一些实施例仍然明确地存储结果值以保证该值在RESUME上不会被不同地计算。

-实施例将该表标记为“在可恢复索引构建中”，使得实施例可以阻止与OIB冲突的其他操作，诸如DDL等。此外，当前与OIB冲突的操作将在继续之前检查此标志，并且如果标志被设置则将失败。

-实施例调用SE 214以创建所需的行集并开始将在表上获取S锁并建立版本化的版本化事务。

-在这一点上，实施例颠覆了表的元数据版本以重新编译所有新查询，使得它们可以开始维护两个索引。为了便于重新编译是持久的并且不需要在回滚时重新编译，不再需要特殊的“在线”元数据版本，但可以代之以使用传统的元数据版本。

-实施例现在开始内部事务T2，其将负责整个OIB操作。此事务负责快照扫描。为了允许在整个操作期间的日志截断，此事务应该是只读的。所有INSERT和其他副作用操作（统计更新等）操作都将在经常提交的独立事务中执行。注意：如稍后所述，新索引构建过程可能不需要快照，但它仍可用于改进并发性。

-索引构建阶段现在可以开始并且将作为特殊的INSERT...SELECT查询来执行。此DML在内部调用索引构建查询处理器（QP）迭代器，这些迭代器将被扩展以递增地执行操作并提交进度，以便实施例可以以最少的工作量从任意故障中恢复。此时，提交版本化事务和T1。在此之前的任意故障都将导致操作的完全回滚。

-以下详细描述用于分类（如果需要）和主索引维护逻辑的算法。

-一旦实施例移动到下一行集合，实施例通过持久化处理的最后一行的键来更新进度。如果对行进行了排序，则实施例可以在实施例移动到要排序的新批次行而不是在实施例插入的各个批次期间更新进度。这意味着在发生故障的情况下可以对特定行进行两次处理。但是，这可以如下所述进行处理。

-一旦索引构建过程完成，实施例开始内部事务T3以将索引的状态持久化为已完成索引构建。

-最后，实施例启动内部事务T4，采用SCH-M锁，完成所有元数据和索引，并提交整体操作。

-随着实施例移动通过索引构建过程的各个阶段，实施例跟踪实施例当前处于能够从那里恢复的阶段。例如实施例可以跟踪实施例是否处于OIB（聚集索引构建）的第一阶段中、第二阶段（非聚集（NC）索引构建）等。

可以实现实施例，其中操作不具有将回滚整个操作的任意虚拟日志记录（VLR）（这些不是真实的日志记录，即它们不被写入磁盘上的事务日志，但是当事务回滚时，它们具有在存储器中执行的逻辑）。

在一些实施例中，ALTER INDEX语句包括允许恢复任意暂停的索引构建操作的动作。

在一些实施例中实现的RESUME操作非常类似于主DDL操作的核心部分（如上所述），其中区别在于不是初始化元数据并从头开始索引构建，而是加载持久化具有新索引和选项的元数据，并从中断处开始索引构建过程。

为实现此目的，INSERT...SELECT查询将加载需要从其开始的行的键并从那里开始扫描。

对于扫描基于索引的情况，将使用常规谓词来从最后处理的实施例的行开始扫描。

如果扫描使用堆，则实施例仍然可以从实施例中断的位置开始扫描。由于实施例是可以阻止重新排列堆上页面的操作，因此实施例在操作开始时访问针对索引存在的页面。即使实施例错过了在索引构建操作开始之后插入的行，但这不是基于下面描述的算法的问题，只要实施例访问在操作开始时存在的所有行。

在一些实施例中实现的ALTER INDEX语句包括允许中止任意暂停的或当前运行的索引构建操作的动作。这模仿了当前的OIB清理逻辑，除了它在一个独立的线程上而不是OIB上运行。该操作将首先杀死此表上正在进行的OIB操作并将其耗尽。这可以通过使用KILL模式请求特殊OIB锁来完成。然后它将清理新索引的元数据并通过碰撞表的元数据版本来强制重新编译，以便任意新DML停止使用新索引。最后，类似于OIB清理任务，它将耗尽表上的所有DML以清理行集。

如上所述，存在被持久化以允许恢复索引构建操作的新元数据。

在先前的系统中，处于“在线”状态的任意索引的元数据，即当前由OIB操作构建的索引，仅保存在存储器中。为了使操作可恢复，这些索引的元数据被持久化。例如在SQLServer®中，用于存储此元数据的一个合适的表是sys.sysidxstats系统表，该表通常用于存储索引元数据。然而，对于REBUILD，在线索引会与相同表的已有索引冲突，因为它们对于重建情况具有相同的ID和名称。为了解决该问题，一些实施例在针对临时索引的保留范围之后为在线索引保留新索引ID范围。可以通过使用以下公式将在线索引映射到已有索引：new_index_id=current_index_id+( x_metadataIndexStatsId_MinResumable).

另外，在一些实施例中，索引的名称被设置为附加有随机生成的全局唯一标识符（“guid”）的索引的名称，使得它不与已有索引冲突，并且因为已有索引已经具有名称，所以实施例可以从那里取回它。

对于CREATE情况，索引可以具有其真实姓名和ID，除了它被标记有一些特殊的“在线”状态。

关于存储器表示，在线索引从盘加载并作为其在线版本附加到已有索引。

为了持久化DDL语句（使其对新DMV可见）和索引操作的任意其他选项，使用SQLServer®实现的实施例可以使用sys.sysobjvalues系统表，但是引入新类。实施例使用不同的有效数字（“valnum”）值来存储单个新类下的所有选项。

为了持久化索引构建阶段，这样的实施例仍然可以在sys.sysobjvalues中使用新类，而为了持久化已经处理的最后一行的键，实施例可以使用更加面向SE的sys.sysseobjvalues。为此，实施例可以使用object_id作为主id，索引id作为次Id（“subid”），键列id作为有效数字，这将允许存储所有所需列和数据类型的值。

在先前的系统中，OIB将在表上保持意图共享（IS）锁和特殊索引构建锁以防止在OIB运行时其他活动进入。本文示出的实施例也防止这些操作在索引构建操作处于暂停状态时运行，但是一些实施例不依赖于用于此目的锁。

为了实现这一点，本文示出的实施例在表上设置状态，并且可能地，行集元数据以阻止这样的操作。

以下示出了被阻止的一些操作的列表：

-任意模式改变，包括其他在线操作。

-与桌面上的IS锁冲突的任意东西。

-DBCC收缩，碎片整理等，其已经被OIB阻止并且还可以重新布置堆的页面，导致可恢复扫描错过数据。

在重新启动时或者在重新水化高速缓存时清空索引高速缓存的任意时间，实施例在重建索引的同时加载可恢复索引。实施例将可恢复索引重新初始化为处于在线构建状态，并收集所有必要字段以从该点重新发起索引构建。对于经历可恢复索引重建的任意索引，实施例不会延迟加载，因为在调用恢复时需要存在针对可恢复索引的相关元数据。

以下描述用于创建新索引（其可具有与源索引相同或不同的键列和排序）的算法，而不需要在操作持续时间内对源索引的一致快照。

在一些实施例中当前不需要持久快照，因为SQL Server®当前不具有支持持久快照的机制，但是它还允许支持暂停索引操作大量时间而不需要在此期间得到更新的所有记录的旧版本的维护。

所谓的“反物质”的概念被示出并用于跟踪目标索引中每行的状态。如本文所示，反物质包括处理以下事实的功能：实施例不再具有索引的一致快照，并且索引构建器将在故障发生后看到来自并发DML的更新。

并发DML以与它们在当前OIB算法中类似的方式维护新索引和任意映射索引。然而，任意行插入都会生成目标索引中的反物质，并且任意删除都会生成删除反物质，无论该行是否已在目标索引中找到。这保证了实施例对于每一行具有持久状态。

假设索引构建器在单个线程上运行。通过将源索引划分为单独线程所涵盖的不相交范围，可以轻松地为多线程索引构建扩展相同的算法。

还假设实施例仍然使用快照隔离来构建两个故障之间的索引。使用快照隔离可以提高算法的并发性，因为没有锁被保持在源索引上。

每行具有存在于所有索引中的唯一标识符。对于堆，这是行标识符（RID）。特别是，对于堆，索引上没有键（实际上没有索引），每行由RID标识，RID是元组（page_id，slot_id_within_the_page）。对于聚集索引，这是聚集索引键，并且对于非唯一索引，这是唯一文件。对于非聚集索引，这是索引行（index_key，bookmark）的完整有效负载，其中书签（基本索引的键）本质上是唯一标识符，因为index_key可以被复制。

假定每行具有唯一标识符，对于源索引中的每一行，实施例可标识目标索引中的对应行。对于聚集索引创建，映射索引维护旧的和新唯一标识符之间的映射。对于所有其他情况，行的唯一标识符保持相同。

实施例可以使用反物质和删除反物质来跟踪目标索引中的行的状态（无论是否已被插入或删除）。任意插入（DML或索引构建器）都将插入的行标记为反物质，并且任意删除（无论该行是否已存在于目标索引中）都会插入删除反物质。这允许以持久方式存储每行的状态，该方式不依赖于该行是否对索引构建器可见，因此不受重新开始的影响。

由于所有DML都在更新源和目标索引，因此可以保证在目标索引中找到的任意行都是最新的。

由于索引构建器正在将行从源复制到目标索引，因此它可以使用反物质状态（常规或删除）来跟踪行是否已被插入或删除。如果该行已被删除，索引构建器将找到删除反物质，并且可以删除该行。移除删除反物质是可选的，因为没有方法可以保证实施例在没有一致的快照的情况下在操作结束时没有任意反物质行。如果该行已被并发DML插入，则索引构建器将找到反物质行并可以安全地忽略该行，因为DML已经插入的版本被保证是该行的最新版本。

图5示出了索引构建操作正在运行并且当索引构建器已处理到源索引的第N行的时间t_f发生故障时的源和目标索引（或堆）的状态。

为简单起见，示出了目标索引具有与源相同的顺序（相同的键列和排序）的场景，但是相同的算法适用于目标索引具有不同排序的场景。

该过程如下工作：

-索引构建处理在时间t₀开始，获取索引的快照并开始将行复制到新索引。

-并发DML维护针对插入或删除的任意行的源和目标索引（为了该算法的目的，可以将更新视为删除后跟有插入）。

这意味着DML将从源索引插入/删除行并在目标索引中插入常规或删除反物质。如上所述并且还可以在图5的图中看到，所有行都被标记为反物质和删除反物质，无论它们是否在目标索引中被发现。

-当索引构建器将行复制到目标索引时，它将跳过标记为常规或删除反物质行并将插入的任意行标记为反物质。移除访问行的删除反物质是可能的，因为这些行不会被重新访问并且可以帮助释放一些空间，但这是可选的，因为没有办法保证实施例在没有一致快照的情况下在操作结束时没有任意反物质行。

-索引构建器批量地将行复制到目标索引并提交内部事务，因此保留所有进度。另外，作为每个批处理的一部分，实施例保留关于实施例复制的最后一行实施例的键（或RID）的一些元数据，使得实施例可以在故障之后从那里恢复。元数据更新在与用于批处理的事务相同的事务中被执行，以保证这两个状态是一致的。

-当在时间t_f1处针对索引构建器发生故障时，任意飞行中批处理事务被回滚并且索引被留在一致状态。由于所有元数据、行集等已经在先前的事务中提交，如前所述，故障不会触发整个操作的回滚，并且索引构建应该能够从那里恢复。

-在故障之后发生的任意并发DML操作仍将照常维护两个索引。这保证了插入/删除也在新索引上发生，因此保证新索引在新操作被关注方面是一致的。

-在任意量的时间之后，索引构建器可以通过建立新快照并从前一个运行中断的第N行开始扫描来恢复。

-在此状态下，实施例具有以下行类别：

从索引构建器已处理的行范围中从源索引删除或插入到源索引中的行。这些已将删除或常规反物质插入到目标索引中，但应该已由索引构建器处理，因此在失败后不会影响该过程，因为它们不会被重新访问。在操作结束时可以忽略常规反物质（成为常规行），而删除反物质被清理/删除（如果尚未被移除，这是可选的）。

从索引构建器尚未处理的行范围中从源索引中删除的行。这些还将删除反物质插入到目标索引中。由于索引构建在恢复之后建立了新快照，因此这些已删除的行在源索引中不再可见，因此不会造成任意问题。他们的删除反物质需要在操作结束时被清理/删除。

在索引构建器已处理的行范围内被插入到源索引的行。这些行也已经以反物质状态被插入到目标索引中。这些行将在新快照中可见，但已由插入它们的DML插入到新索引中。这意味着索引构建器将尝试在新索引中重新插入重复行。为避免这种情况，索引构建器将捕获重复键插入并使用行的唯一标识符来检查目标索引中是否已存在相同的行。如果存在相同的行，则其可以被安全地跳过，因为DML保证将行的最新版本插入到新索引中。

-此操作继续，直到已经处理了源索引中的所有行。如果实施例具有多个故障，则应用相同的算法。

如前所述，一些实施例不能保证在操作结束时将清理所有反物质状态。发生故障后，行可能会在操作结束时保持删除或常规反物质状态并被清理。

对于常规反物质，实施例可以简单地忽略该行的反物质列，但是对于删除反物质，实施例在操作结束时，在切换行集之前同步地删除行，或者如果未来扫描被修改为忽略它们，则延迟。此外，此清理过程高效地完成，以避免全表扫描。为此，实施例可以实现类似于SQLServer®中可用的重影页面清理的收集机制。

为了避免这种复杂性，实施例可以使用每个记录的已有重影状态来跟踪删除反物质状态。为了安全地执行此操作，实施例保证实施例不具有可能与删除反物质混淆的任意已有重影记录。由于这是新索引并将开始分配新页面，因此保证实施例在操作开始时不具有任意重影记录。由于删除反物质行在操作期间存在，因此实施例确保重影清理不能清理该索引的行/页。为了实现该实施例可以阻止针对该索引的行内数据分配单元的重影清理。这将保证实施例清理所有其他索引和小型大对象/大对象（SLOB/LOB）分配单元的重影记录，但不会清理表示删除反物质的重影记录。这可以很容易地完成，因为重影清理取回它正在处理的每个页面的AU 标识符，因此可以轻松绕过特定分配单元的行。

该逻辑防止从目标索引的分配单元清理重影记录，因此，将索引构建操作所需的空间增加到（2 * size_of_index + insertions），因为在操作运行时已删除的行不能被清理。

另外，由于实施例不清除重影记录，所以当索引构建器访问重影记录时，没有必要“消灭”删除反物质，因此甚至进一步简化了状态机。

图6示出了用于可恢复索引构建的反物质状态机600。

可恢复索引构建使用单个反物质状态，因为如上述算法中所述，一些实施例不区分新插入的行和反物质行。索引构建器通过跳过当前正在处理的行来以相同的方式处理它们。

反物质状态用于将由并发DML删除的行与在插入操作回滚时可能已经被引入的其他重影记录区分开。

当行被删除时，首先将其标记为“反物质”，然后如前所述变为重影，以在操作完成之后进行延迟清理。当在反物质-重影记录的顶部插入行时，实施例确保如果插入事务回滚，则该行返回到反物质重影状态。为了实现这些，一些实施例具有两个选项：

（1）在记录头部上保留一位以将记录标记为反物质并扩展插入撤消日志记录以处理回滚到反物质重影状态。

（2）使用对于所有索引构建而存在的已有反物质列来跟踪反物质状态并且当行被插入反物质重影顶部时引入特殊状态转变以将新行标记为反物质。因此，通过删除它而不需要任意特殊处理，该插入的回滚将自动将该行带回到反物质重影状态。

考虑以下问题。唯一NC索引的索引键列仅包含唯一索引列，因此不能允许表示具有不同唯一标识符的两行，这些行对于新索引的唯一键列具有相同的值。以下是此类问题情况的示例：

-源索引包含行，其中c1=1且c2=1

-针对c1上唯一NC索引开始索引创建

-DML插入行，其中c1=1且c2=2

-索引构建崩溃并建立新快照，其中源索引上的两个行都是可见的

-删除到来到并且删除两行。唯一索引没有足够的状态来保持两个“反物质”。

-索引构建器现在处理行，但是找不到2个反物质，因此将至少一行插入新索引，从而破坏它。

然而，这不是重建（在NC上聚集）或唯一聚集索引创建的问题。如果唯一索引已经存在（具有相同的键列），则保证索引对于每个键组合最多具有一行，因此该组合可以被认为是行的标识并且足以表示其在目标索引中的状态。基于此，不存在实施例表示如上例中的多于一行的状态的情况。聚集索引创建使用映射索引来存储每行的反物质状态。映射索引的键包括唯一键列，还包括行的书签，其可用作跟踪每行的状态的唯一标识符。

该问题的解决方案是即使对于唯一的NC索引创建也是使用映射索引来跟踪行的状态。映射索引将包括每行的书签，允许具有针对唯一索引键列的相同值的多行的状态的存储。同时，类似于唯一聚集索引创建，新索引将验证其键的唯一性。

实施例可以使用在该操作正在进行（或暂停）时执行的DML的广泛计划，从而导致一些性能影响。另一种方案是在SE中引入映射索引。

考虑在没有并发DML的情况下的索引构建操作。

假设索引构建器正在查看当前正在处理的行的一致版本，因此行的内容是完整的。这可以通过在行上保持S锁直到它成功迁移到目标索引或使用快照隔离来实现。

索引构建器正在处理源索引I_source的所有行并将它们复制到I_target。由于它使用表扫描，因此可以保证访问每一行，但也不会处理任意行两次，因此维持上述所有不变量。即使在发生故障的情况下，由于操作是事务性的，因此保证了索引的一致性。扫描将从它停止的下一行开始，因为实施例记住了处理的最后一行实施例的键，因此维持所有不变量。

就所涉及的唯一键约束而言，索引本身强制其键的唯一性，并且如果违反约束，则操作将失败。

现在考虑并发DML如何影响该操作：

对于行R_{source，current}其中（current <current_OIB）：

-由于这些DML正在修改已由索引构建器处理的I_source部分中的行，因此这里的任意修改对于索引构建器是不可见的，因此索引构建操作不受它们的影响。索引的这部分中的所有行都保证存在于I_target中，因为索引构建器已经从I_source复制它们，或者因为它们是由并发DML插入的。I_target还可以包含一些删除反物质行，但是这些行可以被认为等同于已删除的行（基于图5中所示的状态机），并且如果DML插入具有相同标识符的行，它将简单地转换为常规反物质。DML维护两个索引，因此保证了实施例将在两个索引上发生完全相同的操作，因此将维持上述所有不变量。

就唯一键约束而言，索引本身强制其键的唯一性，并且因为算法不影响每行的键，所以保证实施例将检测到任意唯一违规并且DML操作将失败。

对于行R_{source，current}其中（current≥current_OIB）：

-对于插入，该行将被插入两个索引中，但是因为current>current_OIB将对索引构建器可见。但是，在处理此行时，索引构建器将能够针对该行将K_source，i重新映射到此行的K_target，并标识该行是否已存在于目标索引中。如果是这样，它可以忽略该行，因为该行已经通过DML操作复制到那里，并且DML将该行更新为最新版本。如果在由另一个DML操作的同时删除了行，则基于图5中所示的状态机，将插入删除反物质，以便索引构建器知道该行的状态并可以忽略它。因此，因为存在唯一地标识新索引中的行的方式，所以保证实施例不将行插入两次。此外，由于并发DML正在维护两个索引，因此所有插入的行都保证具有最更新的行内容。就唯一键约束而言，索引本身强制其键的唯一性，并且由于算法不影响每行的键，因此保证了实施例将检测到任意唯一违规并且DML操作将失败。

-对于删除，从I_source删除该行，并且当正在处理的行尚未被复制到I_target时，以及当它被较早的DML插入并因此已经在I_target存在时，将删除反物质插入I_target。

对于current>current_OIB，该行对于索引构建器是不可见的，并且无法将其错误地插入到目标索引中。

对于current=current_OIB，其中索引构建器已经看到此行但尚未将其插入I_target，删除会插入删除反物质，因此当索引构建器尝试插入行时，它将检测删除反物质并跳过这一行。

目标索引上的任意删除反物质（DAM）可能仍然保持在那里直到操作结束，但是否则不影响操作并且最终可以被清除。

因为这两者是个体索引，所以实施例可能潜在地遇到竞争条件，其中映射索引中指定的状态与实际索引中的状态不一致。但是，由于索引构建器和所有并发DML都将首先更新映射索引，尝试设置该行的状态，因此它们将在该行上获取X锁，从而与该行上的所有其他活动同步。

实施例可以附加地或替代地实现可恢复的排序。

由于至少两个原因，新索引创建使用全表排序：新索引的性能和碎片。关于性能，在没有排序的情况下，索引构建操作将在新索引的随机页面中插入行，从而导致每行插入的随机IO。排序本身主要执行顺序IO，一旦数据被排序，则将保证索引构建器递增地填充页面并避免随机IO。关于新索引的碎片，当数据被排序时，索引构建器可以在移动到下一页之前完全填充每个页面，并且（模块并发DML）这可以保证非常低的碎片，因为页面是按顺序分配的，并且完美填充因子，因为实施例没有页面拆分。执行全表排序需要大量资源和大型表的时间。

一种解决方案用于避免对可恢复索引构建执行原始索引的全表排序，而是逐行地插入或者一次读取相对大块的行（例如10M行），对它们进行排序，并将它们插入新索引。这些方案的问题是对新索引的插入可能发生在随机位置，因此：当缓冲池的大小不足以适应整个索引时，需要物理IO将新索引的页面加载到存储器中，导致到新索引的碎片，因为实施例具有对可能已经满的页面的随机插入并因此导致页面拆分。

尽管读取大批量在一定程度上改善了插入物的局部性，但是当桌子的尺寸明显大于被排序的批次的尺寸时，仍然没有明显更好。

实施例可以基于目标键列来分割工作。实施例基本上基于新索引的键列而不是当前索引来分割工作（对于并行，这被分配给每个线程，对于这种情况，这将是可恢复性的单位）。例如如果实施例正在列C2上构建索引，则实施例可以将工作分成0<C2<10、0<C2<20等的块。这允许执行部分排序，当“合并”在一起时给出完全排序并因此实现新索引的最佳质量（最小碎片）。

以前，并行索引构建需要每个线程执行全表扫描以检索它需要处理的行。在这种情况下，为了避免多次全表扫描会影响性能和可恢复性（可恢复性SLA将受到执行全表扫描的时间的约束），系统可以执行单个表扫描并将所有数据插入到基于上面选择的范围实施例划分的中间数据结构（例如，堆）中。

一旦构建了中间结构，一些系统单独处理每个分区，对其进行排序并将其插入新索引中。该逻辑取决于每个分区可以足够小的假设，因为处理每个分区是可恢复性的单位。

然而，这可能不是安全的假设。定义分区边界需要为目标列创建直方图并相应地拆分范围。目前仅支持单列的直方图，这意味着该分区当前仅依赖于前导键列。系统可以扩展统计逻辑以支持多列统计。但是，可能仍然存在这样的情况：索引是在具有非常少的不同值的列上创建的，这使得很难定义小分区。

如本文所示，一种解决方案是实现可恢复的合并排序。从根本上说，合并排序可以恢复，因为它将工作分成批处理并独立处理（即，排序）它们，最后将它们合并。为了使整个操作可恢复，实施例使得该处理的每个部分都可恢复。

合并排序读取输入数据，在存储器中对其进行排序，并在没有足够的存储器来处理更多数据时将排序的数据刷新到磁盘，以释放存储器中的缓冲区。持久保存到磁盘的已排序数据块称为“排序运行”。为了使该处理可恢复，实施例在从源索引读取数据时跟踪当前排序运行的开始并且具有输入大小的上限，使得即使在具有非常高（例如，TB）可用存储器的系统上也不会丢失大量工作。一旦运行完成，实施例将光标移动到源索引上。最后，实施例可以在故障之后恢复排序运行的内容，这意味着记录和/或检查在每次运行中插入的数据，但是还跟踪关于运行实施例的元数据已经创建以及存储它们的位置。

一旦实施例已经生成了大量单独运行（当前SQL支持多达128个），合并排序将它们合并为一个新运行。如果这是最后组的运行，这将触发最终合并，这将把数据输出到调用者。为了使该处理可恢复，实施例将记住在每次运行中需要处理的下一个元素（类似于核心重建算法），但是，如果这不是最终合并，则使用上述机制来存储输出运行内容及其元数据，以便在故障后恢复它。

为了使整个操作可恢复，实施例存储关于操作的当前状态、实施例停止的阶段（运行生成或合并）、以及已经生成的运行的一些元数据。使用此信息，操作将从停止的位置恢复，仅丢失生成的最后一次运行或合并的最后一批行。

该解决方案允许使新索引创建以针对所针对的场景的高性能可恢复，并且不损害新索引的质量（例如分段）。

上面描述了支持可恢复合并排序的高级逻辑。这里提供了有关此功能的实现以及如何将其嵌入索引构建操作的更多详细信息：

实施例在源索引上开始可恢复扫描，跟踪所做的进展。这会将输入提供给排序，这只会在运行已经被生成并被持久保存到磁盘后推进源索引中的进度。生成运行和更新游览进度可以作为单个事务完成，因为共享资源上没有锁（运行是线程的本地）。

一旦创建了排序运行，关于其存在（runId）和位置（起始pageId）的元数据被例如使用SQLServer®中的sys.sysobjvalues系统表来持久保存在元数据中。这将在创建运行的相同事务中完成。

如果存在故障，则将回滚正在进行的任意排序运行。在Resume上，实施例加载有关已生成的运行的所有元数据并将其馈送给索引构建查询计划，以便排序可以重建其状态并从停止的位置继续。

实施例从持久的分配单元分配所有排序页面并记录行的内容（最小日志记录可用于简单和批量恢复模式）。为此目的，实施例仍然可以重用用于管理排序页面的代码，因为它允许按照它们被插入的顺序访问行，这对于排序是重要的。实施例记录这些页面的内容。

为了避免不必要的日志记录，一些实施例仅在最终合并之前记录排序运行。这意味着如果最终合并最多可以支持N路合并（目前对于SQL设置为128），则可恢复性的单位为表大小的1/N。虽然这对于大型表来说是可接受的阈值，但是实施例可以增加可以在一个步骤中可以被合并的运行次数以考虑甚至大型表。

为了实现这一点，实施例可以将表的近似行数除以N（允许出错的空间），然后对这些行执行常规排序，将结果持久化为将被馈送到最终合并的合并运行。此逻辑意味着为可恢复排序生成的运行可能不会与基于可用存储器生成的运行对齐，因此导致实施例：a）即使有足够的存储器来处理更多行，也会提前关闭排序运行，从而导致在效率较低的最终合并中，或者b）由于存储器不足而对数据进行排序，但也会“溢出”以保持最终运行。

一旦生成了所有运行，实施例就开始合并处理。操作阶段存储在元数据中，并相应地更新。只有在生成所有排序运行之后，才能将合并处理作为完全独立的内部查询或作为相同原始查询的一部分进行调用。

对大型执行最终合并可能花费大量时间，因此损害算法的可恢复性。为了使类型可恢复，实施例跟踪在每次运行中进行合并的进度。新索引的插入将在小事务（N行的批次）中进行，这些事务也将在每个排序运行中推进光标并释放已处理的任意页面/范围。使用该算法，实施例可以在发生故障之后以最小的工作损失恢复合并操作。

如上所述，最终的分类运行是持久的和可恢复的，以允许操作可恢复。这意味着此数据将作为用户数据库的一部分进行存储和记录（而不是在临时数据库中）。这会影响所需的磁盘空间以及操作生成的日志。

此操作的空间要求类似于没有SORT_IN_TEMPDB选项的索引构建。最终的排序运行将保留在用户数据库的页面中，需要额外的（1*size_of_target_index）磁盘空间。然而，在合并这些运行时，存储排序数据的扩展区可以被释放并被重用于最终索引。因此，用户DB中的总体空间要求应与没有SORT_IN_TEMPDB选项的索引构建类似。

对于简单和批量恢复模式，可以在提交生成它们的事务之前将所有排序页面最小化地记录并刷新到磁盘，从而最小化该操作所需的日志量。但是，使用完全恢复模式时，将完全记录所有页面的内容。这将生成一个额外的（1*size_of_target_index）日志，而不是当前操作通常生成的日志。对于日志记录是操作的主要瓶颈的情况，这可能会将操作的性能降低到2倍。

有利地，由于将在小增量事务中生成排序运行，因此将连续截断日志，从而创建日志空间的高效使用。

在已有系统中，基于源索引的快照创建排序，因此保证排序的结果与该快照完全相同。由于可以跨多次重新启动生成排序运行并且不依赖于快照扫描，因此Resumable索引构建不再是这种情况。然而，这对于上述可恢复索引构建算法不是问题。实施例可以执行排序作为从源索引读取行并将其插入目标索引之间的随机延迟。由于并发DML在此期间维护两个索引，因此该延迟不会影响算法，并且也不会导致任意问题。

一些实施例可以在不执行深拷贝的情况下处理LOB。如果排序表仅通过其指针引用LOB，则实施例可能存在挑战以保证其一致性。当前系统通过在排序期间持久化锁或使用版本控制（后者适用于OIB）来处理这一点，但是这不适用于一些可恢复的排序实施例，因为通常实施例不能持久化锁或在重新启动之间保持一致的快照。该问题的一个解决方案如下：可以定义限制，其中LOB不能是索引键列，因此不需要访问LOB来识别源索引中的行与目标索引中的行之间的映射。一致性问题仅在LOB更新时存在，但是，如前所述，DML保证在更新源索引的行时更新/插入目标索引中的任意行。这意味着任意已更新LOB也应在目标索引中被更新。基于此，索引构建器通常不会访问LOB句柄可能过时的行的LOB，因为如果行被更新，它应该已经由执行更新DML移动到新索引，并且和OIB逻辑会跳过这一行。因此，只要没有尝试访问底层LOB，一些实施例可以允许LOB句柄在排序运行中是陈旧的。

为了支持可恢复性，实施例对索引构建处理的查询计划具有约束。

首先，该计划应该是“可恢复的”，意味着实施例应该能够以最小的工作损失为所有操作员恢复工作。随着并行性和过滤索引的引入（如下面更详细的说明），索引构建计划可能变得更复杂并涉及更多操作。查询计划可以定义如何恢复查询计划，或者锁查询优化器（QO）规则以限制可能的计划数量。由于许多QO优化主要适用于小型索引，其中可恢复性不那么重要，因此实施例可以限制可恢复索引构建的QO规则并且允许根据需要进行更多优化。

当一些实施例恢复时，这些实施例使用相同的查询计划或查询计划，其可以基于在先前执行期间跟踪的实施例而恢复。例如实施例使用相同的源索引，相同的搜索范围（对于过滤的索引）等。这可以通过使用USEPLAN提示或实际上在QO/QP内实施逻辑来实现。由于USEPLAN不强制诸如DOP等的所有查询属性。

过滤的索引引入了一些额外的技术挑战，因为它们的过滤器表达式使索引构建计划复杂化并且可能潜在地生成更复杂的查询计划，这需要一些额外的工作来使其可恢复。

例如如果过滤谓词在源索引的键列上，则查询计划可以包含在过滤谓词上具有搜索谓词的范围。同时为了可恢复性，实施例迫使不同的搜索谓词从其停止的地方恢复操作。为了适当地处理这种情况，实施例可以包括合并两个范围的机制。“恢复”范围可以是一子组的过滤器范围，因此，实施例应该能够在没有太多的复杂性的情况下合并范围。

另外，基于过滤谓词的选择性，QO可以在索引选择以及并行策略方面选择完全不同的查询计划。例如对于非常低的选择性，实施例可能选择在NC索引和聚集索引之间使用嵌套循环连接（NLJ）的计划以仅获取合格的行。支持这种计划的一些实施例能够从它们停止的点恢复它们。

可以扩展实施例以支持并行性，但是尤其是在存在过滤索引的情况下QO生成的各种并行计划可能需要分别处理每个计划形状并解决不同的问题集合。以下说明了索引构建器可以选择的并行计划。

一个并行计划是分区扫描。这似乎是最常见的计划（并且可能是为重建生成的唯一计划），逻辑是实施例将N个范围内的新索引的前导键列的值范围分开，并且每个线程用在其指定的范围上的滤波器来执行独立扫描。对于重建，由于源索引也在相同列上，因此该谓词是可搜索的。相同的线程将限定行排序并插入到新索引中。

由于每个线程具有其自己的独立扫描，为了使该计划可恢复，实施例保持分区范围，并且每个线程还将使用元数据部分中描述的相同系统表基于源索引键持久化其进度。由于键列的数量非常有限，因此实施例可以将SQL Server中的valnum（或等效）列分成两部分，并且具有指示线程ID的最重要的2字节和指示键列ID的最不重要的2字节。利用该实施例，可以存储每个线程的范围及其当前位置。

在恢复时，实施例重新加载相同的分区范围并强制每个线程从其最后停止的点开始。由于基于源索引键跟踪进度，因此该谓词将是可搜索的。

一个有趣的挑战是分区范围现在持久化在磁盘上并因此甚至在恢复、changeSLO等之后应用，其中新机器、SLO、RG上的资源可以与原始操作开始时不同。

为了解决这个问题，一些实施例将表拆分成比当前并行度更多的范围，使得如果并行度在将来改变，则实施例可以将它们均匀地分配给更多或更少的线程。每个可用的线程都会获取下一个范围并继续持久化此范围的进度。一旦完成后，它会移动到下一个范围，依此类推。这允许处理在恢复操作时并行度更高或更低的情况，因为一个线程可以处理多于一个范围。特别是在索引重建的情况下，由于范围基于已有索引，因此每个线程处理多个范围没有开销，因为它可以使用索引立即将自身定位到范围的开头并从那里开始。

QO可以生成的另一个并行计划，主要是针对实施例正在创建具有一定选择性的过滤索引的场景，是具有共享的并行扫描（如果选择性低，甚至是单线程扫描），该扫描馈送一个范围交换（分区或停止），该范围交换将扫描的数据拆分为多个范围，这些范围是基于目标索引的前导键列定义的，类似于以前的计划类型。之后，每个线程独立地排序并且插入其数据。

为了使该计划可恢复，实施例可以使范围持久化并使每个线程跟踪其被持久化的最后一行到新索引。在恢复时，实施例可以重新加载先前的范围并从所有线程的最小进度开始共享扫描。这将保证实施例不会遗漏任意行，然而，除非实施例为单独线程引入附加过滤器，否则一些线程可能看到它们已经插入的重复行。

分区索引具有特殊索引构建计划，其中基本上每个线程负责构建特定分区。这是由ConstScan实现的，ConstScan馈送分区ID并且通过应用于索引构建侧被推送。通过跟踪每个分区的进度并从那里恢复，可以使该计划可恢复。

除了交换分区范围基于分区Id虚拟列而被分割，未对准的分区索引构建计划类似于“并行扫描”计划。如果不包括并行计划，则实施例必须修改该计划以使其成为“分区扫描”以支持该场景。这样，所有线程都将扫描所有分区并且过滤掉不属于它们正在构建的目标分区的行。

在用于新索引创建的并行计划中，由于针对分区范围的谓词不可搜索（因为它在新索引的前导键列上），基于数据分布，可能存在对于大量时间将不会从SE获得任何数据的线程，因为没有行符合扫描条件。在一些实施例中，这意味着这些线程将更新它们的进度，并且因此将在发生故障事件时丢失大量工作。

这对于重建不应该是问题，因为范围谓词是可搜索的（并且没有过滤器谓词）并且所有线程将不断地找到符合条件的行。

然而，为了解决该问题，即使没有行符合条件，实施例也可以周期性地更新进度。一些实施例可以发送一些来自扫描的“假”行，从而使得即使没有行被实际插入到新索引中，索引构建器也为该线程更新进度。

另一个有趣的挑战是实施例拆分范围的方式现在被持久化在磁盘上，因此即使在恢复、changeSLO等之后也适用，其中新机器、服务级别对象（SLO）（这实际上是用户已经为他们的云数据库挑选的配置；有多少内核、多少存储器等）、资源治理（RG）（这是SQLServer®中的一个特征，该特征允许用户配置每个查询在CPU、存储器等方面应该使用多少资源）上的资源可以与原始操作开始时不同。

为了解决这个问题，实施例将范围重新分配给不同的任务。移动到更多线程应该是可能的，因为实施例跟踪每个范围的进度，并且实施例可以将其分配给不同的任务来继续工作。然而，由于一个线程需要处理可能使完全不同的进度的不同范围，所以减少线程的数目会进一步引入复杂性。对于重建，实施例可以寻求各个范围。但是，对于新索引创建，如果分区列与源索引的前导键列不同，则评估不同范围可能需要多次扫描。

实施例可以从在恢复时强制相同的并行度（DOP）开始，从而使得实施例不对范围进行重新分区，或者如果没有足够的资源来使用所需的DOP则不能通过查询。

每当索引操作被恢复时，实施例正在建立新快照，这意味着自从上一快照以来被删除的任意行不再可见。因此，任意直到那时已被插入的反物质行（基于上述算法，意味着这种情况下的重影行）将在源索引中不可见，并且基本上是无用的并且可以安全地被清理。

为了允许在索引操作暂停时解除分配空间并最小化在其完成之后清理所需的工作，实施例仅在OIB操作正在运行时而不是在其暂停时阻止重影清理。这可以通过在OIB操作期间设置一些存储器中状态而被轻松完成。实施例仍然保证重影清理不能清理在快照被建立之后由DML插入的行，因为这可能导致实施例错过现在在快照中可见的行。这应该由建立新快照所需的S锁自动实现，因为这会耗尽所有DML，并且ghost清理因为它将已被禁用，因此将无法处理已删除的行。解锁ghost清理可以以更懒惰的方式被完成，因为延迟清理不会导致任意问题。

作为索引构建操作的一部分，实施例重建全表统计，因为实施例已经正在访问表的每一行。传统上，构建统计数据不是可恢复的操作，这意味着每次重新启动发生时，关于直方图的中间信息都会丢失。然而，实施例可以以各种方式对此进行补救。

例如一些实施例，为任意可恢复索引构建操作来构建经采样的统计。实施例仅在索引构建处理期间完全地忽略所有统计信息，而是仅在索引构建操作完成时执行单独的经采样的统计信息创建查询，而不是构建完整统计信息。这意味着创建统计信息所需的时间将在可恢复性服务级别协议（SLA）内，并且因此整个操作是可恢复的。

备选地或附加地，实施例可以实现可恢复的统计创建处理。QO中已经存在用于合并来自当前用于并行统计建立的数据的单独部分以及SQLServer®中的增量统计的直方图的代码。实施例可以重用该逻辑并且递增地构建在磁盘上被持久化的统计数据，以便它们能够从故障中存活下来并且最终被合并在一起以形成最终统计数据。

虽然已经说明了在线索引构建，但是应当理解，一些实施例可以支持离线场景的可恢复性。可恢复索引构建的主要价值主张之一是允许所有查询，并且在索引构建操作被暂停时不保留任意资源。为实现此目的，实施例使用在线索引构建基础结构，以用于离线索引构建。不同之处在于，当操作正在进行时，实施例在表上持久化独占（SCH-M）锁，使得操作离线。

在暂停OIB操作的同时，实施例可以将新索引作为具有基于索引操作被暂停的点的谓词的经过滤的索引，从而使得并发DML操作不维护索引构建器尚未处理的值的索引，从而提高了索引构建被提前暂停的情况下的性能。

而外地，实施例甚至可以允许SELECT操作使用该经过滤的索引以获得改进的计划。

以下讨论现在涉及可以执行的许多方法和方法动作。虽然方法动作可以按特定顺序讨论或在流程图中以特定顺序说明，但除非特别说明或要求，否则不需要特定排序，因为动作取决于在动作被执行之前完成的另一动作。

现在参考图7，示出了方法700。方法700可以在数据库计算环境中被实践。该方法包括用于生成新数据结构的动作。

方法700包括从用户接收用于修改已有数据结构或创建新数据结构的数据库命令（动作702）。例如用户可以请求为数据库创建新索引，诸如图1中所示的数据库102。图2-4还示出了请求各种操作的用户200。用户可以是人类用户或数字实体。

方法700还包括将查询提供给查询优化器组件（动作704）。例如图2-4中的QP 224示出了查询优化器组件的示例。

方法700还包括在查询优化器组件处将查询转换为第一查询执行计划，其中第一查询执行计划包括使第一查询计划的执行的操作状态持久化的一个或多个操作（动作706）。因此，例如QP 224可以被配置为通过将查询的操作状态持久化来创建可恢复查询计划。

方法700还包括通过执行第一查询计划的至少一部分来接收在查询中指定的数据的至少一部分，并且构造新数据结构的至少一部分（动作708）。因此，例如在图1中，可以通过使用来自在数据库102上执行的查询的结果来创建新索引106的部分。

方法700还包括在接收在查询中被指定的数据的至少一部分并且构造新数据结构的至少一部分的同时，使第一查询计划的执行的操作状态持久化（动作710）。因此，例如当执行操作以创建和填充新索引106时，可以保存状态，指示查询计划的哪些部分已被执行。

方法700还包括确定第一查询计划的执行中断已经发生（动作712）。因此，例如用户可能需要中断计划以将计算资源用于某些其他目的。备选地或附加地，，第一查询计划的执行可能由于某些系统故障或其他原因而被中断。

方法700还包括作为确定已经发生第一查询计划的执行中断的结果，使用第一查询计划的执行的被持久化的操作状态来生成经更新的查询计划，使得新查询计划能够被执行而无需完全重新开始接收数据和构造新数据结构（动作714）。因此，实施例可以使用保存状态创建新查询计划，从而允许构建新查询计划以利用先前在创建新数据结构时执行的工作，但是该工作先前被中断。请注意，这可能会重复发生。因此，虽然本文使用了第一和新的查询计划，但是应当理解，这些术语一般涉及查询计划并且不定义特定的出现。因此，例如如本文权利要求所述的第一查询计划的执行可以指查询计划，该查询计划是使用从保存状态创建的查询计划的一个或多个中断和恢复处理的结果。

方法700还包括通过执行经更新的查询计划来恢复接收数据并且构造新数据结构（动作716）。例如如图3中的304所示，可以通过使用存储的执行状态来继续执行先前停止的执行。

方法700还包括在数据作为执行第一查询计划的结果而被接收的同时或者在第一查询计划的执行被中断的同时，接收对新数据结构的外部更新（动作718）。

方法700还包括结合执行经更新的查询计划来事务验证外部更新（动作720）。因此，例如如果用户将数据项添加到数据结构中或将数据项从数据结构中删除，即使数据结构的创建已被中断，可以对新数据结构进行更新，并且一旦由于执行新查询计划的执行而恢复数据结构的创建，就可以保留和验证这些更新。因此，当重用来自上一个事务的状态的新事务（例如在该示例中，新查询执行计划的执行）被启动和/或运行时，即使在事务（例如第一查询执行计划的执行）被中断并且失败时，事务动作（例如数据结构更新）也可以被验证。

方法700还可以包括：基于在第一查询计划执行的中断期间添加或删除数据项的操作，来防止中止和回滚用于生成新数据结构所采取的动作的至少一部分。

方法700还可以包括防止冗余地将数据项插入到新数据结构中。

方法700还可以包括防止冗余地删除新数据结构中的数据项。

方法700还可以包括清理标记，该标记指示数据结构中的数据项在第一查询计划的执行的中断的期间被添加或删除。

方法700还可以包括作为第一查询计划的执行的一部分：将排序操作划分成多个部分；执行排序操作的第一部分；使来自排序操作的第一部分的中间结果持久化；以及使排序操作的状态标识排序操作的哪些部分已经被执行。

可以实践方法700，其中修改已有数据结构或创建新数据结构包括构造针对先前索引的数据存储库的新索引。

可以实践方法700，其中修改已有数据结构或创建新数据结构包括修改表的模式。例如这可以包括修改列的类型或其他此类动作。

可以实践方法700，其中经更新的查询计划包括与被持久化的状态被创建时不同的并行度。例如单个线程可能已创建被持久化的状态，多线程被恢复的查询计划具有被持久化的状态）。

此外，该方法可以由包括一个或多个处理器和诸如计算机存储器的计算机可读介质的计算机系统来实践。特别地，计算机存储器可以存储计算机可执行指令，该计算机可执行指令在由一个或多个处理器执行时引起要被执行的各种功能，诸如实施例中记载的动作。

本发明的实施例可以包括或利用包括计算机硬件的专用或通用计算机，如下面更详细地讨论的。本发明范围内的实施例还包括用于携带或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这种计算机可读介质可以是可由通用或专用计算机系统访问的任意可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。携带计算机可执行指令的计算机可读介质是传输介质。因此，作为示例而非限制，本发明的实施例可包括至少两种截然不同的计算机可读介质：物理计算机可读存储介质和传输计算机可读介质。

物理计算机可读存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器（诸如CD、DVD等）、磁盘存储或其他磁存储设备、或者可以是用于以计算机可执行指令或数据结构的形式存储所需程序代码、并且可以由通用或专用计算机访问的任意其他介质。

“网络”被定义为使在计算机系统和/或模块和/或其他电子设备之间能够传输电子数据的一个或多个数据链路。当通过网络或其他通信连接（硬连线、无线或硬连线或无线的组合）向计算机传输或提供或传送信息时，计算机将连接正确地视为传输介质。传输介质可以包括网络和/或数据链路，其可以被用于携带以计算机可执行指令或数据结构的形式，并且可以由通用或专用计算机访问的期望的程序代码部件。上述的组合也包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件时，计算机可执行指令或数据结构形式的程序代码装置可以自动地从传输计算机可读介质传输到物理计算机可读存储介质（或反之亦然）。例如通过网络或数据链路接收的计算机可执行指令或数据结构可以缓冲在网络接口模块（例如“NIC”）内的RAM中，然后最终传送到计算机系统RAM和/或更少易失性计算机系统中的计算机可读物理存储介质。因此，计算机可读物理存储介质可以被包括在也（或甚至主要）利用传输介质的计算机系统组件中。

计算机可执行指令包括例如使通用计算机、专用计算机或专用处理设备执行特定功能或功能组的指令和数据。计算机可执行指令可以是例如二进制文件，诸如汇编语言的中间格式指令，或甚至是源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但应理解，所附权利要求书中定义的主题不必限于上述特征或动作。相反，所描述的特征和动作被公开为实现权利要求的示例形式。

本领域技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持设备、多处理器。系统、基于微处理器或可编程的消费电子产品、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等。本发明还可以在分布式系统环境中实施，其中通过网络链接（通过硬连线数据链路、无线数据链路或通过硬连线和无线数据链路的组合）的本地和远程计算机系统都执行任务。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备中。

替代地或另外地，本文描述的功能可以至少部分地由一个或多个硬件逻辑组件执行。例如但不限于，可以使用的说明性类型的硬件逻辑组件包括现场可编程门阵列（FPGA）、程序专用集成电路（ASIC）、程序专用标准产品（ASSP）、片上系统（SOC）、复杂可编程逻辑器件（CPLD）等。

在不脱离本发明的精神或特征的情况下，本发明可以以其他特定形式实施。所描述的实施例在所有方面都应被视为仅是说明性的而非限制性的。因此，本发明的范围由所附权利要求而不是前面的描述表示。在权利要求的含义和等同范围内的所有变化都包含在其范围内。

Claims

1.一种计算机系统，包括：

一个或多个处理器；以及

一个或多个计算机可读介质，具有存储在其上的指令，所述指令由所述一个或多个处理器可执行以配置所述计算机系统以生成新数据结构，所述指令包括可执行以配置所述计算机系统以至少执行以下项的指令：

从用户接收用于修改已有数据结构或创建新数据结构的数据库命令；

构造将执行所述数据库命令的查询并且将所述查询提供给查询优化器组件；

在所述查询优化器组件处，将所述查询转换为第一查询执行计划，其中所述第一查询执行计划包括使第一查询计划的执行的操作状态持久化的一个或多个操作；

接收在所述查询中被指定的数据的至少一部分，并且通过执行所述第一查询计划的至少一部分来构造所述新数据结构的至少一部分；

在接收在所述查询中被指定的数据的所述至少一部分并且构造所述新数据结构的至少一部分的同时，使所述第一查询计划的执行的操作状态持久化；

确定所述第一查询计划的执行的中断已经发生；

作为确定所述第一查询计划的执行的中断已经发生的结果，使用所述第一查询计划的执行的被持久化的所述操作状态来生成经更新的查询计划，使得所述经更新的查询计划能够被执行而不用完全重新开始接收数据和构造所述新数据结构，所述第一查询计划至少部分地基于存储的、包括与针对对象的模式有关的信息的元数据而被确定的，所述对象与所述新数据结构有关；

通过执行所述经更新的查询计划来恢复接收数据并且构造所述新数据结构；

在数据作为所述第一查询计划的执行的结果而被接收的同时或者在所述第一查询计划的执行被中断的同时，接收对所述新数据结构的外部更新；以及

结合执行所述经更新的查询计划来事务性地验证所述外部更新。

2.根据权利要求1所述的计算机系统，其中所述一个或多个计算机可读介质具有存储在其上的指令，所述指令由所述一个或多个处理器可执行以配置所述计算机系统：基于在所述第一查询计划的执行的中断期间添加或删除数据项的操作，来防止中止和回滚用于生成所述新数据结构所采取的动作的至少一部分。

3.根据权利要求1所述的计算机系统，其中所述一个或多个计算机可读介质上具有存储在其上的指令，所述指令由所述一个或多个处理器可执行以配置所述计算机系统：防止冗余地将数据项插入到所述新数据结构或者冗余地删除所述新数据结构中的数据项中的至少一项。

4.根据权利要求1所述的计算机系统，其中元数据组件存储与数据库中所有所述对象的所述模式有关的信息，所有所述对象与所述新数据结构有关。

5.根据权利要求1所述的计算机系统，其中所述一个或多个计算机可读介质具有存储在其上的指令，所述指令由所述一个或多个处理器可执行以配置所述计算机系统：清理标记，所述标记指示所述数据结构中的数据项在所述第一查询计划的执行的所述中断的期间被添加或删除。

6.根据权利要求1所述的计算机系统，其中所述一个或多个计算机可读介质具有存储在其上的指令，所述指令由所述一个或多个处理器可执行以配置所述计算机系统：作为所述第一查询计划的所述执行的一部分：

将排序操作划分成多个部分；

执行所述排序操作的第一部分；

使来自所述排序操作的所述第一部分的中间结果持久化；以及

使所述排序操作的状态持久化，所述排序操作的所述状态标识所述排序操作的哪些部分已经被执行。

7.根据权利要求1所述的计算机系统，其中修改已有数据结构或创建新数据结构包括构造针对先前被索引的数据存储库的新索引，包括作为确认用户事务还未开始的结果，创建和持久化所述元数据并且初始化索引构建操作，其中所述元数据针对所述新索引使用针对所述索引构建操作的选项被持久化到持久存储，其中所述索引构建操作跟踪针对数据库的每行的状态。

8.根据权利要求1所述的计算机系统，其中修改已有数据结构或创建新数据结构包括修改表的模式。

9.根据权利要求1所述的计算机系统，其中所述经更新的查询计划包括与被持久化的所述状态被创建时不同的并行度。

10.一种在数据库计算环境中生成新数据结构的方法，所述方法包括：

从用户接收用于修改已有数据结构或者创建新数据结构的数据库命令；

确定所述第一查询计划的执行的中断已经发生；

11.根据权利要求10所述的方法，还包括：基于在所述第一查询计划的执行的中断期间添加或删除数据项的操作，来防止中止和回滚用于生成所述新数据结构所采取的动作的至少一部分。

12.根据权利要求10所述的方法，还包括：防止冗余地将数据项插入到所述新数据结构中或者防止冗余地删除所述新数据结构中的数据项中的至少一项。

13.根据权利要求10所述的方法，其中恢复接收数据包括取回已有索引选项和所述元数据，以及其中操作作为所述中断的结果被停止的起始点。

14.根据权利要求10所述的方法，还包括清理标记，所述标记指示所述数据结构中的数据项在所述第一查询计划的执行的所述中断的期间被添加或删除。

15.根据权利要求10所述的方法，还包括作为所述第一查询计划的所述执行的一部分：

将排序操作划分成多个部分；

执行所述排序操作的第一部分；

16.根据权利要求10所述的方法，其中修改已有数据结构或创建新数据结构包括构造针对先前被索引的数据存储库的新索引。

17.根据权利要求10所述的方法，其中所述经更新的查询计划包括与被持久化的所述状态被创建时不同的并行度。

18.一种数据库计算机系统，包括

执行引擎，其中所述执行引擎被配置为至少执行以下项：

构造将执行所述数据库命令的查询并且将所述查询转换为第一查询执行计划，其中所述第一查询执行计划包括使第一查询计划的执行的操作状态持久化的一个或多个操作；

向查询处理器提供所述查询；

所述查询处理器，其中所述查询处理器被配置为至少执行以下项：

确定所述第一查询计划的执行的中断已经发生；

作为确定所述第一查询计划的执行的中断已经发生的结果，使用所述第一查询计划的执行的被持久化的所述操作状态来生成经更新的查询计划，使得所述经更新的查询计划能够被执行而不用完全重新开始接收数据和构造所述新数据结构，所述第一查询计划至少部分地基于存储的、包括与针对对象的模式有关的信息的元数据而被确定，所述对象与所述新数据结构有关；

通过执行所述经更新的查询计划来恢复接收数据并且构造所述新数据结构；以及

在数据作为所述第一查询计划的执行的结果而被接收的同时或在所述第一查询计划的执行被中断的同时，接收对所述新数据结构的外部更新；以及

存储引擎，其中所述存储引擎被配置为结合执行所述经更新的查询计划来事务性地验证所述外部更新。

19.根据权利要求18所述的数据库计算机系统，其中所述数据库计算机系统被配置为：

将排序操作划分成多个部分；

执行所述排序操作的第一部分；

20.根据权利要求18所述的数据库计算机系统，其中修改已有数据结构或创建新数据结构包括构造针对先前被索引的数据存储库的新索引。