Salesforce

Truncate Area not deactivating all indexes

« Go Back

Information

 
TitleTruncate Area not deactivating all indexes
URL NameP144938
Article Number000151149
EnvironmentProduct: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Question/Problem Description
PROUTIL -C truncate area does not deactivate all indexes

Truncated Tables where indexes are in another Area, are deactivated
Truncated Tables which only have a 'default' index in the Schema Area, are deactivated
Truncated Tables where indexes are also in the same Area, remain active
Truncated Tables where some indexes are in the same Area remain active and some of that table’s indexes are in another Area remain active

Truncated Indexes where table is in another Area, remain active
Truncated Indexes where table is in another Area with the remainder of that table’s indexes remain active

Indexes in an Area that was truncated remained active for a table that wasn't truncated 
Table was truncated and its non-truncated indexes remain active
 
Steps to Reproduce
Clarifying Information
PRIMARY index may or may not be deactivated after Truncate Area
PRIMARY index must be active in order to delete the table before removing the last area extent
PRIMARY index must be active in order to run idxactivate online
Deleting a table results in index corruption when indexes keys are cleared by truncate area but the index remains active
Error MessageRecord <recid> in block <number> has table <number> which doesn't exist. (5433)
Defect NumberDefect OE00183289 / PSC00212733
Enhancement Number
Cause
When part of an area truncate that doesn't include the table data, index key data are cleared but the indexes are not marked as inactive.  Keeping these indexes active will result in database corruption if the table is later dropped or data is added or deleted from it.
Resolution
Apply OpenEdge 10.1C04, 10.2A02 Service Packs or Upgrade to OpenEdge 10.2B where this issue has been fixed.

The following documents the correct active/inactive index behaviour post truncate area:

If an Index is truncated as part of an Area truncate
  1. If the indexes associated Table data resides in the same Area the index can remain active, since there are no invalid data the active indexes are pointing to (similar to when a table is first created with active indexes).
  2. If the indexes associated Table resides in a different Area than the one being truncated, the index must be marked inactive
If a Table is truncated as part of an Area truncate
  1. All indexes in the same Area (which are also truncated) can remain active
  2. All indexes in other Areas associated with tables in the truncated area must be marked inactive

After running a proutil -C truncate area operation, use VST tables to pre-check the active/de-active status of related indexes. For example finding which PRIMARY indexes are active/de-active before (say) deleting the table after truncate area (the primary index needs to be active in order to delete a table).
 
OUTPUT TO "index_primes.file".
PUT UNFORMATTED "some" SKIP.

FOR EACH _file WHERE _file._file-number > 0 AND NOT _file-name BEGINS "SYS",
   FIRST _index WHERE RECID(_index) = _file._prime-index NO-LOCK:
      PUT UNFORMATTED _file-name SKIP _index-name SKIP.
END.

 
Workaround
0.  Revert to backup
1.  Run IDXBUILD offline
2.  If the associated table resides in it's own area or the same area as other tables who's indexes were in the truncated area, then truncate the table area as well
Notes
Keyword Phrase
Last Modified Date6/27/2016 11:07 AM

Powered by