DLFM:ATransactionalResourceManager（论文阅读）

在IBM Almaden研究中心开发的DataLinks技术现已在DB2 UDB 5.2中提供&＃xff0c;它引入了一种称为DATALINK的新数据类型&＃xff0c;用于数据库引用和管理存储在数据库外部的文件。通过将文件“链接”到数据库&＃xff0c;将外部文件置于数据库控制之下。也可以通过“取消链接”来删除对文件的控制。该技术提供了有关在存储或更新DATALINK值时链接或取消链接文件的事务语义。此外&＃xff0c;它提供了以下属性集&＃xff1a;
&＃xff08;1&＃xff09;管理对链接文件的访问控制&＃xff0c;
&＃xff08;2&＃xff09;强制执行引用完整性&＃xff0c;例如&＃xff0c;只要从RDBMS进行引用&＃xff0c;就不能删除或重命名所引用的文件&＃xff0c;以及
&＃xff08;3&＃xff09;
提供RDBMS数据与文件数据的协调备份和恢复。 DataLinks文件管理器&＃xff08;DLFM&＃xff09;是DataLinks技术的关键组件。 DLFM是一个复杂的SQL应用程序&＃xff0c;在文件服务器节点上驻留了一组守护进程&＃xff0c;这些守护进程与主机数据库服务器协同工作以管理外部文件。为了减少数据库服务器和DLFM之间的消息数量&＃xff0c;DLFM在文件系统和受数据库控制的文件上维护一组元数据。
**我们做出的主要决策之一是在现有的数据库管理器&＃xff08;例如DB2&＃xff09;之上构建DLFM&＃xff0c;而不是实现专有的持久性数据存储。**对于使用RDBMS构建这样的资源管理器&＃xff0c;我们有不同的感觉。主要挑战之一是为DLFM操作支持事务语义。为此&＃xff0c;我们在DLFM中实现了两阶段提交协议&＃xff0c;并设计了一种创新的方案以允许在本地数据库提交后回滚事务更新。另外一个主要问题是&＃xff0c;RDBMS的基于成本的优化器会生成访问计划&＃xff0c;该计划未考虑并发工作负载的锁定成本。将RDBMS用作黑匣子会导致“超时”&＃xff0c;从而导致锁定超时和死锁&＃xff0c;并降低并发工作负载的吞吐量。为了解决这个问题&＃xff0c;我们想出了一个简单但有效的方法

十多年来&＃xff0c;IBM一直专注于可扩展数据库研究。这些努力的许多成果已经出现在IBM的DB2关系数据库管理系统&＃xff08;RDBMS&＃xff09;系列中[1]。为了进一步扩展RDBMS功能的范围&＃xff0c;IBM Almaden Research现在已经开发了一种称为DataLinks [2]的新技术&＃xff0c;该技术使DBMS能够管理存储在外部操作系统文件中的数据。 DataLinks为DBMS提供了对外部数据的全面控制&＃xff0c;并提供以下属性&＃xff1a;引用完整性&＃xff0c;访问控制&＃xff0c;协调的备份和恢复以及事务一致性。现在&＃xff0c;数家公司和机构&＃xff08;例如&＃xff0c;波音&＃xff0c;达索和汽车制造商&＃xff09;已经部署了DataLinks技术&＃xff0c;以提供对存储在操作系统文件中的分布式科学和工程数据的数据库管理[2&＃xff0c;3]。
DataLinks技术包括以下主要组件**&＃xff1a;DLFM&＃xff0c;DLFF**&＃xff08;DataLinks文件系统过滤器&＃xff09;以及RDBMS引擎&＃xff08;以下称为数据链路引擎&＃xff09;的扩展。它还引入了新的DATALINK数据类型[4]&＃xff0c;以方便RDBMS引用和管理外部存储的数据。数据链接引擎负责处理DDL请求以创建数据链接列&＃xff0c;并负责处理针对数据链接列的DML请求。另一方面&＃xff0c;DLFM和DLFF组件位于存储数据库管理的外部数据的文件服务器上。 SQL表中datalink列的值为URL&＃xff0c;它可以引用相同或相同的文件

DataLinks是一种软件技术&＃xff0c;使DBMS可以管理存储在外部操作系统文件中的数据&＃xff0c;就好像该数据直接存储在数据库中一样。通过将DBMS的范围扩展到操作系统文件&＃xff0c;DataLinks使用户可以灵活地在数据库内部或外部适当地存储数据。为了在DBMS之外存储和引用数据&＃xff0c;数据库应用程序开发人员在创建SQL表时声明DATALINK数据类型的列。然后&＃xff0c;将数据链接列中存储的值用于表示和引用外部文件中的数据。图2说明了DataLinks技术的体系结构。如图所示&＃xff0c;DataLinks包含两个组件&＃xff1a;数据链接引擎和数据链接管理器&＃xff08;参见图2&＃xff09;。数据链接引擎驻留在主机数据库服务器中&＃xff0c;并作为数据库&＃xff08;DB2&＃xff09;引擎代码的一部分实现。它负责处理涉及数据链接列的SQL请求&＃xff0c;例如表创建以及使用数据链接列的记录的选择&＃xff0c;插入&＃xff0c;删除和更新。数据链接管理器由2个组件组成&＃xff0c;数据链接文件管理器&＃xff08;DLFM&＃xff09;和数据链接文件系统过滤器&＃xff08;DLFF&＃xff09;

