This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


Jul 24, 2017, 8:32 AM
10 Posts

Found a solution !

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

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, 6:18 PM
32 Posts
What release of domino is running on the server ? <eom>
Jul 25, 2017, 6:28 PM
32 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

This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal