cancel
Showing results for 
Search instead for 
Did you mean: 

bad page, but which table ?

Former Member
0 Kudos

Hello,

we're running MaxDB 7.5.0.38 on Linux and last night while create a backup the following error occured:

2008-11-12 04:28:10 7543 ERR 20004 Data Bad page - checksums not matching

2008-11-12 04:28:10 7543 ERR 20005 Data Bad page - calculated checksum [ 26143722 ] checksum found in page [ 23996987 ]

2008-11-12 04:28:10 7543 ERR 52015 SAVE write/check count mismatch 688278

2008-11-12 04:28:11 7542 ERR 52012 SAVE error occured, basis_err 300

2008-11-12 04:28:11 7542 ERR 51080 SYSERROR -9026 BD Bad datapage

We had such a bad datapage almost half a year ago, and we "fixed" it with a "check table extended" via DBM-GUI.

Now I'm going to use the same step, but how can I determine which table belongs to the bad datapage ???

thanks....GERD....

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Gerd,

ok - the AUX means the auxiliary file. Let me try to explain what happens on your system.

You got a bad datapage on an index-tree - you found out the index and dropped and recreated the index.

What happens on the database -> the delketed b*-tree information will be deleted from the filedirectory and after the recreate the new root page number of the index is inserted in the filedirectory again.

But the deleted b*-treepages are marked as relevant for backup even when you deleted the index.

When the backup now starts it checkes the checksum of each page and gets the error again.

To get this problem solved you must start a check data in admin mode. Here the converter will be checked and the pages of the deleted B*-Tree will get the information in the converter that they are free again and not relevant for backup anymore. But it must be a check data in admin mode!

After this has been executed successfully you can start a backup in online mode and it will work.

Regards, Christiane

Former Member
0 Kudos

Hello Christiane,

your suggestion solved the problem. The "check db extended in admin mode" released some pages, and afterwards the backup worked as expected.

Should we perform this extended check on a regular basis to prevent such bad pages ???

thanks in advance...GERD...

Answers (4)

Answers (4)

Former Member
0 Kudos

Hello Gerd,

no, it is not neccessary to start CHECK DATA in ADMIn mode in continues intervals.

We recommend to run CHECK DATA in Online mode in continues intervals - eg. once a week.

The check data in online will find such bad pages (and the bacup as well) and will find other inconsistencies as well and log into the knlgiag.err file.

The check data in Admin mode does not fix and solve such Bad Pages. The only difference between ADMIn and Online is that in Admin Mode the Check data can clear the converter from inconsisntency e.g in your case the pages of the index tree which was deleted were still marked for backup.

So the backup failed with BAD Page because the backup did the Check of header trailer again and this failed again. But this index was laready deleted and recreated so we did not need the old index in the backup. This notices the Check data in Admin and changed the information in the Converter -> deleted the relevant for backup flag.

Bad Pages will never be cleared by a check data neither in ONLINE nor in Admin.

-9026 Bad Page tells you a structure inconsistency on the page. If it is an index you can delete and created the index, followed by a check data in Admin will allow a correct backup afterwards.

If it is a Bad Page on a table you cannot ddrop the table without loss of data - then you have to do a recovery.

You will find more information about the Bad Pages in our Support Guide in SDN using the following link:

[MaxDb Support Guide|https://wiki.sdn.sap.com/wiki/x/BhI]

Regards, Christiane

Former Member
0 Kudos

Hello Gerd,

ok - then let's analyze with x_diagnose the file which has been created tonight. But you should start a check data as soon as possible to getthe information if there are additional corrupted pages.

Please take care thatyou have a complete backup before the last backup failed. Please start a log backup so that we don't loose any data if a recovery is necessary.

Use x_diagnose as follows:

/<Dependant-Data-Path>/bin/x_diagnose

Prot-File: d688278.prt

2 Typebuf

9 Nodisplay

6 Scan KR

1 ALL

please use an editor to get the first page of log file d688278.prt

Post the first page into this call.

Do you have access to SAP custoemr system? Then you can use SAP note 839333 answer 13 to get more detailed information what we are doing here.

Regards, Christiane

Former Member
0 Kudos

Hello Christiane,

sorry for the delay, but yesterday was "real nightmare"....

We had one bad index. After recreation the database had an emergency shutdown after 2 minutes again...

The knldiag.err showed me problems with another index, but no index was marked as "bad".

After detecting the bad index via the root page, and recreating this index also, the database came to online state (and still is there....)

But the nightly incremental backup still fails with the error "BD Bad datapage,write/check count mismatch"

A look in the knldiag.err shows me:

....Bad data page 688278 belongs to root 687066 which is of filetype 'Aux'

Ein "select * from roots where root=687066" ergibt:

"No result" ... ?!?!

What does "filetype Aux" mean, and why is there no root but somehow access to a datapage of that root ?

BTW: we are no SAP customer, and since this is our productive database with thousands of customers we cannot shutdown the db easily.

Does the x_diagnose call produce a lot of load, or doesn't this affect the database performance at all ?

regards ...GERD...

Former Member
0 Kudos

Hi Gerd,

the bad data page which was reported in the knldiag.err file was Pageno 23996987.

The file you found in the rundirectory was B688278 which does not seem to be the one we are looking for.

Please check the timestamp of the file *688278.bad is it created during the time when the backup was active. For me it looks like an elder one.

Regards, Christiane

Former Member
0 Kudos

Hi Christiane,

the file is from tonight, the time at which the backup failed.

Currently our database has been set to db_offline, and we're in panic.

Perhaps we have a root after bring it back to db_online.....

-GERD-

Former Member
0 Kudos

Hi Gerd,

you alredy checked knldiag to get more detailed information? Check if you can find the root page in knldiag, if not.....

The checksum error can be noticed when the data page is read from volume into the Cache. It looks like a data page has not been written completely to the volume before.

If it is a permanent error on the volume you will get this error and root page when you start a

checkdata in online mode.

We do not know if the affected page is on an index or table therefore you should start a check data for tables and indexes.

If the error happens again you should find the root page of the affected B*-Tree in the knldiag and knldiag.err.

You can also check if you have a file like d<pageno>.cor in the rundirectory. Then the system dumped the corrupted data page intoi this file which has to be analyzed via x_diagnose. If you have such a file which was created during the backup then we have a chance to get the root page using x_diagnose.

Regards, Christiane

Former Member
0 Kudos

Hello Christiane,

thanks for your quick reply.

The log-lines in my first post is all I can get out of knldiag.err, but

I found a file called B688278.bad in the rundirectory, does this help ?

regards....GERD....