3rd Try: problem with growing database - invalid / non existant document

HCL Domino Domino Forum
1

…please help…we have 4 replicas of a database → 3 of them growing over 64 GigaByte Limit. Normal size is nearly 40 GByte.

We tried many ways like:

  • Recreate the DB-File

  • Fixup

  • Compact (-B -D)

But every next morning at least the most important (of course!) database has reached the limit.

We discovered that the database size increases by steps of ~120 MBytes and

there is always an Error on the Server-Console:

NoteOpenCallback: n=5, TotalNotes=10, NotesToCopy=6

NoteOpenCallback: hNote=3A60, (source)NoteID=166172, status=0x227=Invalid or nonexistent document, hDestDB=A2

StreamNotes: Requested 10, got 9

Its always the same NoteID: 166172 , but with a simple view showing all docs by NoteID there are NO results. The NoteIDs in the View look like “NT00” + “Hexadecimal Value” for example “NT0001B22A” ???

We suspect the invalid/non existant document is in the Database with correct size, because all others had increased at least once, but thats not sure

Your help will be much appreciated

Best Regards

H.Mueller

2

Subject: 3rd Try: problem with growing database - invalid / non existant document

What agent(s) do you have running? Does the document numbers increase or just the size?

3

Subject: 3rd Try: problem with growing database - invalid / non existant document

What agent do you have running? Does the document numbers increaase or just the size?

4

Subject: RE: 3rd Try: problem with growing database - invalid / non existant document

First Thank you very much for your answer! Its just the size of the database, the number of documents is constant. Because its a mailinDatabase I checked the Agent running when new mail arrived, but I think I can exclude that. There were more than two steps of database increases between the agent was running two times.

There are some agents called by form or view actions, but today no user was working on the database so I think I can exclude its because of agents?

5

Subject: RE: 3rd Try: problem with growing database - invalid / non existant document

How about the view index?

6

Subject: RE: 3rd Try: problem with growing database - invalid / non existant document

All view indizes have together ~ 4 GB, but the difference between the normal db and the increased db is about 20 GB. You mentioned Agents can cause this, I have read another post about agents (in Notes Version 4/5)creating “hidden” documents when “edited and resaved” - uff??

7

Subject: May be Solution: problem with growing database - invalid / non existant document

Running Fixup on the only database replica NOT growing we get the message:

10.06.2004 18:27:21 Document NT00166172 in database D:\Lotus\Domino\Data\SSF\Projekte\PROJEKTSPEICHER.nsf is damaged: Document attachment is invalid

10.06.2004 18:27:21 Document (UNID OFC1256B06:0063FBE7-ONC1256E8A:0037A76F) in database D:\Lotus\Domino\Data\SSF\Projekte\PROJEKTSPEICHER.nsf has been deleted

Thanks Very Much for your help Michael

8

Subject: RE: May be Solution: problem with growing database - invalid / non existant document

I’m impressed your server supports a database of that size. I assume it has many large attachments (???).

Since Fixup is reporting “attachment is invalid”, that would be the first suspect. Have you compacted the one that is not growing? I’m fearing that the bad document or attachment is confusing the replicator.

Aside from the “attachment is invalid” message, I would have first guessed that view index size was the culprit. Use the the Administrator client, right click the database, and use Manage Views. This will help you see if all the space is consumed in view indexes. If you have millions of documents and views with many complex column formulas, you can easily double or triple the size of the database. How do you know the database is naturally around 40 GB?

9

Subject: Fixup was Solution: problem with growing database - invalid / non existant document

We have many large Attachments and we already archived about 1 GB and now we can continue: The fixup deleted the bad document and we decided to run fixup and compact regulary.

All replicas now have returned to normal size of ~40 GB.

Thank You very much for Your Help

H. Mueller