数据链接应用程序是一种操作**SQL表中数据链接属性&＃xff08;列&＃xff09;**的应用程序&＃xff0c;就数据库而言&＃xff0c;它与常规数据库应用程序没有什么不同。在数据链路应用程序可以发出任何请求之前&＃xff0c;它必须首先建立数据库连接。作为数据库连接请求的一部分&＃xff0c;将标识一个DB2代理&＃xff08;进程或线程&＃xff09;来为应用程序提供服务。建立连接后&＃xff0c;应用程序可以开始向数据库引擎提交SQL请求。如果SQL请求需要处理数据链接列&＃xff0c;则调用数据链接引擎以处理特定于请求的部分。到数据链接列。反过来&＃xff0c;如果需要的话&＃xff0c;数据链路引擎向DLFM发送一个或多个请求&＃xff0c;以操纵存储在文件服务器上的文件和元数据

DB2 Data Links Manager的Data Links File Manager&＃xff08;DLFM&＃xff09;组件在管理外部文件中起着关键作用。它负责在链接到数据库&＃xff08;在其中引用&＃xff09;的同一事务中执行链接/取消链接操作。当文件最初链接到数据库时&＃xff0c;DLFM会**应用约束以实现引用完整性&＃xff0c;**访问控制&＃xff0c;DATALINK列定义中指定的备份和恢复。例如&＃xff0c;如果DBMS控制读取访问&＃xff0c;则DLFM将文件的所有者更改为DBMS&＃xff0c;并将文件标记为“只读”。对DLFM存储库和文件系统的所有这些更改都作为与发起SQL语句相同的DBMS事务的一部分应用。如果回滚SQL事务&＃xff0c;则DLFM所做的更改也将被撤消。DLFM还负责协调外部文件与数据库的备份和恢复。当包含链接文件操作的DBMS事务提交时&＃xff0c;如果DLFM负责文件的恢复&＃xff0c;则DLFM将启动新链接文件的备份。该文件备份是异步完成的&＃xff0c;由于性能原因&＃xff0c;它不是数据库事务的一部分。

DLFM使用本地数据库保留其元数据和状态信息。此信息存储在以下SQL表中。

1. Dbid表&＃xff1a;此表由每个可以连接到此DLFM的主机数据库的注册条目组成。该表中的dbid字段表示主机数据库名称&＃xff0c;实例名称和主机名称的唯一组合。
2. 2.组表&＃xff1a;此表由文件组条目组成。每个组条目对应于主机数据库侧SQL表中的数据链接列。
3. 3.文件表&＃xff1a;这是最常访问的表&＃xff0c;包含文件服务器上链接的文件和未链接的文件的信息。每当链接文件时&＃xff0c;都会在文件表中插入一个新条目。在取消链接操作期间&＃xff0c;处于链接状态的现有文件条目被标记为未链接。如果将来需要通过主机数据库还原实用程序还原文件&＃xff0c;则该表保留未链接的文件条目。该表中定义的关注列是dbid&＃xff0c;filename&＃xff0c;transaction_id&＃xff0c;Recovery_id&＃xff0c;file_status&＃xff0c;entry_state。稍后将通过功能处理来描述它们的用法。
4. 4.事务表&＃xff1a;此表跟踪所有活动DLFM事务的事务状态。只要交易处于活动状态&＃xff0c;交易状态就会被维护。事务开始时&＃xff0c;事务状态信息首先保存在内存表中。当事务开始提交处理的第一阶段时&＃xff0c;该条目将插入到SQL表中。交易完成后&＃xff0c;其条目将从交易表中删除。
5. 5.存档表&＃xff1a;此表包含需要存档到存档服务器的文件和组条目。当使用load实用程序将大量文件插入主机数据库侧的datalink列中时&＃xff0c;而不是复制Archive表中的每个文件条目&＃xff0c;而是仅将一个组条目插入Archive表中。将处理“存档”表中的条目以复制一组文件或仅复制一个文件。复制完成后&＃xff0c;将从存档表中删除相应的条目。

