CN1332343C - 数据库中对象标识符回收再利用的方法 - Google Patents

Abstract

本发明涉及数据库中对象标识符回收再利用的方法，它包括：建立数据结构的步骤、对象标识符回收的步骤、对象标识符再利用的步骤。在本发明方法中，OID的回收与对象物理空间的回收过程相一致，能自动回收对象标识符，可充分利用现有的计算机资源并提高系统性能。

Description

数据库中对象标识符回收再利用的方法

技术领域

本发明涉及计算机数据库，具体涉及数据库中对象标识符(OID)，特别是数据库中对象标识符回收再利用的方法。

背景技术

OID(object-identifier)是面向对象数据库(OODBs)中提出的新概念。面向对象数据库中采用了“面向对象”的方法，即实体类型用“类”表示，实体用“对象”表示，系统给数据库中的每个对象赋予一个“对象标识符”(OID)，起唯一标识作用。这种实现方法在语义上克服了以往“面向值”数据模型的缺点。OID的引入，避免了数据库系统的变量冗余，使对象可以方便地被引用并共享。

但就现在看来，OODBs还不成熟，远不能完全替代关系数据库系统。因而人们转入将面向对象数据库的优点(OID是其中必不可少的一部分)引入到关系数据库中，形成了功能强大的对象关系数据库。这种新型的数据模型中，OID的概念消除了传统关系数据库系统中存在的数据模型的缺陷。

OID作为面向对象数据库以及对象关系数据库中的一项非常重要的技术，也存在形式各样的实现方法。目前使用广泛的一种方法为句柄(handle)维护法，该系统每次生成新的对象，都将该句柄的值加一并赋给对象作为对象标志符，由于它简单易行(编程简单且管理方便且移植性强)，因而适用广泛，能够有效应用于ORDBs和OODBs中。

然而，在句柄维护法中，位长的限制决定了数据库中可用OID的个数，一旦所有OID全部分配，则数据库将面临崩溃。为了避免OID资源耗尽而产生系统崩溃，目前一般采用以下两种方法：

1、采用扩展OID的长度来增加可用OID的个数方法。但是该方案会引起OID对资源耗费的增加，而且实现更复杂。

2、对已废弃的OID进行回收。就目前来看，回收不失为一种很好的方法。它可不需要考虑在整个数据库生存周期中所需要的OID个数，而将考虑范围缩小为某个时间周期内所需的OID，对有限的OID进行循环使用。只要OID的数量满足某段时间内数据库的需要即可。

现有的OID回收方法为：

首先，在数据库中设置两个表：①HighestObj(Obj)存放下一个可用的对象标识符；②Free(Obj)：用于回收已删除的对象标识符。

一旦删除对象，则用户手动将其OID插入到表Free中。

一旦创建对象，则先查询Free中是否有可用OID。如果有，则从其中分配一个OID给对象，并手动将该OID从Free中删除；如果没有，则从表HighestObj中分配一个给对象并手动将该OID从HighestObj中删除。

该回收方案虽然能够实现OID的回收，但是却将繁重的工作交与用户手动实现，每删除一个对象即将对应的OID进行回收。用户不仅需要自行分配OID，而且还要根据资源回收情况决定采取哪种方式进行分配；由于用户不清楚数据库内部具体的情况，使数据库的管理变得比较复杂且效率比较低。

发明内容

本发明所要解决的技术问题是：提供一种在采用句柄维护法的数据库中使用的对象标识符回收再利用的方法，在该方法中，OID的回收与对象物理空间的回收过程相一致，能自动回收对象标识符，可充分利用现有的计算机资源并提高系统性能。

本发明解决上述技术问题所采用的技术方案是：

数据库中对象标识符回收再利用的方法，它包括：建立数据结构的步骤、对象标识符回收的步骤、对象标识符再利用的步骤；

建立数据结构的步骤包括：

(1)在磁盘中建立一个用于存贮回收对象标识符的回收文件，该文件分为若干个块，每一个块都具有一个头信息，头信息中至少包括：该块的块号、该块中对象标识符的个数；回收文件以栈的方式存储块；块以栈的方式存储对象标识符；

