Recovering Space from System Tables

In Kognitio, the usual way to recover space is to delete some data and then run either a reclaim or a repack. This is true for any data which has been marked as deleted. However, some system tables can accumulate metadata rows over time which are not marked as deleted, despite the associated objects having been dropped. This situation, and it’s resolution, is explained below.

Lazy Deletes

Kognitio uses a ‘lazy delete’ method to delete system table rows which are obsolete. For example, when a table is dropped, its row in IPE_ALLTABLE is marked as deleted, but the dependent rows in IPE_ALLBASE, IPE_ALLCOLUMN, and other system tables are not. These rows are deleted on the next CREATE [SYSTEM] IMAGE operation.

If CREATE [SYSTEM] IMAGE is not run regularly, it is possible that these orphan system table rows will use significant RAM and some disk space, and also slow down queries on the system tables. To address that, the RECLAIM SYSTEM TABLE command has been provided. To recover the RAM used by deleted system table rows, the command requires a global lock, which means no other sessions can be connected. A script can be used to abort other sessions before running the command. Note that all variants of the command complete very quickly, so the interruption to normal usage is very short.

usage:

RECLAIM SYSTEM TABLE [ROWS | RAM | ROWS AND RAM];

The ROWS option specifies that orphan rows should be marked as deleted - this operation does not require a global lock.

The RAM option specifies that the RAM used by deleted system table rows should be recovered - this operation requires a global lock.

Combining the two options with ROWS AND RAM results in orphan rows being deleted, then RAM occupied by deleted system table rows is recovered. This requires a global lock.

Note that none of the options will physically remove deleted system table rows from disk. For this you need a normal reclaim or repack.