Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: How to repair a corrupted data page?
From: Thorn Roby (trobycavion.com)
Date: Mon Feb 16 2004 - 18:50:30 CST
Strahl, Torsten wrote:
>the error you get from the database structure check means that
>you have a corrupted secondary tree (index) which is identified
>by the root page number 34659. At least one of the index records
>has a corrupted key length. You should check your hardware and after
>that drop and re-create the index.
>But there is something mysterious about it, because the internal
>file name is '030600000000000002CD000000000000'. This means that
>the file is an old style (< release 7.4) single index. All these
>files should be migrated with the 7.4 calatog migration. Therefore
>I suppose that you run in trouble if you want to drop the index.
>Do you have the old 7.3 database instance on your computer, so that
>you can start it and execute the following query as superdba("dba")?
>Select * from roots where root = 34659
>The result should be the "external" name of the index. You could take
>the index name to drop and re-create it. After that you should create
>a new backup for the 7.4/7.5 database migration.
>If the old 7.3 database isn't available we have a big problem, because
>at this time we have no possibility to drop such unsupported indexes,
>i.e. the next steps depends on your answer to my first question (above)!
>What is see size of the 7.3 database backup and which kind of OS do you use?
Thanks for your response. Dropping and recreating the index on the 7.3
followed by a migration backup, results in a successful restore to the
Both are Solaris SPARC systems. The database size is 1.2 GB.
However, before the "Check Successful" message in the log I get hundreds
of messages like this
which I haven't seen before:
43 Converte The dynamic data pageno 119093 on block 1/5899 is deleted.
Is this OK?
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb