CN101263492B

CN101263492B - 用于透明地存档的方法和设备

Info

Publication number: CN101263492B
Application number: CN2004800399660A
Authority: CN
Inventors: 塞尔吉·布尔邦纳斯; 查尔斯·丹尼尔·沃尔夫森
Original assignee: International Business Machines Corp
Current assignee: Tama company
Priority date: 2004-01-07
Filing date: 2004-12-14
Publication date: 2013-02-27
Anticipated expiration: 2024-12-14
Also published as: CN101263492A; WO2005069164A3; WO2005069164A9; WO2005069164A2; US20050149584A1; EP1702278A2; US7287048B2

Abstract

一种方法、设备以及用于实现该方法的制造产品透明地存档数据。一个或多个数据源存储数据。第一数据移动器依照第一规则集把第一数据子集从一个或多个数据源移动到第一联合档案文件。在本发明的另一方面中，处理查询，以便检索第二数据子集，并且从第一联合档案文件中检索第二数据子集的一部分。在本发明的又一方面中，对所述查询的处理确定是否有任何将会满足所述查询的数据被存储在第一联合档案文件中。

Description

用于透明地存档的方法和设备

技术领域

本发明涉及一种技术，特别是涉及一种用于透明地进行存档(archiving)的方法、设备和用于实现所述方法的制造产品。

背景技术

数据库管理系统使用户能够迅速且便利地访问数据。在数据库管理系统中，把数据存储在表格中。所述表格通常被物理地存储在硬盘驱动器上，以便可以迅速地访问数据。

图1描绘了数据库管理系统的示例性数据库表10。表10具有用于存储数据的行12和列14。一行12也被称为一个记录。

档案文件(archive)存储装置也用于存储数据。档案文件存储系统的存储装置通常比硬盘驱动器更为缓慢且价格更为低廉。随着数据库的增长，即随着记录被添加到数据库的表中，数据量可能变得太大以致于无法在单个数据库中方便地进行管理，这使得用户响应时间和系统性能变差了。另外，许多数据可能再也不需要被访问；然而，需要保留这些数据。因此，通常把部分数据从数据库上删除并且移到档案文件存储装置中。

在金融部门中，诸如交易专柜之类的应用收集了数据库中的大量数据。各种政府规章命令必须在相当长的一段时间内保留这些数据。在这些应用中，常常会参考最近的数据；偶而或许再也不会参考较陈旧的数据。随着数据量的增长，较陈旧的数据被存档，以便使数据库保持较小且易于管理，提供更好的响应时间，并且使诸如备份之类的实用程序能够运行得更快。档案文件存储装置与其它类型的存储装置相比通常在维护上成本较低，这也是鼓励进行存档的一个原因。

通常由系统管理员手动地执行用于存档以及从档案文件存储装置中检索数据(特别是从关系数据库管理系统中检索相关数据)的过程。当检索所存档的数据时，找到所想要的存档数据常常是一个挑战，这要求人工干预以及分别搜索档案文件介质。因此，用户不能在单个请求中访问存档数据和未存档数据的组合，并且不能向用户提供存档和未存档(或有效(live))的数据的组合表示。

因此，需要一种使用户能够透明地进行存档并且访问所存档的数据的方法、设备和制造产品。另外，所述方法还应当使用户能够相对于有效数据使用单个查询来组合存档和未存档(或有效)的数据。

发明内容

为了克服上述现有技术中的限制，并且为了克服在阅读并理解本说明书时会变得清楚的其它限制，本发明提供了一种用于透明地存档的方法、设备和制造产品。

在本发明的一个优选实施例中，一个或多个数据源存储数据。第一数据移动器(mover)依照第一规则集把第一数据子集从一个或多个第一数据源移动到第一联合(federated)档案文件。

在本发明的另一方面中，第一数据移动器依照第一规则集把数据移动到多个联合档案文件。

在本发明的又一方面中，把第二联合档案文件耦合到第一联合档案文件，第一数据移动器把第一数据子集移动到所述第二联合档案文件。第二数据移动器依照第二规则集把至少一部分的第一数据子集移动到第二联合档案文件。

在本发明的另一方面中，对查询进行处理，以便检索第二数据子集。从第一联合档案文件中检索第二数据子集的第一部分。在本发明的又一方面中，使用视图(view)来处理查询。作为选择，通过调用表函数来处理所述查询。在本发明的另一替换方面中，依照至少一个配置参数来处理所述查询。在本发明的又一替换方面中，根据元数据来处理所述查询，以便确定第二数据子集的一部分是否被存储在第一联合档案文件中。

依照这种方式，可以在联合环境中透明地进行存档，并且可以从联合档案文件存储装置中透明地检索所存档的数据。

附图说明

通过结合附图考虑以下的详细描述，可以容易地理解本发明的教导，其中：

图1描绘了依照现有技术的示例性表格；

图2描绘了用于把数据从数据库移动到档案文件并且访问该数据就好像它仍然存在于已经从中将其移除的所述数据库中一样的技术的实施例的高级流程图；

图3描绘了使用本发明中的教导的说明性计算机系统；

图4描绘了联合档案文件关系数据库管理系统的第一实施例；

图5描绘了用于创建档案文件存储系统的绰号(nickname)并且进行查询的实施例的流程图；

图6描绘了用于创建视图以访问在档案文件存储系统中所存储数据的实施例的流程图；

图7描绘了用于使用SQL语言的扩展来进行查询的实施例的流程图；

图8描绘了使用表函数来进行查询的实施例的流程图；

图9描绘了用于进行查询的实施例的流程图，其中对包括所存档数据的判定由至少一个配置参数来控制；

图10描绘了由查询处理器根据元数据来透明地查询联合档案文件的技术的实施例的流程图；

图11描绘了由数据移动器用来移动数据的技术的实施例的流程图；

图12描绘了由数据移动器用来移动数据的另一种技术的实施例的流程图；

图13描绘了包含示例性的存档规则的表；

图14描绘了级联的联合档案文件关系数据库管理系统的实施例；和

图15描绘了在异构型环境中具有第一和第二档案文件存储系统的联合档案文件关系数据库管理系统的实施例。

为了便于理解，在可能的情况下，使用了相同的附图标记来表示某些附图所共用的相同元件。

具体实施方式

在考虑了以下描述之后，那些本领域技术人员将会清楚地认识到，可以利用本发明的教导来透明地存档数据。一个或多个数据源存储数据。第一数据移动器依照第一规则集把第一数据子集从一个或多个数据源移动到第一联合档案文件。

图2描绘了本发明的技术的实施例的高级流程图。在步骤22，依照规则集把数据子集从数据源透明地移动到联合档案文件。在步骤24，访问在联合档案文件中的数据子集的一部分，就好像该数据被存储在数据源中一样。

在一个更具体的实施例中，依照规则集把数据从本地数据库管理系统移动到联合档案文件。因为用户不知道数据正被存档，所以移动操作是透明的。相对于本地数据库管理系统中的数据进行查询，这使得能够将档案文件联合。将来自联合档案文件和本地数据库管理系统中的满足所述查询的数据聚集起来(aggregate)，以提供聚集的结果。查询返回所聚集的结果，所以用户不知道所存档的数据被检索了。

图3描绘了利用本发明的教导的说明性计算机系统30。计算机系统30包括处理器32、显示器34、输入接口(I/F)36、通信接口38、存储器40、诸如硬盘驱动器44和光盘驱动器46之类的盘存储器42和输出接口48，所有这些单元通常由一条或多条总线50耦合。输入接口36包括键盘52和鼠标54。输出接口是打印机56。通信接口38是网络接口卡(NIC)，其使得计算机30能够经由例如因特网之类的网络进行通信。通信接口30可以被耦合到诸如双绞线、同轴电缆或光纤之类的传输介质。在另一示例性实施例中，通信接口提供了无线接口。

存储器40通常包括不同的形态(modality)，其说明性地是半导体存储器，诸如随机存取存储器(RAM)和盘驱动器。存储器40存储操作系统56、一个或多个应用程序58和联合档案文件关系数据库管理系统(RDBMS)60。操作系统56可以由任何常规的操作系统来实现，诸如

(国际商业机器公司的注册商标)、

(国际商业机器公司的注册商标)、

(UNIX是通过X/Open有限公司许可的在美国及其它国家中的注册商标)、

(微软公司的注册商标)和

(Linus Torvalds的注册商标)。

联合档案文件RDBMS 60使用户能够执行用于向储存库中分配数据、从储存库中删除数据或查询在储存库中所存储的数据的命令。在一个实施例中，所述命令是符合由美国国家标准协会(AmericanNational Standards Institute，ANSI)或国际标准化组织(InternationalStandards Organization，ISO)所公布的结构化查询语言(StructuredQuery Language，SQL)标准的结构化查询语言(SQL)语句。在替换实施例中，可以使用除SQL之外的语言。通常，使用SQL SELECT语句来查询储存库，并且使用SQL INSERT或UPDATE语句来把数据分配到储存库。

在一个更具体的实施例中，使用某些

信息整合器(Information Integrator)(IBM和DB2是国际商业机器公司的注册商标)功能来至少部分地实现联合档案文件RDBMS 60。无论如何，都不打算将本发明的技术局限于使用

信息整合器来实现，并且可以用具有联合能力的其它关系数据库管理系统来实现。例如，作为选择，联合档案文件RDBMS是XML库(store)。

