By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,333 Members | 1,843 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,333 IT Pros & Developers. It's quick & easy.

How to check "bad page" efficiently?

P: n/a
"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
Apr 8 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"James Yang" <Ja************@gmail.comwrote in message
news:4e**********************************@b5g2000p ri.googlegroups.com...
"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
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.
Apr 9 '08 #2

P: n/a
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 -
Apr 9 '08 #3

P: n/a
"Mark A" <no****@nowhere.comwrote in message
news:AB*******************@bignews8.bellsouth.net. ..
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
Apr 9 '08 #4

P: n/a
Understood, thanks.
Apr 10 '08 #5

P: n/a
On 10 Apr, 07:29, James Yang <James.YangG...@gmail.comwrote:
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.
Apr 10 '08 #6

P: n/a
On Apr 9, 12:09*am, James Yang <James.YangG...@gmail.comwrote:
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 -- Hide quoted text -

- 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.
Jun 27 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.