The hardships of enourmous mail files.
I manage an environment with over 1800 mailboxes that are greater than 2GB (including hub and cluster mate copies) and 66 above 10GB. The physical limit of a Domino database is 64GB.
However, anything beyond 2GB becomes very difficult to manage and here’s why.
1. Databases become corrupt very often.
2. Running Fixup or Compact on a weekly basis as part of Domino routine maintenance becomes problematic because the server is always running the maintenance on the databases. In fact, you’ll need to split up fixup and compact to run on specific directories during different evenings of the weeks. You may even want to run Updall on different directories different nights of the week.
3. Backups take forever and may not finish before the beginning of your work day.
4. Opening the mailboxes takes a very long time because it has to index the inbox every time you open it (if the user does not file messages to folders, which most don’t).
5. You pretty much can’t have full text indexing turned on for the server copies of the database because the full text indexing will be continuous around the clock on your server, not to mention more disk space required on server.
6. We’ve had some very strange things happen with Blackberry Enterprise Server accessing very large mailboxes. Specifically, We have had instances where a Domino server running Blackberry Enterprise Server (BES) can have frequent outages in IDTable code when working with large ID tables, which causes the server to crash. See technote titled “BES server crash in IDTable code”
7. If users have local replicas of their mailboxes, sometimes their hard drive is not large enough, sometimes the local replica becomes corrupt on the hard drive because no maintenance (fixup/compact) is ever run on it.
8. Creating new replicas onto new servers can take a week across the wire.
The list goes on.
These are real world examples of issues that I come up against every week. The best practice is to have quota policies in place that the upper management supports.
The second major thing to note here is that a proper archiving solution needs to be implemented. The local archiving that is built into Notes is often times not sufficient if you have so many enourmous mail files.
6 Responses to “The hardships of enourmous mail files.”
Leave a Reply
I'm currently
for Lotus Notes / Domino consulting engagements.
Connect with me:
We have many, many large mail boxes, but do not see the same type of corruption as you report. Are you running transaction logging? There are several tuning parameters for full text indexing as well that can assist with the overhead that updaters may be experiencing. There are also parms in 8.0.x that assist with the inbox view build. Feel free to contact me offline if you’d like to discuss.
in this case, I believe some education should be given to users on how to manage their mail files.
If they need to keep all emails because of legislation or something the like.. .then an archiving solution is needed
Upgrade to 8.5 asap and DAOS the mail files. With mail files this size, most of it must be attachments and large savings can be done!
I have the luxury of a small environment where extra hand-holding is possible — but also required.
For large mailboxes (over 5GB) I’ve tried:
- Scheduled server-based archiving
- Creating date-limited replicas for local and backup
- Repeated reminders to users that it’s the size of the inbox that limits the speed of working in mail.
They’re all stopgaps. I can’t imaging why users want six years of messages in their live mail. I suspect it’s mostly laziness.
We have not had any trouble with BES hitting the large mailboxes.
I do split the server maintenance tasks up onto different nights even with under 50 mailboxes on the server.
Domino 8 has an inbox management feature that removes older messages from the inbox folder, giving your servers and users a nice performance boost. Users can still find the messages in the All Documents view.
Domino 8,5 has DAOS and improved compression features, which will dramatically decrease mailbox file size.
But a proper archiving solution is still an important factor in managing your data and storage. (Of course, I work for an archiving vendor, so I’m biased.)
-rhs
There are some fundamental flaws to our environment that will always be flaws no matter the tool. A complete void of IT training of any kind, no corporate policies on the size of mail boxes/quotas, a 50MG attachment limit, most of the larger mailboxes belong to upper management or traders who are big revenue generators, most attachments are scanned contracts that go back and forth between our company and external parties, and the general attitude of IT management that imposing any kind of policies on the revenue generators might be seen as interfering with their business.
@Richard – I have heard about the Inbox maintenance agent even being run in R7 environments. Once everyone gets to R8.5, the Inbox maintenance and DAOS will go along way to alleviating these issues. Getting from 6.5 to R8.5 is a different story.
@Patrick – We have very spoiled users that are “too busy” for interruptions (training). Training, Archiving, plus R8.5 would be the best combination of solutions for our environment. We are working on implementing an operational archiving solution and already have compliancy capturing in place, but training and R8.5 probably will probably never happen in our environment. We are in the beginning stages of a migration to Exchange and I suspect that there is a feeling by many people in the organization that Exchange will make all the problems go away.
@Marie – We are not running transaction logging unfortunately.
We have no attachment limits either unfortunately. I’ve seen attachments over 600Mb in users’ databases. However, again we do not have the corruption that you’re reporting. Another item comes to mind – there was a support site flash recently that reported corruption due to using compact
-c -i combination with 8.0.1. So be sure that you are using either just -c or -B as that may reduce the corruption being caused by compacts. With transaction logging and a backup system that supports transaction logging – you wouldn’t be required to backup up all databases every day – only when their DBID changes (when compacts or fixups run). So that may also be something to consider. Check the number of updaters that you are running as well.