Informix - Problem description
Problem IT26764 | Status: Closed |
DISCARD OPTION FOR ROLLING WINDOW FRAGMENTATION STRATEGY DOES NOT AUTOMATICALLY DELETE OLD FRAGMENTS AS DOCUMENTED | |
product: | |
INFORMIX SERVER / 5725A3900 / C10 - IDS 12.10 | |
Problem description: | |
Per the Informix 12.10 doc, the DISCARD option of the Rolling window clause is supposed to automatically discard older fragments beyond the limit defined by the clause. https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ib m.sqls.doc/ids_sqs_2111.htm "When either of these limits is exceeded, the excess interval fragments are automatically destroyed or detached by the database server, as specified by the DISCARD or DETACH keywords respectively." However, in 12.10.FC7 and 12.10.FC12, the DISCARD option is not behaving as documented. For example, if you define a rolling window clause to maintain 10 fragments, once an 11th fragment is created it just gets added to the next dbspace and the oldest fragment outside the 10 fragment window remains without getting destroyed. This continues indefinitely as each new fragment is added until the dbspaces run out of free space. | |
Problem Summary: | |
Local Fix: | |
The syspurge() function can be used to remove older fragments that were not discarded past the rolling window limit, though in the current version this will result in the next fragment being stored in the first dbspace in the list, not the next dbspace that should be up after the most recent fragment. | |
Solution | |
Workaround | |
not known / see Local fix | |
Comment | |
This is expected behavior. | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 26.10.2018 03.12.2019 03.12.2019 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) |