在存储器40中，操作系统56、应用58和联合档案文件RDBMS60包含指令和数据。把用于实现本发明的特定软件指令并入到联合档案文件RDBMS 60中。通常，联合档案文件RDBMS 60软件可以被有形地包含在计算机可读介质、例如存储器40或更具体地说包含在盘驱动器42之一中，并且包含指令，所述指令在由处理器32执行时使计算机系统30利用本发明。

在一个实施例中，存储器40可以把部分的软件指令和数据存储在半导体存储器中，而把其它部分的软件指令和数据存储在盘存储器中。取决于实施例，存储器40存储以下各种数据：

操作系统56；

应用58；

联合档案文件RDBMS 60，其中取决于该实施例，所述联合档案文件RDBMS 60包括以下各项的各种组合：

本地数据库管理系统(本地数据库)62，其提供了用于存储本地表并且可由联合档案文件RDBMS直接访问的有效数据库；

查询处理器64，用于接收SQL语句、分析所述SQL语句并且确定用来访问数据的适当执行计划；

包装器(wrapper)66，用于向各自的档案文件存储系统提供接口，其包括用于向第一档案文件存储系统提供接口的第一包装器68，并且在另一实施例中，还包括用于向第二档案文件存储系统提供第二接口的第二包装器70，在其它实施例中，附加的包装器向各自的外部数据库管理系统、文件系统或应用提供接口；

一个或多个绰号72，像本地数据库62中的本地表那样使用，并且映射到档案文件对象，并且用来引用所述档案文件对象；在其中档案文件存储装置是另一关系数据库系统的一个实施例中，绰号映射到远程表；

服务器对象74，用于识别具有档案文件存储系统的档案文件服务器；

视图(一个或多个)76，用于聚集来自至少一个联合档案文件和本地数据库62的数据；

数据移动器80，用于把数据从本地数据库62移动到联合档案文件存储系统；

元数据82，用于存储由联合档案文件RDBMS所使用的信息，其包括存档规则集84、配置信息86以及监控、审核(auditing)&统计信息88；

表函数(一个或多个)90，在某些实施例中，其用来从档案文件存储系统中检索数据；

数据库配置参数和注册表变量(一个或多个)92，用于至少部分地规定联合档案文件RDBMS的行为；和

管理工具94，由系统管理员用来配置联合档案文件RDBMS。

可以使用用于生成软件、固件、硬件或其任何组合的标准编程和/或工程技术来把本发明实现为方法、设备或制造产品。这里所用的术语“制造产品”(或者作为替换，“计算机程序产品”)意在包含可从任何计算机可读设备、载体或介质访问的计算机程序。那些本领域技术人员应当认识到，在不脱离本发明的范围的情况下可以对此配置进行许多修改。

那些本领域技术人员还应当认识到，在图3中所示的示例性计算机系统并不是意在限制本发明。在不脱离本发明的范围的情况下可以使用其它替换的硬件环境。

图4描绘了提供联合档案文件存储装置的联合档案文件RDBMS60的第一实施例。本地数据库62可以从联合档案文件RDBMS 60直接访问，并且不使用绰号或包装器。例如，本地数据库62可以用于联机事务处理(Online Transaction Processing)。联合档案文件RDBMS 60包括查询处理器64、数据移动器80、元数据82、绰号(一个或多个)72、档案文件包装器68和服务器对象102。

服务器对象102是用于表示一个远程数据储存库的对象，诸如其可以是另一RDBMS的档案文件服务器104。服务器对象102还提供了绰号(一个或多个)72的命名范围。

档案文件包装器68在联合档案文件RDBMS 60和档案文件服务器104之间提供了一个接口。通常，档案文件服务器104与联合档案文件RDBMS 60是远离的。

查询处理器64处理来自应用58、数据移动器80和管理工具94的查询。在一个实施例中，查询是SQL语句。查询处理器64直接访问本地数据库62中的表。查询处理器64使用绰号(一个或多个)74来访问档案文件存储装置。查询处理器64还访问元数据82，以确定数据是否被存储在档案文件服务器104中。在其中元数据82被存储在数据库表中的一个实施例中，查询处理器64接收来自数据移动器80和管理工具94的请求访问所述元数据82的请求。

数据移动器80依照在元数据82中所指定的存档规则，使数据从诸如本地数据库62之类的数据源移动到档案文件服务器104。在一个实施例中，数据移动器80依照所述规则产生用于移动数据的SQL语句，并且把所述SQL语句传递到查询处理器64用于执行。在另一实施例中，元数据82被存储在本地数据库62中的至少一个数据库表中。在此实施例中，数据移动器80还经由查询处理器使用SQL语句来访问元数据82。作为选择，当元数据82被存储在阵列或文件中而不是被存储在数据库表中时，数据移动器80直接访问所述元数据82。在另一实施例中，元数据82包括数据库表(一个或多个)、阵列(一个或多个)、文件(一个或多个)和配置参数(一个或多个)中的一个或其任何组合。

还参照图3，元数据82包括规则集84、配置信息86以及监控、审核和统计信息88。在任何给定时间，元数据统计信息都反映了存在存档规则的数据的位置。在一个实施例中，数据移动器80通过直接更新RDBMS目录，来在每次数据移动之后更新元数据统计信息。在某些实施例中，查询处理器64访问元数据82，以确定是否有满足查询的参数的任何数据被存储在档案文件服务器104中，并且确定所述数据的位置。

规则规定了要存档什么以及何时把数据移动到档案文件存储系统。例如，规则可以涉及商业销售的完成日期或从“打开”改变到“已完成”的订单状态。据此移动对应于这些商业对象、“销售”和“订单”的数据库行。例如，把ORDER表中的对于列“状态”具有值“已完成”的行移动到档案文件存储装置。在另一例子中，规则可以规定：根据在商业对象的一个基础表中的时间戳列，诸如包含完成销售的数据的列，在九十天之后把数据移动到档案文件存储装置。在又一例子中，联合档案文件RDBMS向本地数据库应用以下保留(retention)规则：

每个午夜，移动在90天以前结束的所有ORDERS。

除数据移动准则之外，以上规则还规定了调度信息，即何时移动数据。每个午夜，数据移动器把本地数据库中的在当前日期的九十天前结束的ORDER表中的数据移动到联合档案文件存储系统。

在管理控制台106处的系统管理员使用管理工具94来配置元数据82以便进行联合存档。使用管理工具94来规定用于存档数据和配置参数(如果有的话)的规则。在一个实施例中，当元数据82被存储在数据库表中时，管理工具104产生用于访问元数据82的查询，并且向查询处理器64发送该查询用于执行。在替换实施例中，当元数据82或部分元数据没有被存储在数据库表中时，管理工具84直接地而不是通过使用查询处理器64来访问所述元数据82。

档案文件服务器104包括档案文件存储系统108，并且与档案文件包装器68通信，以便向档案文件数据库表(一个或多个)110写入数据并且从中检索数据。在一个实施例中，档案文件存储系统108是关系数据库管理系统。在另一实施例中，档案文件存储系统是不相关数据存储系统。

档案文件存储系统108包括例如CDROM之类的光学存储装置、磁带存储装置、硬盘、分级存储系统和数据库管理系统中的任何一个或其组合。在另一更具体的实施例中，档案文件存储系统是

Tivoli存储管理器(Storage Manager)。

因为档案文件存储系统108被联合到所述联合档案文件RDBMS60中，所以档案文件存储系统中的数据可经由数据库联合来访问，所述数据库联合使所存档的数据看起来好像该数据仍然存在于本地数据库中一样。联合档案文件RDBMS透明地判定是否访问所存档的数据。可以使用SQL语句来访问数据；并且单个SQL语句可以聚集来自档案文件存储系统108和本地数据库62的数据。

下面将进一步地详细描述联合档案文件RDBMS的组成部分。现在将描述查询语义。

查询语义

由查询处理器处理来自应用的查询。在某些实施例中，查询处理器还处理来自数据移动器和管理工具的查询。查询处理器具有用于接收来自应用的查询(以及在某些实施例中，还接收来自数据移动器和管理工具的查询)的查询接口。在一个实施例中，查询接口包括一个或多个SQL语句。在替换实施例中，查询接口使用可扩展标记语言(XML)。

现在将描述用于实现查询处理器的不同实施例，其中所述查询处理器用于联合存档以便支持SQL查询接口。可以使用以下中的至少一个或其组合来实现查询接口：

1.在绰号上的视图(views over nicknames)；

2.表函数；

3.系统配置参数(一个或多个)；

4.用于规定时间范围的SQL语言扩展部分；和

5.查询处理器确定是否依照存档规则集来访问联合档案文件。

在某些其它的实施例中，还提供了对于查询处理器的命令行和图形查询接口以便检索数据。命令行和图形查询接口在上面所列出的SQL查询接口的实施例上进行操作。

以上的某些实施例允许应用指定用于检索数据的时间间隔。在上面的替换实施例(2)和(4)中，查询指定了时间间隔，并且下面将对其进行进一步详细描述。为了避免在应用中修改查询，在实施例(3)中，使用配置参数来确定怎样对查询进行联合；并且在实施例(5)中，查询处理器的另一实施例自动确定是否依照存档规则集来访问联合档案文件。

不同的查询接口可以一起操作。可以结合其它查询接口一起使用每个查询接口。例如，配置参数(3)可以和表函数(2)和SQL扩展(4)一起使用。在绰号上的视图(1)可以与SQL扩展(4)以及查询处理器确定是否访问联合档案文件(5)一起使用。

联合档案文件RDBMS使得能够精细地指定存档哪些数据对象。一个数据对象对应于数据库中的一行或一组相关行。在某些实施例中，存档规则识别在这些行之间的关系。在一个实施例中，可以存档的最小数据库元素是包括关键词的一行的子集。例如，雇员记录包含姓名、标识符、年龄和薪水各列。联合档案文件存储标识符和薪水的值，并且把其它列存储为空(NULL)值。当存档一行时，从数据源中删除该行。

下面描述了怎样使用示例性的RDBMS、IBM DB2信息整合器来提供联合。然而，本发明并不意味着局限于IBM DB2信息整合器，并且可以使用提供联合能力的其它RDBMS。在下面的描述中，示例性的档案文件存储系统是另一关系数据库管理系统。

图5描绘了用于创建档案文件系统的绰号并且执行查询的实施例的流程图。在步骤120，创建服务器映射。特别地是，在本地数据库中创建服务器对象。在步骤122，创建档案文件对象到本地关系数据库管理系统中的本地模式(schema)和绰号的映射。在给定了用于在本地数据库中指定特定表的存档规则的情况下，联合档案文件RDBMS在档案文件存储系统中创建具有与该特定表兼容的结构的表或重新使用该表。绰号被映射到档案文件存储系统中的数据库表，该数据库表用于进行存档。在替换实施例中，绰号映射到其它数据对象，诸如文件存储系统中的文件、电子表格文件、平面文件、XML文档或不相关的档案文件，该其它数据对象可以被用作为档案文件的数据源或者被用作为档案文件。在步骤124，使用绰号来访问档案文件存储系统中的表。

现在将描述用于创建包装器、服务器对象、模式和绰号的更详细的例子。包装器是用于把档案文件存储系统中的表的数据类型映射到绰号的本地定义中的数据类型的组件，其透明地说明了系统之间的差异。在某些实施例中，可以利用所谓的“create wrapper(创建包装器)”的DB2命令来创建包装器。例如，如下所示创建被称作DRDA 的包装器：create wrapper DRDA。

服务器对象表示可以为其创建绰号的联合数据源或目标。使用所谓的“create server(创建服务器)”的DB2数据定义语言命令来创建服务器对象。例如，创建服务器命令如下所示创建被称作UDB的服务器对象：

create server UDB type DB2/UDB VERSION 8.1

WRAPPER DRDA

OPTIONS (Node ‘ARCHIVE’，

DBNAME‘ARCHIVEDB’，

FOLD_ID‘L’，

FOLD_PW‘L’，

PASSWORD ‘Y’)。

绰号是用于提供远程数据对象的本地定义的数据库对象，其用于把远程数据对象映射到关系。绰号是用于远程数据集的代理，所述远程数据集可以被映射到本地表定义，并且经由用于特定服务器的包装器进行访问。当档案文件存储系统是另一RDBMS时，远程数据对象是档案文件存储系统中的表，并且看起来好像是联合档案文件RDBMS中的本地表一样。例如，被称作ORDERS的本地表包含采购订单。下面的表1示出了本地表ORDERS中的示例性记录，其具有列名和相关联的数据类型(列名：数据类型)。

表1：示例性的记录

表1

如下所示创建模式名以指定表或视图所属的模式：

create schema ARCHIVE。

假定表存在于档案文件存储系统中，并且使用DB2信息整合器命令，在上述创建包装器和创建服务器命令中引用档案文件存储系统中的表的绰号，并且使用上面所创建的模式，对于表1中的ORDERS表，如下所示由“create nickname(创建绰号)”命令来创建绰号：create nickname ARCHIVE.ORDERS for UDB.ARCHIVE.ORDERS。

第一参数“ARCHIVE.ORDERS”是绰号。第二参数“UDB.ARCHIVE.ORDERS”是远程对象名。远程对象名具有三个部分：数据服务器名、模式名和远程表名。数据服务器名用于指定在创建服务器语句中所分配的数据源，例如“UDB”。模式名用于指定表在远程系统上的所有者，例如“ARCHIVE”。远程表名用于指定表或视图的名称或别名，例如“ORDERS”。

下面的表2描绘了响应于上面的创建绰号语句而创建的示例性绰号定义。

表2：示例性绰号定义

表2

绰号ARCHIVE.ORDERS看起来像本地表一样，但是涉及远程数据，或者在替换实施例中，其涉及甚至可能并未被存储在关系数据库中的数据。

用户可以通过在相对于本地数据库的查询中指定此绰号，来从档案文件中检索数据。例如，使用ORDERS表和上面为所述ORDERS表所创建的绰号，下面的SQL选择语句只返回本地数据库中的未存档的订单：

select^＊from ORDERS。

在另一例子中，下面的SQL选择语句明确地指定了ARCHIVE.ORDERS的绰号，并且返回来自档案文件存储系统的存档了的订单：

select^＊from ARCHIVE.ORDERS

在又一例子中，如下所示，下面的SQL选择语句从本地数据库中的订单表以及档案文件存储系统中的相关联表中检索价格值，并且向查询的结果应用求和函数，其中所述相关联的表由绰号archive. orders引用：

select sum(orders.price+archives.orders.price)

from orders，archive.orders。

另外，数据移动器使用绰号把数据从本地数据库中的OEDERS表移动到档案文件存储系统中的相关联表。

对于具有至少一个相关联数据移动规则的每个表而言，取决于实施例，联合档案文件RDBMS具有档案文件存储系统的绰号、合并(union)视图和表函数中的一个或其组合。这些数据库对象用与源表相同的名称创建，但是处于用户可以提供的不同数据库模式下。绰号的默认模式名是档案文件服务器名；至于视图和表函数，默认模式名是系统默认值，例如“IBMFA”。

下面示出了一些示例性的数据库对象。名为“SALES”的本地表具有custid、closedate和price各列。在此例子中，下面的表3示出了对于SALES表的closedate列的存档规则。

表3：示例性的规则

表3

源表：	SALES(custid，dosedate，price)
		规则：	“移动closedate＞1年的行”

联合档案文件RDBMS在包含档案文件存储系统的档案文件服务器上创建以下对象。在此例子中，档案文件存储系统是关系数据库管理系统，并且创建档案文件表。下面的表4示出了在档案文件服务器上所创建的示例性对象，即档案文件表。

表4：在档案文件服务器上创建的对象

表4

对象类型	所创建的对象的名称	描述
			档案文件表：(创建或使用现有的表)	ARCHIVE.SALES(custid， closedate，price)	向其中存储所存档的行的对象。在此实施例中，对象是表；作为选择，对象是分级存储管理系统中的文件。

[0123] 下表、即表5描绘了使用用户提供的数据库模式名称“ARCHIVE”在联合档案文件RDBMS中创建的对象。

表5：在联合档案文件RDBMS中创建的对象

表5

对象类型	所创建的对象	描述
			WRAPPER (包装器)	名称取决于档案文件类型。例如，‘DRDA’是支持使用任何DB2系列数据库作为档案文件介质的包装器。	提供了用于从一种类型的档案文件介质透明地检索并访问数据的代码。每种类型档案文件服务器一次地创建包装器。
SERVER OBJECT(服务器对象)	ARCHIVE	识别一个档案文件服务器。每个档案文件服务器一次地创建所述服务器对象。
			NICKNAME(绰号)	ARCHIVE.SALES (custid，closedate， price)	把本地表映射到其远程档案文件介质。
VIEW(视图)	IBMFA.SALES(custid， closedate，price)	来自本地表的数据与来自档案文件的数据的合并(union)。
			TABLE FUNCTION(表函数)	ARCHIVE.SALES (goback time，time unit) return table (custid integer，closedate time， price decimal(10，2))	如果需要并且当需要时，从档案文件中检索数据。

在某些实施例中，可以不创建VIEW和TABLE FUNCTION对象。

通过使用联合，应用可以显式地访问存档数据和本地数据，使用绰号把本地数据归并(merge)到存档数据，并且发布相对于所述绰号的查询。

在绰号上的视图

图6描绘了用于创建视图以便访问档案文件存储系统的实施例的流程图。视图是可以在绰号上直接创建以便归并本地数据和存档数据的另一数据库对象。在图6中，步骤130与图5的步骤122相同，并且不再进一步描述。在步骤132，在本地数据库中的表和绰号上创建视图，以便归并本地数据和存档数据。例如，以下的创建语句创建一个被称作ORDERS_PAST_7YEARS的视图：

create view ORDERS_PAST_7YEARS(custid，closedate，price)as

SELECT custid，closedate，price

FROM ARCHIVE.ORDERS

UNION ALL

SELECT custid，closedate，price

FROM USER1.ORDERS；

在步骤134，相对于视图进行查询。例如，应用可以如下所示相对于视图ORDERS_PAST_7YEARS发布查询：

select^＊from ORDERS_PAST_7YEARS。

以上查询返回来自本地数据库和联合档案文件存储系统中的少于七年的所有订单。

在另一例子中，当从视图中进行选择时，用户还可以指定“FETCH FIRST 5 ROWS ONLY(只取前5行)”，这由查询处理器的查询优化器部分来考虑，以便确定并选择最优的执行计划。查询优化器还能够在谓词(predicate)指定索引时避免访问档案文件存储装置，对于所述索引，所述查询优化器可以访问元数据中的统计信息。例如，假定被称作closedate的列上的索引，而且假定相对于视图ORDERS_PAST_7YEARS进行以下查询：

select^＊from ORDERS_PAST_7YEARS

where closedate＞current date-3months。

以上查询返回在前三个月结束的所有订单。在替换实施例中，当进行查询时，查询优化器访问在元数据中所存储的统计信息，并且根据所述统计信息，确定不会访问档案文件存储系统，这是因为，所述档案文件存储系统不包含在前三个月内结束的任何订单。

