FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.


Jul 20, 2017, 7:50 AM
11 Posts
topic has been resolvedResolved

Multi-Segment ID table length from Server

  • Category: Application Development
  • Platform: Windows
  • Release: 9.0
  • Role: Developer
  • Tags: Db.AllDocuments,error,Multi-Segment ID table
  • Replies: 9

Hi there,

got the below error message (labeled like several other errors as  error# 4005) from an agent's log. The agent collects data from several databases on our cluster - all Domino 9 server . The agent was developed and executed on a Windows 7 /Designer 8.5.3 FP6 platform.

<<< Multi-Segment ID table length from Server is not length expected ({dbname}.nsf)>>>

This error is bound to a certain Db with 3'150'160 documents and around 12.2 GB.
I could find out that this error is caused by the call:

n&=DB.AllDocuments.count.

For testing purposes I have split it into :

Dim coll as Notesdocumentcollection
Set coll=db.AllDocuments
n&=coll.count

The error arises in the 2. line.
We tried to verify the db with Ytria ScanEZ  - it gets the same error.

What does this error mean ? Couldn't find an official error description !
Any ideas / suggestions ?

TIA, Joe

Jul 20, 2017, 11:21 AM
1 Posts
RE: Multi-Segment ID table length from Server

Probably an access problem.

Check if the agent signer is supposed to access the database or if the windows account used for the domino server has enough rights.

Jul 21, 2017, 2:18 AM
11 Posts
Multi-Segment ID table length from Server

Thanks for your reply Emilie

Unfortunately it is not a rights problem. The agent clearly has acces to the DB (can read ACL, Data docs etc.) and I meanwhile have written a quite slow but working workaround:

Have replace the n&= DB.AllDocuments.Count by a method, that first tries to use the normal AllDocuments method and if this one fails (error 4005) it creates a NotesNoteCollection for all DataDocuments and so gets the number of documents. But (!!!) this is very slow, it takes around 100-160 sec alone for this one DB ! The agent usually needs 20 seconds for all 400+ db's ... ;-)

 But this is a  workaround and  not really a solution for this error. The question is what is going on in this DB. Is there more coming ?

Will today create a copy and then try to compact the whole DB.

Will keep you informed.

Joe

Jul 22, 2017, 5:46 PM
36 Posts
I believe the idtable from the source is close to full
causing the indigestion. Apparently when the idtable flows over the wire, the client code leaves some gas in each of the chunks of memory for future growth. Unfortunately this gas is needed now but the client doesn't have a way to reclaim this gas for current use.

NOTE: I'm not that familiar with this area of the code, and it is just from a quick perusal of the code that I've come to this conclusion. You should probably open a PMR to get a definitive answer.


--Steve
swatts@notesdev.ibm.com
Jul 24, 2017, 4:32 AM
11 Posts
Found a solution !

Hi all,

First of all , Steve, thanks for your reply, I think your explanation is pretty close to what actually happend.

Meanwhile we have compacted the database and it's size went down from 13 GB to only 4GB ! And, most important, afterwards I could and still can get the total amount of docs in the database via db.GetAlldocument.count.

This made me a bit curious about what could have been the reason for such a big difference in size  as there were no data losses at all. I found out, that this DB is used as a backup DB for a ticket DB. Every day new tickets get stored in it and ... everyday those older than 1 year -  get deleted. So obviously this DB must have been used for a while without compacting and I assume that all those deletion stubs must have added up to a huge amount and have caused this condition (my theory). But its strange that the cluster servers do not report a db with such extreme conditions. 

I really would appreciate if IBM could give us their official error explanation(s) ...

Joe

 

Jul 25, 2017, 2:18 PM
36 Posts
What release of domino is running on the server ? <eom>
Jul 25, 2017, 2:28 PM
36 Posts
Okay, did a little digging
With the introduction of dbmt, the purge has been pushed off to either the compact process or the dbmt process, depending on which you run. So if the database hasn't been compacted in quite some time, that would explain the accumulation of the stubs/documents.

As for the servers, the admin client does show the last compact time of the database (assuming you are running 9.01fpx). I believe it allows sorting on the last compact time column so it is easy enough to see if there is a potential issue building up.

If there is something more you are asking for, I'd have to defer to someone else, I'm just the db guy but I can find out who to ask.


--Steve
swatts@notesdev.ibm.com
Jul 26, 2017, 2:18 AM
11 Posts
Multi-Segment ID table length from Server

Hi Steve,

thanks so much for your reply.

Yes, 9.01 indeed. I will inform our administrators about that compact column you described.

Appart from this will my agent in the future be able to handle such a condition and  will add a warning line in the admin email and  all logs concerned.

Joe Herrmann

Jul 27, 2017, 4:15 AM
11 Posts
Multi-Segment ID table length from Server

Hi there,

got the below error message (labeled like several other errors as  error# 4005) from an agent's log. The agent collects data from several databases on our cluster - all Domino 9 server . The agent was developed and executed on a Windows 7 /Designer 8.5.3 FP6 platform.

<<< Multi-Segment ID table length from Server is not length expected ({dbname}.nsf)>>>

This error is bound to a certain Db with 3'150'160 documents and around 12.2 GB.
I could find out that this error is caused by the call:

n&=DB.AllDocuments.count.

For testing purposes I have split it into :

Dim coll as Notesdocumentcollection
Set coll=db.AllDocuments
n&=coll.count

The error arises in the 2. line.
We tried to verify the db with Ytria ScanEZ  - it gets the same error.

What does this error mean ? Couldn't find an official error description !
Any ideas / suggestions ?

TIA, Joe

Jul 27, 2017, 3:37 PM
360 Posts
Interesting thread, thanks Steve.

Just for future reference, I've run into a number of databases that claim 95% & up usage. Then on compact, the size of the DB drops like a rock (well over 50% recovered).

I'm not sure of the cause but this sounds possible. I've taken to requesting compact for databases that seem large for their doc counts.


FORUM PLAN UPDATE
Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.