How to check "bad page" efficiently?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

James Yang - 08 Apr 2008 08:04 GMT

"bad page", especially in table, is a risk for database maintenance.
The particular access
attempt for corrupt blocks may not occur often, and corrupt DB2 blocks
are not recognized during a database backup, corrupt blocks can remain
undetected in an UDB system for a long time.

The potential solution is:

1) Restore from a GOOD backup and rollforward (Recommended). The
problem is backup normally is kept for 30 days so we must find the bad
page in DB with retention period.

2) db2dart /DDEL to dump the data, db2dart /IP to initialize the
corrupt page, and then recreate the tabel, upload the data. The
problem is data lost may happen and we need open an PMR.

Anyway, we need check the bad page efficiently. My question is:

* Which tool is recommended? db2dart or "inspect database" command?
* Can we inspect a backup instead of the online database to avoid
performance issue?
* In general, how fast is it? Suppose it takes 10 hours for us to
backup the database to Tivoli.

P.S. It is a simple DBA task on Oracle platform.

Any comment is appreciated.

TIA
James

Reply to this Message

Mark A - 09 Apr 2008 01:29 GMT

> "bad page", especially in table, is a risk for database maintenance.
> The particular access
[quoted text clipped - 26 lines]
> TIA
> James

The reason why it is a simple task on Oracle is that, unlike DB2, corrupted
blocks are not unusual in Oracle. Extremely rare in DB2.

Reply to this Message

James Yang - 09 Apr 2008 05:09 GMT

Even it happens extremely rarely, we still need take it into account,
don't we?

So, how?

> The reason why it is a simple task on Oracle is that, unlike DB2, corrupted
> blocks are not unusual in Oracle. Extremely rare in DB2.- Hide quoted text -
>
> - Show quoted text -

Reply to this Message

Mark A - 09 Apr 2008 05:28 GMT

> Even it happens extremely rarely, we still need take it into account,
> don't we?
>
> So, how?

No we don't.

Why do you think you need to check it if no problems have occured? The only
time I have seen this happen in DB2 is when the server was experiencing
serious disk errors (and the disk errors where also recorded in the
db2idag.log file). Our admins were asleep on the job and did not notice that
one disk already failed in the RAID array and when the second disk got
errors, we had problems.

I have never heard of it happening on DB2 running on stable hardware. When I
went to Oracle training about 4 years ago, I was alarmed that they taught
how to repair bad pages in the second DBA Admin class (Oracle Corp
training). Since it happens so rarely in DB2, I believe the only feasible
way to repair a bad page is to restore the database (or tablespace) from a
backup, and roll forward to end of logs.

Generally a DB2 backup, or a db2ckbkp command on an existing backup, will
find corrupted pages. But I don't know if it is as comprehensive as db2dart.
But inspect is probably less intrusive.

Reply to this Message

Mark A - 09 Apr 2008 05:30 GMT

> The only time I have seen this happen in DB2 is when the server was
> experiencing serious disk errors (and the disk errors where also recorded
> in the db2idag.log file).

Correction:

s/b db2diag.log

Reply to this Message

James Yang - 10 Apr 2008 06:29 GMT

Understood, thanks.

Reply to this Message

john.enevoldson@pulsen.se - 10 Apr 2008 12:15 GMT

> Understood, thanks.

Hi,
We actually had this problem once which prompted us to include a
little automatic control against the db2diag.log each day:

if grep -i "bad page" /home/$1/sqllib/db2dump/db2diag.log
then mutt -s "$1 - bad page" dba@????????? < /PXX/scripts/prod/
badpage.txt
fi;

This mails out a warning to our dba mailbox. It gets run as part of
our daily housekeeping which amongst other things archives the
db2diag.log.

Regards,
John.

Reply to this Message

Pierre StJ - 14 Apr 2008 20:00 GMT

> Even it happens extremely rarely, we still need take it into account,
> don't we?
[quoted text clipped - 7 lines]
>
> - Show quoted text -

This is a late answer as I'd been away from the group for a while.
At DB2 V8.2 and up you can use the INSPECT command on the whole or any
part of the db. It runs concurrently with the db and is not very
intrusive.
DB2DART is an older command that will give you the bad page info but
it ihas to run with the db deactivated.
DB2CKBKP will also allow you to check a backup image for checkbits and
checksums that would show it in the image.

Understand that DB2 has an internal mechanism that will stop it from
retrieving a corrupted page.
The only way that I see the page being corrupted is if you have
hardware problems and/or applications that would have writtwen to the
file system holding the container of the tablespace that holds the
table. I really don't know or see how that could happen.
Regards, Pierre.

Reply to this Message