(2)在共享内存中增加存放两个变量的域，其中一个变量为块变量，它指向对象标识符回收文件中最后一个可用块；另一个变量为对象标识符变量，它指向对象标识符回收文件中最后一个可用块的最后一个对象标识符；两个变量始终表示工作的开始位置；

(3)在内存中建立一个缓冲区，用于存放回收文件中的最后一个有效块的拷贝；

对象标识符回收的步骤为：物理上删除废弃对象时，将其对象标识符存贮到回收文件的步骤；物理上删除对象包括：单个对象的删除、整个类的删除；

对象标识符再利用的步骤包括：

(1)将块变量所指向的文件块拷贝到该缓冲区中；

(2)当对新的对象分配对象标识符时，系统从缓冲区中取出对象标识符变量所对应的对象标识符，同时将对象标识符变量减1；

当对象标识符变量为空时，将该缓冲区在磁盘上对应的块清空，并从回收文件中拷贝出前一个块到缓冲区中，同时将块变量减1；

当块变量为空时，则转入到原对象标识符分配机制。

上述方案中，在删除单个对象时回收对象标识符的步骤为：

(1)对类中的被删除对象加标记；

(2)扫描单个对象的标记，将被删除对象的对象标识符回收，并存贮到回收文件中。

上述方案中，直接清理整个类的所有对象时回收对象标识符的步骤为：

(1)为该事务分配一个临时文件；

(2)在删除该类的过程中，扫描该类所有对象，并将其中的未被删除的对象(live对象)和废弃对象的标识符(OID)存放在该临时文件中；

当在事务提交时，将该临时文件中的所有对象标识符全部导入回收文件；

当事务发生回滚时，将该临时文件中的内容抛弃。

上述方案中，它还包括系统恢复处理的步骤，系统恢复处理的步骤包括：将两个变量记录到检查点中的步骤。

上述方案中，它还包括系统恢复处理的步骤，系统恢复处理的步骤为包括：

(1)将两个变量记录在日志中；

(2)系统恢复时，根据日志找到最后一次分配的对象标识符，

当在系统对象标识符的原分配模式之下，直接将该对象标识符变量加1，作为下一个可分配的对象标识符；

当在回收对象标识符的分配模式，还要在日志记录中找到最后分配的对象标识符对应的块变量，然后根据该对象标识符和块变量在回收文件中匹配，确定下一个可分配的对象标识符。

本发明方法与现有的对象标识符回收再利用的方法相比，具有以下优点：

1、能自动回收对象标识符。不需要用户决定如何回收、回收后的OID如何放置以及如何分配已回收OID。一旦系统开始进行物理空间回收，即会同步回收对应的无用的对象标识符，使得回收对象标识符的过程对用户透明。

2、根据数据库系统中不同的对象删除策略对OID的进行相应的回收处理，使之与对象物理空间的回收工作同步。

对于一般数据库系统，对象删除包括逻辑删除和物理删除两个部分。其中，逻辑删除对象只是将其标记为不可见，但该对象仍然占用物理空间，如果需要，可以通过修改相关域使得该对象重新可见；物理删除即真正的将对象从磁盘中删除并回收其物理空间。在这种情况下，本发明将OID的回收放到对象物理删除时进行。

如果数据库中对象的删除是一次性的，即直接物理删除该对象，则直接在这一步回收该对象的OID。一般而言，这种一次性删除情况出现比较少。

3、为了便于回收OID的再利用，减少磁盘输入/输出(I/O)并有效实现回收再利用的同步，在内存中开辟一块专门缓冲区用于进行OID的分配工作。

由于回收的OID是无序的，不能使用数值递加的策略来管理回收的OID，而必须在文件中准确定位下一个可分配OID。在内存中开辟一块缓冲区buffer_for_oid(BFO)，以块为单位对OID回收文件(ORF)进行读取，有效的减少磁盘I/O并提高效率。

采用栈机制对ORF进行管理。从前往后存放回收的OID并从后往前分配OID。BFO总是记录回收文件中最后一个块，并从该块的末端向前分配。这样可以有效避免块内部空洞情况的出现。

4、在事务中加入OID处理模块，使得在故障出现时避免OID的重复分配，并尽可能地减少OID损失。

