The query corresponding to each monitoring element to check GC (Garbage Collector) information is as follows.
Main Column Description
| Column | Description |
|---|---|
| GC_NAME | There are two GC names. MEM_LOGICAL_AGER is a GC that deletes the old version of the index, and MEM_DELTHR is a GC that deletes the old version of the table record. |
| SCNOFTAIL | The number of the most recent version among the old versions to be deleted identified by GC. |
| MINMEMSCNINTXS | The number of the oldest 'old version'. |
| GC_GAP | Each GC means the amount of the old version to be deleted. The larger this value, the greater the amount of old version to be deleted. At this time, if scnoftail> minmemscnintxs, the deletion cannot proceed because of the active transaction. Conversely, if scnoftail <minmemscnintxs, the deletion is still in progress, but it can be judged that the old version to be deleted is increasing due to the completion of the update transaction. |
Query Being Executed in a Transaction Where the Memory DB GC is Waiting
The transaction that GC is waiting for refers to the transaction referring to the 'oldest version in Altibase'. If the GC does not work and waits indefinitely due to such a transaction, the memory usage can also increase infinitely, so it is one of the factors to check when the GC gap increases.
By executing the query below, the user can see the query executed in the session where the GC is waiting for the transaction. In addition, it can be usefully used when detecting queries that perform an index scan but consume instantaneous CPU as it is no different from a full scan due to its poor distribution.
Please note that depending on the situation, it must be performed periodically and repeatedly because it may not be detected in one operation.
Or