最近我们遇到了几次不愉快的经历，使用频繁的 Lotus Notes 数据库超出了 64GB 的限制。
数据库有一些空闲空间，这使得我们可以运行数据库压缩来解决问题，但是让数据库离线足够长的时间以使压缩能够独占数据库是一场真正的噩梦。
我们尝试了：
- 在数据库压缩时允许用户以只读方式访问数据库。
（压缩会在一段时间后失败，提示数据库已被修改） - 删除所有非管理员对数据库的访问权限
- 禁用数据库复制
- drop database.nsf - 将所有人踢出该数据库
- dbcache flush-关闭数据库缓存中打开的所有数据库
用户仍然会显示访问数据库，并且不允许独占模式压缩。
最终我们采取了以下措施：
- 删除所有非管理员对数据库的访问权限
- 重启服务器
- 在任何人尝试访问数据库之前，快速在服务器控制台中输入：“compact -c databasename.nsf”
有没有更简单的方法可以将所有人踢出数据库并强制进行独占数据库压缩？我们正在运行 Lotus Domino Server 8.5.3
答案1
compact -B是“原地压缩文件大小”。如果你还没有尝试过，那就试一试吧。
在我看来，这drop db.nsf行不通。试试看Drop All，如果行得通，你可以写一些代码，只删除访问该数据库的用户。
答案2
为什么不实施集群（配置为故障转移），然后您可以将用户切换到另一个集群。然后您有时间修复数据库并运行压缩。然后您还可以删除数据库并让它从第二台服务器重新创建它（重新创建的数据库将已经压缩）。
顺便说一句。我会启用（如果尚未启用）文档和设计压缩以及 LZ1，这可能有助于稍微缩小数据库（取决于内容）。
答案3
您可以尝试使用 Notes 客户端的 ncompact 实用程序进行离线压缩。它具有与 Domino 控制台中的 compact 命令相同的选项，但它直接在 nfs 上运行，无需打开 Notes 或运行 Domino。
如果您不想移动这个巨大的 nfs，您可以使用网络共享并在其上运行 ncompact。我强烈建议在其上运行 fixup，如果它使用旧的 ODS 版本，则将其转换为 ODS 5.1。
我还建议检查 nsf，不要让它们达到该大小，将文档存档并将它们移动到新的 nsf 副本。尽量将它们保持在几 GB 左右，这样您就可以经常运行修复和压缩，确保它们的一致性。
答案4
我在 Compact -C -DAOS ON 中遇到了同样的问题。它失败了，说压缩过早停止，因为另一个用户在压缩时对其进行了修改。停止路由器、smtp 和复制器任务可以解决这个问题。我不知道目前哪个任务负责，但正在运行