在故障出现时，内存中的信息包括BFO内容以及定位BFO中OID位置的变量(包括SBN和SROC。SBN：ORF中最后一页的块号，SROC：最后一个可用OID在块中的位置)将会全部丢失。在这种情况下，可通过引入事务的恢复策略(具体为检查点和回滚恢复算法)将损失降到最小。

检查点恢复

检查点(checkpoint)是指在磁盘中对某些请求作记录的一种状态。系统会定期地或在系统关闭时做检查点，一旦发生故障，能够自动地从最后一个检查点开始进行恢复工作。我们在检查点中加入记录OID分配位置的两个变量(SBN和SROC)。按照这种机制，在系统正常关闭时检查点中记录的是当前SBN和SROC，系统重启时能够恢复到关闭前的状态，不会出现任何损失。

普通日志恢复

每当系统从回收文件中取出一个块时，即将该块的块号记录到日志文件中，称为PR(PageRecord)。一旦系统发生故障，即从日志记录中的最后一个检查点开始向后扫描，在该扫描过程中记录下最后的一个PR以及最后一次分配的OID(后面简称为LOID)，然后根据这两项日志记录值在ORF中进行匹配，得到故障前的OID分配情况。这样一来，就可以避免故障恢复后OID的重复分配并将损失降低为0。

附图说明

图1为本发明的实施方案回收OID建立的数据结构框架

图2为本发明的实施方案OID回收机制

图3为本发明的实施方案OID分配流程图

图4为本发明的实施方案事务恢复流程图

具体实施方式

本发明的实施方案仅包括在PostgreSQL数据库中的实现。但是本领域的技术人员会了解到对于其它的数据库系统本发明也可以通过调整具体方案得以实现。

PostgreSQL数据库是一个使用句柄维护策略的典型对象关系数据库，它使用32位的无符号整数作为OID，最多可以分配4G个OID。

本发明的实施方案包括：建立数据结构的步骤、对象标识符回收的步骤、对象标识符再利用的步骤、系统恢复处理的步骤；

1、建立数据结构的步骤

由于不同的数据库系统会采取不同的删除、更新策略，因而需要调整具体策略对OID加以回收。为了实现OID的回收和再利用，本发明方法建立了如下三个数据结构(如图1)：

(1)在磁盘中建立一个用于存贮回收OID的ORF，用于记录收集的OID。该文件分为若干个块(block)，每一个块都有一个头信息(head information)，头信息中包括：该块的块号(block_num)、该块中OID的个数(oid_num)。在该ORF中，每一个块除去相应的头信息，最多可以存放255个OID。ORF以栈的方式存储块；块以栈的方式存储OID。

(2)在共享内存ShareMemory中的ShmemVariableCache结构体中增加存放两个变量的域：其中一个变量为块变量block_num(以下简称为SBN)，用于记录对应于OID文件中的最后一个有效块的块号，另一个变量为对象标识符变量reclaim_oid_count(以下简称为SROC)，用于记录该块中当前可用OID。无论对于OID的回收还是OID的再利用操作来说，它们总是表示工作的开始位置。它们各自拥有一个特殊的Invalid值：SBN等于Invalid表示整个OID文件为空；SROC为Invalid表示当前的OID文件块为空。在系统的运行过程中，这两个变量始终指向OID回收文件中最后一个可用块的最后一个OID。

(3)在内存中建立一个存放ORF中的最后一个有效块拷贝文件的缓冲区BFO(其结构和和大小都同于OID文件的一个块)。分配回收的OID时，系统会把OID文件中的最后一个有效块拷贝到BFO中。

2、对象标识符回收的步骤

对象标识符回收的步骤为将物理上删除对象的对象标识符回收并存贮到回收文件中的步骤，物理上删除对象包括：物理上删除的清理表中的所有废弃对象、物理空间删除整个关系的所有对象。

对象的删除分为逻辑上的删除和物理上的删除，逻辑删除只是将对象标记为无效，使得对象不可见，在用户输入delete或是update命令时，只是逻辑删除对象；而物理删除才真正释放对象占有的物理空间。逻辑删除的对象，称为旧版本对象，在某种情况下，旧版本对象可能被重新置为有效。考虑到上述对象恢复的情况，我们将OID的回收工作推迟到物理删除时进行。在PostgreSQL系统中，有下面两种操作会导致对象的物理空间删除：

