Re: Corrupt indexes on a system catalog

Peter Tashkoff wrote: > Jake > Hi > I have had the same problem over the last month except that the table concerned was sysindexes, not systables. Other than that, the problem was the same. > The gallant lads at tech support tried their best but even with the benefit of the source code they were unable to correct the situation. The solution that I was forced to take was, dbexport the database, (take a level zero archive) , drop and dbimport the database. (I hesitate to share with you the feeling I had when I typed drop database for my live database...., suffice it to say that I would rather be pursuing undomesticated aquatic avians) <snip> If you want to re-create your database to overcome this problem you can't use a binary archive / backup, like the one you get from ontape, etc. But I will never use dbexport for many reasons, out of which first two are performance related problems. Normally any well designed/tuned dbschema will have first & next extend sizes and lock level differing from the default sizes of 16-pages (were 8 before) and page level locking ( a major screw-up on OLTP ). When you dbimport your database will be nailed to these defaults. Now after the dbimport if you don't happen to have any document saying what where those extend sizes before, you will end up re-doing the calculations. Other problems are like long transaction, etc. for which you can have workarounds. We make use of awaked output of dbschema, and unload with named pipes and compress to get a neat-compressed ( 5-7 times compression ) backup. For re-store we use uncompress named pipes & dbaccess, we get the job done perfectly. This whole thing is done in two scripts one for archive and another one for restore -- Have a nice day Felix K. Mathews mailto:fmathews@systems.dhl.com