混合oltp和olap高性能数据库系统的制作方法

专利名称：混合oltp和olap高性能数据库系统的制作方法
混合OLTP和OLAP高性能数据库系统
背景技术：
在线业务处理(OLTP)和在线分析处理(OLAP)这两个领域对于数据库架构存在不同的挑战。在传统系统中，具有高关键任务业务率的消费者将他们的数据拆分成两个分离系统，一个数据库用于0LTP，一个数据库用于OLAP的所谓数据仓库。尽管允许合理的业务率，但是这种分离由许多缺点，包括由于仅周期性地发起精确转移负载数据分级而引起的延迟所导致的数据新鲜度问题以及由于维护两个分离的信息系统所导致过度资源消耗。在历史上，数据库系统主要用于在线业务处理。这种业务处理系统的典型示例是销售订单录入或银行业业务处理。这些业务访问和处理仅是整个数据的一小部分，内插可以非常快速地执行。根据标准化的TPC-C基准结果，当前最高的标度系统可以每秒处理多于100. 000个这种销售业务。
大约二十年前，开发了对数据库系统的新使用商业智能(BI)。BI应用依赖于长期运行的所谓在线分析处理(OLAP)查询，在线分析处理(OLAP)查询对数据的实质部分进行处理以便产生商业分析的报告。典型的报告包括根据地理区域、产品分类或消费者类别等分组的策略销售统计。取消了对可操作的OLTP数据库执行这些查询的首次尝试(例如，SAP的EIS项目)，这是由于OLAP查询处理导致资源争夺并且严重地损害了关键任务业务处理。因此，设想了在图I中示例的数据分级架构。这里，对专用的OLTP数据库系统执行业务处理。此外，针对商业智能查询处理安装分离的数据仓库系统。周期性地，例如在夜晚期间，提取OLTP数据库变化，将OLTP数据库变化转移到数据仓库规划的布置中，并且加载到数据仓库中。这种数据分级及其关联的ETL处理展现了以下若干固有缺陷·过期数据由于ETL处理只能周期性地执行，因此数据仓库状态不会影响最新的商业业务。因此商业分析必须基于它们对过期(过时)数据的判断。 冗余两个系统的使用导致维护数据的两个冗余拷贝的成本。另一方面，冗余允许以应用特定方式对数据进行建模在针对OLTP处理的归一化表中并且作为针对OLAP查询的星形方案。·高费用维护两个分离的系统导致技术和经济惩罚，因为必须考虑两个系统(硬件、软件等)的费用和两个系统的维护成本以及复杂的ELT处理。本发明的目的是解决这些缺陷。

发明内容
根据本发明，提供了一种权利要求I中限定的方法。在其余权利要求中引述了有利实施例。本发明提供了一种混合系统，可以使用硬件辅助复制机制来同时处理OLTP和OLAP这二者，以维护业务数据的一致快照(consistent snapshot)。在一个实施例中，本发明提供了一种主存储器数据库系统，保证OLTP业务的ACID属性并且同时对任意当前和一致快照执行OLAP查询会话(多次查询)。使用对虚拟存储器管理(地址解译、高速缓存、更新拷贝)的处理器固有支持可以同时获得高业务率和低OLAP查询响应时间。
根据本发明的实施例，放弃OLTP数据库与OLAT数据仓库系统的分离。可以通过主存储器数据库架构来实现在同一系统上集成这两个非常困难的工作量所需的处理性能。本发明实现了对业务OLTP数据的最新状态执行OLAP查询。这与传统系统相反，传统系统分开进行对OLTP数据库的业务处理和对数据仓库的查询处理，数据仓库仅周期性刷新，这导致基于过期(过时)数据的查询。在本发明的实施例中，业务数据库具备查询处理能力，从而(一部分)查询处理从数据仓库移至OLTP系统。为此，支持对相同数据库的OLTP业务处理和OLAP查询处理的混合工作量。这与最近针对不同应用情况构建专用系统的趋势略有不同。如果例如通过主存储器数据库架构提高了处理性能，则可以最佳地实现在相同系统上集成这两个非常不同的
工作量。第一方面，(互联网可访问的)数据量的惊人激增与这种保持所有业务数据主存储器驻留的假设冲突。然而，较近的检查示出了商业关键业务数据库量具有支持主存储器数据管理的有限尺寸。为了证实这种假定，可以对Amazon的估计业务量进行分析。订单处理数据量具有大约150亿欧元的估计年度税收。假定单独订单线具有大约15欧元值，并且每个订单线导致大约54字节的存储数据(如针对TPC-C基准而指定的)，对于作为这种销售应用中的主要仓库的订单线，总数据量应当是54GB每年。这种估计既不包括增加其他数据的量(消费者和产品数据)，也不包括压缩数据以减小量的可能性。然而，安全地假定使年度销售数据适合大规模服务器的主存储器。此夕卜，推断过去开发，安全地预测日用品的主存储器容量，并且与最大商业消费者的要求相t匕，高端服务器更快速增长。


