Monthly Archives: June 2008

事务能以不同的级别来进行隔离。序列化提供了最大的隔离，同时意味着在事务的生存时间，任何时间都只有一个thread of control能读一个数据项，它将不会由前一个数据发生改变（假定这个thread of control不改变它）。缺省情况下，BDB迫使事务包装下的数据库操作序列化，这被称为级别3隔离。 很多应用并不需要在事务中包装所有的读取，因此可能的情况下，事务保护下使用序列化读取应该尽量避免，因为会因为会引起性能问题。比如，一个序列化读游标读取数据库中的每个key /data对，将会对数据库中的绝大多数页上读锁因此会阻塞数据库上的写操作直到事务提交或者取消。实际上，如果有更新操作存在于应用中，读操作仍然必须使用锁，必须准备重复执行任何可能返回DB_LOCK_DEADLOCK的操作（比如关闭和打开游标）。需要重复读的应用需要能重复访问一个数据项而能确切知道它并没有在它操作过程中被其它事务改变过。 快照隔离(snapshot isolation)也能保证重复读取，但是通过使用MVCC(multiversion concurrency control)避免读锁。这使得更新操作更加昂贵，因为它们不得不为新版本分配空间和保存快照，但是能减少读锁增大吞吐量。 一个事务可能只要求游标稳定性。它能保证游标看见的提交的数据只要被游标定位就不会改变，但是可能在读事务完成之前改变。这是2级隔离。一旦游标移动，先前引用的数据可能会改变。 Berkeley DB也支持读未提交的数据，也就说，读操作可能请求的数据已经被修改但是仍然没有被另外事务提交。这被称为1级隔离。这使得当另外一个事务在请求的数据上持有写锁时读操作不会被阻塞；缺点是读操作可能会返回被写操作取消的数据，这些数据可能被持有写锁的事务取消。 快照隔离 当配置环境使用快照隔离时，应用可能会花去更多的cache。如果cache在老的页被丢弃之前变满，这些页会被写到磁盘上的临时"freezer"文件，可能会导致额外的IO。为了避免产生此类freezing的缓存，可以通过DB_ENV->log_archive进行检查点来进行估计。cache的量大概是剩下日志的2倍。 环境应该被配置足够多的事务。 利用快照隔离好处最简单的方法：对于有更新操作的事务使用读写锁，在只读事务或者游标上使用DB_TXN_SNAPSHOT。这应该最小化快照隔离被阻塞的可能性。 如果应用更新的事务读取了大量的数据项并只更新了一小部分，也能在快照隔离时运行一些更新来提高吞吐量。

BDB的恢复基于 write-ahead日志，这意味着当对一个数据库页做改动时，关于此改变的描述被写到日志文件中，这个日志文件中的描述保证在数据库中受影响的页写到可靠的存储之前被写到可靠的存储介质上。这通常是日志系统提供持久性和回滚的基础特性。 如果应用或者系统崩溃，日志在恢复过程中被查阅。任何日志中描述的已经提交事务的改变而从未写到数据库的将会被作为恢复的一部分写到实际的数据库，未提交的且写到实际数据库的将被取消。 当考虑可恢复性时，有2个接口需要考虑： 1、BDB和文件系统/OS。 2、文件系统/OS和潜在的可靠存储硬件。 BDB使用OS接口和潜在的文件系统来进行文件的读写，这意味着当潜在的文件系统失效时BDB会失效。接口的要求很简单，比如BDB用于刷新数据到磁盘的系统调用，必须保证在它将结果返回到BDB之前将所有必须的信息写到可靠的存储介质上。 除此以外，BDB潜在使用OS和硬件之间的接口，这个要求描述起来不简单。 首先，必须考虑的是BDB的页大小，BDB使用应用指定的页大小进行写操作，它假定页级写操作是原子性的，这意味着如果OS的IO的块大小和页大小不同，将增加数据库崩溃的可能。 另外，如果你拷贝数据库文件（不管你是不是在进行热备），同样需要关注页大小，copy命令必须以数据库页大小为单位原子化运行，中间不能穿插写操作，copy程序必须读取页大小的整数倍，一般情况下这并不是问题。某些Solaris上的cp可能有问题。 第三，必须考虑潜在的存储硬件的影响。 如果储存数据库的磁盘爆炸，你能进行通常的灾难恢复，因为它仅仅要求一个数据库的快照加上已经归档的日志文件。如果你的数据库环境和数据库在丢失日志文件之后仍然可用，你能导出你的数据库，但是这可能是一个不一致的快照，因为事务的部分改变没有提交但是出现在导出之中，此时你可将导出的数据库和灾难恢复之后的进行对比。

