最近我们遇到了一些令人讨厌的经验，那就是大量使用的Lotus Notes数据库已经超过了64GB的限制。
数据库有一些松散的空间，使我们能够运行数据库压缩来解决问题，但是将数据库离线足够长的时间来压缩以独占使用数据库是一个真正的噩梦。
我们尝试了：
仍然有用户将显示为访问数据库，并且不允许独占模式压缩。
最终我们诉诸于：
是否有一个更简单的方法来踢每个人从数据库，并强制独家数据库压缩？ 我们正在运行Lotus Domino Server 8.5.3
compact -B是“在文件大小减less到位”。 试试看，如果你还没有。
在我的理解drop db.nsf不起作用。 尝试Drop All ，如果这样的作品，你可以写一些代码，只有用户访问该数据库。
为什么不实施一个集群（configuration为故障切换），那么你可以通过另一个切换用户。 然后你有时间修复数据库并运行一个压缩文件。 然后，您也可以删除数据库，并让它从第二台服务器重新创build（重新创build的数据库将已经压缩）。
顺便一提。 我将启用（如果尚未启用）文档和devise压缩与LZ1，可能有助于缩小数据库一点点（取决于内容）。
您可以使用Notes客户机的ncompact实用程序来尝试离线压缩文件。 它与Domino控制台中的compact命令具有相同的选项，但是它可以在不打开Notes或运行Domino的情况下直接在nfs上运行。
如果你不想移动这个庞大的NFS，你可以使用networking共享，并运行它。 我强烈build议运行fixup，并将其转换为ODS 5.1，如果它使用旧的ODS版本。
我也build议检查nsf并且不要让它们达到那个尺寸，将文档归档到新的nsf副本。 尝试维护他们几个千兆字节，所以你可以运行修复和紧凑经常确保其一致性。
在使用集群中的新副本replace主服务器上的副本之前，我build议确认文档数量相同或相当接近，并且集群服务器上的副本没有任何结构性问题。 我将通过在群集上的数据库上运行compact来检查此问题，并parsing群集服务器上的控制台日志以查找错误。
我遇到与Compact -C -DAOS ON相同的问题。 它没有说压缩过早停止，因为另一个用户修改它，而它被压缩。 停止路由器，smtp和复制器任务解决了这个问题。 我不知道现在哪个任务是负责任的，但正在工作