CN102436490A - 多功能存储器内数据库恢复 - Google Patents

Abstract

本发明涉及一种实现事务日志记录的各方面以优化数据库恢复性能的数据库恢复技术。事务被逻辑性地日志记录而无需参考物理位置，这允许日志记录经由多个独立的日志流并行地执行。日志流集还可被调整成符合镜像节点或副节点的局部配置以增加镜像灵活性。另外，使用单个日志记录来记录各个事务或事务组，该日志记录包含在无需参考物理检查点文件的情况下实现数据库恢复的时间戳信息。此外，在本文中提供了用于在无需提前写入日志记录或加固撤销信息的情况下处理事务的技术。如在本文中进一步所述的，可经由分层阶段集提交事务，这进而可便于存储器内数据库系统与一个或多个外部数据库系统的集成。

Description

多功能存储器内数据库恢复

技术领域

本发明涉及数据库系统中的恢复，更具体地涉及用于多功能数据库系统恢复的日志记录过程和提交过程。

背景技术

数据库系统可实现各种机制以确保在数据库系统上执行的事务产生正确的结果。例如，数据库系统可以其他合适的方式实现并发控制机制以使多个并发执行的事务相互隔离和/或防止这些事务相互干扰。作为另一示例，数据库系统可实现用于确保与数据库系统相关联的数据项的一致性和/或恢复的一种或多种机制。

数据库恢复子系统(RS)管理对相关联的数据库系统内所执行的各个操作的记录，这进而便于镜像数据库系统、在系统崩溃或其他故障的情况下的恢复与数据库系统相关联的数据项、和/或增强相关联的数据库系统的弹性和稳健性的其他手段。在各个数据库系统实现中，操作主要在一个或多个基于盘的数据存储或其他类似存储介质中进行，并且RS可参考与操作相关联的数据存储内的物理位置来将这些操作进行日志记录。例如，数据库系统中的数据存储可被分成页面或其他合适的存储单元，并且影响一个或多个页面的操作可与操作所影响的页面一起由RS进行日志记录。在一些情况下，诸如特定页面内的行位置或存储地址之类的精细物理位置信息可与相关页面身份一起被日志记录。另外，RS可在检查点操作(checkpointing)时获得一个或多个页面的物理检查点，这些物理检查点指示存储在经检查点操作的页面中的数据。随后，在因系统崩溃或故障和/或其他原因发起对数据库系统的重建的情况下，可通过将系统中的各页面还原到一个或多个检查点所指示的状态来重建数据库系统。另外，可重建在创建检查点之后所作出的对一个或多个页面或其他物理数据位置的改变，如RS所维护的操作的日志所指示的。

然而，对于诸如被设计成主要在存储器内操作的数据库系统(例如，不是如上所述的主要在盘上(on-disk)的数据库系统)之类的一些数据库系统，为了使相关联的RS适应对所实现的特定数据库系统的需要，各种设计考虑是合乎需要的。例如，对于一些数据库系统实现，RS实现允许增强的多功能性、并行化、与其他数据库系统和/或其他系统集成、镜像能力等是合乎需要的。

当今的数据库恢复技术的以上描述仅仅旨在提供常规系统的概览，而不旨在是穷尽的。其他常规系统以及在本文中所述的各非限制性实施例的对应益处可在审阅以下描述后变得更显而易见。

发明内容

此处提供了简化概述以帮助能够对以下更详细的描述和附图中的示例性、非限制性实施例的各方面有基本或大体的理解。然而，本发明内容并不旨在作为详尽的或穷尽的。相反，本节发明内容的唯一目的在于，以简化的形式提出与一些示例性、非限制性实施例相关的一些概念，作为以下各实施例的更详细的描述的序言。

在一个或多个实施例中，可以如在本文中所述的各种方式管理与数据库系统相关联的恢复子系统，从而便于存储器内(in-memory)数据库系统和/或其他合适的数据库系统内的多功能的和高度功能性的日志记录和恢复。本文中的各个实施例提供多功能性以允许RS满足对崩溃恢复、高可用性(HA)(例如，镜像)、备份/还原、以及其他合适功能的需要。另外，本文中的各实施例提供了并行化，从而在没有可预测排序的一些情况下允许RS从多个日志流和/或多个HA连接并发地接收恢复信息。此外，本文中的一些实施例便于与现有二阶提交协议集成的RS设计，由此允许相关联的数据库系统与一个或多个外部数据库系统和/或其他系统之间的互操作(inter-operation)。另外，本文中的一些实施例定义经镜像数据库节点可另外用作可读副节点的可见性规则和/或其他机制。

在一个实施例中，经由逻辑日志记录实现部分或全部的上述设计考虑，其中对数据库系统内的数据操作的各个事务在无需参考数据的位置或任何其他物理信息的情况下被日志记录。在另一实施例中，在不使用缓冲池的情况下处理数据库事务。结果，在无需将“废”数据写入盘并且无需存储撤销信息和/或与转换事务相关的其他信息的情况下管理数据库事务。

在如上所述的所维护的逻辑日志内，与数据库事务相关的信息被记录在单个日志记录中。日志记录可被配置成携带关于单个事务的信息，或者在替换实施例中，多个事务可被归组到一个日志记录中。在日志记录内，各个字段可提供开始时间戳和结束时间戳和/或指示其中对应事务活动的时间段的其他信息。这些信息可形成逻辑检查点操作系统的基础，其中可在无需参考事务操作的物理位置的情况下，通过以事务的开始时间戳和结束时间戳所指定的次序重复记录在各个日志条目中的事务来重建数据库系统的状态。通过以此方式消除对物理检查点信息的依赖性，可在包括副节点的各个相关联的数据库节点处独立于这些节点的存储配置或输入/输出(I/O)能力来构建或重建数据库。在本文中的一些实施例中，可通过实现部分检查点、差分检查点和/或其他技术来减小检查点大小。

除实现逻辑检查点操作以外，如以上所提供的日志记录结构允许经由多个独立的日志流来进行数据库系统的日志记录，每个日志流可被分配给不同的I/O设备等以增加效率、使用更优化的资源等。在一些情况下，实现多个日志流的RS可合并、拆分、或以其他方式操纵日志流以使改变适应叠加操作环境、与各个日志流相关联的一个或多个I/O设备的故障、或其他情形。另外，通过合并、拆分、或以其他方式操纵日志流集，数据库系统可计及镜像节点处的不同几何形状；例如，镜像节点可接收关于日志流集的恢复信息并且调整日志流以适应局部系统配置。

在本文中的其他实施例中，存储器内数据库系统可充分利用如上所述的逻辑日志记录以在不使用提前写入日志记录的情况下管理对数据库系统内的数据进行操作的事务。例如，可限制存储器内通过事务修改的数据向盘的写入，直到事务已经提交并且已经记录在日志记录中之后。此外，如上所述，撤销信息和/或与逆转事务相关的其他信息可在提交事务之后被丢弃。

另外，本文中的各实施例提供了事务可分多个阶段提交的分层提交过程。首先，通过加固与恢复数据库系统中的事务相关联的信息来物理地提交事务。其次，通过在整个系统存储器施加事务所作出的改变来逻辑地提交事务。再次，通过使事务的结果对数据库系统外部的实体可见来可见地提交事务。在一个实施例中，该分层提交过程可用于将多个数据库系统集成到表面上单一的数据库系统中，由此以透明方式向数据库用户提供多个数据库系统的益处和功能。

这些和其他实施例在下文中更详细地描述。

附图说明

参考附图进一步描述各非限制性实施例，在附图中：

图1示出数据库中的事务的示例性生存期的说明性概览；

图2示出数据库恢复子系统所维护的日志流的示例性集的说明性视图；

图3是示例性日志结构的说明性视图；

图4是关于数据库事务所使用的提交阶段的说明性视图；

图5是示出根据一个或多个实施例的实现事务管理和恢复机制的数据库系统的框图；

图6是示出根据一个或多个实施例的日志流管理机制的示例性功能的框图；

图7是示出根据一个或多个实施例的实现日志流管理机制的数据库镜像节点的框图；

图8是示出根据一个或多个实施例的数据库系统集成机制的示例性功能的框图；

图9是示出用于管理存储器内数据库系统中的恢复子系统的示例性、非限制性过程的流程图；

图10是示出用于维护关于数据库事务的数据库恢复信息的示例性、非限制性过程的另一流程图；

图11是示出用于在副节点处维护数据库系统的示例性、非限制性过程的又一流程图；

图12是示例性数据库检查点操作方案的说明性视图；

图13是示例性差分检查点操作技术的说明性视图；

图14是另一示例性差分检查点操作技术的说明性视图；

图15是表示其中可实现在本文中所述的各实施例的示例性、非限制性联网环境的框图；以及

图16是表示其中可实现在本文中所述的各实施例的一个或多个方面的示例性、非限制性计算系统或操作环境的框图。

具体实施方式

概览

作为介绍，数据库系统可通过诸如但不限于数据创建和维护、信息检索、经由搜索或其他机制的数据访问等操作来便于对各个相关联的数据项的管理。在某些实施例中，数据库系统可提供各种机制来确保相关联数据的可恢复性和完整性。例如，数据库系统可管理在系统内执行的(例如，与数据库系统所执行的各个事务相关联的)操作以确保这些操作产生正确的结果。作为示例而非限制，数据库系统可结合并发控制机制以确保数据库系统所并发执行的各个事务不相互干扰。另外，数据库系统可结合各种其他机制以确保正确的操作。作为非限制性示例，数据库系统可使用确保与系统相关联的数据的一致性、完整性和/或可恢复性的各种机制。

在一个示例中，数据库系统可用于管理存储在至少一个数据存储中的信息。作为示例而非限制，存储器内数据库可被设计并且实现为管理存储在对应的计算机存储器或任何其他合适的非瞬态计算机存储介质中的数据。存储器内数据库系统的各非限制性实施例、或者可用于提供类似功能的其他数据库系统一般可提供关于相关联数据存储的低级功能。这些功能可包括，例如，支持事务和/或查找、光标等。另外，这些数据库系统可直接地或间接地通过与提供这些功能的一个或多个不同的系统的协作来提供对各个更高级功能的支持。可由数据库系统直接地或间接地支持的更高级功能的示例包括但不限于，相关联用户界面的生成或控制、对基于各种查询语言的查询的支持(例如，美国国家标准协会(ANSI)/国际标准组织(ISO)结构化查询语言(SQL)、Xquery等)等。

