We've got what appears to be a messed up database. Even when running an innocuous command such as "select * from SYSINDEX", this appears:
005 Can't read 0x7012 bytes at 0xDFA in KDBF file /database/principalfa/tbldoc/S
YSINDEX.tbl: error 0: Unknown (Read past EOF) in the function read_rest_data
000 Could not open SYSINDEX in the function ddopen
000 Couldn't connect to . in the function SQLConnect
So, it would appear it's time for some kdbfchk. Only thing is, we're not sure what syntax to use to repair the tables with-- do we need to run the command for SYSINDEX as well as our own table? If so, what flags should we use? Thanks for the help.
This just happened again, on a separate database. Unfortunately, the fix listed above didn't seem to work. Here's what I get:
myserver>>kdbfchk -o SYSINDEX.tbl badSYSINDEX.tbl
Checking file badSYSINDEX.tbl:
Reading free tree and list
0% 50% 100%
-------------------------------------------------------------------------------
Scanning for orphaned free tree pages
0% 50% 100%
###############################################################################
Free tree and list appear intact
Repairing KDBF file
0% 50% 100%
###############################################################################
Bad block summary:
1 orphaned free block found
*** Corruption detected ***
This appears to be a problem on *all* the SYS tables. For instance:
myserver >>kdbfchk SYSUSERS.tbl
Checking file SYSUSERS.tbl:
Reading free tree and list
0% 50% 100%
-------------------------------------------------------------------------------
Scanning for orphaned free tree pages
0% 50% 100%
###############################################################################
Free tree and list appear intact
Scanning data blocks
0% 50% 100%
###############################################################################
Bad block summary:
1 data block deleted
1 free block pad inserted
*** Corruption detected ***
However, it's not a problem on any of our non-SYS tables in this database. Have you ever seen this before? Last time, we simply moved our tables to another directory and recreated the indexes, but it would be good to avoid this if at all possible. Thanks for the help.
It appears to have fixed them ok. The orphan blocks will remain orphans and still be reported if you the fix again. We've not heard of that happening unless there's some problem with the disk or you're using singleuser mode when you're really not singleuser. What's your texis version and release (texis -version)?
Here's our texis version. I don't believe it's singleuser mode, but I don't know if this reveals that or not:
Texis Web Script (Vortex) Copyright (c) 1996-2001 Thunderstone - EPI, Inc.
Commercial Version 3.01.984591953 of Mar 14, 2001 (sparc-sun-solaris2.6)
If it's our disk causing this problem both times, why would only the SYS* tables be affected, and not our much larger, man-made tables?
FYI, after running kdbfchk -o on the SYSINDEX table and moving the "fixed" one back into place, we still get the same "Could not open SYSINDEX in the function ddopen" message when trying to select from it.
We've been fortunate in that only the SYS* tables have been affected thus far, as we can move our own tables to another directory, run addtable, and reindex. Again, if you've seen this before or have any ideas what might be happening, please share your theories (crazier the better), and thanks again.
