Corruption with active duplication

[Mladen Gogala]

Hi!

I am doing an active duplication of one test database to another one,
for another group of developers. Here is what I am getting:

consistency value in tail: 0x00000001
 check value in block header: 0xb601
 computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at
rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)

It probably means that the source database is corrupt, yet there is
nothing in the alert log.  I will do backup validate logical, but this
will take some time, since it's a database over 2TB. Does anyone have
any idea how to establish whether the source DB is corrupt faster than
using backup validate?

[Ruel, Chris]

Try running a dbverify command on the corrupt datafile?

_____________________________________________________________________
Chris Ruel * Distributed Database Services * Lincoln Financial Group
***@lfg.com<mailto:***@lfg.com> * Desk:317.759.2172 * Cell 317.523.8482

From: oracle-l-***@freelists.org [mailto:oracle-l-***@freelists.org] On Behalf Of Mladen Gogala
Sent: Thursday, November 08, 2018 9:17 PM
To: oracle-l <oracle-***@freelists.org>
Subject: Corruption with active duplication

***This email is from an external source. Only open links and attachments from a Trusted Sender.***

Hi!

I am doing an active duplication of one test database to another one, for another group of developers. Here is what I am getting:

consistency value in tail: 0x00000001
check value in block header: 0xb601
computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file /app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)

It probably means that the source database is corrupt, yet there is nothing in the alert log. I will do backup validate logical, but this will take some time, since it's a database over 2TB. Does anyone have any idea how to establish whether the source DB is corrupt faster than using backup validate?
--
Mladen Gogala

Database Consultant

Tel: [phone]
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**

[Mladen Gogala]

No, unfortunately, the database is active. The dbverify isn't very good
on active data files.

Regards

Post by Ruel, Chris
Try running a dbverify command on the corrupt datafile?
_____________________________________________________________________
Chris Ruel * Distributed Database Services * Lincoln Financial Group
317.523.8482
*Sent:* Thursday, November 08, 2018 9:17 PM
*Subject:* Corruption with active duplication
***This email is from an external source. Only open links and
attachments from a Trusted Sender.***
Hi!
I am doing an active duplication of one test database to another one,
consistency value in tail: 0x00000001
 check value in block header: 0xb601
 computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at
rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there is
nothing in the alert log.  I will do backup validate logical, but this
will take some time, since it's a database over 2TB.  Does anyone have
any idea how to establish whether the source DB is corrupt faster than
using backup validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is
privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the
individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**

[Stefan Knecht]

Since you know which files it is, you can just run a backup validate
datafile # instead of the entire database.

No, unfortunately, the database is active. The dbverify isn't very good on
active data files.
Regards
Try running a dbverify command on the corrupt datafile?
_____________________________________________________________________
Chris Ruel * Distributed Database Services * Lincoln Financial Group
Behalf Of *Mladen Gogala
*Sent:* Thursday, November 08, 2018 9:17 PM
*Subject:* Corruption with active duplication
***This email is from an external source. Only open links and attachments
from a Trusted Sender.***
Hi!
I am doing an active duplication of one test database to another one, for
consistency value in tail: 0x00000001
check value in block header: 0xb601
computed block checksum: 0x0
0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there is
nothing in the alert log. I will do backup validate logical, but this will
take some time, since it's a database over 2TB. Does anyone have any idea
how to establish whether the source DB is corrupt faster than using backup
validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**
--
Mladen Gogala
Database Consultant
Tel: [phone]

[Leng]

If you look at the message it’s all on block 1!! So something odd is happening at the auxiliary end. Is the file system mounted correctly?

You can run dbv or Rman validate against just a single block rather than the entire 2tb.

Cheers,
Leng

Since you know which files it is, you can just run a backup validate datafile # instead of the entire database.

No, unfortunately, the database is active. The dbverify isn't very good on active data files.
Regards

Post by Ruel, Chris
Try running a dbverify command on the corrupt datafile?
_____________________________________________________________________
Chris Ruel * Distributed Database Services * Lincoln Financial Group
Sent: Thursday, November 08, 2018 9:17 PM
Subject: Corruption with active duplication
***This email is from an external source. Only open links and attachments from a Trusted Sender.***
Hi!
consistency value in tail: 0x00000001
check value in block header: 0xb601
computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file /app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there is nothing in the alert log. I will do backup validate logical, but this will take some time, since it's a database over 2TB. Does anyone have any idea how to establish whether the source DB is corrupt faster than using backup validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**

--
Mladen Gogala
Database Consultant
Tel: [phone]

--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!

[Mladen Gogala]

Yes, there was in fact problem with the mount. The system was recently
updated from RHEL 6.9 to 6.10 and the system needed some additional
configuration. Thanks to everybody, the problem was solved by the SA.