SQL语言的扩展部分

在另一实施例中，对SQL语言进行扩展以便指定时间范围。查询接口允许用户对于将要检索的存档和未存档数据、指定相对于当前时间的时间间隔，即谓词。换句话说，查询接口允许用户在时间上进行“追溯(go back)”。在此实施例中，在默认情况下，没有任何谓词的查询只返回未存档的数据，因此，希望在结果中包括所存档数据的应用要指定在时间上将向前追溯多久来应用查询。在另一实施例中，查询接口还允许查询设置用于从档案文件中检索数据的时间量的上限，即指定“在N秒之后停止”(“STOP AFTER”N seconds)。

下面的表6示出了使用“追溯”扩展的示例性SQL查询，以及根据这些查询可能会返回的结果。对于表6中的例子，联合档案文件RDBMS具有两个联合档案文件存储系统和规则集。第一规则规定了在九十天之后把数据从交易表移动到第一档案文件存储系统。第二规则规定在一年之后把数据从第一档案文件存储系统移动到第二档案文件存储系统。第三规则规定了在七年之后从第二档案文件存储系统上删除数据。

表6：使用“追溯”扩展的示例性SQL查询和结果

表6

查询	结果
		select trades for user ‘user1’	返回过去90天的交易： ·从本地数据库中选择(在下述的另一实施例中，还可以使用配置设置以便在结果中包括存档数据)。
select trades for user ‘user1’go back 1 year	返回过去一年的交易： ·结合(join)来自第一档案文件存储系统和本地数据库的数据。
		select trades for user ‘user1’go back 7 years	返回过去多达7年的交易： ·结合来自本地数据库、第一档案文件存储系统和第二档案文件存储系统的数据。
select trades for user ‘user1’go back 8 years	错误：“数据不可得到”
		select trades for user ‘user1’go back 2 years fetch first 50 rows only	返回所找到的多达2年的前50个交易： ·按要求结合数据源——应用渐进搜索：首先搜索本地数据库。如果没有找到所指定的行数，那么搜索第一档案文件存储系统。如果没有找到所指定的行数，那么搜索第二档案文件存储系统。 ·搜索次序是基于存在存档规则的列的，例如，如果规则是‘closedate＞90天’，那么按照closedate 对前50行进行排序。
select trades for user ‘user1’go back 7 years fetch first 50 rows only	返回在30秒内所找到的内容。同时搜索本地数据库和档案文件，继而归并结果；只返回50行。
		stop after 30seconds
update trades set price＝50.0where price＝100.0and ticket＝‘IBM’go back oldest	在所有可访问的可写档案文件中，更新交易表中所有合格的行。(例如，可以在2/1分股(stock split) 之后更新档案文件中的参考金融数据)。

在另一实施例中，“追溯”扩展具有表范围和时间间隔作为自变量。

在一个实施例中，“追溯”扩展适用于整个查询，即所有表。作为选择，对于每个表在查询中独立地指定“追溯”扩展。例如，以下查询只把“追溯”扩展应用于订单表：

select c.customer_name，o.number，o.info-客户的所有订单信息

from orders o go back 5 years，-自过去5年起

customers c-但是，只有当客户尚未被存档时才如此

where c.cust_name＝‘user1’and

c.cid＝o.cid。

图7描绘了用于使用SQL扩展来进行查询的实施例的流程图。在步骤140，查询处理器接收具有SQL扩展的查询来访问联合档案文件存储系统。在一个实施例中，所述SQL扩展是上述的“追溯”扩展。在步骤142，查询处理器确定是否有满足查询的任何数据被存储在联合档案文件存储系统中。查询处理器检索元数据，特别是统计信息。根据所述统计信息和与“追溯”扩展相关联的时间间隔，查询处理器确定是否有满足查询的任何数据被存储在联合档案文件存储系统中。如果是的话，那么在步骤144，查询处理器改写所述查询，以便访问本地数据库和联合档案文件存储系统。利用子查询来增强查询，以便包括来自联合档案文件存储系统的数据。在步骤146，查询处理器执行所述查询，以便检索满足所述查询的数据子集。在步骤148，查询处理器返回满足所述查询的数据子集(如果有的话)。

如果在步骤142中查询处理器确定没有满足查询的数据被存储在联合档案文件存储系统中，那么在步骤146中执行所述查询。

表函数

在另一实施例中，可以使用表函数来实现查询接口和查询处理器功能。表函数是利用编程语言(例如C编程语言)所编写的用户定义的函数，其包括SQL调用并且返回0到N行。表函数根据由这些函数的调用者所提供的追溯自变量来透明地结合存档和未存档数据。所述函数根据元数据和表函数自变量，确定在哪里以及什么时候需要联合。

图8描绘了使用表函数来进行查询的实施例的流程图。在步骤160，创建至少一个表函数。在步骤162，查询处理器接收具有表函数的查询。例如，假定被称作“myarchive.orders”的表函数具有值和时间单位作为自变量。以下示出了调用表函数并且传递值和时间单位自变量的示例性SQL语句：

select sum(price)from table(myarchive.orders(80，days))

as t

在上面的例子中，表函数myarchive.orders(80，days)从档案文件存储系统中请求过去八十天的ORDERS。

在步骤164，查询处理器使用表函数进行查询。所述表函数产生重组的(reformulated)查询，以便访问本地数据库和联合档案文件存储系统，并且发布所述重组的查询。特别地是，表函数改写所述查询以便包括绰号，并且联合档案文件RDBMS进行访问。在步骤166，返回由查询所检索的数据(如果有的话)。

可以使用表函数来在所述数据上创建视图。例如，利用如下所示的表函数来通过过去五年的数据创建视图：

create view ORDERS_PAST_5YEARS(custid，closedate，price)as

SELECT^＊from TABLE(myarchive.orders(5，years)))as t。

在另一例子中，为了指定要检索的行数目，把用于指定行数目的附加自变量传递给表函数。例如，为了取出前N行，如下所示调用表函数myarchive.orders：

select sum(price)from table(myarchive.orders(90，days，10))

as t

在上面所引用的表函数myarchive.orders中，前两个自变量与先前例子中的相同。最后的自变量10指定了要检索的行数目。此查询返回它从本地数据库或联合档案文件存储系统中所找到的前10个订单。

在又一实施例中，表函数还可以在已经过去了所指定的时间量之后返回，所指定的时间量可以作为自变量传递给表函数。

配置参数

在另一实施例中，使用配置参数来确定怎样对查询进行联合。在此实施例中，应用不知道正从档案文件中检索信息。在一个实施例中，至少一部分的配置参数是元数据的配置信息的一部分。作为选择，配置参数被至少部分地存储作为RDBMS目录的一部分。在一个特定的实施例中，RDBMS或数据库的配置参数被存储在DB2目录中或存储在工具的目录中。在另一替换实施例中，至少一个配置参数是运行时间变量。

例如，在一个实施例中，由系统管理员经由数据库系统配置来控制要应用到查询的时间间隔，并且所述时间间隔作为配置信息被存储在元数据中。因此，应用可以访问档案文件数据而不需要对其进行修改。可以使用系统、会话、应用或查询级配置参数来实现对联合档案文件的透明访问。

图9描绘了使用至少一个配置参数来进行查询的实施例的流程图。在步骤170，对至少一个配置参数进行初始化。例如，配置参数指定怎样对SQL查询进行联合。可以如下所示使用数据库级配置参数来对于所有查询始终允许联合：

db2 update db cfg for myDatabase include_archive MYARCHIVE其中，“MYARCHIVE”是为联合档案文件RDBMS所知的联合档案文件服务器。

在步骤171，查询处理器接收查询。在步骤172，查询处理器检索配置参数(一个或多个)。在步骤173，查询处理器确定是否有满足查询的任何数据被存储在联合档案文件存储系统中。查询处理器检索元数据，特别是统计信息，并且查询处理器根据所述统计信息和配置参数(一个或多个)，确定是否有满足所述查询的任何数据被存储在联合档案文件存储系统中。如果在步骤173中查询处理器确定满足查询的数据被存储在联合档案文件存储系统中，那么在步骤174，所述查询处理器依照配置参数(一个或多个)改写所述查询，以便从本地数据库和联合档案文件存储系统中检索所述数据。作为选择，如果查询处理器确定由查询所检索的数据未被存储在本地数据库中，那么依照配置参数(一个或多个)来改写所述查询，以便只从联合档案文件存储系统中检索所述数据。在步骤175，查询处理器执行所述查询。在步骤176，查询处理器返回所述数据(如果有的话)。

如果在步骤173中查询处理器确定没有满足所述查询的数据被存储在联合档案文件存储系统中，则查询处理器进行到步骤175，以便执行所述查询。

在上述示例性的“db2 update db cfg...”语句中的配置参数，改变对于所有应用对这个数据库的一般SQL查询的行为，以便从本地数据库和档案文件存储系统(一个或多个)中返回数据。例如，当执行下列SQL语句：

select^＊from orders where user＝‘user1’时，从本地数据库和被称为MYARCHIVE的档案文件存储系统中返回订单。

在一个替换实施例中，使用视图来聚集来自本地数据库和档案文件存储系统的数据。如上所述，创建本地表和对于联合档案文件存储系统中的表的绰号的UNION VIEW(合并视图)。这个合并视图存在于不同的模式下。

在又一实施例中，附加的配置参数可以通过设置最大的查询时间来限制检索的时间。

在另一实施例中，配置参数(一个或多个)规定：“对于所有查询始终读取本地数据和存档数据”。作为选择，另一个配置参数可以规定时间范围。