另外，数据库系统可实现恢复系统(RS)和/或其他机制，这些其他机制被配置成在系统崩溃、数据存储设备故障的情况和/或与数据库系统相关联的数据的恢复是合乎需要的其他情况下保存结合数据库系统所存储的信息。一般而言，RS经由将对数据库系统内的数据所执行的各个操作的日志记录、数据存储设备镜像和冗余、检查点操作以及其他合适的技术提供数据库系统的弹性。

诸如采用如本领域公知的用于恢复和隔离开发语义的算法(ARIES)的基于盘的数据库系统之类的一些数据库系统和/或可采用如本领域已知的其他合适恢复技术的其他常规数据库系统使用物理日志记录来记录对数据库系统内的数据执行的操作。在物理日志记录方案中，数据库系统内所修改的数据与数据的物理位置一起被记录。物理日志记录的变体是混合物理-逻辑日志记录、或“生理”日志记录，其中维护结构化索引，该结构化索引包含与盘上的各页面和/或相关联数据存储的其他合适单元直接或间接相对应的索引记录。在对与一个或多个页面相对应的数据进行操作(例如，插入数据、删除数据等)之后，使用适当的索引记录来生成并且索引指示该操作和该操作所影响的物理页面的日志记录。

在如上所述的物理或生理日志记录技术或其他合适的日志记录技术中，向日志记录分配与在数据存储内执行对应操作的次序相对应的序列。因此，这种系统中的日志记录包括序列信息、页面信息(或其他位置信息)、以及事务信息。

与如上所述的常规数据库系统相反，各个其他数据库系统展示了使恢复子系统设计的上述方面无效或不适用的特性。作为示例，存储器内数据库系统可被配置成主要在存储器内(例如，不是盘上数据存储)操作。因此，参考物理页面、盘位置和/或主要与盘上数据存储相关的其他信息来记录数据库事务的数据库日志记录机制提供了对这种数据库系统的最小化利用。

除上述内容以外，一些存储器内数据库系统和/或其他合适数据库系统内所实现的恢复系统可具有各个期望的特征，至少一些特征在传统恢复子系统设计中未予以考虑。例如，可期望恢复子系统提供多功能性以满足对崩溃恢复、高可用性(HA)或镜像和备份/还原的需要。另外，可期望恢复子系统实现并行化，从而在没有可预测排序的一些情况下允许恢复信息从多个日志流或多个HA连接并发地到达。此外，可期望恢复子系统与现有二阶段提交协议集成。在一个实施例中，该集成可使数据库系统能与一个或多个数据库系统互操作，如在本文中进一步所述的。另外，可期望如在本文中所述的恢复子系统通过例如定义可见性规则来实现可读镜像，以使镜像节点还可用作可读副节点。

在这点上，在如本文中所阐述的各实施例中，提出了数据库恢复管理方案，这些数据库恢复管理方案提出了现有方案的至少上述限制。另外，在本文中提供了恢复方案的其他益处。可以理解，如在本文中所述的各实施例的益处仅仅旨在作为经由使用这些实施例来实现的益处的非限制性示例。此外，本文中所提供的各个方案不旨在关于所阐明益处中的任一个和/或可从这些方案中实现的任何其他益处而被视为优于彼此。

在一个实施例中，数据库管理系统包括日志管理器组件，该日志管理器组件被配置成以逻辑日志记录格式生成与对至少一个数据存储中的数据进行操作的事务相关的一个或多个日志记录。在这种系统中，与逆转事务相关的信息(例如，撤销信息)响应于提交事务被丢弃。

系统可包括被配置成存储与各个事务相对应的信息的至少一个持久数据存储，并且在这种示例中，系统可另外包括被配置成防止将对应于一个或多个未提交事务的数据写入至少一个持久数据存储的组件。

日志管理器组件还可被配置成在一个或多个日志记录中记录对至少一个数据存储中的数据进行操作的多个事务。此外，日志管理器组件可包括被配置成维护一个或多个日志流的日志流管理组件，这些日志流与各个日志记录相关联。日志管理器组件还可被配置成至少部分地通过合并日志流或拆分日志流来对日志流进行重组。

在一些实现中，日志流管理组件还被配置成以并行方式加载多个日志流。另外地或替换地，日志管理器组件还被配置成便于将与多个日志流相对应的各个数据库行以并行方式插入与至少一个数据存储相对应的索引。

日志管理器组件还可被配置成在对应日志记录中记录事务的开始时间和事务的结束时间。基于该日志记录结构，该系统还可包括恢复组件，该恢复组件被配置成至少部分地通过以基于如在其各个日志记录中所记录的事务的开始时间和结束时间所确定的次序施加经由各个日志记录所记录的事务来重建至少一个数据存储的操作状态。

系统可另外包括被配置成将日志管理组件的各个事务日志记录与至少一个不同的数据库系统的各个日志记录集成的恢复子系统集成组件。在这样做时，系统创建公共日志的外观，该公共日志包括日志管理组件的事务日志记录和至少一个不同的数据库系统的事务日志记录。

日志管理器组件可包括被配置成在无需参考至少一个数据存储中的各个物理位置的情况下生成指示至少一个相关联数据存储的状态的至少一个检查点的检查点操作组件。在一些实施例中，检查点操作组件被进一步配置成生成分别指示至少一个数据存储的各个指定部分的状态的经划分检查点集。替换地，检查点操作组件可被进一步配置成生成指示至少一个数据存储中的各个数据的状态的至少一个差分检查点，该检查点从前一检查点起已作了修改。在其他实现中，检查点操作组件被进一步配置成发起与经由日志管理器组件加载日志并行的检查点加载。

系统还可包括事务处理组件，该事务处理组件被配置成经由其中与事务相对应的恢复信息被持久地记录的物理提交、其中事务所引起的至少一个数据存储中的数据的变化对至少一个数据存储内的其他事务是可见的逻辑提交、以及其中使事务的结果对至少一个数据存储外部的实体可用的可见提交来提交事务。

在另一实施例中，一种用于维护数据库恢复系统的方法包括：接收与对至少一个存储器内数据存储中的数据进行操作的事务相关的信息；根据逻辑日志记录格式在一个或多个日志记录中将事务日志记录；响应于提交事务，丢弃与事务相关的逆转信息；以及防止将对应于一个或多个未提交事务的数据写入至少一个对应的持久数据存储。

在一些实现中，日志记录可包括在无需参考事务操作的数据存储中的数据的位置的情况下将事务日志记录。

该方法还可包括维护多个日志流，在此情况下日志记录可另外包括使用从多个日志流选择的日志流来将事务日志记录。在这种实现中，该维护包括将各个输入/输出设备分配给多个日志流中的各个日志流。

在其他实现中，该方法包括在无需参考至少一个存储器内数据存储中的各个物理位置的情况下生成与至少一个存储器内数据存储的状态相关的至少一个检查点。

在又一实施例中，一种用于维护数据库恢复系统的方法包括：标识局部日志流配置；接收与多个日志流上的至少一个数据存储相关的事务日志信息；以及通过合并多个日志流中的至少一个日志流或拆分多个日志流中的至少一个日志流之一来使多个日志流符合局部日志流配置。

在一些实现中，该方法可包括：标识事务日志信息内所记录的一系列事务；以及通过对至少一个局部数据存储执行一系列事务来重建与事务日志信息至少部分相关的至少一个数据存储的操作状态。

此处，以上已经呈现了用于实现数据库系统恢复的实施例中的某些的概览。作为接下来的内容的路标，更详细地描述数据库系统恢复的各示例性、非限制性实施例和特征。随后，为了附加说明，给出一些非限制性实现和示例，之后是其中可实现这些实施例和/或特征的代表性网络和计算环境。

数据库恢复子系统

关于恢复子系统设计，本文中所述的各个实施例在存储器内数据库系统的上下文中提供。然而，应当理解，本文中所提供的各个实施例不旨在限于任何特定数据库系统实现，除非以其他方式明确阐明。此外，除非以其他方式阐明，所附权利要求不旨在限于任何数据库系统实现。

另外，提供了其中一个或多个实施例写入盘存储和/或以其他方式管理盘存储的各个示例性实现。然而，应当理解，盘存储仅仅是持久存储的一个示例，该盘存储可被本文中的实施例使用，并且可以类似于如本文中所述的盘存储的方式使用任何合适类型的盘存储。因此，除非以其他方式明确阐明，在本文中使用的对盘存储和/或管理的引用被视为可与任何其他合适类型的持久存储互换。

作为关于可由数据库恢复子系统采用的日志设计的一个或多个非限制性方面的进一步描述，可实现与可在数据库系统内实现的示例性日志记录方案相关联的各个非限制性特性。作为第一示例，如本文中所述的日志记录方案在没有缓冲池或未将“废”数据(例如，与还未提交的事务相关联的数据)写入盘的情况下操作。结果，实现本文中所提供的实施例的数据库系统可被配置成从不加固撤销日志记录。例如，撤销日志记录可被用于存储器以允许事务回退(rollback)所作出的任何改变；然而，一旦提交了事务，如本文中所述的日志记录方案就丢弃存储器内撤销日志。相反，重做日志通过日志记录方案来加固，并且被用于恢复。在本文中提供了关于构建重做日志的其他细节。

由于废数据从未被写入盘，因此数据库系统不需要执行提前写入日志记录(Write Ahead Logging)以在废数据之前强迫对盘的日志改变。因此，可构建日志，其中I/O的最小单元是至少一个完整事务。此外，在一些数据库系统(例如，取决于硬件能力等)中，多个完整事务可被归组到单个I/O单元中。在本文中称为日志集合(LA，log arena)的这些成组I/O单元通过启用多个事务的成组提交来提供事务处理效率的较大提高和/或优于常规事务处理方案的其他改进。

尽管本文中所呈现的实施例将单个日志集合用于事务，但应当理解，恢复子系统不需要将整个事务写入单个日志集合。相反，在一些实现中，可跨多个日志集合拆分事务。

作为本文中所呈现的恢复子系统实施例的另一示例特性，日志记录方案可被配置成利用纯逻辑日志，其中物理信息未保存到日志。结果，恢复子系统可使用多个独立的日志流来加固其日志。在一些情况下，各个日志流可被配置成使用不同的I/O设备，这可用来便于日志的可伸缩性、弹性(例如，通过在I/O设备发生故障的情况下将日志写迁移到其他设备)、和/或其他益处。

作为附加说明，图1示出事务T1的示例性处理，该事务T1创建关于如根据本文中的各实施例所述的恢复子系统的记录R1。尽管图1示出在各个时刻发生的一系列事件，但应当理解，图1中所给出的时刻以及图1内事件的排序不旨在关于可根据本文中的实施例发生的事件的时刻或次序作出限制。此外，图1中所给出的时刻未按比例分配，并且与各个事件之间的时刻相关的比例不旨在经由图1暗示。