Post by Leng
If you look at the message it’s all on block 1!! So something odd is
happening at the auxiliary end. Is the file system mounted correctly?
You can run dbv or Rman validate against just a single block rather than the entire 2tb.
Cheers,
Leng

Post by Stefan Knecht
Since you know which files it is, you can just run a backup validate
datafile #  instead of the entire database.
On Fri, Nov 9, 2018 at 10:10 AM Mladen Gogala
No, unfortunately, the database is active. The dbverify isn't
very good on active data files.
Regards

Post by Ruel, Chris
Try running a dbverify command on the corrupt datafile?
_____________________________________________________________________
Chris Ruel * Distributed Database Services * Lincoln Financial Group
317.523.8482
*Sent:* Thursday, November 08, 2018 9:17 PM
*Subject:* Corruption with active duplication
***This email is from an external source. Only open links and
attachments from a Trusted Sender.***
Hi!
I am doing an active duplication of one test database to another
consistency value in tail: 0x00000001
 check value in block header: 0xb601
 computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption
at rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there
is nothing in the alert log.  I will do backup validate logical,
but this will take some time, since it's a database over 2TB. 
Does anyone have any idea how to establish whether the source DB
is corrupt faster than using backup validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]
Notice of Confidentiality: **This E-mail and any of its
attachments may contain
Lincoln National Corporation proprietary information, which is
privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the
individual or entity to
which it is addressed. If you are not the intended recipient of
this E-mail, you are
hereby notified that any dissemination, distribution, copying,
or action taken in
relation to the contents of and attachments to this E-mail is
strictly prohibited
and may be unlawful. If you have received this E-mail in error,
please notify the
sender immediately and permanently delete the original and any
copy of this E-mail
and any printout. Thank You.**

--
Mladen Gogala
Database Consultant
Tel: [phone]
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
fb.me/zztat <http://fb.me/zztat> | zztat.net/blog/
<http://zztat.net/blog/>

[Sokolowski Remigiusz]

There is an article on that on Metalink:
Corrupt block relative dba message in the Alert Log - Definition and Solution (Doc ID 1950383.1)

From: oracle-l-***@freelists.org <oracle-l-***@freelists.org> On Behalf Of Mladen Gogala
Sent: Friday, November 09, 2018 3:17 AM
To: oracle-l <oracle-***@freelists.org>
Subject: Corruption with active duplication


Hi!

I am doing an active duplication of one test database to another one, for another group of developers. Here is what I am getting:

consistency value in tail: 0x00000001
check value in block header: 0xb601
computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file /app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)

It probably means that the source database is corrupt, yet there is nothing in the alert log. I will do backup validate logical, but this will take some time, since it's a database over 2TB. Does anyone have any idea how to establish whether the source DB is corrupt faster than using backup validate?

[Gus Spier]

I swear, you guys are Brilliant!

On Fri, Nov 9, 2018 at 2:33 AM Sokolowski Remigiusz <

Post by Sokolowski Remigiusz
Corrupt block relative dba message in the Alert Log - Definition and
Solution (Doc ID 1950383.1)
Behalf Of *Mladen Gogala
*Sent:* Friday, November 09, 2018 3:17 AM
*Subject:* Corruption with active duplication
Hi!
I am doing an active duplication of one test database to another one, for
consistency value in tail: 0x00000001
check value in block header: 0xb601
computed block checksum: 0x0
0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there is
nothing in the alert log. I will do backup validate logical, but this will
take some time, since it's a database over 2TB. Does anyone have any idea
how to establish whether the source DB is corrupt faster than using backup
validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]

[Mladen Gogala]

The problem was in the multi-path configuration. When the SA has fixed
the problem, everything was well.  And I thought that system
administrators are obsolete. Who could know?

Post by Sokolowski Remigiusz
Corrupt block relative dba message in the Alert Log - Definition and
Solution (Doc ID 1950383.1)
*On Behalf Of *Mladen Gogala
*Sent:* Friday, November 09, 2018 3:17 AM
*Subject:* Corruption with active duplication
Hi!
I am doing an active duplication of one test database to another one,
consistency value in tail: 0x00000001
 check value in block header: 0xb601
 computed block checksum: 0x0
Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at
rdba: 0x11000001 (file 68, block 1)
Reread (file 68, block 1) found same corrupt data (no logical check)
Hex dump of (file 69, block 1) in trace file
/app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
Corrupt block relative dba: 0x11400001 (file 69, block 1)
It probably means that the source database is corrupt, yet there is
nothing in the alert log.  I will do backup validate logical, but this
will take some time, since it's a database over 2TB.  Does anyone have
any idea how to establish whether the source DB is corrupt faster than
using backup validate?
--
Mladen Gogala
Database Consultant
Tel: [phone]