使用配置参数，允许现有的应用访问存档的数据，而不需要对应用进行改变。此外，如果例如在数据库级规定了配置参数，则该配置参数影响所有使用该数据库的应用。

在另一实施例中，注册表变量(另一类型的配置参数)被用来请求各级联合。在一个应用内规定注册表变量，以便请求关系数据库管理系统中的仅仅适用于该应用的行为或功能。在一个实施例中，在数据库连接的范围内，使用注册表变量案来请求各级联合，例如，SETARCHIVE_QUERY_TIME 1 year。当对于存在存档规则的列规定具有时间限制的谓词时，查询处理器自动地确定数据的位置、以及是否依据该注册表变量而访问联合档案文件存储系统以便满足所述查询。

查询处理器确定是否要访问档案文件

在还有的另一实施例中，查询处理器确定是否要访问联合档案文件存储装置。在这个实施例中，查询处理器将用户的查询转换为联合查询，以便访问档案文件存储系统。在一个替换实施例中，查询处理器包括为每个存档的表所产生的一组表函数和/或一组产生的SQL视图。

图10描述了由查询处理器用来访问联合档案文件存储系统的技术的实施例的流程图。在步骤180，查询处理器接收查询。在步骤182，查询处理器分析所述查询，以便识别哪些列构成了谓词。步骤184确定是否有任何规则引用谓词中的列。如果是的话，则在步骤186，对于谓词中的存在规则的每一列，查询处理器确定本地数据库中所存储的最陈旧的行，并且确定该行的位置，即确定该行是被存储在本地数据库中还是被存储在联合档案文件存储系统中。特别地，用于数据的位置的元数据取决于列类型。在一个实施例中，如果所述列是有序的单调递增型的列，例如，时间戳，并且如果对于该列存在诸如“当超过三个月以上时存档”之类的规则，则在元数据统计信息中跟踪还没有被存档的最陈旧的数据。在移动数据时，数据移动器使查询处理器用最陈旧的值更新元数据。

在步骤188，查询处理器通过用子查询增强所述查询，来改写所述查询，其中所述子查询对于在所述查询中引用的表名规定了档案文件存储系统的绰号。在步骤190中，查询处理器执行所述查询。在步骤192中，查询处理器返回数据(如果有的话)。

如果步骤184中确定没有规则引用谓词中的列，则查询处理器继续到步骤190，以便相对于本地数据库进行查询。

例如，查询处理器可以如下确定查询的数据的位置：

SELECT^＊from trades where trades.closedate＞‘01-01-97’。

如果执行查询的年份是2003年，并且如果存在有关“closedate”的存档规则，诸如“存档结束1年以上的任何交易”，那么查询处理器访问联合档案文件，以便检索可能被存储的任何数据。在此例子中，联合档案文件RDBMS在向应用返回结果之前，把来自本地数据库的交易与从档案文件存储系统所检索的数据透明地组合。

在另一例子中，假定有关closedate的以下存档规则：

当对于过去90天，closedate为空值时移动销售，

以及下列元数据统计信息：

在服务器：‘MYARCHIVE’上对于closedate：‘2003年9月30日’所存档的最高值。

在2004年1月1日发布以下查询：

select sum(qty)from sales

where closedate＝(current data-1 year)(其中closedate＝(当前日期-1年))。

查询处理器读取元数据，以便确定是否将要访问联合档案文件。如果在过去一年里没有数据被移动到档案文件，那么查询处理器将会确定不访问联合档案文件。

在另一例子中，查询处理器改写查询，以便使用其绰号来访问档案文件存储系统。查询处理器接收以下查询：

select from orders

where status＝‘closed’and closedate＜1995(其中状态＝‘结束’并且closedate＜1995)。

对于closedate和状态列的规则如下：

规则1：closedate-

在2年之后移动到第一档案文件存储系统；

规则2：状态-

在90天时移动到第二档案文件存储系统。

第一档案文件存储系统中的表与被称作archiveA.orders的绰号相关联，并且第二档案文件存储系统中的表与被称作archiveB.orders的绰号相关联。此查询会在本地数据库以及第一和第二档案文件存储系统的表之间进行3种方式的结合。查询处理器把此查询改写为：

select from orders where status＝′closed′

UNION ALL

select from archiveA.orders where status＝′closed′

UNION ALL

select from archiveB.orders where status＝′closed′

依照这种方式，从本地数据库、第一档案文件存储系统和第二档案文件存储系统中透明地检索数据。

更新存档数据

在另一实施例中，联合档案文件RDBMS使得能够更新所存档的数据。例如，在金融市场应用中，在分股之后，尽管可能已经存档了额度(positions)和持有股份(holdings)，但是可能也需要更新该数据。经由联合档案文件RDBMS发布更新，以便联合档案文件RDBMS可以适当地更新元数据。某些更新还可能影响是否把数据从档案文件带回到本地数据库。例如，当数据是正确的时，可以把所述数据返回到本地数据库。如果用户把“closedate”从“九十天以前”改变到“当前日期”，并且如果存档规则规定当“closedate”大于或等于九十天时将存档数据，那么受该改变所影响的任何数据会被从档案文件存储系统中移动并且被返回到本地数据库。

监控和审核

联合档案文件RDBMS提供了关于数据移动的审核追踪(audittrail)。审核追踪可以被写入文件和/或存储在数据库表中。例如，在一个实施例中，联合档案文件RDBMS将对于相关表中的每个表来说所移动的行数目以及所应用的规则记入日志。在另一实施例中，审核追踪以及所应用的规则和所移动的行数目的日志记录是元数据的监控、审核和统计信息的一部分。

数据移动器

如上所述，数据移动器依照用户定义的规则集来移动数据，所述规则集反映了应用语义和/或数据之间的关系。当数据正被移动时，所述应用可以查询联合档案文件RDBMS，并且向应用提供一致的视图。所述查询返回给定行一次且只有一次，即便该行当前正被存档也是如此。存档一行，指的是把一行拷贝到档案文件存储系统中，继而从该行的数据源中物理地删除该行。数据移动器将数据在审核追踪中的移动以及在元数据中的新位置记入日志，所述元数据由查询处理器访问，以便确定数据的位置以及联合档案文件存储系统是否被访问以满足所述查询。

可以使用两种技术来移动数据。在第一种技术中，在单个事务处理中将数据拷贝到档案文件存储系统并且从数据源中删除。在第二种技术中，在第一事务处理中将数据拷贝到档案文件存储系统，继而在第二事务处理中更新元数据以反映所述数据的新位置，并且从数据源上删除所述数据。

图11描绘了在移动数据的过程中由数据移动器使用的第一种技术的实施例。在步骤200，数据移动器读取规则。在步骤201，数据移动器产生移动查询(move-query)(在一个实施例中，其包括一组SQL语句)，以便依照所述规则把数据从至少一个数据源移动到档案文件存储系统。在步骤202，数据移动器使查询处理器启动在联合档案文件RDBMS和档案文件存储系统之间的两个阶段的提交(commit)事务处理。在某些实施例中，由联合档案文件RDBMS隐式地提供两个阶段的提交处理。在步骤203，数据移动器向查询处理器发送所述移动查询。查询处理器执行所述移动查询，以便把数据从数据源(一个或多个)拷贝到联合档案文件存储系统，并且从所述数据源(一个或多个)中删除所述数据。在步骤204，数据移动器更新元数据以便反映所述数据的新位置。在一个实施例中，当元数据被存储在数据库表中时，数据移动器通过查询处理器来更新所述元数据。在步骤205，数据移动器利用用于描述所移动数据的统计信息来更新元数据。在步骤206，数据移动器使查询处理器执行事务处理的提交。在替换实施例中，最初执行步骤200和201以便产生移动查询，并且每当数据移动器执行时，执行步骤202到206。

第一种技术防止行在例如本地数据库和档案文件存储系统之类的两个数据源中同时出现。在任何给定时间，数据看起来存在于一个且只存在于一个位置中。为了在使用两个阶段的提交来移动数据时使争用最小化，按照少量数目来移动行。在一个实施例中，“子秒(sub-second)”是使数据移动器保持本地数据库上的任何锁定所允许的时间量的准则。对于非常大的存档任务，诸如存档过去一年的数据，提供了脱机快速存档模式。在脱机快速存档模式中，本地数据库被停止，并且使用输出、加载和删除来移动数据。

图12描绘了由数据移动器用来移动数据的第二种技术的实施例。在步骤210，数据移动器读取规则。在步骤211，数据移动器产生拷贝查询(copy-query)，以便依照规则从数据源(一个或多个)中拷贝数据并且把该数据写入档案文件存储系统，并且还产生删除查询(delete-query)，以便从所述数据源(一个或多个)删除所拷贝的数据。在步骤212，数据移动器使查询处理器开始数据库事务处理。在步骤213，在一个实施例中，数据移动器向查询处理器发送拷贝查询；并且所述查询处理器执行所述拷贝查询，以便把数据从数据源拷贝到联合档案文件存储系统。在步骤214，数据移动器使查询处理器执行事务处理的提交。在步骤215，数据移动器开始与查询处理器的另一数据库事务处理。在步骤216，数据移动器更新元数据，以便反映所述数据的新位置。在其中元数据被存储在数据库表中的一个实施例中，数据移动器向查询处理器发送SQL语句，以便更新所述元数据。在步骤217，查询处理器执行删除查询，以便从数据源(一个或多个)删除所移动的数据。在一个实施例中，数据移动器向查询处理器发送所述删除查询以供执行。在步骤218，数据移动器使查询处理器执行第二事务处理的提交。在另一实施例中，最初执行步骤210和211，并且每当数据移动器执行时，执行步骤212到218。

