Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

 
alt

Daniel Nashed

 

Maximum Database Size still 64GB? What about DAOS?

Daniel Nashed  15 December 2008 20:48:15


Today I got the question about the maximum size of a database. The current limit is still 64GB.
TN
#21093509 says the certified limit is 64GB but customers reported that databases do not work beyond this size.
 
It seems to be a limit in the internal database structure.

However with DAOS in Domino 8.5 the limit might change. The physical file and the structure of the NSF will be much smaller because the objects are stored in NLO (Notes Large Object) files in a separate file-system.


To verify I have created a test database a while ago with a beta release of 8.5

The documents have been created by cloning (opening the doc and saving it with a new UNID) .
Creating 10000 documents with a attachment size of 100MB each did only take a couple of seconds.


I just did the test to have a better understanding in which situations the files are still causing I/O and in which cases the reference is passed. Copying documents form one to another database is really fast. This is for example also helpful when the mail-router is delivering mail to local mail-databases.


Here is how it looks with 10000 documents


Image:Maximum Database Size still 64GB? What about DAOS?

So we have a database with almost 1 TB of data.

Not sure how much sense it would make but it would be possible with a DAOS enabled database ;-)



-- Daniel

Comments

1Paul Mooney  16.12.2008 0:01:57  Maximum Database Size still 64GB? What about DAOS?

Hi Daniel (nice to see you here at last!)

Off the record, I have heard that IBM .nsf structure starts to feel a pinch after 32GB size, but I have seen .nsf databases beyond 64GB functioning fine. Slow, but fine.

I think a problem that may occur with DAOS will be non DAOS replicas - for example you have a 500GB database that is only 30GB with DAOS.

The replicated .nsf may go onto a server that is not using DAOS but the file system has problems with large files

DAOS is really really cool, and many customers really want to implement it .. like.. yesterday, but solid understanding of the new strucutre is needed. Like yourself, we have an SNT session. Mine will cover DAOS as fully as possible at sphere.

I wonder when backup software vendors will have an API for DAOS enabled databases (my guess, 8 months).

2Bill  16.12.2008 9:16:12  Maximum Database Size still 64GB? What about DAOS?

W'eve actually seen a LIVE mailfile with over 254gb of information on it. And yes, it was in daily use. Slow - very very slow - but still worked.

Domino 6.5 too.

Scary, eh?

---* Bill

3Daniel Nashed  17.12.2008 9:16:05  Maximum Database Size still 64GB? What about DAOS?

@Paul, yes I agree it can happen quite easy when it is replicated to a server that is not DAOS enabled. But this can also happen when a user creates a local replica of a huge database... And that could be more often the case.

I am looking into DAOS since the first beta release was available. For me it is one of the best features to move to Domino 8.5. It will give better performance, saves space, reduces backup time, saves I/O and has a couple of other very positive effects on a server. I did a session about storage optimization at DNUG in June. The session is about DAOS and the already existing storage optimization features in 8.0.x. The slides are posted here -> http://www.nashcom.de/dnug

For backup vendors we have two steps. Currently the backup vendors can use the existing backup routines for NSF and backup the DAOS store (NLO files) separately with the normal file-backup functionality. The idea is that the retention time for the backup is lower than the retention time for DAOS objects. So in theory it should always work and backup vendors "just" need to make sure they coordinate their backups for NSF and NLO files accordingly.

But because things can go wrong they need a way to scan databases for missing NLOs and have a call-back for missing files similar to what the daosmgr has in the current beta.

So currently an admin would need to do this manually with the daosmgr after restoring a backup or when troubleshooting.

The good news is that daosmgr does provide all the functionality and you can redirect the output to a file. This could run on a single DB or on the whole server. But it can be quite complicated to restore in the eventually case when many NLO files are missing.

So in theory when nothing goes wrong backup should work but a backup is kind of an insurance and you need to be protected against all kind of problems.

So yes I fully agree that we need the similar functionality we have in daosmgr in the C-API!

I think IBM understood the need and they have been focused on getting the functionality done. I am pretty sure they will look into it for 8.5.1

-- Daniel

4Carl Tyler  17.12.2008 13:50:39  Maximum Database Size still 64GB? What about DAOS?

For US readers, Daniel's machine has the thousand separator as a . not a , so that's isn't 987 mb, but 987,000

5Yancy Lent  18.12.2008 16:44:25  Maximum Database Size still 64GB? What about DAOS?

