One solution to this limitation is to use DAOS: Domino Attachment and Object Service:
http://www.ibm.com/developerworks/lotus/library/domino-green/
Another solution is to use Domino-DB2 Integration:
http://www.ibm.com/developerworks/lotus/library/domino-db2/
Or, create a new database where all attachments of the current database will moved to.
Then the rich text field of the original document will contain a document link to where the attachment has been moved to.
How to fix a database that has reached the 64gb limit:
- Temporarily prevent replication
- Purge views
- Delete the database index
- Create an archive database
- Copy large documents to the archive database.
- If possible, delete the copied documents from the database.
- Sometimes this is not possible because document links that point to these large document will be broken. In this case, remove the contents of the document and replace it with a document link that points to the document you copied to your archive database.
- Run Fixup on the database. We need this to ensure that we can compact the database.
- Compact the database.
- If compact does not reduce the size of the database, try creating a new replica of the database. Then delete the old replica and replace it with a new replica
- Re-create the index.
- Re-enable replication.
- If the database has a replica that has also reached the 64GB limit, force a replication so that we get any update from that replica. Then delete that replica and create a new replica from our fixed replica.
More importantly, design your applications with scalability in mind!
Instead of performing a workaround by archiving large documents, a new database should be created, let's say: per quarter, per half year, or per year.