第二种技术被用于其中查询处理器通过检查元数据来确定是否存档数据的实施例。在第二种技术中，将对于联合档案文件RDBMS的查询路由到查询处理器，以便访问规则，从而确定数据的位置。第二种技术消除了争用，这是因为，对于依照规则集来更新元数据中的数据映射所要求的持续时间，使用了锁定。

数据移动器经由元数据与查询处理器通信。元数据反映了联合档案文件RDBMS的当前状态。例如，如果用户选择“sum(sales)whereclosedate between＜‘1999-01-01.00.00’and‘2000-12-31.00.00’”(即，在1999年结束的所有销售的总和)，那么在假定该谓词和已知例如在‘1999-06-01’之前已经存档了数据的情况下，查询处理器自动搜索联合档案文件存储系统。数据移动器维护关于数据的统计信息，其中所述数据按照规则级移动。对于上面的示例性的“sum(求和)”语句，如果规则根据“closedate”列中的值来存档数据，那么查询处理器访问元数据，以便确定被称作“closedate”列的最大值。统计信息作为元数据的一部分被存储在联合档案文件RDBMS的本地表中。

在一个实施例中，每当数据依据与删除/插入对相同的同步点被移动时，数据移动器就更新元数据。依照这种方式，查询处理器可以在任何给定时间准确地确定所述数据的位置。此实施例还利用档案文件存储系统来使用两个阶段的提交。

数据移动器可以在任何时间被停止并重新开始。数据移动器在获取新的存档规则时被停止并重新开始。

在一个实施例中，数据移动器连续地执行。当连续地执行时，“commit_interval”自变量确定数据移动器多长时间应用一次用于选择移动哪个数据的规则。利用中断来停止数据移动器的执行。

作为选择，在“过去(one-time)”模式中启动数据移动器。在“过去”模式中，数据移动器应用用于选择所要移动的数据的规则一次，移动所述数据，更新元数据，然后停止。

元数据

元数据指的是在联合档案文件RDBMS的不同组件之间共享的一组控制表。元数据存在于联合档案文件RDBMS中。元数据包括存档规则、配置信息以及审核、监控和统计信息。在一个实施例中，使用联合档案文件RDBMS中的表来实现存档规则、配置信息以及审核、监控和统计信息。

配置信息包括用于数据移动器的参数，并且在某些实施例中还包括用于注册表变量的缺省值。在另一实施例中，某些配置信息被存储在关系数据库管理系统的数据字典中。

审核、监控和统计信息由数据移动器使用，并且在某些实施例中，该信息由查询处理器的查询优化器使用，以便确定数据的位置以及是否会访问联合档案文件存储系统。在一个实施例中，对于每个档案文件服务器的每个规则中所指定的每个列，将审核、监控和统计信息存储在表中。

例如，在另一实施例中，为存在存档规则的每一列维护统计信息。下面的示例性的表FEDARC_STATS如下所示维护统计信息：

表FEDARC_STATS：

对于对其进行排序并且其中以“大于或等于”谓词(例如，closedate＞当前日期＝3个月)来表示规则的范围列：

列：

SCHEMA_NAME

TABNAME

COLNAME

TARGET_ARCHIVE_SERVER：

TARGET_ARCHIVE_NICKNAME

LAST_ARCHIVE_TIME

HIGHKEY-在此档案文件服务器上对于此列所存在的最高值

LOWKEY-在此档案文件服务器上对于此列所存在的最低值

LOWKEY和HIGHKEY是互斥的。

对于相等列，其定义了一个集合(例如，customer_status和诸如“当可用性＝‘Discontinued(中止)’时存档”之类的规则)：

RULE_VALUE＝Discontinued

TARGET_ARCHIVE_NICKNAME。

对于相等列，如果RULE_VALUE值不是NULL，那么数据已经被移动了。如果RULE_VALUE值是NULL，那么数据被存储在本地数据库中。

在另一实施例中，元数据包括下列在指定模式下所创建的一组控制表：

1.FEDARC_CONFIG-包括用于系统的配置参数

2.FEDARC_RULES-包括例如规则名称、表模式、表名、列名、规则和保留期

3.FEDARC_TABLES-包括存在规则的表的名称和档案文件状态

4.FEDARC_COLUMNS-包括存在规则的列的名称

5.FEDARC_STATS-包括关于存在规则的每个列的统计信息

6.FEDARC_SERVERS-包括档案文件服务器的名称

7.FEDARC_TRACE-包括数据移动的轨迹。

存档规则

规则识别对于给定表要存档的一组行。在一个实施例中，可以存档的最小元素是一行。对于将要存档的每个表，存在至少一个规则。在另一实施例中，对于本地数据库中的所有表，提供了默认规则。

可以对规则进行组合，以便根据不同的数据属性来为相同表的不同子集指定不同的保留期。例如，商业规则可以指定“除非交易是来自优选的客户，否则移动在90天以前结束的任何交易，在所述优选客户的情况下保持所述交易长达1年”。数据移动器可以结合来自不同表的数据以便应用规则。例如，客户的状态(诸如优选状态)不在TRADES表中而是在CUSTOMERS表中，因此结合来自TRADES和CUSTOMERS表的数据。应用规则甚至可以包括查询另一系统以便确定客户状态，例如调用web服务。无论数据可能驻留在何处，联合都提供了一种访问数据的透明方式。在另一例子中，规则引用其它表。商业规则指定“存档已经持续无效(未购买任何东西)达1年以上的任何客户的客户信息”。数据库具有CUSTOMERS表和SALES表。为了实现此规则，可以把CUSTOMERS表中的行与SALES表中的行相结合。

可以经由图形用户接口或命令行接口来指定规则，下面将对其进行进一步详细描述。在一个实施例中，规则被存储在具有内部格式的关系数据库表中，在联合档案文件关系数据库管理系统目录中为了谓词评估而优化所述内部格式，例如将其优化为可直接执行的SQL表述。对于每个表，可以指定规则集。组合所述规则以便确定移动哪些行。在另一个实施例中，修改系统目录以便反映存档规则。

多表规则

规则还可以指定把来自几个表的行存档为一个集合，所述集合被称作“存档组”。这使得能够请求存档那些跨过几个相关表的应用对象。例如，应用客户对象可以包括购买历史记录和简档，并且可以被存储在三个或四个表中。当存档此应用对象时，数据移动器访问这些表，并且根据例如“客户id”来结合数据。例如，存档规则可以如下所示引用几个表：

“存档其中accounts.closedate＞1年的购买、出租”。

使用以上规则，对于已经关闭其帐户一年以上的客户，存档购买和出租。为了满足此请求，使用相关关键词来结合该表。管理工具和命令行接口使用户能够指定每个表中的哪个列被用作相关关键词。

用于存档行的子集的规则

在另一实施例中，存档行的子集。例如，假定本地表具有包含传真的二进制的大的对象，其将被存档在档案文件存储系统中，在该系统中将其存储为文件。用于此表的绰号指定了一个关键词，所述关键词映射到档案文件系统上的索引以便检索包含所述传真的文件。当数据被存档时，在未被定义用于存档的任何列中所存储的数据会被丢失。结果，当查询数据时，在行中可能存在“缺口(hole)”；档案文件存储系统对于在档案文件系统中不存在的列值返回NULL。在此例子中，用户可以检索传真，但是如果在与所述传真相关联的行(诸如购买量)中存在其它值，那么那些其它值将不再是可检索的。

在另一实施例中，存档在表中被引用的文件。例如，如果一个表具有包含文件名的列，那么该行和文件都可以被存档。数据移动器使用SQL来移动表中的值。数据移动器使用例如FTP协议之类的其它手段来移动文件。在此实施例中，包装器支持对远程文件的访问。

规则语法

现在将描述规则语法。下面的表8示出了一些示例性的规则元素。左列是规则元素，而右列是该元素的描述。

表8：示例性的规则元素

表7

规则元素	描述
		源：	·视图或表
目标：	·目标服务器：数据库或联合服务器的名称 ·目标表：表、可更新的视图、绰号或NULL(空)(即，删除数据)
		存档条件：	下列各项的集合： ·谓词：用于评估的条件(例如，状态＝‘结束’) ·保留期：在所述条件为真后保持数据多久(例如，90天) ·时间戳列：可据此计算保留期(例如，closedate时间戳)的列(或者在子句上)，是可选的 ·描述：注释说明所述规则的简短文本
调度：	·当应用所述规则时：连续地，或在具体的(重复)时间，例如每天晚上6:00PM。默认是连续的。

存档条件包括一组谓词，其中每个谓词是用于识别要从表中存档的列和条件的带注释的SQL子句。存档条件还包括保留期、可选时间戳以及可选描述。命令和图形用户接口(GUI)向导可以用来构造语法上正确的谓词，并且在构造时显示产生的组合条件。当添加规则时，系统检验该规则。谓词使得能够进行任意操作。例如，规则可以包括count()，其用于当数据库达到预定大小限制时触发存档。

引用多个表的规则还使用相关列来存储相关关键词。例如，本地数据库具有SALES表和CUSTOMERS表。表9描绘了SALES表，而表10描绘了CUSTOMERS表。

表9：示例性的SALES表

表8

表10：示例性的CUSTOMERS表

表9

以下是存档条件：

1.“除非客户具有优选的状态或者销售在$1000000之上，否则，当closedate超过90天时，把SALES移动到ARCHTVE1”。