图I示出了现有技术的分离的OLTB数据库和OLAP数据仓库。图2示出了根据本发明实施例的主存储器OLTP数据库架构。图3示出了根据本发明实施例的混合OLTP和OLAP数据库架构。图4示出了根据本发明实施例的新虚拟存储器快照的分岔。图5示出了在本发明实施例中使用的“更新拷贝”策略。图6示出了根据本发明实施例的针对OLAP查询使用虚拟存储器快照。图7示出了根据本发明实施例的不同时间点处多个OLAP会话。图8示出了根据本发明实施例的对分区数据的多线程OLTP处理。图9示出了根据本发明实施例的一致快照备份存储器。图10示出了根据本发明实施例的重做记录日志。图11示出了根据本发明实施例的用作OLTP处理器的备份以及活跃OLAP处理器的副服务器的使用。图12示出了根据本发明实施例的活跃业务的取消记录日志。图13示出了根据本发明实施例的恢复处理，包括⑴加载归档备份和⑵应用重做记录日志。
具体实施方式
在图2中示出了根据本发明实施例的用于业务处理的主存储器架构。在该实施例中，采用了单线程方法，其中，顺序地执行所有OLTP业务。该架构消除了以高成本锁定和锁存数据对象或索引结构的需要，这是由于仅活跃的更新业务“拥有”整个数据库。有利地，可以通过主存储器数据库来实现该串行执行方法，其中，不需要通过针对其他业务交错地利用CPU来代表一个业务从而掩蔽I/O操作。在主存储器架构中，典型的商业业务(例如，订单录入或支付处理)具有仅不到10毫秒的持续时间。然而，如果允许将复杂的OLAP型查询注入到工作量队列中，则会阻塞系统，这是由于所有的后续OLTP业务必须等待这种长运行查询的完成。即使这样的OLAP查询在30ms内完成，但是也会将系统锁定能够完成大约1000或更多OLTP业务的持续时间。然而，期望提供一种主存储器数据库系统，以每秒I万次的速率处理OLTP业务，同时能够处理对业务数据的最新快照的OLAP查询。根据本发明的实施例，提供了一种混合系统，能够使用硬件辅助复制机制同时处理OLTP和0LAP，以维护业务数据的一致快照。本发明可以通过保证OLTP业务的ACID属性的主存储器数据库系统来实现。具体 地，可以采用记录日志和备份归档用于持久性和快速恢复。与OLTP处理并行地，可以同样对任意当前和一致快照执行OLAP查询会话(多次查询)。使用对虚拟存储器管理(地址解译、缓存、更新拷贝)的处理器固有支持在相同系统中同时获得空前的高业务率和超低OLAP查询响应时间。系统架构根据本发明的实施例，可以对相同主存储器驻留数据库执行OLTP业务和OLAP查询。与老式基于磁盘的存储服务器相比，可以省略任何数据库特定缓冲器管理和页面结构化。数据驻留在虚拟存储器内的简单的主存储器优化数据结构中。因此，可以以“全速”采用OSJCPU实现的地址业务，而无需任何附加间接方式。可以采用两个主导相关数据库存储方案在行存储方法中，将关系保持为整个记录的阵列，而在列存储方法中，将关系垂直分区成属性值的向量。尽管虚拟存储器可以(显著地)超越物理主存储器，但是优选地数据库不限于物理主存储器的尺寸，以免虚拟存储器页面的OS控制交换。备选地，诸如闪速存储器或固态驱动器等副存储装置可以补充主存储器。OLTP 处理由于所有数据是主存储器驻留的，因此不会停止等待10。因此，可以依赖单线程方法，其中所有OLTP业务顺序地执行。这种架构消除了以高成本锁定和锁存数据对象的需要，这是由于仅一个更新业务“拥有”整个数据库。可以在主存储器数据库来实现该串行执行方法，其中，不需要通过针对其他业务交错地利用CPU来代表一个业务从而掩蔽I/O操作。在主存储器架构中，典型的商业业务(例如，订单录入或支付处理)具有仅大约10毫秒的持续时间。这转移了每秒一万次量级的吞吐量，需要超大规模商业应用。在图4中通过左手侧的队列示例了 OLTP业务的串行执行，其中，对业务进行序列化以等待执行。可以用高级脚本语言将业务实现为存储的过程。这种语言提供通过搜索关键字查找数据库条目、整个对象集合的重复、插入、更新和删除数据记录等的功能。然后将高级脚本语言编译成低级代码，低级代码直接操作存储器中的数据结构。OLTP业务应当具有短响应时间，以免队列中后续业务的长等待时间。这禁止了任何类型的交互业务，例如，请求用户输入或同时调用外部代理的信用卡检查。OLAP怏照管理如果允许将复杂的OLAP式查询注入到OLTP工作量队列中，则会阻碍系统，这是由于所有后续OLTP业务必须等待这种长运行查询的完成。即使这样的OLAP在30ms内完成，但是也会将系统锁定能够完成可能几千次OLTP业务的持续时间。为了实现提供主存储器数据库系统的目标，主存储器数据库系统以每秒一万次的速率处理OLTP业务，并同时处理对业务数据的最新快照的OLAP查询，采用为新处理创建虚拟存储器快照的操作系统功能。这通过重复OLTP (即，创建OLTP处理的子处理)来进行。例如，OLTP处理重复可以通过分岔forking (Unix中的fork O系统调用)来执行。在下文中，对“分岔”的引用应指OLTP处理重复的任何实现方式。
为了保证业务一致性，应当仅在两个(串行)业务之间执行分岔，而不是在业务之中执行。子处理通过覆盖的页面框板获得父处理地址空间的精确拷贝，如图4中所示例。通 过分岔操作创建的虚拟存储器快照用于执行OLAP查询的会话，如图6所示。快照精确地保持在分岔操作进行时存在的状态中。不幸地，现有技术的操作系统不会立刻物理拷贝存储器段。相反，现有技术操作系统采用“更新拷贝策略”，如图5所示。首先，父处理(OLTP)和子处理(OLAP)通过将虚拟地址(例如，对象a)解译到相同的物理主存储器位置来共享相同的物理存储器段。在附图中通过虚线框加亮存储器段的共享。虚线框表示(还)没有被复制的虚拟存储器页面。仅当更新对象(例如，数据项a)时，支持OS和硬件的更新拷贝机制发起其上驻留的虚拟存储器页面的复制。其后，存在执行业务的OLTP处理可访问的表示为a’的新状态，以及OLAP查询会话可访问的表示为a的旧状态。与附图建议的不同，实际针对发起页面变化的OLTP创建附加页面，并且OLAP快照是指旧页面，在创建了若干这种快照的情况下(例如图7)，该细节对于估计页面消耗是重要的。另一观看该功能的直观方式如下0LTP处理对整个数据库进行操作，数据库的一部分与OLAP模块共享。将所有OLTP变化应用于分开拷贝(区域)，Delta由拷贝(映射(shadowed))的数据库页面构成。因此，OLTP处理根据需要创建其更新页面的工作集合。这有点类似于将页面覆盖到缓冲器池中，然而根据需要拷贝更新页面在幅度上快3至4个量级，这是由于拷贝主存储器页面仅花费2 μ s而不是IOms来处理缓冲器池中的页面故障。有时，通过针对最新OLAP会话分岔新处理来将Delta与OLAP数据库合并。从而，Delta在概念上重新集成到(主快照)数据库中。与用于将Delta合并回到主数据库中的任何软件解决方案不同，硬件支持的虚拟存储器合并(分岔)可以亚秒非常高效地实现。以整个页面的粒度执行复制(到Delta中)，整个页面通常缺省地具有4KB尺寸。在本示例中，a到a’的状态变化不仅引起对a的复制，而且还引起对该页面上所有其他数据项(例如b)的复制，尽管这些数据项没有变化。该缺陷通过OS和处理器非常高效和快速的虚拟存储器管理来补偿，例如，经由TLB高速缓存和写入拷贝施加的超高效VM地址变换。数据库系统中的传统映射构思基于在页面级维护映射拷贝或者映射各个单独对象的纯软件机制。快照导致与父(即，OLTP请求执行)处理更新的页面数目成比例的存储开销。快照在分岔操作创建快照时OLTP处理的存储器状态与OLTP处理的当前存储器状态之间复制delta(对应于变化的页面)(OLAP处理(几乎)不改变共享页面，当然这会由于更新拷贝机制而引起问题。然而，为了提高性能，OLAP处理会在非共享的主存储器区域中分配它们的临时数据结构)。如果主存储器容量稀少，则OLAP查询引擎可以采用副存储设备(例如，盘)，从而在更长执行时间内交换主存储器容量。通过创建基于磁盘的运行来对关系进行分类是一个主要的示例。OLAP查询队列中由椭圆形表示的所有OLAP查询访问数据库的相同一致快照状态。这样的一组查询可以被称作查询会话，以表示商业分析师能够通过反复查询相同状态使用这种针对数据的详细分析的会话，用于例如挖掘更多细节或者实现更好的概览。
多个OLAP会话迄今为止，已经描述了利用两个处理的数据库架构，一个处理用于0LTP，另一个处理用于0LAP。由于OLAP查询是只读的，因此它们容易在共享相同地址空间的多线程中并行执行。同样可以避免任何同步(锁定和锁存)开销，这是因为OLAP查询不共享任何易变数据结构。典型地具有多于10个核的现代多核计算机可以经由该查询间并行化来获得实质加速。良好地利用多核服务器的其他可能是创建多个快照。具体地，可以获得任意当前快照。这可以简单地通过周期性(或一经请求)分岔新快照并因此开始新OLAP查询会话处理来实现。在图7中示例了这一点，图7示出了一个且仅一个OLTP处理的当前数据库状态(前面板)和三个活跃查询会话处理的快照，其中最早的是背景中的状态。连续状态变化由数据项的四个不同状态a(最早状态)、a’、a”和a”’(最近业务一致状态)加亮。显然，在不同快照之间大多数数据项不会变化，这是因为期望以几秒而不是几分钟或几小时的间隔来创建最新查询的快照，在具有ETL数据分级的当前分离数据仓库解决方案中通常就是这样。原则上活跃快照的数目不受限，由于每个“使用期限(lives)”在其自身的处理中。甚至在OLAP处理众多和/或利用多线程并因此超过核的数目的情况下，通过调节优先权也可以确保在核中始终分配关键任务OLTP处理。在完成会话的最后查询之后删除快照。这可以通过简单地终止执行查询会话的处理来进行。不必按照创建快照的顺序来删除快照。例如，为了详细估量，一些快照可以持续更长的持续时间。然而，快照的存储器开销与从创建该快照到下个较晚快照的时间(在存在下个较晚快照的情况下，或者到实际时间)执行的业务的数目成比例。图7通过数据项c示出了这一点，针对“中年”快照在物理上重复并因此共享数据项C，并由最早快照可访问。在直觉上，仍能够在最早快照之前终止中年快照，由于c所驻留的页面会因为经由相关联于物理页面的基准计数器与最早快照共享而被OS/处理器自动删除。因此保持终止中年快照，与在终止中年快照处理时释放a’所驻留的页面不同。最晚快照访问当前OLTP处理地址空间中包含的状态c’。多线稈OLTP处理如上所述，OLAP处理可以被配置为多个线程，以更好地利用现代计算机的多个核。这对于OLTP处理也是可能的。一个简单扩展是允许多个只读OLTP业务并行。只要读取/写入业务在OLTP工作量队列前面，系统就停顿并转移回到顺序模式中，直到在队列前面没有更多更新业务为止。在实际应用中，通常存在比更新业务更多的只读业务，因此期望获得一些并行级别，这些并行级别甚至通过(仔细地)重新排列OLTP工作量队列而增加。
存在许多自然分开数据的应用情况。对于这一点一种非常重要的应用型是多租用。不同的数据库用户(被称作租户)对相同或相似的数据库方案进行操作，但是不会共享他们的业务数据。相反，这些数据库用户维护他们对数据的专有分区。在不同的租户之中仅共享一些只读数据(例如，产品分类、地理信息、商业信息分类，例如Dun和Bradstreet)。令人感兴趣地,对于业务处理广泛已知的工业标准TPC-C基准(www. tpc. org)呈现类似的分区，由于多数数据可以由所属仓库水平分区。只有项目表除外，项目表对应于当前共享的数据分区。在这样的分区应用情况下，OLTP处理可以配置为多线程，以经由并行更进一步提高性能。在图8中示出了这一点。只要业务仅访问和更新它们的专有分区，并且访问(不更新)共享的数据，那么多个这样的业务就可以并行运行(每个分区一个)。附图示出了这一点，面板内的每个椭圆形(表示业务)对应于分离的线程执行的一个这样分区受限业务。
然而，读取交叉分区或者更新共享数据分区的业务需要同步。在一个实施例中，交叉分区业务请求排他地访问系统(就像在纯顺序方法中)。这在中央系统中非常高效，在中央系统中，所有分区驻留在一个节点上。然而，如果节点分布在对于多分区业务需要二阶段执行协议的计算机簇上，则更高级的同步方法是有利的。除了以业务一致方式进行上述之前停顿所有线程以外，可以如以前对OLAP快照进行分岔。可以在所有分区和共享数据上对OLAP查询公式化，这在例如用于广告目的的多租用应用中是有利的。还可以针对分布式系统开发对数据库的分区，分布式系统将专有分区分配到计算机簇中的不同节点。可以在所有节点上重复读取多数情况下共享的分区。然后，将分区受限的业务转移至对应的节点，并且并行运行，而无需任何同步开销。对于分区交叉业务和所有节点上的同步快照创建而言需要同步。OLAP杳询会话的怏照隔离在快照隔离中，业务继续看到业务一致数据库状态，由于该业务存在于(就在)业务开始之前的时间点处。存在实现这种快照同时数据库修改并行运行的不同可能性 重新运行该方法适当地更新数据库。如果较早查询需要早期版本的数据项，则通过取消对该对象的所有更新来根据当前版本创建。因此，通过逆应用所有取消日志记录达到所需时间点来在所谓的重新运行端中创建对象的较早拷贝。 版本化所有对象更新创建对象的新加时间戳版本。因此，代表查询的读取获取最晚版本(最长时间戳)，最晚版本的时间戳小于查询的开始时间。持久地(运行时间行进查询)或暂时维护版本化的对象，直到没有更多活跃查询需要访问它们。·映射创建初始映射以消除取消记录日志的需要，这是因为写入所有变化以进行映射并然后在业务提交时间安装在数据库中。然而，映射构思还应用于维护快照。·虚拟存储器快照根据本发明实施例的快照机制显式地创建了针对一系列查询(称作查询会话)的快照。在这一点上，将查询会话的所有查询绑定至可以依赖于经由分岔处理保留的相同一致状态的一个业务。同样，可以开发VM快照用于创建非易失性副服务器或存储装置上的整个数据库的备份归档。在图9中示出了该处理。典型地，经由I至lOGb/s的高带宽网络将归档写入相同计算中心内的专用存储服务器。为了保持该转移速度，存储服务器必须为对应的总带宽采用若干(大约10)个磁盘。OLTP业备同步在单线程模式中，OLTP业务不需要任何同步机制，由于它们拥有整个数据库。在多线程模式中，对两种类型的业务进行区分·分区受限业务可以读取和更新它们自己分区中的数据，以及读取共享分区中的数据。然而，更新受限于它们自己的分区。·分区交叉业务是除了更新共享数据还访问(读取或更新)其他分区中的数据的业务。
后一种类型的分区交叉业务中的业务非常稀少，由于很少出现对共享数据的更新，并且导出分区，使得业务通常仅对它们自己的数据进行操作。OLTP工作量中存储的过程业务的分类可以基于分析它们的实现代码来自动进行。如果在执行期间，证明业务被错误地分类为是“分区受限的”，则将其重新运行并重新插入到OLTP工作量对象中作为“分区交叉”。优选地，至多允许每个分区一个分区受限业务并行。在这种限制的情况下，不需要任何类型的锁定和锁存，这是因为分区具有非交叠数据结构，并且共享数据是只读访问的。然而，必须在排他模式中允许分区交叉业务。实质上，在允许之前，必须在整个数据库上预先要求排他锁定(或者，在POSix术语中，在运行之前必须通过障碍)。因此，执行分区交叉业务成本相对较高，这是因为分区交叉业务必须等待直到所有其他业务终止为止，并且在它们的持续时间内不允许其他业务。一旦系统允许，业务就全速运行，因为分区交叉业务的排他运行会再次取消共享数据分区或专用数据分组的任何类型的锁定或锁存同步。持久件业务的持久性需要在失败之前必须恢复进行了的业务的所有效果。为了实现这一点，采用经典重做记录日志。在图10中这通过灰色椭圆形来加亮，灰色椭圆形从串行业务流发出，到达非易失性重做存储设备。在传统数据库系统中，因为系统崩溃之后数据库可以在动作非一致状态中，因此逻辑日志记录有问题。这一点在所示意的本发明实施例中不会发生，因为从业务一致归档重新开始执行(例如图9)。唯一重要的是，按照执行这些逻辑日志记录的顺序写入这些逻辑日志记录，以便能够正确地恢复数据库。在单线程OLTP配置中，这容易实现。对于多线程系统，仅分区交叉业务的日志记录必须总体上安排到所有业务中，而分区受限业务的日志记录可以并行写入，并且因此仅每个分区序列化日志记录。经由副服务器的高可用性和OLAP负载平衡重做日志流也可以用于维持副服务器。该副服务器仅执行与主服务器相同的业务。在主服务器故障的情况下，将业务处理切换至副服务器。然而，优选地不放弃将重做日志记录写入稳定存储装置，并且不仅依赖于用于故障冗余的副服务器。软件错误(在最差的情况下)导致主服务器和副服务器“同时”崩溃。副服务器典型地由于不需要执行任何只读OLTP业务而经历较少负载，因此与主服务器相比具有较少的OLTP负载。这一点可以通过将一些(或所有)OLAP查询会话委托给副服务器得到开发。代替对或除了对主服务器上的OLAP会话的处理进行分岔，也可以使用副服务器。在图11中示出了对用作OLTP处理的备用的并且作为活跃OLAP处理器的副服务器的使用。附图中未示出使用副服务器代替主服务器来将一致快照写入存储服务器的归档的可能性。从而，从主服务器向负载少的副服务器委托备份处理。日志记录的优化可以证明在日志记录之前写入(WAL)的原理会成为性能瓶颈，这是因为在提交业务之前需要转储日志记录。具体地，由于业务必须等待，因此上述在单线程执行中成本高。两种通常采用的策略是可能的 组提交，或者 异步提交例如，在IBM的DB2中可配置组提交。在业务结束之后不马上执行业务的最终提交。相反，对若干业务的日志记录进行累积，并按照批处理方式转储。因此，延迟提交的肯 定应答。当等待批次业务完成并正转储它们的日志记录时，已经释放了它们的锁定。这被称作早期日志释放。在本非锁定系统中，这解译成允许对应分区的下个业务。一旦针对业务组转储日志缓冲器，向客户肯定应答业务的提交。另一种不安全的方法为了避免等待转储日志记录放宽WAL原理。只要将日志记录写入易失性日志缓冲器，就提交业务。这被称作“异步”提交。在失效的情况下，这些日志记录中的一些会丢失，并因此恢复处理在重新开始期间丢失那些提交的业务。原子件业务的原子性要求能够从数据库中消除失败业务的任何影响。仅需要考虑明显失败的业务，被称作Rl恢复。在本实施例中不需要所谓的R3恢复，所谓的R3恢复要求在恢复的数据库中取消损失业务(在崩溃时活跃的那些业务)的更新，这是由于数据库仅在易失性存储器中，并且仅在保证业务成功提交时写入逻辑重做日志。此外，用作恢复的开始点的数据库的归档拷贝是业务一致的，并因此不包含在恢复期间需要消耗粗的任何操作(例如，图9)。因此，取消操作仅需要针对活跃业务(在针对所有活跃业务的多线程模式中)，并且可以仅在易失性存储器中维护。在图12中这一点通过页面框面板的左上侧中环形缓冲器来加亮。在业务处理期间，将任何更新数据对象的前像日志记录在该缓冲器中。环形缓冲器的尺寸非常小，这是因为其受到每业务(乘以多线程操作中活跃业务的数目)的更新数目的限制。清除动作一致怏照取消记录日志也可以用于从动作一致VM快照中创建业务一致快照，动作一致VM快照是在一个或多个业务活跃时创建的。这在多线程OLTP系统中特别有利，因为避免了必须完全停顿业务处理。在对包括与其相关联的VM快照的OLAP进行分岔之后，将取消日志记录应用于快照状态(按照逆时间顺序)。由于取消日志缓冲器反映活跃业务(在分岔时)(以及仅那些生成的快照是业务一致的业务)的所有效果，并且反映在发起分岔时仍为活跃的业务(包括完全达到改时间点的所有业务)之前的数据库状态。系统故障之后的恢复在恢复期间，能够以主存储器中恢复的最晚完全写入的归档开始。然后，按照时间顺序应用取消日志，以针对归档的快照的分岔之后的第一个重做日志条目开始。例如，如果以高达lOGb/s (受限于来自存储服务器的网络带宽)的带宽恢复归档，并且可以以每秒100, 000的业务率应用重做日志，则针对典型大企业(例如，100GB数据库以及每秒数以千计的更新业务)的时间上的失败在仅一到几分钟量级(如果以小时为基础写入备份归档)。如果不容容忍这种时间上的失败，也能够依赖于复制的服务器，一个在活跃模式中，另一个例如，经由重做日志“测错”执行相同业务，如图11所示。在失败的情况下，简单转换恢复系统。在图13中概括了恢复处理。应当认识到 ，上述实施例仅作为示例描述，并且对这些实施例的修改包括在所附权利要求的范围内。
权利要求
1.一种维护混合OLTP和OLAP数据库系统的方法，所述混合OLTP和OLAP数据库系统包括存储器，该方法包括 执行一个或多个OLTP业务； 创建一个或多个虚拟存储器快照；并且 使用一个或多个虚拟存储器快照来执行一个或多个OLAP查询。
2.根据权利要求I所述的方法，还包括响应于对数据对象的更新来复制存储有该数据对象的虚拟存储器页面，随后更新的数据对象可访问用于OLTP业务，而未更新的数据对象保持可访问用于OLAP查询。
3.根据权利要求I所述的方法，其中，OLTP业务在第一地址空间中执行，其中创建虚拟存储器快照包括提供对第一地址空间的拷贝加以指示的第二地址空间，其中OLAP查询在第二地址空间中执行，并且创建虚拟存储器快照包括复制OLTP过程以创建用于执行OLAP查询的子过程。
4.根据前述权利要求中任一项所述的方法，其中，数据库存储分区中的专有数据以及共享数据，其中分区可以驻留在不同数据处理系统中，该方法包括 并行执行OLTP业务，包括对专有数据的读取和/更新访问，或者对共享数据的读取访问； 顺序执行OLTP业务，包括分区上的读取访问，或者对共享数据的更新访问；和/或 在分区和共享数据中的一个或多个上执行一次或多次OLAP查询。
5.根据前述权利要求中任一项所述的方法，其中，虚拟存储器快照是业务一致的。
6.根据权利要求5所述的方法，还包括当没有OLTP业务是活跃时创建虚拟存储器快照。
7.根据权利要求5所述的方法，还包括当一个或多个OLTP业务是活跃时创建虚拟存储器快照，并且使用取消日志机制将虚拟存储器快照适配为表示发起所述一个或多个活跃OLTP业务之前的数据库状态。
8.根据前述权利要求中任一项所述的方法，还包括使用虚拟存储器快照之一并行执行多个OLAP查询。
9.根据权利要求I至5中任一项所述的方法，还包括创建多个虚拟存储器快照以用于相应的并行OLAP查询。
10.根据前述权利要求中任一项所述的方法，还包括周期性地或者按照需求创建新的虚拟存储器快照。
11.根据权利要求I至9中任一项所述的方法，还包括使用现有硬件支持的存储器一致性控制机制，来识别何时更新数据库中的数据对象，以及触发对应页面的新物理拷贝的创建。
12.根据前述权利要求中任一项所述的方法，还包括在完成对应的OLAP查询之后删除虚拟存储器快照。
13.根据前述权利要求中任一项所述的方法，还包括使用虚拟存储器快照来提供数据库的业务一致备份。
14.根据权利要求13所述的方法，还包括使用业务一致备份和重做日志机制来恢复数据库。
15.根据前述权利要求中任一项所述的方法，还包括 保持主服务器执行所述OLTP业务；并且 保持副服务器也执行主服务器所执行的OLTP业务的至少一部分，具体地是包括更新对数据的访问在内的所有OLTP业务，以及保持副服务器执行所述OLAP查询的至少一些。
16.一种混合OLTP和OLAP数据库系统，包括 存储器中存储的数据库； 处理器；以及 存储装置，耦合至处理器，存储指令，指令在被执行时使处理器执行前述权利要求中任一项所述的方法。
17.根据权利要求16所述的混合OLTP和OLAP数据库，其中，数据库是主存储器数据库。
18.—种包括介质的产品，所述介质存储指令，指令在被执行时使基于处理器的系统执行权利要求I至15中任一项所述的方法。
19.一种在下文中参照附图描述的方法。
全文摘要
提供了一种维护混合OLTP和OLAP数据库的方法，该方法包括执行一个或多个OLTP业务；创建一个或多个虚拟存储器快照；并且使用虚拟存储器快照来执行一个或多个OLAP查询。优选地，该方法还包括响应于对数据对象的更新复制存储有该数据对象的虚拟存储器页面，从而更新的数据对象可访问用于OLTP业务，而同时未更新的数据对象保持可访问用于OLAP查询。相应地，提供了一种混合系统，可以使用硬件辅助的复制机制来同时处理OLTP和OLAP，以维护业务数据的一致快照。
文档编号G06F17/30GK102906743SQ201180024418
公开日2013年1月30日 申请日期2011年4月4日 优先权日2010年5月17日
发明者阿尔方·坎佩, 托马斯·纽曼 申请人:慕尼黑技术大学