Error: "Unable To Extend an ID Table - Insufficient Memory"

Technote (troubleshooting)


Problem

Error: "Unable To Extend an ID Table - Insufficient Memory"

Cause

The ID Tables are an in memory structure used to hold lists of notes. Currently there is no way to display how full these would be. The ID Tables contain ranges of ID's so the size is variable. As the allocated and deleted notes become more fragmented the tables take up more memory.

Resolving the problem

This issue has been reported to IBM Quality Engineering under SPR # JPAI6W8KUJ and it is fixed in IBM Domino 9.x series.

For Domino 8.5.x version , if customer upgrades to 8.5.3 FP3 , then hotfix can be requested to IBM Technical Support.

New functionality is added to compact task as below

  • Compact -REPLICA (aka ID Table Re-org Feature)

A mechanism to create a new replica in-place in order to internally reorganize the IDs in a database to avoid ID table fragmentation that results in database access failure. This is accomplished via the compact utility with a new set of switches to control the new functionality.

  • There are additional benefits with the new compaction

I. Allowing access to the database during the compact (except during the short duration of a rename phase) provides a reasonable trade-off to the longer duration compact of the database.

II. Optionally allowing a pending/wait time period when compact is finishing up to improve the ability for the replacement of the original database to retry and eventually succeed.

III. Optionally perform a server restart too if the replacement times out (see II. above) where the replacement completes at server restart.

The compact happens in phases as below :

1. ID Table analysis (optional) - calculates fullness of ID table to determine need for compaction

2 . Synchronize temp database with original database - Get initial full set of notes

    a. Note Copy Phase - Outputs to a new temp copy of database the notes, keeping existing deleted notes in contiguous sets to avoid ID table fragmentation
    b. View Synchronization - Build views in temp copy based on views from original
    c. Unread synchronization - Build unreads based on unreads from original

3. Replace -

    a. Drop all users from database
    b. Take database offline
    c. Replace original with temp, make original the old original

4. Synchronize new NSF database with original NSF database - copy any new notes incrementally that are new since initial sync given in point 2

    a. Note Copy Phase - Outputs to a new temp copy of database the notes, keeping existing and deleted notes in contiguous sets to avoid ID table fragmentation
    b. View Synchronization - Build views in temp copy based on views from original
    c. Unread synchronization -Build unreads based on unreads from original

5. Bring database back online.

Note: If any of the phases after 2 fails due to a soft time out (not errors), the server restart can be applied to complete the compact

  • Indirect file

The re-org compaction is currently supported via indirect files or command line.
Here is a sample indirect:

mail\sender.nsf -REPLICA -REN_WAIT=1 -RESTART -IDS_FULL=10

Where:

-REPLICA - Compact via the background replication mechanism

-REN_WAIT=<nn> - Length of time in minutes to continue to try and rename after the replication and synchronization phase is complete

-RESTART - Set to one if a server restart should occur to allow the compaction rename to complete on server startup

-IDS_FULL=<n> - % Fullness of the IDTable for compact to occur. (0 means all the time)

** For Domino 9.0, due to defect reported in SPR # TSOE95L8PY, IDS_FULL need to to pre-fix number with a '0' for percentage for the function:

For example for 70% enter:

-IDS_FULL= 070

for 10%:

-IDS_FULL=010

  • Known Caveat with creating a new replica:

The new compact -REPLICA essentially creates a new replica and replaces the existing database on the server automatically. Notes client sessions that are connected to this database will be dropped in this process.

However, there are occasions that note's client will have problems with new sessions accessing views on the new replica after the new replica is in place. This is due to optimization on the client which cache information in memory concerning server replicas. To flush the cached information, the notes client may require the database be closed and re-opened.

IBM is investigating an implementation change to correct this behavior with the new feature so the client does not require user intervention.

Compact Replication – Additional Background

It internally reorganizes the IDs in the new replica; thus, does not maintain NoteIDs (So comapct -Replica will change original NoteID which Full Text Index is based on. So, full text index should be rebuilt after database running "compact - replica", ex: have to use updall -X. Otherwise, search result will be incorrect and list the new docs which occupying original NoteID.

Rate this page:

(0 users)Average rating

Document information


More support for:

IBM Domino

Software version:

8.5.3.3, 9.0

Operating system(s):

AIX, IBM i, Linux, Linux zSeries, Solaris, Windows, Windows 64bit, i5/OS, z/OS

Reference #:

1635439

Modified date:

2014-04-10

Translate my page

Machine Translation

Content navigation