2.“把一年以上没有购物的CUSTOMERS移动到ARCHIVE2”。

3.“当表超过5千万行时，移动最陈旧的INVOICES(每月执行一次)”。

4.“当中止时立即把PRODUCTS移动到ARCHIVE3”。

图13示出了包含存档规则集的示例性规则表220，所述存档规则集是根据上面所示出的存档条件产生的。为方便起见，在每一列的顶部示出了列名。在实践中，规则表可以不存储如图所示的列名。规则表220包括规则名称列221、表名列222、谓词列223、相关列224、时间戳列225、保留期列226、调度列227、目标服务器列228和描述列229。作为选择，可以不使用描述列229。

上面的存档条件一由图13中的规则R1、R2和R3来规定。上面的存档条件二由图13中的规则R4规定。上面的存档条件三由图13中的规则R5规定。上面的存档条件四由图13中的规则R6规定。

在图13中，在所述规则中，通过把源表中的列包括在方括号中来注释该列。存档条件的每个子句被指定为独立的规则，以便便于描述复杂的条件。在每个保留期内使用“AND”来组合用于每个本地表的子句，并且对于具有较长保留期的子句利用“NOT IN”。例如，数据移动器可以如下所示使用SQL语句来产生示例性的移动查询：

移动SALES表中的90天的候选项：

-‘移动’从sales s起的行

insert into ARCHIVE1.SALES

select^＊from SALES s

where

-规则R1

(s.closedate is not null and s.closedate＞90days)AND

-将规则R2和R3组合：排除满足具有较长保留期的规则的行

not s.custid in(select c.ckey from customers c

where c.status＝′preferred′)and

price＞1000000)

delete from SALES s

where

-规则R1

(s.closedate is not null and s.closedate＞90 days)AND

not s.custid in(select c.ckey from customers c

where c.status＝′preferred′)and

price＞1000000)

commit

由数据移动器对于365天和5年的规则以及用于INVOICES和PRODUCTS表的规则产生附加的SQL语句。

在图13中，目标服务器列228允许在具有多个档案文件存储系统的那些配置中指定目标档案文件存储系统。当目标服务器是NULL时，将访问预先定义的默认目标服务器，例如ARCHIVE1。

在假定图13中的规则集的情况下，SALES表的最小保留期是一天，而最大保留期是五年。在一个实施例中，如果“追溯”值大于最小保留时间，那么查询会访问联合档案文件。例如，以下的SQL语句指定了等于100天的“追溯”值：

select^＊from sales go back 100 days where c.custid＝101

此选择结合了来自本地数据库和档案文件存储系统的数据，即使custid等于101的客户记录是优选的客户也是如此，其SALES数据不会被移动到档案文件存储装置。

管理和系统接口

管理工具包括用于安装和配置的图形用户接口(GUI)和命令行接口。管理工具可以建立档案文件服务器，例如安装软件组件并创建数据库，配置联合并创建绰号，以及创建元数据。管理工具还通过提供向导和命令以便调查可用的档案文件和功能来帮助程序员使用查询接口。在另一实施例中，还提供了应用编程接口(API)。

命令行接口

在命令行接口中，命令行解释器(interpreter)支持管理命令。在此说明书中，命令行解释器被称作“ibmfa”。使用以下示例性的命令来查询系统对象。“ibmfa list nicknames[server]”命令列出了给定或所有档案文件服务器的绰号。“ibmfa list archives”命令列出了档案文件服务器的名称。“ibmfa list rules [dbname][tabname]”命令返回了用于表或数据库的存档规则的格式化列表。还可以提供用于列出联合视图的命令。另一命令、“ibmfa mover dbname”执行数据移动器。可以如下所示把规则添加到规则表中：

ibmfa addrule archiveName nulename tabschema.tabname.colname pred＝″string″retain＝″duration″desc＝″string″

在另一实施例中，当添加规则时，命令行解释器检验谓词串。

以下规则从规则表中除去规则：

ibmfa droprule archiveName rulename。

在一个实施例中，并不恢复先前依照所除去的规则而存档的数据。

还提供了用于依照规则集根据命令行来从档案文件存储装置检索数据或把数据移动到档案文件存储装置的命令。以下是用于从档案文件存储装置中检索数据的示例性命令：

ibmfa restore localschema.tabname go back 2 years。

上面的示例性的“ibmfa restore...”命令从档案文件存储装置恢复在过去两年内所存档的行，并且把该行重新插入到源表中。例如因为违反引用的完整性限制而不能被重新插入的行，被插入到异常表中。“ibmfa restore...”命令用于在撤消使数据被存档的规则之后使用。

级联的联合档案文件存储系统

图14描绘了级联的联合档案文件存储系统230的实施例。在此实施例中，第一计算机系统232包括第一联合档案文件RDBMS 234，而第二计算机系统236包括第二联合档案文件RDBMS 238。第一联合档案文件RDBMS 234使用所述第一联合档案文件RDBMS 234中的第一绰号240和第一包装器242来与第二联合档案文件RDBMS238进行通信。第一联合档案文件RDBMS 234还包括第一查询处理器244、第一数据移动器246、第一本地数据库248、第一管理工具250和第一元数据252。如以上关于图3所述，第一元数据包括第一规则、第一配置信息以及第一监控、审核和统计信息。第一应用254与第一联合档案文件RDBMS 234通信。第一管理控制台256与第一管理工具250通信，以便更新第一元数据252。

第二联合档案文件RDBMS 238具有第二管理工具260、第二查询处理器262、第二数据移动器264、第二本地数据库266、第二绰号268、第二包装器270和第二元数据272。如以上关于图3所述，第二元数据272包括第二规则、第二配置信息以及第二监控、审核和统计信息。第二包装器270与第二档案文件服务器274通信。第二管理控制台276与第二管理工具260通信，以便更新第二元数据272。

在级联的联合档案文件存储系统230中，可以通过使用上述用于查询处理器的任何实施例和/或技术，来分别实现第一和第二查询处理器244和262，并且可以查询数据。上述关于联合档案文件RDBMS的实施例和技术还可以分别用在第一和第二联合档案文件RDBMS234和238中。另外，上述关于数据移动器、本地数据库、管理工具、管理控制台、绰号(一个或多个)、包装器和元数据的实施例和技术可以被分别实现和/或用在第一数据移动器244、第一本地数据库248、第一管理工具250、第一管理控制台256、第一绰号240、第一包装器242和第一元数据252中。另外，上述关于数据移动器、本地数据库、管理工具、管理控制台、绰号(一个或多个)、包装器和元数据的实施例和技术可以被分别实现和/或用在第二数据移动器264、第二本地数据库266、第二管理工具260、第二管理控制台276、第二绰号(一个或多个)268、第二包装器270和第二元数据272中。档案文件服务器274包括上述任何一个档案文件存储系统。

当存档数据时，第一数据移动器246把第一数据子集经由第一包装器242从第一联合档案文件RDBMS 234移动到第二联合档案文件RDBMS 238。在一个实施例中，第一数据移动器使第一查询处理器向第二联合档案文件RDBMS 238发送用于写入数据的一组SQL语句以及所述数据。在第二联合档案文件RDBMS 238中，第二查询处理器262从第一包装器242接收SQL语句和第一数据子集，并且依照元数据272中的第二规则把第一数据子集存储在第二本地数据库266中。在另一实施例中，第二查询处理器262把第一数据子集存储在第二本地数据库266中，并且第二数据移动器264依照第二元数据272中的规则把至少一部分的第一数据子集移动到档案文件服务器274。

在另一替换实施例中，级联任意数目的联合档案文件RDBMS。例如，第二联合档案文件RDBMS可以被耦合到第三联合档案文件RDBMS，而不是档案文件服务器274。

多个联合档案文件服务器

图15描绘了在异构型环境280中具有多个档案文件服务器的联合档案文件RDBMS的实施例。在计算机系统282中，联合档案文件RDBMS 284包括查询处理器286、数据移动器288、本地数据库290、管理工具292和元数据294。如以上参考图3所述，元数据294包括规则、配置信息以及监控、审核和统计信息。联合档案文件RDBMS284还具有第一、第二、第三和第四绰号300、302、304和306，分别通过第一、第二、第三和第四包装器310、312、314和316与第一档案文件服务器、第二档案文件服务器、第二关系数据库管理系统和文件系统320、322、324和326进行通信。第二关系数据库管理系统324具有包括一个或多个表的数据库328。文件系统326具有至少一个文件330，其可以是例如平面文件或电子表格。应用332通过查询处理器286查询联合档案文件RDBMS 284。在管理控制台334处的系统管理员使用管理工具292来配置元数据294。

在多个档案文件服务器配置280中，可以通过使用上述关于查询处理器的任何实施例和/或技术，来实现查询处理器286，并且可以查询数据。上述关于联合档案文件RDBMS的实施例和技术还可以用在联合档案文件RDBMS 284中。另外，上述关于数据移动器、本地数据库、管理工具、管理控制台、绰号(一个或多个)、包装器和元数据的实施例和技术可以被分别实现和/或用在数据移动器288、本地数据库290、管理工具282、管理控制台334、绰号300-306、包装器310-316和元数据294中。

第一和第二档案文件服务器320和322分别包括第一和第二档案文件存储系统中的任何一个。第一和第二档案文件服务器320和322可以分别使用上述关于图4的档案文件服务器104的任何一个实施例来实现。第一和第二档案文件服务器320和322的第一和第二档案文件存储系统可以分别使用上述关于图4的档案文件存储系统108的任何实施例来实现。

