Conference orarep::nomahs::rdb_60

5115.0. "drop index, NODBK error" by NLVMS3::ADRIEL () Thu Mar 06 1997 11:26

	Oracle Rdb V6.1-04
	OpenVMS/VAX V6.1

	Hi,

	since a few days customer gets Rdb bugcheck while running application.
	Exception is : PSIHASH$DELETE + 88

	Via the bugcheck I know which table and index is involved.
	Although It will be necessary to see what the possible cause of the 
	hashed index inconsistency is, the primary goal is to get rid of
	the bugcheck eg. drop/recreate the index
	
	There is 1 table with 3 hashed indices. 2 out of 3 indices are dropped.
	Storage map is altered NO PLACEMENT.
	Drop of index BESTAND_IND (log. area 77) fails with error:

%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer associated 
with a record
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-NODBK, 77:1410:3 does not point to a data record
 
	Any idea how to delete this index?

	thx in advance,

	Adri van Driel

below  page dumps of relevant area's:

                 002C 00000582  0000  page 1410, physical area 44
                        1B72039E  0006  checksum = 1B72039E
               009B0DD5 407116A0  000A  time stamp =  6-MAR-1997 16:38:15.05
                       0000 005E  0012  94 free bytes, 0 locked
                            0004  0016  4 lines
                       0005 03E4  0018  line 0: offset 03E4, 5 bytes
                       0119 02CA  001C  line 1: offset 02CA, 281 bytes
                       0119 01B0  0020  line 2: offset 01B0, 281 bytes
                       0119 0096  0024  line 3: offset 0096, 281 bytes

                        00000000  0028  line 0: TSN 0
                        0013558C  002C  line 1: TSN 1267084
                        00132932  0030  line 2: TSN 1255730
                        00136B5D  0034  line 3: TSN 1272669

00030003000300030003000300030003  0038  free space '................'
                                  ::::  (4 duplicate lines)
    0003000300030003000300030003  0088  free space '..............'

                       004D 2005  0096  line 3: bucket for hash index 77
                                  ....  total hash bucket size: 281
              004D 0000056C 0004  009A  bucket overflow 77:1388:4
                              00  00A2  flags 0
                        00000001  00A3  duplicate count 1
              0072 000001C3 0007  00A7   pointer 114:451:7
                              FF  00AF   key len: 255 bytes
4B4341425F4D4F52465F445F42455600  00B0   key: '.VEB_D_FROM_BACK'
5F464549484352415F45434946464F5F  00C0   key: '_OFFICE_ARCHIEF_'
5D3633333431303030305B3A544F4F52  00D0   key: 'ROOT:[000014336]'
534D565F5A5245565F5254425F424556  00E0   key: 'VEB_BTR_VERZ_VMS'
562E35313632303030415F3135323030  00F0   key: '00251_A0002615.V'
202020202020202020544B5245575245  0100   key: 'ERWERKT         '
20202020202020202020202020202020  0110   key: '                '
                                  ::::  (8 duplicate lines)
  202020202020202020202020202020  01A0   key: '               '
                              00  01AF  padding '.'
         

*******************************************************************************

                   002C 000001C3  0000  page 451, physical area 44
                        19DE013E  0006  checksum = 19DE013E
               009B0DD5 407116A0  000A  time stamp =  6-MAR-1997 16:38:15.05
                       0000 00BE  0012  190 free bytes, 0 locked
                            0008  0016  8 lines
                       000B 03E2  0018  line 0: offset 03E2, 11 bytes
                       0064 02B6  001C  line 1: offset 02B6, 100 bytes
                       000D 018E  0020  line 2: offset 018E, 13 bytes
                       0119 019C  0024  line 3: offset 019C, 281 bytes
                       0000 0000  0028  line 4: empty
                       0064 031A  002C  line 5: offset 031A, 100 bytes
                       0064 037E  0030  line 6: offset 037E, 100 bytes
                       0078 0116  0034  line 7: offset 0116, 120 bytes

                        00055E78  0038  line 0: TSN 351864
                        0011D1F7  003C  line 1: TSN 1167863
                        00136B72  0040  line 2: TSN 1272690
                        00136D92  0044  line 3: TSN 1273234
                        00136B7C  0048  line 4: TSN 1272700
                        0011E256  004C  line 5: TSN 1172054
                        0011FA7B  0050  line 6: TSN 1178235
                        00131ED8  0054  line 7: TSN 1253080
00030003000300030003000300030003  0058  free space '................'
                                  ::::  (10 duplicate lines)
    0003000300030003000300030003  0108  free space '..............'

                            0018  0116  line 7 (72:451:7) record type 24
                         00 0001  0118  Control information
                                  ....  115 bytes of static data
41425F4D4F52465F445F424556000126  011B   data '&..VEB_D_FROM_BA'
4549484352415F45434946464F5F4B43  012B   data 'CK_OFFICE_ARCHIE'
36333334311C30835B3A544F4F525F46  013B   data 'F_ROOT:[.0.14336'
4D565F5A5245565F5254425F4245565D  014B   data ']VEB_BTR_VERZ_VM'
2E353136320C3082415F313532303053  015B   data 'S00251_A.0.2615.'
4245561120A720FF544B524557524556  016B   data 'VERWERKT. � .VEB'
893800009B078692FABC19205A524556  017B   data 'VERZ .��......8.'
                          C00000  018B   data '..�'

                       004D 2005  018E  line 2: bucket for hash index 77
                                  ....  total hash bucket size: 13
              004D 000001A4 0003  0192  bucket overflow 77:420:3
                              00  019A  flags 0
                              00  019B  padding '.'
      

That is rather strange.

I suggest using ALTER INDEX ... MAINTENANCE IS DISABLED;
Then carry on to recreate the indices (you'll need a different name).

As far as this error, we would probably need to see the database in our lab to
determine why it can't erase this hash bucket.  Did you perform an RMU/VERIFY
for the indices?

Ian