(1)vaccum操作

(2)drop_class操作

其中，vacuum的作用是集中清理表中的所有废弃对象，回收物理空间；而drop_class是指系统直接删除关系对应的文件，相当于物理上删除了整个关系的所有对象并回收磁盘空间。

Vacuum操作下的OID的步骤为：

(1)对废弃对象加标记；

回收OID时需要区分两种dead对象，一种为被逻辑删除对象，另一种为被更新对象，其中被逻辑删除的对象称为废弃对象。废弃对象的OID已经失效，可以回收；而对于被更新的对象来说，在更新时它的OID被赋给更新后的对象，该OID仍然有效，不能回收。为了区分这两种对象，本发明实施方案对废弃对象加上标记，而对被更新对象不加标记。

当然也可以只对被更新对象加标记，其目的只是为了区分“被删除对象”和“被更新对象”。

(2)在扫描单个对象时，将被删除对象的对象标识符回收，并放到对象标识符回收文件中(如图2)；

将回收OID的工作放在关系扫描的过程时，如果它的物理空间可以回收(说明这个对象已经被删除或是已经被更新)，则检查它的可回收标记，如果有该标记，则回收它的OID，放到OID回收文件中。

在drop_class情况下对OID回收的步骤为：

一旦事务结束，该类所对应文件的空间将会全部回收。表面看来，这种情况下逻辑删除与物理空间删除是同时进行的，但是事实上，在事务内部会出现对象回滚情况，即将该事务中前面的动作置为无效，还可以将类删除的内部动作分为逻辑删除和物理删除，与Vacuum不同的是这两部分动作在同一个事务内部进行。

考虑到多进程情况，每当一个drop_class事务开始时，

(1)为该事务分配一个临时文件；

(2)在删除该类的过程中，扫描该类所有对象——包括有效对象和无效对象(在不同数据库中对于update操作是不同，根据不同的数据库策略决定是否需要回收update对象的OID)，并将这些对象OID存放到该进程的临时文件中；

当在事务提交时，将该临时文件中的所有OID全部导入ORF的末尾处；

当事务发生回滚时，直接将该临时文件中的内容抛弃即可。

3、回收OID再利用的步骤

本发明实施分方案采用优先使用ORF中OID的原则进行分配OID。回收OID的再利用，即将回收得到的OID从磁盘文件中提取出来并进行重新分配的过程。回收文件以栈的方式存储块，块以栈的方式存储对象标识符；在OID文件中由前往后记录回收的OID，由后往前分配回收的OID，回收OID类似于压栈，而分配类似于出栈。

OID再利用的流程图如图3，图中，B为block_num变量，R为reclaim_oid_count变量，Inv为变量的无效值。

OID再利用的具体步骤为：

(1)在进行分配之前，将SBN所指向的文件块拷贝到该缓冲区中。此时SROC指向缓冲区中最后一个有效的OID。

(2)当对某个新对象分配OID时，系统从OID缓冲区中取出SROC所对应的OID，同时，将SROC变量减1。

当该变量SROC为0时，表示本块中的OID已经分配完。此时将该缓冲区在磁盘上对应的块清空(oid_num置为0)，并从文件中拷贝出前一个块，同时将变量SBN减1。

如果SBN为0，说明文件中的OID已经分配完毕，则转入到原OID分配机制中，即目前使用的OID分配机制中(句柄加一方式)。

4、系统恢复处理的步骤

系统恢复处理的事务恢复流程如图4，图中，ORF为OID回收文件，BFO为专门为OID再利用而分配的缓冲区，SROC为共享内存中记录最后一个可用OID的位置，PR为日志中记录ORF中最后一可用页面的页号，LOID为日志中记录的最后一次分配的OID，CBN，CROC为检查点中分别对应共享内存中对SBN和SROC值的拷贝，BX为事务恢复时，用于进行页面内OID匹配的参照页面号。

由于记录OID分配的关键变量放置在共享内存中，一旦系统出现故障，这些数据将会全部丢失。为了解决系统故障并降低损失，本发明实施方案在OID回收机制中扩展了系统恢复模块。系统恢复分为正常关机后的恢复和非正常关机后的恢复。

