Unable To Extend an ID Table - Insufficient Memory

IBM Domino Server version 9.0.1 FP8 running on Windows Server 2008 R2

AMgr: Error executing agent ‘Agent Name’ in ‘database.nsf’. Agent signer ‘username/o’: Unable to extend an ID table - insufficient memory.

The application in question is quite large, having 2.5M documents. There are a number of agents that run After documents are created or modified, each updating a table in SQL. Everything has worked reliably for many years until recently, when the above error started to appear.

There are two replicas and on one server none of these agents will run without throwing the error, while on the other some will run fine while others throw the error.

To resolve the problem, I ran Compact -REPLICA -IDS_FULL=0. Before FP8 was released, this failed as there were documents that had more than 64KB Summary data. After FP8 was installed and the application upgraded to allow more Summary data, I tried the Compact again. This time the Compact ran to completion, but the Agents still throw the same error message.

Has anyone else experienced this issue on scheduled agents, where running Compact failed to resolve the issue? Can anyone suggest a way to fix the problem?

Thanks in advance

Dominic

Subject: Re: New replica

Hi Barry

That is an option, and it would give us some improvement, but the problem is present on both replicas, just more so on one than the other.

If all else fails, I will create an empty application and copy over all document one at a time, ensuring that they retain their current UNID so that the response hierarchy is maintained. Then I will create a new empty template and copy over the design elements one at a time and finally replace the design of the new application. But that is the last resort and if I can get the ID Table fixed by another means, I would be happier.

Kind regards

Dominic

Subject: Or if the database replicates quickly, drop stubs in a week.

What Barry said, set the stub retention time lower, to the outside # days your database might miss replication (purge interval, normally 90 days, you’ll see it on replication properties). Assume you’ll be on vacation, maybe a week? :slight_smile:

Subject: It also sounds as if the agents are trying to create documents.

There’re 2.5M documents. Why are the agents creating more?

Putting on the developer hat, you might need to split up the functionality, to where the agents are putting less useful informational docs into another database.

Subject: Re: It also sounds as if the agents are trying to create documents.

Hi Mike

The agents in question run when documents are created or modified and do not change any data themselves, at least not in the Domino environment. They push changes into SQL tables for reporting purposes.

I have considered splitting up the application but the bulk of the documents are related by $Ref fields. Where this is not the case, the numbers are so small that it would not benefit us much.

Thank all the same

Dominic

Subject: Agent log will be overwritten.

Also, even if you’re using system-level unprocessed lists, these lists do cost something. They also cost something to generate.

Dunno what the agent trigger is, but it sounds like it may be the agent firing off, that could be causing a problem. Is the agent in the middle of its script, or does it die just trying to startup?

If it’s dying just trying to start up I’d put a copy of the agent itself elsewhere to experiment with what’s actually causing the error.

Subject: new replica

Have you tried pulling a new replica over from the other server and see if that works? Are you sure about the deletion stubs? You say new fields any way of removing some fields?

Subject: Re: DeletionStubs

Thanks Barry

There are no deletion stubs, or there were none at the point after the Compact -REPLICA -IDS_FULL=0.

The usual cause for ID Table issues is excessive deletions, and there are usually a lot each month. But the problem became noticably worse on the server where a new field was added to 100K documents. The other server, while all changes were replicated via the cluster replication process, did not get any worse and only gave the error on some of the agents.

Kind regards

Dominic

Subject: Deletion stubs

How many deletion stubs are in the db? If the db does not replicate try setting it lower to like 1 or 2 days

A tool I used in the past nsftools - Tools - delstubs http://www.nsftools.com/tools/delstubs.htm helped identify and purge the db