This strategy uses bitmap errors to locate data blocks containing information that belongs in the B-tree, but are no longer indexed because of errors and/or repairs to defective indices.
The algorithm is based on the fact that most bitmap errors are secondary to index errors. Therefore, it is optimistic about bitmaps and pessimistic about indices, and tends to error on the side of restoring more rather than less data to the B-tree. After using this technique, you should always check to see if obsolete, deleted data was restored. If data was restored, and GDS integrity has been restored, you can safely KILL the "extra" data.
IF THE INDICES HAVE BEEN DAMAGED FOR SOME TIME AND THE DAMAGE CAUSED DUPLICATE KEYS TO BE CREATED, this strategy raises the issue of which value is the "correct" value. Because most applications either form new nodes or update existing nodes rather than simply overlaying them, this issue seldom arises. Usually the application will fail in an attempt to update any "misplaced" node. If the problem does arise, the issue may not be determining the "correct" value, but the best available value.
IF THE DUPLICATE NODE PROBLEM COULD BE AN APPLICATION ISSUE, you can load the sequential file produced in DSE with an M program that detects and reports duplicate nodes. You can also use the block transaction numbers as clues to the order in which blocks were updated. However, remember that you generally cannot know which record was modified on the last update, and that DSE repair actions modify the block transaction number.
If the duplicate node problem poses a significant problem, you should probably not use DSE to repair the database, but instead, use journals to recover or restore from backups.
This strategy works well when the missing indices are level one (1). However, the time required increases dramatically as the level of the missing index increases. If you have a problem with a level four (4) or level five (5) index, and you have developed skill with DSE, you may wish to try the more technically demanding approach of repairing the indices.
Once you have corrected all errors except bitmap errors, SPAWN and use MUPIP INTEG FAST REGION NOMAP to get a list of all remaining bitmap errors. If the report includes any "Blocks incorrectly marked free", MAP them BUSY. Then use DUMP HEADER BLOCK= to examine each "Block incorrectly marked busy." If the level is one (1), DUMP the block GLO. In any case, MAP it FREE. Once all blocks have been collected in a sequential file in this fashion, use MUPIP LOAD to reclaim the data from the sequential file.
Example:
r !,"SET REGION to <DEFAULT>: ",r s:r="" r="DEFAULT"
w !
s in="db_integ.log",x="mupip integ -fast -nomap -region"
s teg="/bin/csh -c """_x_" "_r_" > "_in_""""
zsy teg
s out="db_drive",skip=$c(32,10,13)
s prefix="map -bl=",old="",lenold=0,blk=0
o in:(read:exc="g done"),out:newv
u out
w "dse <<yz",!,"find -region=",r,!,"open -file=","db.go",!
u in
f r x i x["marked" u out d out u in
; CAUTION: in the above line, "marked" MUST be in lower-case
;
done u out
w "close",!,"exit",!
w "yz",!
w "mupip load db.go",!
; comment out the line above if you wish to examine
; db.go and initiate the load separately
c in,out
zsy "/usr/local/bin/tcsh -c ""source db_drive"""
q
out f j=1:1:$l(x) q:skip'[$e(x,j)
s blk=$p($p($e(x,j,999)," ",1),":",1)
s state=$s($e(x,42)="f":" -busy",1:" -free")
; CAUTION: in the above line, "f" MUST be in lower-case
i state=" -free" w "dump -glo -bl=",blk,!
; CAUTION: in the above line " -free" MUST match the
; case in the $SELECT above
; comment out the above line (starting with "i state")
; if you wish to eliminate, rather than save,
; the contents of loose busy blocks
w prefix,blk,state,!
q
This routine provides a basic example of automating the technique described in this section. It must be run from an appropriate directory with a properly defined gtmgbldir, but can be extended to be more user friendly.