理论上，维护基于 BDB 的仓库所涉及的步骤与维护基于 FSFS 的仓库所涉及的步骤基本相同。然而，在历史上，Berkeley DB 仓库需要一些额外的 TLC[89]才能保持运行。本节将介绍 Berkeley DB 管理的一些独特方面。
如 名为“容错和恢复的必要性”部分中所述，如果未正确关闭 Berkeley DB 仓库，则该仓库有时会处于冻结状态。发生这种情况时，管理员需要将数据库回滚到一致状态。这是基于 BDB 的仓库所特有的，但是，如果你使用的是基于 FSFS 的仓库，则这种情况不适用于你。对于那些使用 Subversion 1.4 及更高版本以及 Berkeley DB 4.4 或更高版本的你来说，你会发现 Subversion 在这些情况下已经变得更加健壮。尽管如此，卡住的 Berkeley DB 仓库仍然会发生，管理员需要知道如何安全地处理这种情况。
为了保护仓库中的数据，Berkeley DB 使用了一种锁定机制。该机制确保数据库的各个部分不会被多个数据库访问器同时修改，并且每个进程在从数据库读取数据时都能看到数据处于正确的状态。当一个进程需要更改数据库中的内容时，它首先检查目标数据是否存在锁。如果数据未锁定，则进程锁定数据，进行所需的更改，然后解锁数据。其他进程必须等到锁被删除后才能继续访问数据库的该部分。（这与你作为用户可以对仓库中版本化的文件施加的锁无关；我们试图在边栏 “锁”的多种含义 中消除由这种术语冲突引起的混淆。）
在你使用 Subversion 仓库的过程中，致命错误或中断可能会阻止进程有机会删除它在数据库中设置的锁。结果是后端数据库系统被“卡住。”发生这种情况时，任何尝试访问仓库的操作都会无限期挂起（因为每个新的访问器都在等待锁消失，而这种情况不会发生）。
如果你的仓库发生了这种情况，不要惊慌。Berkeley DB 文件系统利用数据库事务、检查点和预写日志来确保只有最灾难性的事件[90]才能永久破坏数据库环境。一个足够谨慎的仓库管理员会以某种方式对仓库数据进行异地备份，但现在还不要急着去磁带备份存储柜。
相反，请使用以下方法尝试 “解除卡住” 你的仓库
-
确保没有进程访问（或尝试访问）仓库。对于网络仓库，这还意味着关闭 Apache HTTP 服务器或 svnserve 守护进程。
-
成为拥有并管理仓库的用户。这很重要，因为以错误的用户身份恢复仓库可能会以某种方式调整仓库文件的权限，使得即使在仓库被 “解除卡住” 之后，也无法访问仓库。
-
运行 svnadmin recover 命令
$ svnadmin recover /var/svn/repos Repository lock acquired. Please wait; recovering the repository may take some time... Recovery completed. The latest repos revision is 19. $
此命令可能需要几分钟才能完成。
-
重新启动服务器进程。
此过程可以修复几乎所有仓库卡住的情况。确保你以拥有并管理数据库的用户身份运行此命令，而不仅仅是以 root 身份运行。恢复过程的一部分可能涉及从头开始重新创建各种数据库文件（例如共享内存区域）。以 root 身份恢复将创建这些文件，使它们由 root 拥有，这意味着即使在恢复与仓库的连接后，普通用户也无法访问它。
在 Berkeley DB 4.2 版本发布之前，对于基于 BDB 的 Subversion 仓库来说，磁盘空间使用量最大的罪魁祸首是 Berkeley DB 在修改实际数据库文件之前执行预写操作的日志文件。这些文件捕获了从一种状态更改到另一种状态过程中所采取的所有操作，而数据库文件在任何给定时间都反映了特定状态，日志文件则包含所有之间状态变化的众多更改。因此，它们会迅速增长和积累。
幸运的是，从 Berkeley DB 的 4.2 版本开始，数据库环境能够自动删除自己的未使用日志文件。使用 svnadmin 在针对 Berkeley DB 4.2 或更高版本编译时创建的任何仓库都将为此自动日志文件删除功能进行配置。如果你不想启用此功能，只需将 --bdb-log-keep 选项传递给 svnadmin create 命令。如果你忘记这样做或之后改变主意，只需编辑仓库 db 目录中的 DB_CONFIG 文件，注释掉包含 set_flags DB_LOG_AUTOREMOVE 指令的行，然后在仓库上运行 svnadmin recover 以强制配置更改生效。
如果没有某种自动日志文件删除机制，日志文件会在你使用仓库时不断积累。这实际上是数据库系统的一项功能，你应该能够只使用日志文件来重新创建整个数据库，因此这些文件对于灾难性数据库恢复很有用。但通常情况下，你需要将不再被 Berkeley DB 使用的日志文件存档，然后从磁盘中删除它们以节省空间。使用 svnadmin list-unused-dblogs 命令列出未使用日志文件
$ svnadmin list-unused-dblogs /var/svn/repos /var/svn/repos/log.0000000031 /var/svn/repos/log.0000000032 /var/svn/repos/log.0000000033 … $ rm `svnadmin list-unused-dblogs /var/svn/repos` ## disk space reclaimed!
![[Warning]](images/warning.png)
|
警告 |
|---|---|
|
日志文件用作备份或灾难恢复计划一部分的基于 BDB 的仓库 不应该使用日志文件自动删除功能。只有当 所有 日志文件都可用时，才能从日志文件重建仓库的数据。如果在备份系统有机会将日志文件复制到其他位置之前，一些日志文件从磁盘中删除，则不完整的备份日志文件集基本上是无用的。 |
如果你使用的是 Berkeley DB 仓库，你所有版本化的文件系统结构和数据都存储在仓库 db/ 子目录中的一个数据库表集中。此子目录是一个普通的 Berkeley DB 环境目录，因此可以与任何 Berkeley 数据库工具一起使用，这些工具通常作为 Berkeley DB 发行版的一部分提供。
对于日常 Subversion 使用，这些工具是不必要的。Subversion 仓库通常需要的大多数功能已在 svnadmin 工具中复制。例如，svnadmin list-unused-dblogs 和 svnadmin list-dblogs 执行 Berkeley db_archive 实用程序提供的功能的子集，而 svnadmin recover 反映了 db_recover 实用程序的常见用例。
但是，仍然有一些 Berkeley DB 实用程序你可能会发现有用。db_dump 和 db_load 程序分别写入和读取一个自定义文件格式，该格式描述了 Berkeley DB 数据库中的键和值。由于 Berkeley 数据库在不同机器架构之间不可移植，因此这种格式是将这些数据库从一台机器传输到另一台机器（无论架构或操作系统如何）的实用方法。正如我们将在本章后面介绍的那样，你也可以使用 svnadmin dump 和 svnadmin load 来实现类似的目的，但是 db_dump 和 db_load 可以同样出色地完成某些工作，并且速度更快。如果经验丰富的 Berkeley DB 黑客需要出于某种原因对基于 BDB 的仓库中的数据进行就地调整，它们也可能很有用，而 Subversion 的实用程序不允许这样做。此外，db_stat 实用程序可以提供有关 Berkeley DB 环境状态的有用信息，包括有关锁定和存储子系统的详细统计信息。
有关 Berkeley DB 工具链的更多信息，请访问 Oracle 网站的 Berkeley DB 部分的文档部分，网址为 https://docs.oracle.com/cd/E17275_01/html/api_reference/C/utilities.html。/>。