在应用或者系统失效以后，有2个可能的方法来做数据库恢复： 1、不需要恢复性，所有的数据库能从0开始重新创建。尽管这些应用可能仍然需要事务保护，恢复通常包括删除数据库环境，然后重启应用。 2、在系统或者应用失效后需要恢复信息。在这种情况下，需要使用db_recover工具或者调用带DB_ECOVER或者DB_RECOVER_FATAL标志的DB_ENV->open方法。 在恢复过程中，所有被取消或者未完成的事务被撤销，所有提交的改变将重做，在恢复完成之前数据库应用不能重启。 有2个类型的恢复过程：通常的和灾难性的。 如果当前的数据库和日志文件都存在于稳定的文件系统上，且是可访问的，则通常的恢复是足够的，运行db_recover或者在DB_ENV->open中指定DB_RECOVER标志。实际上，通常的恢复绝不包括使用数据库环境的热备。比如，你不能热备数据库和日志文件，还原热备然后运行通常恢复————你必须在使用热备时运行灾难恢复。 如果数据库或者日志文件被损坏，或者通常的恢复失效，灾难恢复将是必须的。比如，灾难恢复包括磁盘驱动器物理损坏，潜在的文件系统损坏，操作系统通常的文件检查操作不能将文件系统调整为一致。此类很难侦测，通常的做法是当通常的恢复失效时或者在数据库应用过程中校验码出错使用灾难恢复。运行灾难恢复时，做下面的步骤： 1、还原最近的数据库和日志快照。 2、如果从上次快照以来的日志文件存在，则将其还原到恢复的目录。 3、运行db_recover，指定-c选项，或者调用DB_ENV->open指定DB_RECOVER_FATAL标志，灾难恢复将检查日志和数据库文件，将数据库带到一个最近未损坏的日志文件所指示的时间所处的时刻。要注意的是只有那个时刻之前被提交的数据出现在数据库中  

潜在的页大小可以通过DB->set_pagesize方法设定，最小是512字节，最大64K，必须是2的整数次方，如果你没有设定，那么系统将根据潜在的文件系统IO块大小设定。 当选择一个页大小的时候有几点考虑：overflow记录大小，锁问题，IO效率，恢复性。 首先，页大小设定了溢出(overflow)记录的大小。溢出记录是key或者data项太大而不能存放于一个单个的数据库页中，因此存放于溢出页中，溢出页是哪些存在于正常的数据库结构之外的页。由于这个原因，对于溢出记录，修改或者获取溢出记录有明显的性能损害。如果页太小，使得不得不创建大量的溢出页，能严重影响性能。 第二，在Btree，Hash和Recno访问方式中，最细的锁是页级锁，选择一个太大的页将会引起进程或者线程等待更久，因为其他的thread of control正在修改同样页上的数据。 第三，页大小设定了数据库对于操作系统的IO粒度，Berkeley DB使用页级单位字节来进行磁盘读写的操作系统调度。对于许多操作系统，有一个内部的块大小，也被用来作为OS向磁盘进行IO的粒度。一般来说，对于Berkeley DB写入和OS写入同样大小的块会有较高效率。 选择一个数据库页小于文件系统块大小引起操作系统对于Berkeley DB的页进行额外的拼接或者操作，可能会影响性能。当页尺寸小于文件系统块大小的时候，当一个Berkeley DB要写的页没有在OS缓存中找到的时候，OS不得不从磁盘上读取一个块，将此页拷贝到要读的块中，然后将这个块写到磁盘上，而不是简单将这个页写到磁盘上。另外，由于OS会读比每次Berkeley DB请求一页时所严格要求的更多的数据到它的缓存中，OS的缓存可能在浪费内存。 相反，选择一个页大小大于文件系统的块大小可能引起OS读取比要求更多的数据。在某些系统上，连续读文件系统块可能引起OS开始进行预先读。如果请求一个单一的数据库页暗示要读足够的文件系统块来满足OS进行预先读的准则，OS不得不进行比需求更多的IO。 第四，当使用事务的时候，页大小影响数据库错误的恢复。