如图1所示，事务T1在开始事务事件100之后(例如，时刻t10)进入活动阶段。随后，事务T1可在事件110请求提交(例如，在时刻t20)，此时事务T1进入提交准备阶段以用于进行确认和/或在提交事务t1之前要执行的其他操作。随后，事务T1在完成提交准备阶段之后(例如，在时刻t30)进入日志写阶段，此后事务T1在事件115(例如，在时刻t40)提交。如图1中进一步所示，在事务T1创建记录R1的情况下，记录R1可在时刻T1提交被写入盘。此外，处理事务T1期间所创建的撤销信息在提交T1之后被丢弃。

转向图2，呈现了根据各实施例的示例性日志配置的布局和功能方面的说明性概览。图2示出两个日志流。上面的流包含两个日志集合：携带与事务1、3和4相关的信息的LA 1.1；以及携带与事务8和9相关的信息的LA 1.2。下面的流包含三个日志集合：携带与事务2和5相关的信息的LA 2.1；携带与事务6相关的信息的LA 2.2；以及携带与事务7和10相关的信息的LA 2.3。每个日志集合表示I/O的单个单元，如上所述。如图2进一步示出地，可通过I/O事件(例如，I/O事件200和202)来界定日志集合。

在HA配置中，日志集合可用作主节点和副节点两者上的I/O的基本单元。由此，在一个实施例中，在与主节点上使用的布局不同的布局中，镜像不拆分镜像上的日志集合。然而，可以理解，镜像节点可被配置有不同数量的日志流，并且在此情况下主节点上所聚集的日志集合以与镜像上可用的配置相一致的方式分布在镜像上。作为非限制性示例，在图2所示的示例中，配置有三个日志流的镜像可能将流配置成LA 1.1和LA 2.3使用第一日志流，LA 2.1使用第二日志流，并且LA 2.2使用第三日志流。

在一个实施例中，日志集合可以各种方式携带与各个相关联的事务相关的信息，每个事务进而可携带与各个相关联的记录相关的信息。可用于日志集合的示例结构由图3示出并且在此处描述。如图3所示，日志集合300可包含与一个或多个事务310相关的信息。与事务310相对应的信息进而可包含与关联于事务310的一个或多个记录320相关的信息。

作为具体、非限制性示例，现在更详细地描述可在日志集合300内利用的各个信息字段和结构及其组成部分。应当理解，以下所提供的结构只是可根据本文中的实施例来构造信息的一种方式，并且可利用适当信息的任何其他合适构造。

对于事务级信息，可用事务范围(transaction-wide)粒度保存包含在日志集合中的各个事务的各个字段。例如，开始时间戳字段和结束时间戳字段可用于标识系统中的事务。另外，当事务不是二阶段提交事务的一部分时，独立字段可被设置为“真”。如果该字段被设置为“真”，则事务日志可被视为连续的，并且可被包含在当前日志集合中(例如，没有提交记录，如以下所述)。否则，主事务标识符字段可标识对应主事务的事务标识符，并且主提交日志序列号(LSN)字段可标识主事务的进展。在一个实施例中，这可用作对拉锚(crossanchor)的一部分，该对拉锚使如根据本文中的实施例所构建的日志与不同的日志同步。

当独立字段被设置为假时，在一些情况下，还可在当前日志集合或稍后的日志集合中找到属于对应事务的提交记录。在一个实施例中，提交记录被异步添加以指示已经提交事务并且与其结果相关的信息可被主事务丢弃。

在另一示例中，日志集合可包括中止记录字段。当系统处于HA配置时，该字段可包括在发出“结束”时间戳(例如，确认中)之后已经被中止并且正在被日志记录的全部事务，以供恢复子系统成功地重建各个镜像节点上的提交谱系。

对于记录级信息，可以日志记录粒度保存各个字段。在一个实施例中，日志包含给定事务的一系列日志插入记录(LIR)和日志删除记录(LDR)。这些记录可被恢复子系统用于重新建立数据库系统的完整存储器内映像。LIR可与对应于创建了版本的事务的结束时间戳的“开始”字段(例如，如基于事务级信息已知的)和被设置为无穷大的“结束”字段相关联。类似地，LDR可与被设置为创建了版本的事务的结束时间戳的“开始”字段和被设置为删除了版本的事务的结束时间戳的“结束”字段(例如，如基于事务级信息已知的)相关联。在一个示例中，与各个LDR相对应的“结束”字段可与各个日志记录一起保存以便于对数据库系统的恢复。

鉴于上述内容，记录级信息可包括指示插入操作或删除操作的操作字段，该记录级信息进而指示随后的日志记录的类型。如果操作字段指示删除操作，则开始时间戳字段可用于存储创建了记录的事务的结束时间戳。在插入操作的情况下，该字段可能不存在。此外，表格标识符字段可包含表格标识符，该表格标识符可用于在表格对象中定位与记录相对应的行。除以上字段之外，有效载荷字段可包含行的实际数据。这可以是，例如，用于插入操作的行的实际内容。替换地，在删除操作的情况下，可存在保存更少信息时的情况(例如，在具有唯一键码的表格的情况下，在此情况下可只使用该键码)。

参考提交处理，关于恢复对提交的定义可依赖于给定事务特定的情形作出。如此处所使用的，术语“提交”与以下维度一起按分层结构分层，这些维度由图4另外示出。如图4所示，物理提交400形成提交分层结构中的最低层。如此处所使用的，物理提交400指的是在系统中加固恢复事务中所使用的所有信息的第一时间点。在一个实施例中，物理提交400充分利用物理提交中所使用的日志字段以及基本上保证恢复的I/O操作序列的全面描述。在本文中进一步详细地描述这些方面。

如图4中接下来所示，逻辑提交410形成提交分层结构中的中间层。如此处所使用的，在第一时间点处逻辑地提交事务，在该第一时间点处其存储器数据结构被标记为已提交并且其改变被施加到整个系统存储器。在一个实施例中，逻辑提交410负责将存储器内改变施加到恢复系统。

如图4另外所示，可见提交420形成提交分层结构中的上层。可见提交420指的是事务的结果对外部观察者可见的第一时间点。因此，可见提交420的实现落后于物理提交400和逻辑提交410的实现。

在一个实施例中，图4所示的分层结构可形成提交事务的全部或部分的序列。由此，在基于图4中的分层结构的一个非限制性示例中，直到已经物理地提交事务才可逻辑地提交事务。在类似的非限制性示例中，直到已经逻辑地提交了事务，事务才能是可见的。然而，应当理解，该提交序列仅仅旨在作为在数据库系统中可提交事务的示例，并且除非以其他方式明确阐明，此处的实施例不旨在限于任何特定提交过程。

以下更详细地描述了物理提交400、逻辑提交410和可见提交420的操作，如图4所使用的。如上关于图4所示的提交分层结构所阐明的，以下描述是示例性的和非限制性的，并且可以理解，可使用用于提交事务的任何合适的技术。

首先参考物理提交，以下概述了针对可包括数据库事务的各个情形的物理提交的含义。作为第一示例，当没有依赖性的、与实现本文中的各实施例的数据库系统完全相关联的事务完成客户机代码处理时，可发生包括一阶段提交、单个系统实例和无传出依赖性的情形。事务可在完成客户机代码处理之后进入确认。在成功的确认之后，日志区段可被指派并填充在单个场所内部。区段随后被标记为独立的并且被加固。在此情形中，当日志I/O成功地完成时，认为事务被物理地提交。

在一个实施例中，在已经成功地加固日志时的时间点处非二阶段提交事务的事务一般可认为被物理地提交。此外，在上述特定情况下，物理、逻辑和可见提交实质上与日志I/O的完成一致。

如果日志I/O写操作失败，则对应的数据库被标记为离线并且发生恢复。在一些情况下，这可触发HA设置中的故障转移(failover)，该故障转移随后被传递到主事务实例，以供主数据库本身跟进(例如，变成离线的)。可以理解，在集成数据库的情况下，以此方式进行恢复的失败可通过在一个系统中失败而在另一个系统中未失败来破坏单一系统映像幻像。在另一示例中，使用如此处所述的并行日志配置可使失败的I/O能重复尝试另一可用日志流，并且通过只使失败的日志流离线来继续运行。

在外部相关联的数据库的日志失败时，可使用类似的通知机制。在此情况下，数据库可与外部相关联的数据库一起离线，不管是否有因混合系统事务产生的失败。

作为另一示例，可发生具有一阶段提交、单个系统实例和传出依赖性的情形，其中例如事务T1对另一事务T2具有提交依赖性。在此情况下，T1可与T2并行地构建并提交其日志。如果日志I/O两者都成功地完成，则物理地提交T2。响应于提交T2，可去除T1对T2的依赖性并且可激活T1。在没有其他依赖性的情况下，T1随后变成立即物理提交并且前进到将其本身标记为之后在短时间内逻辑地提交。

替换地，如果T2的日志I/O失败，则T2从未被认为已提交并且数据库进入如在以上情形中所述的恢复。

在另一替换方案中，T1的日志I/O可失败，而T2的日志I/O(先前的、落后的、或并行的)可成功。在此情况下，可以理解，因为在恢复时T1的事务日志将是不可用的，所以T2仍然从未被认为已物理地提交；因此，在到达(完全一致的，但现在是孤立的)T2日志之前日志重放将停止。

当正在提交的事务是与外部关联数据库的主事务相关联的从事务时，可发生包括二阶段提交和单个系统实例的又一情形。在此情况下，事务接收来自主事务的“准备”请求，在此期间其以类似于以上情况的方式加固其日志。然而，与以上情形相反，与该事务相关联的日志区段被标记有假的独立字段，以指示在确定是否已经提交事务之前要对恢复进行附加协调。另外，可用主事务标识符的值将如上所述的主事务标识符字段填充到日志中。在一个实施例中，系统发出如先前情况中的加固请求，但从成功的I/O返回时，事务未转换到提交状态。相反，事务保持在确认阶段中，等待来自主事务的“提交”通知。

当主事务提交时，与主事务相关联的外部系统通知依赖事务整个提交已经成功。在接收到此信息之后，向其中已经发出提交的相同日志流发出提交记录I/O。可以理解，提交日志记录可能包含在或可能未被包含在相同日志集合中，作为通用日志记录。一旦已经发出I/O(或在发出它之前)，事务被标记为正在提交并且通过后处理和无用信息收集。