Have you considered rerunning your test with no attachments and documents that border around the 1024 kb range to equal the same total database size. Maybe a log.nsf or domlog.nsf type document. Just to see if it changes things.

6Jens Bruntt  08.01.2009 7:05:23  Is there really an issue with backup here?

I was reading the documentation for DAOS. And it says the storage using DAOS is transparent to the API: "Attachment consolidation is completely transparent to users and API programs".

If the Domino backup vendors use the APIs for retrieving the Notes to back up then they aught to still pick up the attachments as if they were still physically stored with the Note inside the NSF.

7Sjaak Ursinus  18.02.2009 9:13:02  Maximum Database Size still 64GB? What about DAOS?

@Jens

This is a very interisting opinion. This need to be tested bij someone how things work when a backup is done and want to be restored to a differant server and then looks if the database hold the attachments or not.

8@Andreas  06.04.2009 20:21:09  Maximum Database Size still 64GB? What about DAOS?

I have realized that documents are going missing when using local replicas and umts.

If one my users does replicate all files then usually one mail/attachments gets the information that the file is used by another program.

This email is missing after looking to the sender emails.

There are few more issues but I have to say that this tool is very cool beside the bugs

9Johann Lumandas  22.11.2012 9:04:57  Maximum Database Size still 64GB? What about DAOS?

64 Gb or higher Database size are prone for Database Corruption. Even you enabled the DAOS and the logical size database are more than 64 Gb. Check also the Physical Database size which is the real database size. All attachment will move to DAOS base path depend on settings (Minimum size of object before Domino will store in DAOS)

And store as a single file. Assuming you send 4mb of mail into 1000 users w/o DAOS it consume almost 4GB but with DAOS only consumed 4mb in Harddisk.

10Ravi Gupta  16.08.2017 9:14:15  Maximum Database Size still 64GB? What about DAOS?

One of our notes db with beyond 64 Gb database size has corrupted.

Any suggestion to recover or repair it ?

We have tried all possible ways (fixup, compact, updall) from Domino admin.

Any good 3rd party software to repair? We are using Notes 9.0.1 with ODS version: 43

11Manuel  29.09.2021 1:59:37  Maximum Database Size still 64GB? What about DAOS?

Hi Daniel! i have Lotus Domino 9 and a database with 65GB and still works, very slow, but works.....when the database get to 68GB crushhh....and theres no way to fix it....just cant make that the database still running! so...can i do something about it? what is DAOS? can i get more space? pls....help! thankyou and appologize for my poor lenguague!!

12Daniel Nashed  29.09.2021 5:24:46  Maximum Database Size still 64GB? What about DAOS?

Hi Manuel,

newer Domino versions support databases up to 256 GB.

DAOS is a feature to allow moving attachments to NLO files (one file per attachment) to the DAOS directory and this allows logical databases sizes up to 1 TB.

The physical size is still limited to 64/256 GB depending on the Domino version/ODS.

You are replying to a post from 2008! ;-)

There is good documentation in the admin help for DAOS. But if this is just one database getting big, upgrade to the latest release and get up to 256 GB.

Domino 10.0.x introduced ODS 53, which has the higher limit. There is no chance to increase the size in an earlier ODS!

https://help.hcltechsw.com/domino/10.0.1/wn_ods_53_supports_larger_databases_and_folders.html

-- Daniel

13Manuel Vasquez  02.10.2021 11:07:54  Maximum Database Size still 64GB? What about DAOS?

Hi Daniel, how are you! Thank you for your answer. And yes, i saw the date of the post...ja! but i had an answer!!! ja ja! thank you again!

Just one more question to you....when i was removing documents from the database, showed me up a message that i cuuld not find out what the problem is....the message is ' Multi-Segment ID table length from Server is not length expected .....what's mean that?

Thanks for your patience Daniel. Hope you are well.

14Daniel Nashed  03.10.2021 13:13:55  Maximum Database Size still 64GB? What about DAOS?

@Manuel, sounds like an ID table is damaged. If your database hit the limit you have to be very carefully what you do until you managed to get the used data in the database smaller to fit into the 64GB and perform a compact -d to get rid of the views and hopefully ID tables will be OK.

I would do a compact -d first and then finally a fixup -j -f to ensure all parts of the database are OK.

Before you try any operations please take a OS copy of the database when the server is down to ensure to not make your problem worse!

Nobody can really say what happens when the database is over the limit and you run those operations. Good luck getting the database back to life!

-- Daniel

Links

    Archives


    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]