我们如何绕过 Lotus Notes 60 Gb 数据库障碍
有没有办法绕过 Notes 数据库的数据库大小上限？ 我们正在压缩一个大小仍接近 60 GB 的数据库。 如果您能提供建议，非常感谢。
Are there ways to get around the upper database size limit on Notes databases? We are compacting a database that is still approaching 60 gigs in size. Thank you very much if you can offer a suggestion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
即使您可以找到突破 64GB 限制的方法，这也不是推荐的解决方案。 如果您希望提高 Domino 服务器的性能并保持稳定性，那么将应用程序拆分为多个数据库会更好。 如果您认为必须将所有内容都放在同一个数据库中才能进行搜索，请在 Domino Administrator 帮助中查找域搜索和多数据库搜索。
也许数据的某些部分是“旧的”，可以放入一个或多个存档数据库中？
也许您有很多大型附件并且可以将它们存储在一系列附件数据库中？
也许您有很多复杂的视图可以简化或消除，从而节省大量空间并将所有内容暂时保留在同一个数据库中？ （在不需要的列上删除排序，使用“单击列标题进行排序”是增加视图索引大小的可靠方法。）
Even if you could find a way to get over the 64GB limit it would not be the recommended solution. Splitting up the application into multiple databases is far better if you wish to improve performance and retain the stability of your Domino server. If you think you have to have everything in the same database in order to be able to search, please look up domain search and multi-database search in the Domino Administrator help.
Maybe some parts of the data is "old" and could be put into one or more archive databases instead?
Maybe you have a lot of large attachments and can store them in a series of attachment databases?
Maybe you have a lot of complicated views that can be streamlined or eliminated and thereby save a lot of space and keep everything in the same database for the time being? (Remove sorting on columns where not needed, using "click on column header to sort" is a sure way to increase the size of the view index.)
我假设您的数据库很大，因为文件附件也很大。 在这种情况下，请考虑 DAOS - 它将在文件系统上存储所有文件附件（服务器功能 - 对客户端和现有应用程序透明）。
作为奖励，它会找到重复项并仅将其存储一次。
更多信息请参见：http://www.ibm.com/developerworks/lotus/library /多米诺骨牌绿色/
I'm assuming your database is large because of file attachments as well. In that case look into DAOS - it will store all file attachments on filesystem (server functionality - transparent to clients and existing applications).
As a bonus it finds duplicates and stores them only once.
More here: http://www.ibm.com/developerworks/lotus/library/domino-green/
只是摸索一下：
使用 DB2 存储方法而不是 Domino 服务器？
Just a stab in the dark:
Use the DB2 storage method instead of to a Domino server?
我猜测 80-90% 的空间被文件附件占用。 我的建议是将所有附件移动到文件共享（前提是每个人都可以访问该共享），或者移动到每个人都可以连接的 FTP 服务器。
这并不理想，因为安全性成为一个问题 - 现在您需要管理 Notes 数据库和外部文件共享的凭据 - 但从 Notes 管理员的角度来看，这是值得的。
在 Notes 文档中，只需提供文件的链接即可。 如果用户通过 Notes 表单添加这些文件，也许您可以添加一些后台代码以在保存文档后从文档中提取文件，并将其替换为指向该文件的链接。
I'm guessing that 80-90% of that space is taken up by file attachments. My suggestion is to move all the attachments to a file share, provided everyone can access that share, or to an FTP server that everyone can connect to.
It's not ideal because security becomes an issue - now you need to manage credentials to the Notes database AND to the external file share - however it'll be worth the effort from a Notes administrator's perspective.
In the Notes documents, just provide a link to the file. If users are adding these files via a Notes form, perhaps you can add some background code to extract the file from the document after it has been saved, and replace it with a link to that file.
64GB实际上并不是一个绝对限制，你可以超过这个限制，我见过80GB甚至接近100GB，尽管一旦超过64GB你随时都会遇到问题。 限制实际上不是 Notes，它是底层文件系统，我在 AS400 上看到过这一点，但 Notes 的伟大之处在于，如果您确实遇到严重崩溃，您仍然可以访问所有文档，并使用以下命令将所有内容提取到新副本即使您无法再在客户端中打开视图，也可以安排代理。
最好的是定期归档，如果是文件附件，则任何超过两年的内容都不需要在主系统中，只需简短的概要和链接，您甚至可以有 5 年归档、2 年归档、1 年归档等，无论您使用什么平台来存储数据，数据都会不断积累并且必须进行管理。
The 64GB is not actually an absolute limit, you can go above that, I've seen 80GB and even close to 100Gb although once your past 64Gb you can get problems at any time. The limit is not actually Notes, its the underlying file system, I've seen this on AS400 but the great thing about Notes is that if you do get a huge crash you can still access all the documents and pull everything out to new copies using scheduled agents even if you can no longer get views to open in the client.
Your best best is regular archiving, if it is file attachments then anything over two years old doesn't need to be in main system, just brief synopsis and link, you could even have 5 year archive, 2 year archive 1 year archive etc, data will continue to accumulate and has to be managed, irrespective of what platform you use to store it.
如果问题确实是大文件附件，我当然建议考虑在您的服务器/数据库上实施 DAOS。 它仅适用于 Domino Server 8.5 及更高版本。 另一方面，如果您的数据库包含超过 100,000 个文档，您可能需要认真考虑将数据划分为多个 NSF - 对于该数量的文档，您需要非常小心您的视图设计、查找代码等.
DAOS 的一些成功记录：
http://www.edbrill.com/ebrill/edbrill.nsf/dx/yet-another-daos-success-story-from-darren-duke?opendocument&comments
If the issue really is large file attachments, I would certainly recommend looking into implementing DAOS on your server / database. It is only available with Domino Server 8.5 and later. On the other hand, if your database contains over 100,000+ documents, you may want to look seriously at dividing the data into multiple NSF's - at that number of documents, you need to be very careful about your view design, your lookup code, etc.
Some documented successes with DAOS:
http://www.edbrill.com/ebrill/edbrill.nsf/dx/yet-another-daos-success-story-from-darren-duke?opendocument&comments
如果您的数据库达到 60GB.. 不要使用 Domino 解决方案，您需要切换到关系数据库。 您需要在多个数据库之间存档或移动文档。 尽管您可以达到 60GB，但您不应该这样做。 活动数据库的性能受到显着影响。 对于静态数据库来说问题不大。
If you're database is getting to 60gb.. don't use a Domino solution you need to switch to a relational database. You need to archive or move documents across several databases. Although you can get to 60gb, you shouldn't do it. The performance hit for active databases is significant. Not so much a problem for static databases.
我还会考虑删除任何不必要的视图和内容。 他们的索引。 查看索引可能会占用 80-90% 的磁盘空间。 如果您无法删除它们，请简化它们的排序安排/公式并删除任何不必要的列排序选项。 我通过像这样的一些简单更改将 50GB 减半为 25GB，但几乎没有用户注意到。
I would also look at removing any unnecessary views & their indexes. View indexes can occupy 80-90% of your disk space. If you can't remove them, simplify their sorting arrangements/formulas and remove any unnecessary column sorting options. I halved a 50gb down to 25gb with a few simple changes like this and virtually no users noticed.
一次，一条路径可能是从用户开始。 所有用户都需要始终访问所有这些数据吗？ 如果不是，则需要拆分或存档。 如果是，则应用程序的设计可能存在缺陷。
从技术上讲，我会在之前的评论中添加一条建议，以检查许多选项压缩。 快速而肮脏：放弃所有视图索引，但如果您不希望用户骚乱，请务必至少重建默认视图的索引。 请参阅 updall
One path could be, for once, to start with the user. Do all the users need to access all that data all the time ? If no, it's time to split or archive. If yes, there is probably a flaw in the design of the application.
Technically, I would add to the previous comments a suggestion to check the many options for compaction. Quick and dirty : disard all view indices, but be sure to rebuild at least the one for the default view if you don't want your users to riot. See updall
还有一件事要检查：确保您已经检查过
[x] 对数据库属性中的
One more thing to check: make sure you have checked
in db properties.