LinkFile和UnlinkFile是两个最常见的操作&＃xff0c;**分别与从主机数据库插入和删除数据链接值相对应。**每当应用程序将文件条目插入到datalink列中时&＃xff0c;在LinkFile操作期间&＃xff0c;DLFM将在File表中放置一个新条目。该条目包括dbid&＃xff0c;事务ID&＃xff0c;文件名和Recovery ID等。主机数据库上生成的恢复ID由dbid和时间戳组成。保证它在全球范围内是唯一的&＃xff0c;并且会单调增加。对于每个LinkFile操作&＃xff0c;DLFM都会进行以下两项检查&＃xff1a;
1.如果DLFM元数据表中的同一文件已经存在链接条目&＃xff0c;则该链接条目将拒绝LinkFile操作&＃xff0c;因为该文件已处于链接状态。
2.如果DLFM表中存在未提交取消链接事务&＃xff08;即&＃xff0c;进行中或处于怀疑状态&＃xff09;的同一文件的取消链接条目&＃xff0c;则它会拒绝LinkFile操作&＃xff0c;因为取消链接事务的结果仍是未知的。
但是DLFM必须确保最多一个条目处于链接状态。因此&＃xff0c;仅文件名上的唯一索引是不够的&＃xff0c;通常在“文件”表中具有数十万或数百万个条目。由于每个链接或取消链接文件操作都需要访问File表&＃xff0c;因此从File表中查找和检索条目的效率对于提供良好的整体性能至关重要。
我们要做的第一件事是通过建立多个索引&＃xff08;每个访问路径一个索引&＃xff09;来避免表扫描。
DLFM在文件表中将事务ID与其他信息一起记录为持久性信息。与事务关联的条目在提交处理期间由此ID标识。
DLFM为此提供了四个API&＃xff1a;BeginTransaction&＃xff0c;Prepare&＃xff0c;Commit和Abort

DLFM在协调备份和恢复DBMS数据以及文件数据中发挥着重要作用。当链接文件提交的事务和文件组具有recovery选项7时&＃xff0c;DLFM启动将该文件归档到归档服务器&＃xff08;如ADSM.8&＃xff09;DLFM Child Agent&＃xff08;第3.5节中描述&＃xff09;将文件的条目放入存档中表和复制守护程序从存档表中拾取条目&＃xff0c;并将文件写入存档服务器。归档表后面的主要目的是避免在主元数据表&＃xff0c;文件表中的争用以及从任何DLFM故障恢复后有效重启复制。由于在存档表上定义了多个索引&＃xff0c;并且归档表的大小很小&＃xff08;在存档后立即删除条目&＃xff09;&＃xff0c;因此在访问存档表时&＃xff0c;子代理和复制守护程序之间会遇到死锁。禁用DLFM本地数据库中的下一个密钥锁定功能消除了这些死锁。请注意&＃xff0c;当未执行下一个密钥锁定时&＃xff0c;可能会出现幻像。但是&＃xff0c;DLFM无法正常运行可重复读取属性。

请注意&＃xff0c;提交事务时&＃xff0c;文件的归档是异步的。进行备份副本时&＃xff0c;DLFM不持有任何数据库锁。之所以可以进行异步备份&＃xff0c;是因为DLFM在提交操作期间取消了文件的“写入”权限。主机数据库端的备份实用程序确保在声明备份成功之前&＃xff0c;将自上次备份以来链接的所有文件都存档到存档服务器。如果某些文件的归档正在等待中&＃xff0c;则它会要求Copy守护程序以高优先级来归档这组文件。

DLFM是一个并发服务器&＃xff0c;即&＃xff0c;当接收到DB2代理的连接请求时&＃xff0c;它具有一个主要守护程序&＃xff0c;该主守护程序会产生子代理&＃xff08;或进程&＃xff09;。然后&＃xff0c;子代理与请求DB2代理建立连接。此子代理将提供来自相同连接的所有后续请求。 DLFM的主要守护程序然后等待来自相同或不同主机DB2的另一个连接请求。主机DB2侧的应用程序将与DLFM建立单独的连接&＃xff0c;因此它们由DLFM侧的单独的儿童代理服务提供服务。除了儿童代理商之外&＃xff0c;DLFM还提供了几种作为守护程序实现的其他服务&＃xff0c;并且它们也被主DLFM守护进程产生了它们[REF。图5]。本节介绍每个守护程序提供的功能和服务、
如果将SQL表放在主机DB2端&＃xff0c;则DLFM端的相应文件组&＃xff08;如果有&＃xff09;也将需要删除。删除的表中的数据链接列可能引用了许多文件&＃xff0c;所有这些文件都需要取消链接。所以在事务前进过程中&＃xff0c;文件组在“组”表中被当前事务标记为“已删除”。在准备处理期间&＃xff0c;子代理会记录此事务删除的组数&＃xff0c;并将其与事务条目一起记录在事务表中。提交处理通过检查事务条目中当前事务中已删除的组数来检查是否删除了任何组&＃xff0c;如果已删除&＃xff0c;则它将事务ID发送到Delete Group守护程序。使用事务标识&＃xff0c;“删除组”守护程序查找在此事务中删除的所有组&＃xff0c;然后取消链接每个组中的所有文件

通过该守护程序取消文件的链接是异步的&＃xff0c;并且对drop table的提交处理不会等待它完成。请注意&＃xff0c;直到该组中的所有文件都已取消链接&＃xff0c;才删除该组条目。并且&＃xff0c;只要此事务未提交&＃xff0c;就不允许重新链接相同的文件名。因此&＃xff0c;如果DLFM在Delete group守护程序完成从已删除的组中取消所有文件的链接之前失败&＃xff0c;则在DLFM重新启动后&＃xff0c;Delete group守护程序仍可以从事务表中提取所有已提交的事务条目并恢复其工作。