在刚刚描述的情形中，可以理解，事务可能在提交日志记录将其写入盘之前要逻辑地(并可见地)提交。这无法推断出，物理提交在逻辑提交之后，因为在“提交”调用由主事务发出之前，外部相关联系统处的日志已经包含经加固提交日志记录，该经加固提交日志记录标记用于该事务的物理提交处理的有效结束。

在恢复时，当在已经找到具有假独立字段的对应先前日志区段的日志流中找到提交日志记录时，或当所恢复主事务可被确定为已经成功地提交时，二阶段提交中所包括的事务被认为先前已物理地提交。

在事务之间有数据依赖性(例如，T1#2PC-＞T2)的情况下，可以理解，直到T1依赖的事务(例如，T2)完成其确认和其提交处理，才能如在以上主要情形中那样完成与T1的“准备”请求相关联的工作。因此，可以完成T2之后发生T1的激活的方式引入改变。通常，可以理解，提交依赖性使用提交事务的线程来模仿等待事务。然而，在此情况下，存在需要同步的两个不同的线程：T2的提交线程和主事务的“准备”线程。

在一个实施例中，一旦“准备”线程被解除阻塞，就可以类似于以上通常情况的方式来处理此情形。然而，可以理解，在一些情况下，包括已经采用提交依赖性的只读事务的事务可因其提交依赖性事务未实现其自己的确认的事实而失败。另外，在“准备”线程因日志I/O失败以外的原因失败的情况下，可对与“准备”线程相关联的系统作出一个或多个改变以正确地报告这种出现和/或对这种出现作出反应。例如，在先前情形中，系统可被配置成制止假定日志写失败并使数据库离线，并且相反回退并报告正确的差错。

在替换情形中，事务可涉及向外部数据库服务器的二阶段提交，但数据库服务器的主事务是只读的。在此情况下，足够的信息可被保存在本地事务日志和外部数据库服务器的事务日志两者中，以使当在别处重放事务时，本地事务在外部事务之前不可见。在外部服务器的事务是读-写的情况下，可以理解，在一些情况下，由于在恢复期间事务标识符可被保存(例如，在本地日志记录中的主事务标识符字段中)并且是可见的，因此上述内容不是问题。为了适应此情形，本地事务在与只读外部事务配对时将当前外部LSN保存到主提交LSN字段。在恢复期间，该字段可用于等待本地系统状态匹配外部系统的状态。类似地，外部系统的日志可被配置成保存本地事务的当前串行化时间戳，从而有效地实现对拉日志锚。

在包括具有一阶段提交的HA副节点的实施例中，将日志流场所从主节点连续地运送到副节点。可以理解，通信传输将场所片断(例如，没有排序保证)传送到副节点，并且该完整的场所变成是只递增可用的。此外，可以理解，场所信息的传输与对主节点的物理提交处理并行地发生，该物理提交处理如以上对应的单个系统情形中所述地进行。

在此情形中，当在被包括在同步镜像中的节点中的任一个上加固第一日志集合时实现物理提交。在一个实施例中，向副节点的即时故障转移被配置成跟随主节点上的日志写失败，从而使以上所述的“对第一加固的提交”规则变成逻辑上正确的。

在包括事务的HA副节点的另一实施例中，这些事务被包括在主节点上的二阶段提交中，可以理解，副节点在未确保首先加固对应场所的主系统的日志的情况下无法加固日志集合。这可被完成以例如防止其中接收并加固包含事务准备数据和提交日志记录两者的日志集合、但对应的主事务日志在传输中丢失且从未到达的情形。如果在此情形中加固所接收日志集合，则可以理解，对镜像节点的故障转移将找到指示未(并且曾经无法)发现完整提交的事务而非对应的主事务日志的日志集合。

为了防止以上情形，本地日志集合可包含描述场所中的所有事务的主事务标识符的区段(例如，主事务标识符字段，如以上一般描述的)，并且场所I/O可跟随对具有主事务标识符集中的标识符的所有主事务的加固。

接下来参考逻辑提交，此处描述了各种情形，这些情形用关于将经加固日志记录应用于存储器内系统映像的信息扩充对如上所提供的物理提交的描述，以在恢复时获得功能系统或在HA部署期间获得可用镜像。

首先参考包括一阶段提交、单个系统实例和未传出的依赖性的情形，一旦日志I/O成功地完成，就可进行逻辑提交。在完成日志I/O之后，事务可被标记为已提交，并且可基本上即时地执行其余的后处理和无用信息收集。

可发生包括一阶段提交、单个系统实例和传出的依赖性的情形，其中事务被给予结束时间戳(例如，指示提交序列)、进行确认、发出其日志I/O，并且随后在被标记为已提交之前延缓其传出依赖性的待决完成。尽管处于该状态中，可以理解，事务仍然是未确定的，例如如果事务依赖于失败，则该事务也将失败。一旦先前I/O成功地完成，该事务本身就将成功。

在包括二阶段提交和单个系统实例的情形中，要求事务在主事务调用“准备”期间加固其日志。对应的日志记录可包含假的独立标记，从而指示还不知道要提交与事务相关联的数据。在成功地完成I/O时，事务保留不确定状态，直到主事务发出将事务的状态从“不确定”改变到“已提交”的“提交”调用(并且稍后调度提交日志记录)。

在包含HA副节点和一阶段提交的情形中，镜像可被配置成维护以其提交(例如，结束)时间戳的次序排序的事务的串行化次序。该事务对象集在本文中称为串行化事务时间线(STT)。为了构建STT，可在副节点上获得主节点上所发出的所有结束时间戳的完整历史。此外，一旦事务已经进入提交处理就可将相继标识符分配给所有“结束”事务时间戳的方案用于此情形。

在一个实施例中，副节点上的STT可被分成两个区段：较旧事务的压缩区段，其中所有事务时间戳是相继的，所有事务被提交并且在事务序列号之间没有间隙；以及具有丢失(或仍然开放)事务的空洞的稀疏区。

给定如上所述指派“结束”时间戳的方式，副节点上的压缩事务历史可被标识为其中所有可能时间戳(例如，相继的64位整数)的全部事务存在并且被提交的历史。在一个示例中，这可通过将日志记录配置成使主节点上的、在确认(例如，意味着其已经发出“结束”时间戳)期间已经中止的事务还被包括在日志流中(例如，经由中止记录)，从而使其可用于副节点来实现。

副节点所接收的每个日志集合片断可对应于STT中的一个或多个事务槽。逻辑提交操作可将来自相邻场所片断的片断缝合在一起，在一些情况下逻辑提交操作可横跨行日志记录，并且随后在适当时将新接收的记录应用于其存储器内容器(例如，散列集或跳过列表)。

然而，可以理解，存在新接收的记录无法被即时应用于其各个容器的情况。这可在例如当从相同记录的先前版本无序地得到记录并且记录的先前版本尚未经由STT处理时发生。当发生该情况时，还不能应用的行日志记录被追加到其(仍然开放的)对应事务，并且实际插入/删除操作被延迟，直到所应用事务的高水位标记达到当前事务。换言之，插入/删除操作被延迟，直到具有较旧提交时间戳的事务已经被完全应用并提交并且当前事务位于所应用事务的压缩列表的顶部。响应于该发生，可基本上即时地应用仍然与事务一起待决的延迟工作项(例如，行日志记录)。由于压缩事务历史在当前事务之前，因此可以理解，可保证应用了仍然待决的当前事务的工作项在相关时间点成功。

还应当理解，尽管STT是全局共享的数据结构，但因STT可展示较大程度的并行化的事实如上所述的方案不可能引入并发限制。另外，可以理解，由于与从各个场所读取行和将其施加到其各个容器中相关联的大多数工作可并行地进行，因此延迟工作项将不会引起实质性延迟。例如，读取日志记录、基于日志记录生成新的行和计算新的行的位置各自可并行地实现。因此，STT可被视为用于在恢复时组织事务日志的并行应用的大流水线。

在包括HA副节点和二阶段提交的情形中，STT可以类似于如上所述的单个阶段提交情况的方式起作用。然而，应当理解，在二阶段提交情况下在STT中提交事务依赖于完全地应用源于对应日志集合的日志记录。此外，在一些情况下，这种事务会需要通过相应地应用使用经协调日志锚的主事务日志来门选，该经协调日志锚被保存在主事务标识符和主提交LSN字段中。

进一步参考可见提交，以下描述了可应用于已经完成逻辑提交的事务的各个可见性规则，如以上所一般描述的。在一个实施例中，这些规则可在考虑可读副节点所需要的可见性和恢复序列期间的时间点的情况下设计，在该时间点处数据对等待的客户机是可见的。在包括一阶段提交、单个系统实例和未传出的依赖性的第一情形中，事务可通过在事务已经被标记为逻辑提交之后的确认来进行可见地提交。

在包括一阶段提交、单个系统实例和传出的依赖性的另一情形中，可以类似于先前情形的方式进行可见提交。此外，可从用于达到逻辑提交状态的依赖性的实施导出此情形中的系统行为。例如，当事务T1依赖于事务T2(例如，T1-＞T2)时，T1的提交处理可被延迟，直到T2的结果为已知。在一个实施例中，提供回用户的确认(ACK)消息可被类似地排序，如果这种排序对客户机ACK处理有用。替换地，所使用的排序对客户机正确性标准可以是次要的。

在另一实施例中，在多个存储过程上实现的事务(此处被称为多步骤事务(MST))的情况下可发生附加处理。对以上示例进行扩展，在一些情况下，T1可以是采用对T2(例如，通过读取T2所创建的行)的提交依赖性的MST。称为，尽管T2仍然不确定，但T1可能需要返回给用户，作为其多步骤处理的一部分。因此，可以理解，在该上下文中，T1可将尚未保证已提交的数据项展现给终端用户。尽管该出现未创建正确性问题(由于如果T2失败则T1可能失败)，但其可呈现信息公开的元素。在一个实施例中，这可通过在T1返回给用户作为其多步骤处理的一部分之前使T1在“提交障碍”之后能够串行化来缓解，该“提交障碍”允许对应于T1的通知只在已经提交其全部依赖事务时进行。

在包括二阶段提交和单个系统实例的又一情形中，一旦来自主事务的“提交”调用由事务接收，就可发出用户ACK。此外，在单个系统崩溃恢复期间，系统可被配置成直到恢复完成才允许新的事务。通过这样做，可见提交可被延迟，直到恢复结束。在一个示例中，二阶段提交恢复可被配置成创建STT并且当各个事务从各个日志流读取时应用这些事务。在另一示例中，当已经接收到日志集合、先前事务和主事务提交日志记录的全部时事务关闭。

可以理解，在此情况下，在没有并发读者的情况(例如，如恢复中的情况)下，由于没有可见信息的读者，“可见提交”的发出可能是不太重要的。结果，在一些情况下，在恢复期间可通过简化版本处理来简化提交处理。在一个实施例中，这可至少部分地通过明确地实现本地提交和恢复来实现，其模拟事务的常规处理、但通过使用STT而非常规用户代码驱动数据修改来这样做。

在崩溃恢复的相反情况下，在没有参与读者的情况下，旧版本数据的无用信息收集可与应用相同数据的新版本基本上并发地执行。通过这样做，事务可被处理成没有无用信息留下。这还可通过去除确认处理、无用信息收集处理和后处理的需要来简化事务处理，并且在一些情况下可向崩溃恢复提供显著的速度加快。

如以上情况下所述，此情形中的STT可被配置成保留对主事务恢复处理的依赖性。然而，应当理解，即使在没有读者的情况下，也可存在继续应用来自其各个日志集合的事务的完整STT返回(STT-backed)重放的原因。例如，依赖于所使用的检查点操作方案，在一些情况下，经由无用信息收集将日志完全应用于收集并将事务发送到收集可以是获得副节点上的检查点而对主节点没有任何要求(例如，运送检查点页面等)的一种有效机制。

在包括HA副节点和一阶段提交的情形中，相关联的数据库系统可采用可见提交的方案，该方案类似于基于盘的数据库系统的方案。例如，一旦事务的确认返回到用户，第二通信就可用于向次要实例指示将先前提交的数据“显示”给可读副节点上的任何读者是安全的。可通过维护“可见性高的水位标记”来实现此可见性的延迟，该“可见性高的水位标记”是已经向用户确认并且因此可安全地显示给副节点上的读者的最后一个提交时间戳。在一个示例中，副节点上的读者可用作为其时间戳的此可见性水位标记来发起只读事务，以避免看见任一个已经施加的稍后改变(例如，已经被逻辑提交但还未可见提交的改变)。

在包括HA副节点和二阶段提交的另一情形中，可以理解，可以类似于以上各个其他情形中所述的方式来进行提交处理。此外，在此情形中，外部关联数据库可将进展报告ACK通知从主节点提供到副节点。作为响应，系统可使用如上所述的主事务标识符字段来与外部相关联的数据库同步可见性。

图5是示出数据库系统510的示例性实现的框图。如图5所示，数据库系统510可与一个或多个数据存储500和/或一个或多个镜像数据存储502相关联。在一个实施例中，数据存储500与主数据库节点相关联，而镜像数据存储502与一个或多个副节点相关联；然而，应当理解，可使用数据存储500和镜像数据存储502的任何合适配置。在一个示例中，数据存储500和/或镜像数据存储502可以是存储器内数据存储、盘数据存储、或其任何合适的组合。在一个实施例中，使用存储器内存储和盘存储的组合，由此存储器内数据存储用作主数据存储，其中数据库系统510维护数据项并且处理对数据项进行操作的事务。在各个有规律的间隔或可变的间隔处，与存储器内数据存储相关联的数据随后可被写入盘。以此方式，可独立于数据被排列在盘上的方式来组织存储器内的数据，由此提供经改进的灵活性和设计的简化、以及其他益处。

数据库系统510可包括事务处理组件520，事务处理组件520可便于根据图4所示和以上一般描述的提交分层结构来提交事务。此外，数据库系统510包括被配置成维护逻辑事务日志的日志管理器组件530，如根据此处的实施例所述的。如此处所述地，日志管理器组件530可被配置成通过每个事务或事务组(例如，日志集合)使用单一日志记录来将各个事务日志记录。此外，由于日志管理器组件530被配置成用于逻辑日志记录，因此记录由日志管理器组件530构建，而无需参考与记录相关联的数据的物理位置和/或任何其他物理位置信息。

日志管理器组件530包括日志流管理组件540，日志流管理组件540可被配置成便于经由多个日志流将数据库事务日志记录。如上所述，日志流可被分配给各个I/O设备和/或用于维护日志流的其他合适机制。在一个实施例中，日志流管理组件540可维护独立日志流集并且在需要时修改这些日志流。图6示出日志流修改的简化概览，其中日志流管理组件610将事务集600中的各个事务分配给一个或多个日志流640。如图6所示，日志流管理组件610可通过例如经由流合并组件620合并日志流640、或例如经由流拆分组件630拆分日志流640来至少部分地修改日志流640。

在一个实施例中，对如图6一般示出的日志流的管理可进一步用于使数据库镜像(例如，在副节点处等)能修改日志流以与镜像的本地I/O配置相符合。例如，如图7所示，系统日志流集700可被传递到数据库镜像710，数据库镜像710可使用日志流管理组件720或其他合适的机制来修改系统日志流集700中的各个日志流。这些修改可导致例如镜像日志流集702，镜像日志流集702符合数据库镜像710的I/O设备配置。尽管图7提供了压缩日志流的数据库镜像710的说明性示例，但应当理解，数据库镜像710可使用日志流管理组件720和/或任何其他合适的机制来以任何合适的方式管理各个相关联的日志流。这些修改可包括，但不限于，合并日志流、拆分日志流、创建或删除日志流、修改包含在日志流内的一个或多个记录、或任何其他合适的操作。

返回到图5，日志流管理组件540可便于改变恢复并行化的级别，如此处所一般描述的。例如，日志流管理组件540可被配置成通过例如以并行方式加载和/或以其他方式处理多个日志流来实现日志流预处理/处理并行化。在另一示例中，日志管理器组件530可与日志流管理组件540和/或数据库系统510的其他组件协作，以通过例如便于以并行方式将对应于多个日志流的各个数据库行插入对应于数据存储500和/或502的索引来实现索引插入并行化。

在另一实施例中，日志管理器组件530还包括检查点操作组件550，检查点操作组件550可被配置成维护数据库系统510的检查点信息。不同于使用物理检查点文件的常规数据库系统，检查点操作组件550可便于使用逻辑检查点，而例如无需参考数据存储500或502内的各个位置。在一个实施例中，检查点操作组件550所创建的检查点可以是至少部分地为日志管理器组件530所生成的日志信息所固有。例如，与如常规物理检查点集中所提供的序列信息相反，检查点操作组件550可充分利用事务日志记录内所提供的时间戳，从而允许通过以其各个时间戳隐含的次序重复各个日志记录的事务来恢复数据存储500或502。在另一实施例中，检查点操作组件550可充分利用数据库系统510的多版本化功能以与数据库系统510内的其他操作并行地生成与数据库系统510相关的检查点信息。因此，可实现优于常规系统的增加效率，其中数据必须在检查点操作之前被锁定以防止非预期行为。此处更详细地提供可由本文中的实施例执行的检查点操作功能的各方面。

在一个实施例中，检查点操作组件550可与日志管理器组件530协作，从而通过发起例如与日志管理器组件530处的日志加载并行的检查点加载来实现检查点加载并行化。此处更详细地提供可实现日志流预处理/处理并行化、索引插入并行化、检查点加载并行化和/或恢复系统并行化的其他合适方面的各个示例。

在数据库崩溃、储存设备故障的情况和/或期望恢复与数据库系统510相关联的部分或全部数据的任何其他合适的情况下，恢复组件560可被数据库系统510用来恢复数据库系统510和/或一个或多个数据存储500或502的状态。在一个实施例中，可通过以各个事务的时间戳所给出的次序重放日志管理器组件530所生成的事务日志中所记录的事务来实现对与数据库系统510相关联的数据的恢复。在一个示例中，可在检查点操作组件550的辅助下或独立于检查点操作组件550来执行以此方式的恢复。

数据库系统510还可包括盘管理组件570，盘管理组件570被配置成管理与数据库系统510相关联的一个或多个盘数据存储。作为其中数据库系统510是存储器内数据库系统的非限制性示例，盘管理组件570可响应于对存储器内的数据项所执行的对应操作来管理对盘上的数据项的插入、删除和/或修改。

在其中数据库系统510是存储器内数据库系统的另一实施例中，盘管理组件570可被配置成避免将废数据(例如，对应于尚未提交事务的数据)写入盘。例如，由于常规盘上数据库系统未被设计成在存储器内操作，因此在一些情况下，在没有足够的存储器可用于系统以供完全处理对应于数据项的事务的情况下，这些系统可能需要将废数据的一个或多个项写入盘。相反，响应于经由提交数据项的对应事务来确认数据项，盘管理组件570可充分利用数据库系统的存储器内性质将数据项写入盘。

另外，在一些情况下，数据库系统510可充分利用存储器内工作环境来制止执行提前写入日志记录，如以上一般描述的。由此，与被配置成在提交之前将事务信息日志记录的一些常规数据库系统相反，数据库系统510(例如，通过盘管理组件570)可限制事务的日志记录，直到已经了提交事务。结果，数据库系统510可另外操作，而无需依赖于各个事务的撤销日志。由此，响应于提交事务，可丢弃撤销信息和/或与逆转事务相关的其他信息。

在另一实施例中，如此处所述的日志记录和恢复技术可用来便于数据库系统集成。图8示出根据此处所呈现的实施例的、可执行的数据库系统集成的简化说明性概览。如图8所示，数据库环境800可包括多个数据库系统，诸如存储器内数据库系统810和盘上数据库系统830。存储器内数据库系统810和盘上数据库系统830可分别包括各自的恢复子系统820和840，恢复子系统820和840进而可结合日志记录组件822和842来记录各个对应的系统内所执行的操作。在一个特定、非限制性示例中，存储器内数据库系统810可根据此处的各个实施例执行日志记录和恢复，并且盘上数据库系统830可对应于存储器内数据库系统810与其交互的主数据库实例。尽管图8示出数据库环境800，存储器内数据库系统810和盘上数据库系统830作为单个框，应当理解，这些实体的功能可分布在任何合适数量的计算设备或其他设备之间，这些设备各自可经由任何合适的有线或无线通信手段和/或任何其他机制来通信地耦合。

如图8另外示出地，在数据库环境800内实现恢复子系统集成组件850。在一个实施例中，恢复子系统集成组件850被配置成集成日志记录组件822和842所生成的各个系统日志，并且集成这些日志以将单一、公共日志860的外观呈现给数据库环境800的用户。在一个示例中，恢复子系统集成组件850可被配置成组合与存储器内数据库系统810和盘上数据库系统830相关联的日志，从而两个系统都使用公共日志860。替换地，恢复子系统集成组件850可被配置成管理与存储器内数据库系统810和盘上数据库系统830相关联的日志并且便于其间的通信，基于此可维护公共日志860，作为表面上组合各个系统日志以供数据库环境800的加速用户管理的结构。在一个实施例中，通过以一种或多种上述方式提供日志集成，恢复子系统集成组件850可独立于一个或多个其他组件或结合一个或多个其他组件起作用，从而允许在数据库环境800内操作的各个数据库系统在终端用户看来作为单一数据库操作。

在一个实施例中，存储器内数据库系统810和盘上数据库系统830可经由恢复子系统集成组件850和/或其他合适的机制来协作，以优化数据库环境800中所使用的二阶段提交过程。在一个示例中，数据库环境800使盘上数据库系统830的客户或其他用户能将一些其表格和/或工作负荷移交至存储器内数据库系统810，以获得对整体系统行为的改进而无需对其代码作出显著改变。由此，为了实现此目的，在与存储器内数据库系统810一起使用时，对盘上数据库系统830的二阶段提交的成本可降低。

在概念上，可以理解，二阶段提交的成本从以下事实导出：“准备”阶段需要来自每个参与者的至少一个I/O，并且“提交”阶段需要来自主参与者的一个I/O(以及来自其他参与者的延迟活动)。由此，具有两个参与者(例如，盘上数据库系统830作为主参与者而存储器内数据库系统810作为次参与者)的简单实现招致3个I/O，而非盘上数据库系统830单独所招致的1个I/O。结果，在一些情况下，通过移动其数据的子集并且对存储器内数据库系统810进行处理，用户可看到性能的降级。因此，可使用使混合容器事务所招致的惩罚最小化的一个或多个方案。

为了达到以上目标，数据库环境800可允许关于存储器内数据库系统800上的事务的数据驻留在多个日志流中。然而，应当理解，除添加对各个日志集合中所包含的事务片断的排序以外，该修改将对此处所述的其他实施例没有影响。

在跨集合拆分事务是可能的情况下，当混合事务在系统之间转换时或当多步骤事务返回给用户时，部分事务日志可被发送到日志管理器。这些动作实质上等价于为处于“几乎准备好的”状态中的存储器内数据库系统810上的事务保留相当部分时间。因此，当对主事务的“准备”调用到达时，日志的存储器内部分已经被持久保持并且在存储器内数据库系统810处无需采用动作是可能的。由此，如果盘上数据库系统830另外决定首先“准备”存储器内数据库引擎并且随后准备主事务，则其可随后将“准备”调用和“添加”调用绑定到单一I/O事务中，由此达到类似于盘上数据库系统830处的单阶段提交情况的性能级别。

图9是示出用于管理存储器内数据库系统中的恢复子系统的示例性、非限制性过程的流程图。在900，标识对一个或多个存储器内数据存储中的数据进行操作的事务。在910，提交事务；响应于此，在920，在一个或多个逻辑日志记录中将事务日志记录。在一个非限制性示例中，在920，对事务的日志记录可包括将事务所修改的记录的所有新版本写入盘。在930，丢弃与事务相关的撤销信息。随后，在940，作出对关于是否已经发生数据库恢复是合乎需要的事件的确定。如果未发生这种事件，则数据库系统继续其正常操作。否则，在950，至少部分地通过遍历各个日志记录的事务(例如，如在930日志记录的)来执行对数据库系统的恢复。

图10是示出用于维护关于数据库事务的数据库恢复信息的示例性、非限制性过程的流程图。在1000，接收与对至少一个存储器内数据存储中的数据进行操作的事务相关的信息。在1010，根据逻辑日志记录格式将事务日志记录到一个或多个日志记录中。在1020，响应于提交事务，丢弃与事务相关的逆转信息。在1030，防止将对应于一个或多个未提交事务的数据写入(例如，废写入)至少一个对应的盘上数据存储。

图11是示出用于在副节点处维护数据库系统的示例性、非限制性过程的流程图。在1100，标识本地日志流配置(例如，副节点所使用的日志I/O配置等)。在1110，经由多个日志流接收与至少一个数据存储相关的事务日志信息。在1120，副节点通过合并和/或拆分多个日志流中的至少一个日志流来使多个日志流符合本地日志流配置。

非限制性示例检查点管理过程

以上已经描述了数据库恢复机制的各个实施例。在以下描述中，提供了可用于创建并维护检查点、可用于检查点(例如，经由检查点操作组件550，如图5所示)、崩溃恢复和备份的各种技术，如此处所述。与以上实现特定细节一样，以下描述不应当作为对更一般概念和在别处所述的实施例的限制，并且仅仅出于说明性目的包括在内。

在一个实施例中，可通过例如在预定间隔将一个大I/O中的数据库的全部内容保存在单一文件中来生成简单完整的检查点。可以理解，以此方式进行的检查点操作提供了易于实现和事务的一致性，以及其他益处。作为非限制性示例，该检查点方案可收集并保存被以下伪脚本隔离的数据。

对于小数据库，快照隔离方案使查询(诸如以上所示的查询)容易实现并且在运行时资源中相对便宜。查询的结果是包含整个数据库的单一文件。当数据库生长时，可通过划分数据查询来扩展该方法，如下所述。

例如，简单划分的完整检查点方案可被实现为对以上简单检查点的细化。代替使用一个事务来扫描整个数据库，经划分检查点过程使用多个更小的事务，这些更小的事务各自只隔离并加固检查点集的子集。可在逐表格的基础上进行划分；替换地，检查点过程可使用物理划分方案(例如，散列表元的计数)来获得将行更平均地分发给检查点操作事务。

通过允许跨多个核并行化检查点生成过程，划分可有助于检查点操作。另外，跨多个事务拆分检查点避免生成具有系统范围影响的长期运行的事务。作为非限制性示例，可如以下伪脚本所示进行划分的检查点操作。

然而，应当注意，除非事务共享相同的“开始”时间戳，否则检查点映像不可能事务性地一致。换言之，与第一简单检查点映像不同，通过以上过程所获得的映像可能需要来自叠盖检查点的日志记录的帮助以在恢复时产生完全一致的数据库。因此，可以理解，该方案以并行化和存储器使用率换取恢复事件和代码复杂性。

作为另一替换方案，可使用只向前(forward-only)的差分检查点。与简单的和经划分的检查点操作方案不同，差分检查点操作算法无法产生存储器内数据库的完整映像。相反，差分检查点操作使用自最后一个检查点起被保存在系统中的信息来隔离自最后一个检查点起已修改的数据的“岛”。

通过只保存已经改变的数据，可以理解，差分检查点提供了显著节约中央处理单元(CPU)成本以及与检查点相关联的I/O成本的可能性。此外，如以下进一步描述的，数据库系统内所提供的现有数据的相当部分可被用于跟踪检查点之间的改变。由此，差分检查点提供了上述益处和与恢复和存储器使用率相关联的成本之间的折衷。

作为以下所述的差分检查点维护技术的附加背景，以下描述了数据库无用信息收集的各方面。在一个示例中，数据库系统可使用快照隔离作为所有其他隔离级的基础。结果，实现负责清理旧版本的无用信息收集组件。因此，这种系统中的无用信息收集作为系统中的所有数据修改的全局交换所。具体而言，无用信息收集组件可在实质粒度基础上(例如，用表元粒度)跟踪与各个索引相关联的“无用信息”的量。在一个示例中，经由无用信息收集表元信息结构来实现该目的。

响应于无用信息收集器观察到的已提交事务中的被删除行(或所中止事务中的插入行)，创建无用信息收集表元信息结构。无用信息收集表元信息对特定表元上的无用信息的量计数。一旦建立，该计数由无用信息收集器组件和遇到无用信息并在常规扫描过程中将其清理的任何常规线程两者维护。在一个示例中，这形成了协作式无用信息收集器的基础。

在一个示例中，差分检查点操作可扩展无用信息收集表元信息结构，以使其不仅跟踪表元中的无用信息行的数量而且包含“检查点废旧”标志，该“检查点废旧”标志指示给定无用信息收集表元信息结构所跟踪的表元应当包括在下一个差分检查点中。作为非限制性示例，以下提供了可用于以上述方式生成检查点映像的伪脚本。

在另一示例中，可划分以上脚本，并且以类似于以上所述的简单划分的检查点方案的方式并行化工作负荷。

在以上方法中，每个差分检查点被存储在单独的文件中，并且差分检查点方案依赖于过去某时存在完整检查点。该过程的折衷在于，因为从未“在适当位置(in place)”更新数据，所以在创建新差分检查点文件的情况下原始的完整检查点可“衰减”。具体而言，新差分检查点文件实际上可自原始检查点文件渐进地重写更多的区段，从而加速其降级。

在一个实施例中，数据库引擎可在恢复时查明哪些检查点文件(例如，完整的和差分的)的哪些区段要被扫描并且加载到存储器中。为了加速该过程，可创建“主检查点索引”，该“主检查点索引”包括指向可能跨多个文件的其各自位置中的最近检查点片断的指针。作为非限制性示例，索引可被结构化为包含区段的Brree，这些区段在串接起来时形成完整检查点。图12示出了该布局。

如图12所示，原始检查点1200包含8个记录，并且之后的每个差分检查点1202、1204和1206修改(并且保存)8个记录中的各个记录。在没有检查点范围索引1210的情况下，最终检查点的内容可能难以从组件部分重新创建。例如，由于在第三检查点1206中重新创建第一检查点1202的全部内容，因此读取第一检查点1202仅仅导致错过时间。

作为以上差分检查点过程的替换方案，“在适当的位置更新”检查点文件的策略可用于代替主检查点索引。在一个实施例中，可使用“在适当的位置更新”加固策略，其中所保存粒度的单位是多个表元构成的集。图13参考存储器内行表示1300以及两个检查点1310和1320示出该过程。在一个示例中，相邻表元的该集群可有效地形成“逻辑页面”，在一些情况下该“逻辑页面”可改进对应盘上文件中的空间管理(例如，由于满足和/或返回来自相同逻辑页面上可用的“宽松空间”的添加和/或去除的能力)。

在少量更新到达多个页面的情况下，可触发对部分或全部受影响页面的写。在数据被组织为散列的情形中，这可导致创建用于差分检查点请求的相当部分的“几乎完整的”检查点。替换地，如果持久保持的数据在经排序索引(诸如跳跃列表)而非散列索引中组织，则在一些情况下导致随机页面的写的改变可根据其密钥邻近性来群集。

作为另一示例性检查点操作方案，可使用虚拟存储器(VM)仿形检查点设计。这种设计可用于例如展示存储器管理和检查点操作方案之间紧密集成的系统。在一个示例中，考虑行数据来自递增指派器型存储器对象的情形。在数据库系统使用版本化的情况下，该指派类型可与已就位的引擎的各方面紧密地对齐。

在一个实施例中，由于在这种检查点操作方案中检查点简单地指定从前一检查点起已指派的页面的事实，VM仿形检查点操作可由递增指派器辅助。图14参考前一检查点1400之后发生的差分检查点1410示出该概念。

进一步关于此处所提供的数据库恢复技术，恢复处理的结构可如下地实现。从纯等待时间的角度，可以理解，当与非基于存储器的系统相比时，基于存储器的系统的恢复处于劣势。这是因为，在基于存储器的系统中直到数据库的全部内容在存储器中才恢复数据库，而传统数据库被认为在重做和撤销之后恢复，在其结束时只有少量数据页面需要已加载到缓冲池中。鉴于上述内容，可在存储器中系统中实现用以在可能的程度上实现恢复级并行化的机制。

如此处所述地，存储器中数据库恢复系统可支持多个日志流，这是恢复系统所使用的逻辑日志格式的结果。因此，这种系统中用于恢复的方案可遵循以下示例性序列。

(1)扫描日志以供分析，并且找到最后一个检查点的位置。

(2)重新加载检查点(从一个或多个文件)。

(3)运行重做阶段，这重新扫描多个日志流的相关尾部。

(4)将日志流尾部合并成单一顺序的、“统一的”日志历史。

(5)将在该统一的日志历史中找到的日志纪录应用于先前加载的检查点映像。

在其他实施例中，可结合各种其他机制来使用以上序列，从而提供并行化的附加机会。以下更详细地描述这些机会。

在第一示例中，负载扫描预处理并行化可如下地实现。注意，可并行地读取和预处理多个日志流。由于事务具有唯一的序列ID，因此可能通过例如使每个读者线程在虚拟统一的历史时间线上填充其指定槽来并行地创建统一的历史(并且，在一些情况下，以服从无锁实现的方式)。在该时间线中，第一事务(例如，具有ID 100的事务)与其对应的日志纪录一起在槽0处被加载。另外，事务101可在槽1处加载，事务113可在槽13处加载等等。在一个示例中，异步填充该时间线，以使在任何时间点处给定槽之后的槽可能还未被填充。然而，仍然可以理解，在扫描全部日志流结束时，时间线将被填满(例如，事务ID的每个槽将被占用)。

除并行加载以外，纪录可被插入实际存储器内索引。这可例如由只在该任务中专用的单个线程(此处被称为插入线程)完成。作为示例，填充压缩统一历史的高水位标记的负载线程可承担插入线程而非单独的、专用的线程的角色。例如，在出现统一历史的情况下，如以下：

事务Id：[100，101，102，103，]，，106，，108

以上序列示出具有9个槽的历史，其中前4个槽已经被加载到存储器内表格中，{104、105和107}仍然是缺少的，并且108是从日志流加载的最后一个事务。给定该布局，由于104是整个压缩(或“所应用的”)事务历史的高水位标记，因此加载事务104的线程还负责将104的内容推送到对应的表格中。换言之，填充“最旧的”空槽(例如，在没有其事务ID比该槽小的其他空槽的意义上更旧)的线程变成插入线程。在一个示例中，插入线程保持“插入者”的角色并且向上移动插入所填充事务的事务时间线，直到其找到另一个空槽，在该点处线程回复到标准加载器线程。

可以理解，在以上方案中，单个线程可插入多个行而多个线程可加载多个行。然而，由于加载行的动作可卸下在表格中插入行的大部分工作，因此该限制未显著地受限制。例如，加载器线程可为新的行指派存储器，并且为新的行计算插入位置(例如，以供散列索引)。因此，为插入行保留的全部将行移动到其预计算的位置。

还可以理解，在以上方案中，行插入不需要使用完整事务。尽管插入需要以正确的次序找到并施加纪录，但插入不需要做任何确认、后处理或日志记录(虽然无用信息收集仍然可能需要执行)。

在第二示例中，插入并行化可如下实现。负载扫描预处理并行化方案示出了如何能并行地执行多个日志流加载。在以上方案中，可以理解，仅有的串行化点是“插入”线程。然而，另外可以理解，没有插入线程的性质需要在系统中是唯一的。因此，假定还允许加载器线程插入行，可导出在插入所有行之后导致一致数据库的方案。

在一个实施例中，假定日志和检查点两者都包含行的完整映像(包括时间戳)，可在逐行的基础上而非在事务幅度范围内建立时间线。由于使用多个插入线程，因此可以理解，行可被处理并且准备好无序地插入索引。这可以各种方式来处理；例如，基于将足够的信息留在索引中，可采用各种技术来向后续的顺序插入指示关于未来插入的那些信息在别处可用。这可通过例如重影(ghost)纪录和/或任何类型的延迟工作项的指示器或其他合适的指示器来实现。

在第三示例中，可另外实现检查点并行化。例如，检查点加载可与日志的加载并行地开始。这可通过在分析结束时将系统放在开始检查点加载(本身并行的给定的多个检查点流)和日志加载两者的位置来增强性能。换言之，在先前方案中，可以理解延迟了重做，直到检查点被加载到存储器。然而，如果插入并行化被应用于日志加载和检查点加载两者，则可并行地处理所有数据流以使处理与重做日志扫描同时完成。

在一个实施例中，可使用与实现插入并行化中所使用的机制类似的机制来实现检查点并行化。另外，为了支持检查点并行化，足够的信息可被保存(例如，在日志和检查点两者中)以能够完全重建行，包括报头时间戳。在一个示例中，由于主密钥提供了一种唯一地标识行而无需具有其完整内容的方式，因此其存在允许放松对“完整行”的要求。

示例性联网和分布式环境

本领域技术人员可以理解，此处所述的数据库回复系统和方法的各实施例可结合任何计算机或其他客户机或服务器设备来实现，该任何计算机或其他客户机或服务器设备可作为计算机网络的一部分来部署或者被部署在分布式计算环境中，并且可连接到任何种类的数据存储。在这点上，此处所述的各实施例可在具有任意数量的存储器或存储单元以及出现在任意数量的存储单元上的任意数量的应用程序和进程的任何计算机系统和环境中实现。这包括但不限于具有部署在具有远程或本地存储的网络环境或分布式计算环境中的服务器计算机和客户计算机的环境。

分布式计算通过计算设备和系统之间的通信交换来提供计算机资源和服务的共享。这些资源和服务包括信息的交换、对于诸如文件之类的对象的高速缓存存储和盘存储。这些资源和服务还包括多个处理单元之间的处理能力共享以便进行负载平衡、资源扩展、处理专门化等等。分布式计算利用网络连接，从而允许客户机利用其集体力量来使整个企业受益。在这点上，各种设备可具有可如参考本主题公开内容的各实施例所述的参与恢复机制的应用程序、对象或资源。

图15提供了示例性的联网或分布式计算环境的示意图。该分布式计算环境包括计算对象1510、1512等以及计算对象或设备1520、1522、1524、1526、1528等，这些计算对象或设备可包括如应用程序1530、1532、1534、1536、1538所表示的程序、方法、数据存储、可编程逻辑等。可以理解，计算对象1510、1512等以及计算对象或设备1520、1522、1524、1526、1528等可包括不同的设备，诸如PDA、音频/视频设备、移动电话、MP3播放器、个人计算机、膝上型计算机等。

每个计算对象1510、1512等以及计算对象或设备1520、1522、1524、1526、1528等可经由通信网络1540直接或间接地与一个或多个其他计算对象1510、1512等以及计算对象或设备1520、1522、1524、1526、1528等通信。尽管在图15中被示为单个元件，但通信网络1540可包括向图15的系统提供服务的其他计算对象或计算设备和/或可表示未示出的多个互连网络。每计算对象1510、1512等或计算对象或设备1520、1522、1524、1526、1528等还可包含应用程序，诸如可以利用API或其他对象、软件、固件和/或硬件的、适于与本主题公开内容的各实施例通信或实现本主题公开内容的各实施例的应用程序1530、1532、1534、1536、1538。

存在支持分布式计算环境的各种系统、组件和网络配置。例如，计算系统可由有线或无线系统、本地网络或广泛分布的网络连接在一起。当前，许多网络耦合到因特网，因特网为广泛分布的计算提供了基础结构并且包含许多不同的网络，但任何网络基础结构可用于变得与如各实施例中所述的数据恢复系统相关联的示例性通信。

由此，可使用诸如客户机/服务器、对等、或混合体系结构之类的网络拓扑结构和网络基础结构的主机。“客户机”是使用与其无关的另一类或组的服务的一类或组中的成员。客户机可以是进程，即大致上是请求另一程序或进程所提供的服务的一组指令或任务。客户机进程使用所请求的服务，而无需“知道”关于其他程序或服务本身的任何工作细节。

在客户机/服务器体系结构中，尤其在联网系统中，客户机通常是访问另一计算机(例如，服务器)所提供的共享网络资源的计算机。在附图15的图示中，作为非限制性示例，计算对象或设备1520、1522、1524、1526、1528等可被认为是客户机而计算对象1510、1512等可被认为是服务器，其中计算对象1510、1512等作为提供数据服务的服务器，诸如从客户机计算对象或设备1520、1522、1524、1526、1528等接收数据、存储数据、处理数据、向客户机计算对象或设备1520、1522、1524、1526、1528等发送数据，但任何计算机都可取决于环境而被认为是客户机、服务器、或两者。这些计算设备中的任一个可处理数据、或请求可暗示如此处参考一个或多个实施例所述的恢复技术的事务服务或任务。

服务器通常是可通过诸如因特网或无线网络基础架构之类的远程网络或本地网络访问的远程计算机系统。客户机进程可在第一计算机系统中活动，而服务器进程可在第二计算机系统中活动，它们通过通信介质相互通信，由此提供分布式功能并允许多个客户机利用服务器的信息收集能力。按照此处所述的技术来利用的任何软件对象可单独提供或分布多个计算设备或对象上。

在通信网络1540或总线是因特网的网络环境中，例如，计算对象1510、1512等可以是其他计算对象或设备1520、1522、1524、1526、1528等经由诸如超文本传输协议(HTTP)之类的多种已知协议中的任一种与其通信的Web服务器。计算对象1510、1512等作为服务器还可用作例如计算对象或设备1520、1522、1524、1526、1528的客户机，这可以是如分布式计算环境的特性。

示例性计算设备

如所述的，有利的是，此处所述的技术可适用于期望执行数据库恢复的任何设备。因此，应当理解，构想了所有种类的手持式、便携式和其他计算设备和计算对象以供结合各实施例来使用，即，在设备可能希望从数据存储读事务或向数据存储写事务的任何地方。因此，以下在图16中所述的通用远程计算机只是计算设备的一个示例。另外，数据库服务器可包括以下通用计算机或其他数据库管理服务器组件的一个或多个方面。

尽管并非所需，但各实施例可部分地经由操作系统来实现，以供设备或对象的服务开发者使用和/或被包括在用于执行此处所述的各实施例的一个或多个功能方面的应用软件内。软件可在诸如客户机工作站、服务器或其他设备之类的一个或多个计算机所执行的诸如程序模块之类的计算机可执行指令的通用上下文中描述。本领域的技术人员可以理解，计算机系统具有可用于传递数据的各种配置和协议，并且由此没有特定配置或协议应当被认为是限制性的。

由此，图16示出其中可实现各实施例的一个或多个方面的合适的计算系统环境1600的一个示例，尽管如上所清楚描述的，计算系统环境1600只是合适的计算环境的一个示例，并且不旨在对使用范围或功能提出任何限制。也不应当将计算系统环境1600解释为对在示例性计算系统环境1600中所示的组件中的任何一个或其组合有任何依赖或要求。

参考图16，用于实现一个或多个实施例的示例性远程设备包括计算机1610形式的通用计算设备。计算机1610的组件可包括，但不限于，处理单元1620、系统存储器1630、以及将包括系统存储器的各种系统组件耦合到处理单元1620的系统总线1622。

计算机1610通常包括各种计算机可读介质，并且可以是可由计算机1610访问的任何可用介质。系统存储器1630可包括诸如只读存储器(ROM)和/或随机存取存储器(RAM)之类的易失性和/或非易失性存储器形式的计算机存储介质。作为示例而非限制，系统存储器1630还可包括操作系统、应用程序、其他程序模块、以及程序数据。

用户可通过输入设备1640向计算机1610输入命令和信息。监视器或其他类型的显示设备也经由诸如输出接口1650之类的接口连接到系统总线1622。除监视器以外，计算机还可包括诸如扬声器和打印机之类的其他外围输出设备，它们可通过输出接口1650连接。

计算机1610可使用到一个或多个远程计算机(诸如远程计算机1670)的逻辑连接在联网或分布式环境中操作。远程计算机1670可以是个人计算机、服务器、路由器、网络PC、对等设备或其他常见网络节点、或者任何其他远程媒体消费或传输设备，并且可包括以上关于计算机1610所述的任何或全部元件。图16所示的逻辑连接包括诸如局域网(LAN)或广域网(WAN)之类的网络1672，但也可包括其他网络/总线。这些联网环境在家庭、办公室、企业范围的计算机网络、内联网和因特网中是常见的。

如上所述，尽管结合各种计算设备和网络体系结构描述了各示例性实施例，但基本概念可被应用于期望便于恢复数据库系统的任何网络系统和任何计算设备或系统。

而且，存在实现相同或类似功能的多种方式，例如适当的API、工具箱、驱动器代码、操作系统、控件、独立或可下载软件对象等，它们使得应用和服务能够利用数据库恢复技术。由此，此处的各实施例从API(或其他软件对象)的观点以及从实现此处所述的机制的一个或多个方面的软件或硬件对象进行构想。由此，此处所述的各实施例可具有完全采用硬件、部分采用硬件并且部分采用软件、以及采用软件的方面。

本文中所使用的词语“示例性”意味着用作示例、实例、或说明。为避免疑惑，本文所公开的主题不限于这些示例。另外，本文中作为“示例性”所述的任何方面或设计不一定被解释为比其他方面或设计更优选或有利，它也不意味着排除本领域普通技术人员已知的等效示例性结构和技术。此外，在使用术语“包括”、“具有”、“包含”和其他类似词语的程度上，为避免疑惑，这些术语旨在以类似于术语“包括”作为开放的过渡词的方式是包含性的而不排除任何附加或其他元素。

如所述的，此处所述的各种技术可结合硬件或软件，或在适当时以两者的组合来实现。如此处所使用的，术语“组件”、“系统”等同样旨在指计算机相关实体，或者是硬件、硬件和软件的组合、软件或者是执行中的软件。例如，组件可以是，但不限于，在处理器上运行的进程、处理器、对象、可执行码、执行的线程、程序和/或计算机。作为说明，在计算机上运行的应用程序和计算机都可以是组件。一个或多个组件可驻留在进程和/或执行的线程内，并且组件可位于一个计算机上和/或分布在两个或更多的计算机之间。

如前所述的系统已经参考若干组件之间的交互来描述。可以理解，这些系统和组件可包括组件或指定的子组件、某些指定的组件或子组件和/或附加的组件，并且根据上述内容的各种置换和组合。子组件还可作为通信地耦合到其他组件的组件来实现，而不是被包括在父组件内(层次性)。另外，应当注意，一个或多个组件可被组合成提供聚集功能的单个组件，或被分成若干单独的子组件，并且诸如管理层之类的任何一个或多个中间层可被设置成通信地耦合到这些子组件以便提供集成功能。此处所述的任何组件也可与一个或多个此处未专门描述的但本领域技术人员一般已知的其他组件进行交互。

鉴于以上所述的示例性系统，参考各附图的流程图还可理解根据所述的主题实现的方法。尽管为了说明简洁起见，作为一系列框示出和描述的方法，但是应当理解，各实施例不仅仅限于框的次序，因为一些框可以与此处所描绘和描述的框不同的次序发生和/或与其他框并发地发生。尽管经由流程图示出了非顺序或分支的流程，但可以理解，可实现达到相同或类似结果的各种其他分支、流程路径和框的次序。此外，并非全部所示的框都是实现下面所述的方法所必需的。

除此处所述的各实施例以外，应当理解，可使用其他类似实施例，或者可对所述实施例作出修改和添加以便执行对应实施例的相同或等效功能而不背离这些实施例。此外，多个处理芯片或多个设备可共享此处所述的一个或多个功能的性能，并且类似地，存储可跨多个设备实现。因此，本发明不应限于任何单个实施例，而是应当根据所附权利要求书的广度、精神和范围来解释。

Claims (15)

1.一种数据库管理系统，包括：

日志管理器组件(530)，所述日志管理器组件(530)被配置成以逻辑日志记录格式生成与对至少一个数据存储(500、502)中的数据进行操作的事务相关的一个或多个日志记录(320)；以及

其中与逆转所述事务相关的信息响应于提交所述事务被丢弃。

2.根据权利要求1所述的系统，还包括：

被配置成存储与各个事务相对应的信息的至少一个持久数据存储；以及

被配置成防止将对应于一个或多个未提交事务的数据写入所述至少一个持久数据存储的组件。

3.根据权利要求1所述的系统，其特征在于，所述日志管理器组件(530)还被配置成将对所述至少一个数据存储(500、502)中的数据进行操作的多个事务记录在所述一个或多个日志记录(320)中。

4.根据权利要求1所述的系统，其特征在于，所述日志管理器组件(530)包括被配置成维护一个或多个日志流(640)的日志流管理组件(540、610、720)，所述一个或多个日志流(640)与各个日志记录(320)相关联。

5.根据权利要求4所述的系统，其特征在于，所述日志流管理组件(540、610、720)还被配置成至少部分地通过合并所述一个或多个日志流(640)中的至少一个日志流或拆分所述一个或多个日志流(640)中的至少一个日志流来管理对所述一个或多个日志流(640)的重组。

6.根据权利要求4所述的系统，其特征在于，所述日志管理组件(540、610、720)还被配置成以并行方式加载多个日志流(640)。

7.根据权利要求6所述的系统，其特征在于，所述日志管理组件(530)还被配置成便于将与所述多个日志流(640)相对应的各个数据库行以并行方式插入与所述至少一个数据存储(500、502)相对应的索引。

8.根据权利要求1所述的系统，其特征在于，所述日志管理组件(530)还被配置成将事务的开始时间和所述事务的结束时间记录到所述一个或多个日志记录(320)中，并且所述系统还包括：

恢复组件(560)，所述恢复组件(560)被配置成至少部分地通过以基于如其各个日志记录(320)中所记录的事务的开始时间和结束时间所确定的次序应用经由各个日志记录(320)所记录的事务，来重建所述至少一个数据存储(500、502)的操作状态。

9.根据权利要求1所述的系统，还包括：

恢复子系统集成组件(850)，所述恢复子系统集成组件(850)被配置成将所述日志管理组件(530)的各个事务日志记录与至少一个不同的数据库系统(830)的各个日志记录集成、由此创建公共日志(860)的外观，所述公共日志(860)包括所述日志管理组件(530)的事务日志记录和所述至少一个不同的数据库系统(830)的事务日志记录。

10.根据权利要求1所述的系统，其特征在于，所述日志管理组件(530)包括：

检查点操作组件(550)，所述检查点操作组件(550)被配置成在无需参考所述至少一个数据存储(500、502)中的各个物理位置的情况下生成指示所述至少一个数据存储(500、502)的状态的至少一个检查点。

11.根据权利要求1所述的系统，还包括：

事务处理组件(520)，所述事务处理组件(520)被配置成经由其中与所述事务相对应的恢复信息被持久地记录的物理提交(400)、其中所述事务所引起的至少一个数据存储(500、502)中的数据的改变对所述至少一个数据存储(500、502)内的其他事务是可见的逻辑提交(410)、以及其中所述事务的结果对所述至少一个数据存储(500、502)外部的实体可用的可见提交(420)来提交所述事务。

12.一种用于维护数据库恢复系统的方法，包括：

接收与对至少一个存储器内数据存储中的数据进行操作的事务相关的信息(1000)；

根据逻辑日志记录格式将所述事务日志记录在一个或多个日志记录中(1010)；

响应于提交所述事务，丢弃与所述事务相关的逆转信息(1020)；以及

防止将对应于一个或多个未提交事务的数据写入至少一个对应的持久数据存储(1030)。

13.根据权利要求12所述的方法，还包括：

维护多个日志流；

其中所述日志记录包括使用从所述多个日志流选择的日志流来日志记录所述事务。

14.根据权利要求13所述的方法，其特征在于，所述维护包括将各个输入/输出设备分配给所述多个日志流中的各个日志流。

15.根据权利要求12所述的方法，还包括：

在无需参考所述至少一个存储器内数据存储中的各个物理位置的情况下，生成与所述至少一个存储器内数据存储的状态相关的至少一个检查点。

Images