A problem was
introduced in v4.3 where DBKEYs (line numbers on database storage
area pages) were not being reused as efficiently as possible. This
resulted in the space allocated for the line index (not the space
used by your data) to be lost. Ideally, the DBCS would allow a DBKEY
to be reused after the process which deleted the line (record) has
committed its transaction and unbound from the database.
While in most environments, the optimal time to allow DBKEY reuse
would be after the commit, there are some valid reasons for waiting
until the deleting process unbinds from the database.
The problem introduced in v4.3, caused DBKEYs to
be reused only when a single process was attached to the database.
Thus, at most sites, DBKEYs would never be reused.
For each record that was deleted, eight (8)
bytes would be lost if the storage area has snapshots, or four (4)
bytes if snapshots were not allowed for that area. Unfortunately,
the DBO/ANALYZE report does not report space used by line indices,
so it is possible for ANALYZE to show 100% space available, but for
the area to completely full!
To determine if your database is suffering from
excessive unused dbkeys, you must use DBO/DUMP to dump out the
storage area pages. If the pages contain large numbers of
"empty" lines (locked by), then this is probably a result
of this problem. In severe cases, it is not uncommon to see
relatively small pages contain a 80 or more "empty" lines
while larger pages may contain even more empty lines.
Recovering the space lost to these dbkeys may be
difficult. The excess dbkeys at the end of the page can be freed by
using DBO/RESTORE to restore the area, while recovering dbkeys in
the "middle" of the page will require an unload/load of
the affected storage areas. While this problem was fixed in v4.3b
and v5.0a and all versions since, your database may still be
suffering from the ill-effects of this problem.
