Kbase P126064: SYSTEM ERROR: Index 0 (PUB._User, _Userid): 0 index block pointers and 2 blocks found. (8780)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/04/2008 |
|
Status: Verified
FACT(s) (Environment):
OpenEdge 10.x
SYMPTOM(s):
SYSTEM ERROR: Index 0 (PUB._User, _Userid): 0 index block pointers and 2 blocks found. (8780)
idxcheck finds index corruption on the _User table
Database Security was never enabled
_User table was not deleted
No entries returned from select "_user-name" from pub."_user";
idxbuild (by T_able) for _user | _userid does not fix the corruption
CAUSE:
The errors are as a result of orphan index blocks in the Schema Area. iow, index blocks that do not belong to an index of a table. This block is not necessary related to the _Userid index. Because it's idxnum field happens to be 0 (so might be the rest of the header), idxcheck treats it as a block belonging to _Userid.
Idxbuild will not recycle orphan index blocks for schema indexes. _Userid index itself is actually fine. At the time of writting it is unknown what caused these orphan indexes.
FIX:
Options that are likely to remove the orphan index:
1.) Option 3 of idxfix is very much like idxcheck, except that: It could **possibly** also detect orphan index entries as well as orphan records while idxcheck could not detect orphan index entries and idxbuild will not recycle orphan index blocks.
Run: proutil dbname -C idxfix (online or offline) for the entire database:
Validate recids for index entries
Y
Fix indexes on Scan.
Y
2.) Since this corruption is in the Schema Area, the Schema mover (proutil -C mvsch) utility could be used.
Essentially, this moves Only the database schema out of the current schema, leaving behind anything that is not schema related into "Old Default Area". The old area will still have the orphan index blocks.
If the Schema Area only contains index data, then after the schema move there will be no useful data left in the "old" schema area. The old area could then be dropped (prostrct remove) or truncated (proutil -C truncate area "Old Area") and the problem will be resolved.
However, if there is non-schema data in the Schema Area then the "old" schema area will have the problem.
Run: proutil -C tabanalys to determine the objects in the "Old Area" then run "proutil -C tablemove" to move these objects to a new area. Finally, remove the "Old Area" as described above.