检查点系统恢复处理的步骤：

在正常关机时的系统恢复处理的步骤为：系统自动做一个检查点，记录当前内存中某些关键变量。参照原系统的做法，我们将回收中涉及OID的两个关键变量(SBN和SROC)记录到检查点中。系统重新启动时可以完全恢复到关机前的状态，因而在这种情况下不会出现OID的损耗；对于非正常关机后的恢复，系统检测到的检查点为定期检查点，记录的是下一分配单位OID。按照原系统的恢复机制一次最多可能会损失8191个OID——即刚分配了该块中的第一个OID就出现非正常关机的故障。

针对上述这种缺陷，本发明实施方案还可采用增加记录当前OID文件最后一块的块号日志的系统恢复处理方法。

日志系统恢复处理的步骤：

(1)将两个变量记录在日志中；

(2)系统恢复时，根据日志找到最后一次分配的OID，

当在系统OID的原分配模式之下，直接将该SROC加1，作为下一个可分配的OID；

当在回收OID的分配模式，还要在日志记录中找到最后分配的OID对应的SBN，然后根据该SBN和SROC在回收文件中匹配，确定下一个可分配的OID。

这样一来，可以将故障恢复时OID的损失降低为0。

Claims (5)

1、数据库中对象标识符回收再利用的方法，其特征在于：它包括：建立数据结构的步骤、对象标识符回收的步骤、对象标识符再利用的步骤；

建立数据结构的步骤包括：

(1)在磁盘中建立一个用于存贮回收对象标识符的回收文件，该文件分为若干个块，每一个块都具有一个头信息，头信息中至少包括：该块的块号、该块中对象标识符的个数；回收文件以栈的方式存储块；块以栈的方式存储对象标识符；

(2)在共享内存中增加存放两个变量的域，其中一个变量为块变量，它指向对象标识符回收文件中最后一个可用块；另一个变量为对象标识符变量，它指向对象标识符回收文件中最后一个可用块的最后一个对象标识符；两个变量始终表示工作的开始位置；

(3)在内存中建立一个缓冲区，用于存放回收文件中的最后一个有效块的拷贝；

对象标识符回收的步骤为：物理上删除废弃对象时，将其对象标识符存贮到回收文件的步骤；物理上删除对象包括：单个对象的删除、整个类的删除；

对象标识符再利用的步骤包括：

(1)将块变量所指向的文件块拷贝到该缓冲区中；

(2)当对新的对象分配对象标识符时，系统从缓冲区中取出对象标识符变量所对应的对象标识符，同时将对象标识符变量减1；

当对象标识符变量为空时，将该缓冲区在磁盘上对应的块清空，并从回收文件中拷贝出前一个块到缓冲区中，同时将块变量减1；

当块变量为空时，则转入到原对象标识符分配机制。

2、如权利要求1所述的方法，其特征在于：在删除单个对象时回收对象标识符的步骤为：

(1)对类中的被删除对象加标记；

(2)扫描单个对象的标记，将被删除对象的对象标识符回收，并存贮到回收文件中。

3、如权利要求1所述的方法，其特征在于：直接清理整个类的所有对象时回收对象标识符的步骤为：

(1)为该事务分配一个临时文件；

(2)在删除该类的过程中，扫描该类所有对象，并将其中的未被删除的对象和废弃对象的标识符存放在该临时文件中；

当在事务提交时，将该临时文件中的所有对象标识符全部导入回收文件；

当事务发生回滚时，将该临时文件中的内容抛弃。

4、如权利要求1所述的方法，其特征在于：它还包括系统恢复处理的步骤，系统恢复处理的步骤包括：将两个变量记录到检查点中的步骤。

5、如权利要求1所述的方法，其特征在于：它还包括系统恢复处理的步骤，系统恢复处理的步骤为包括：

(1)将两个变量记录在日志中；

(2)系统恢复时，根据日志找到最后一次分配的对象标识符，

当在系统对象标识符的原分配模式之下，直接将该对象标识符变量加1，作为下一个可分配的对象标识符；

当在回收对象标识符的分配模式，还要在日志记录中找到最后分配的对象标识符对应的块变量，然后根据该对象标识符和块变量在回收文件中匹配，确定下一个可分配的对象标识符。

Images