我正在使用第三方应用程序，该应用程序将BerkeleyDB用于其本地数据存储区（称为BMC Discovery）。随着时间的推移，它的BDB文件碎片化并变得非常庞大，BMC软件编写了一个紧凑的实用程序，该实用程序基本上使用带有新文件名的db_dump管道传输到db_load，然后用重建文件替换原始文件。
大文件所花费的时间非常长，可能需要数小时，而其他一些相同大小的文件需要花费一半的时间。它似乎真的取决于文件中的碎片级别和/或其中的数据类型（我假设？）。
提供的实用程序使用粗略方法根据数据存储区（由多个BDB文件组成）的总大小来估计持续时间。防爆。如果大于1G说“需要几个小时”，如果大于100G说“需要几个小时”。这根本没有用。
我想知道是否会有更好，更准确的方法，使用BerkeleyDB.6.0（在Red Hat上）提供的命令来估计特定BDB文件的db_dump / db_load操作的持续时间？
注意：尽管这个问题提到了特定的第三方应用程序，但它只是将您置于上下文中。这个问题对BerkelyDB来说是通用的。
答案 0 :(得分：0)
db_dump / db_load是通常的（可移植的）碎片整理方式。
较新的BDB（比如过去4 - 5年，当然是db-6.x）有一个db_hotbackup（8）命令，通过避免十六进制转换可能会更快。
（以下解决方案需要自定义编码）
还有一个DB-＆gt; compact（3）调用“可选地将未使用的Btree，Hash或Recno数据库页面返回到底层文件系统。”这可能会导致稀疏文件显得非常大（使用“ls -l”），但实际上只使用存储数据所需的块。
最后，有db_upgrade（8）/ db_verify（8），两者都可以使用DB-＆gt; set_feedback（3）进行自定义，以便为长时间操作执行回调（即进度条）。
在此之前，我会使用db_tuner（8）和db_stat（8）检查配置，并考虑一下在DB_CONFIG中调整参数。