在另一实施例中，第一档案文件服务器320的第一档案文件存储系统包括具有硬盘驱动器存储装置的关系数据库管理系统，而第二档案文件服务器322的第二档案文件存储系统包括光学存储装置。在替换实施例中，第一和第二档案文件服务器320和322的第一和第二档案文件存储系统可以分别包括硬盘驱动器、光学存储装置、磁带存储装置、分级存储系统或文档管理系统。在另一替换实施例中，第一和第二档案文件服务器320和322的第一和第二档案文件存储系统分别可以是如图14中所示的另一联合档案文件RDBMS。在其它实施例中，使用两个以上的档案文件服务器。

在另一实施例中，数据移动器288依照规则从第一档案文件服务器320提取数据，并且把该数据存储在第二档案文件服务器322上。例如，如果第一档案文件服务器320具有大量数据，那么可以通过依照元数据294中的存档规则集从第一档案文件服务器320中提取数据子集并且把它存储在第二档案文件服务器322中，来提供更小的第二档案文件322。

在另一实施例中，规则规定：把不同的数据分别存储在第一和第二档案文件服务器320和322上。例如，第一和第二档案文件服务器320和322可以分别存档来自本地数据库290中的不同表的数据。

在又一实施例中，规则规定：把较陈旧的数据从第一档案文件服务器320移动到第二档案文件服务器322。例如，规则可以规定：在九十天之后把数据从本地数据库290移动到第一档案文件服务器320，而且在一年之后把该数据从第一档案文件服务器320移动到第二档案文件服务器322。

在另一实施例中，数据移动器288依照规则来存档来自至少一个联合数据源的数据。例如，所述规则可以规定：在六个月之后把第二关系数据库管理系统324中的数据移动到第一档案文件服务器320。在另一例子中，所述规则可以规定：在三个月之后把文件330中的数据移动到第一档案文件服务器320。

在又一实施例中，具有多个档案文件服务器的联合档案文件RDBMS 280被级联为图14的第二联合档案文件RDBMS 238。

本发明的联合档案文件RDBMS允许使用关系数据库的应用得到数据存档的好处，诸如更小的数据集以及由此得到改进的应答时间，同时能够访问所存档的数据，就好像所存档的数据存储在本地数据库中一样。应用还可以使用标准SQL，因此能够在相同的SQL查询中组合存档和未存档的数据。数据可以在任何给定时间被查询并看起来好像所述数据存在于单个存储系统中一样，即便当所述数据正被移动或已经被移动了时也是如此。

为了说明和描述的目的，已经给出了本发明的优选实施例的上述描述。其并不是穷举的，并且也不打算把本发明限制为所公开的精确形式。按照上述教导可以进行许多修改和变化。本发明的范围并不受到此详细说明的限制，而是由其所附的权利要求来限制。

Claims

1.一种用于透明地存档在联合档案文件关系数据库管理系统中的一个或多个第一数据源中所存储的数据的方法，包括：由第一数据移动器依照第一规则集把第一数据子集从所述一个或多个第一数据源移动到第一档案文件存储系统；

其中，所述第一档案文件存储系统通过接口耦合到所述联合档案文件关系数据库管理系统；

所述联合档案文件关系数据库管理系统还包括查询处理器，所述查询处理器能够直接访问所述联合档案文件关系数据库管理系统中的一个或者多个第一数据源，且所述查询处理器使用绰号访问所述第一档案文件存储系统；所述绰号映射到所述第一档案文件存储系统中的档案文件对象或者远程表。

2.如权利要求1所述的方法，还包括：由所述第一数据移动器依照所述第一规则集把第二数据子集从所述第一档案文件存储系统移动到第二档案文件存储系统。

3.如权利要求1所述的方法，其中，所述第一档案文件存储系统被耦合到第二档案文件存储系统，所述方法还包括：由第二数据移动器依照第二规则集把至少一部分的第一数据子集移动到所述第二档案文件存储系统。

4.如权利要求1所述的方法，还包括：处理查询，以便检索第二数据子集，其中，从所述第一档案文件存储系统中检索所述第二数据子集的第一部分。

5.如权利要求4所述的方法，其中，所述处理步骤包括：确定是否有任何将会满足所述查询的数据子集被存储在所述第一档案文件存储系统中。

6.如权利要求4所述的方法，还包括：在一个或多个第一数据源和第一档案文件存储系统中的至少一个上创建视图；其中，所述处理步骤包括：使用所述视图来处理所述查询，以便从一个或多个第一数据源和第一档案文件存储系统中的至少一个聚集第二数据子集。

7.如权利要求4所述的方法，其中，所述处理步骤包括：调用表函数，以便从所述第一档案文件存储系统中检索所述第二数据子集的第一部分。

8.如权利要求1所述的方法，还包括：接收用于指定从中检索数据的时间范围的查询；并且处理所述查询，以便根据所述时间范围来从第一档案文件存储系统中检索数据。

9.如权利要求1所述的方法，还包括：接收用于检索第二数据子集的查询；确定由所述查询所请求的第二数据子集的一部分是否被存储在第一档案文件存储系统中；并且从所述第一档案文件存储系统中检索所述第二数据子集的所述部分。

10.如权利要求9所述的方法，还包括：更新用于表明数据的位置的元数据，并且其中，所述确定由所述查询所请求的第二数据子集的一部分是否被存储在第一档案文件存储系统中的步骤，是基于所述元数据的。

11.如权利要求1所述的方法，还包括：更新至少一个配置参数；接收查询；并且依照所述至少一个配置参数来处理所述查询，以便从所述第一档案文件存储系统中检索第二数据子集。

12.如权利要求1所述的方法，其中，所述规则集中的至少一个规则把谓词与一个或多个第一数据源中的表上的保留期相关联，并且其与另一规则组合，以便表示在所述一个或多个第一数据源中的不同表之间的相关性。

13.如权利要求1所述的方法，还包括：更新在所述第一档案文件存储系统中的第一数据子集的一部分的值。

14.一种用于透明地存档在联合档案文件关系数据库管理系统中的一个或多个第一数据源中所存储的数据的设备，包括：

第一数据移动器，用于依照第一规则集把第一数据子集从所述一个或多个第一数据源移动到第一档案文件存储系统，所述第一档案文件存储系统通过接口耦合到所述联合档案文件关系数据库管理系统；

查询处理器，能够直接访问所述联合档案文件关系数据库管理系统中的一个或者多个第一数据源，且使用绰号访问所述第一档案文件存储系统，所述绰号映射到所述第一档案文件存储系统中的档案文件对象或者远程表。

15.如权利要求14所述的设备，其中，所述第一数据移动器还用于，依照所述第一规则集把第二数据子集从所述第一档案文件存储系统移动到第二档案文件存储系统。

16.如权利要求14所述的设备，其中，所述第一档案文件存储系统被耦合到第二档案文件存储系统，并且所述设备还包括：第二数据移动器，用于依照第二规则集把至少一部分的第一数据子集移动到所述第二档案文件存储系统。

17.如权利要求14所述的设备，其中，所述设备还包括：用于在一个或多个第一数据源和第一档案文件存储系统中的至少一个上创建视图的模块；以及用于使用所述视图来处理查询以便检索第二数据子集的模块，其中，从所述第一档案文件存储系统检索所述第二数据子集的第一部分，并且所述视图从所述一个或多个第一数据源和第一档案文件存储系统中的至少一个聚集第二数据子集。

18.如权利要求14所述的设备，其中，所述设备还包括：用于接收用于检索第二数据子集的查询的模块；用于确定由所述查询所请求的第二数据子集的一部分是否被存储在第一档案文件存储系统中的模块；以及用于从所述第一档案文件存储系统中检索所述第二数据子集的所述部分的模块。

19.如权利要求18所述的设备，其中，所述设备还包括：用于更新用于表明数据的位置的元数据的模块，并且其中，所述确定由所述查询所请求的第二数据子集的一部分是否被存储在第一档案文件存储系统中的处理，是基于所述元数据的。

20.如权利要求14所述的设备，所述设备还包括：

用于更新至少一个配置参数的模块；

用于接收查询，并且依照所述至少一个配置参数来处理所述查询，以便从第一档案文件存储系统中检索第二数据子集的模块。

21.如权利要求14所述的设备，其中，第一规则集中的至少一个规则把谓词与一个或多个第一数据源中的表上的保留期相关联，并且其与另一规则组合，以便表示在所述一个或多个第一数据源中的不同表之间的相关性。

22.如权利要求14所述的设备，所述设备还包括：用于更新在所述第一档案文件存储系统中的第一数据子集的一部分的值的模块。

23.如权利要求14所述的设备，所述设备还包括用于处理查询以便检索第二数据子集的模块，从所述第一档案文件存储系统中检索所述第二数据子集的第一部分。

24.如权利要求23所述的设备，其中，所述用于处理查询以便检索第二数据子集的模块，包括：用于确定是否有任何将会满足所述查询的数据子集被存储在所述第一档案文件存储系统中的子模块。

25.如权利要求23所述的设备，其中，所述用于处理查询以便检索第二数据子集的模块，包括：用于调用表函数，以便从所述第一档案文件存储系统检索所述第二数据子集的第一部分的子模块。

26.如权利要求14所述的设备，其中，所述设备进一步包括：

用于处理查询以便检索第二数据子集的模块，从所述第一档案文件存储系统中检索所述第二数据子集的第一部分；

用于接收用于指定从中检索数据的时间范围的查询的模块；以及

用于处理所述查询，以便根据所述时间范围来从第一档案文件存储系统中检索数据的模块。