Thinking Out Loud

December 8, 2012

Bad header found during kcvxfh for active db duplication

Filed under: 11g,RMAN,Dataguard — mdinh @ 4:19 pm

While performing active database duplication to create physical standby database using RMAN, I have encountered error:  Bad header found during kcvxfh v8.

Thought to self, this does not look good. Is there corruption at the primary database? For good measures, I wanted to verify the primary using:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXOPENFILES 1;
CONFIGURE DEVICE TYPE DISK PARALLELISM 8 BACKUP TYPE TO BACKUPSET;
backup validate check logical database filesperset 1;

No corruption – sign of relief.

The following note was found from performing further research -

Corrupt Block, Bad Header Found Message during Rman Restore On Raw device [ID 1399327.1]

Here is an example of the output from the Note:

Hex dump of (file 37, block 1) in trace file /u01/oracle/product/diag/rdbms/test/trace/test_ora_1155088.trc
Corrupt block relative dba: 0x09400001 (file 37, block 1)
Bad header found during kcvxfh v8
Data in bad block:
type: 0 format: 2 rdba: 0x09400001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0x8e7
computed block checksum: 0x0
Reading datafile '+DATA/test//datafile/apps_ts_tx_data.295.741794537' for corruption at rdba: 0x09400001 (file 37, block 1)
Reread (file 37, block 1) found same corrupt data

Here is an example from alert log output:

Thu Dec 06 14:24:04 2012
db_recovery_file_dest_size of 102400 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu Dec 06 14:25:27 2012
Hex dump of (file 42, block 1) in trace file /u01/app/oracle/diag/rdbms/db07/db07/trace/db07_ora_21376.trc
Corrupt block relative dba: 0x0a800001 (file 42, block 1)
Bad header found during kcvxfh v8
Data in bad block:
 type: 0 format: 2 rdba: 0x0a800001
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000001
 check value in block header: 0xb27
 computed block checksum: 0x0
Reading datafile '/oracle/oradata/db01/data01.dbf' for corruption at rdba: 0x0a800001 (file 42, block 1)
Reread (file 42, block 1) found same corrupt data (no logical check)
Hex dump of (file 49, block 1) in trace file /u01/app/oracle/diag/rdbms/db01/db01/trace/db01_ora_21376.trc
Corrupt block relative dba: 0x0c400001 (file 49, block 1)
Bad header found during kcvxfh v8
Data in bad block:
 type: 0 format: 2 rdba: 0x0c400001
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000001
 check value in block header: 0xde7
 computed block checksum: 0x0
Reading datafile '/oracle/oradata/db01/index01.dbf' for corruption at rdba: 0x0c400001 (file 49, block 1)
Reread (file 49, block 1) found same corrupt data (no logical check)
Hex dump of (file 53, block 1) in trace file /u01/app/oracle/diag/rdbms/db01/db01/trace/db01_ora_21376.trc
Corrupt block relative dba: 0x0d400001 (file 53, block 1)
Bad header found during kcvxfh v8
Data in bad block:
 type: 0 format: 2 rdba: 0x0d400001
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000001
 check value in block header: 0xce7
 computed block checksum: 0x0

Database duplication completed successfully and opened standby database for READONLY to confirm.

SQL:PHYSICAL STANDBY> select open_mode, to_char(current_scn) from v$database;

OPEN_MODE            TO_CHAR(CURRENT_SCN)
-------------------- ----------------------------------------
READ ONLY            10549710065445

SQL:PHYSICAL STANDBY> conn / as sysdba
Connected.
SQL:PRIMARY> select open_mode, to_char(current_scn) from v$database;

OPEN_MODE            TO_CHAR(CURRENT_SCN)
-------------------- ----------------------------------------
READ WRITE           10549710142051

SQL:PRIMARY> @stby_status

Session altered.

DT                   DEST_ID DB_UNIQUE_N STATUS    DATABASE_MODE   RECOVERY_MODE ARCHIVED   APPLIED    APPLIED_LAG GAP_STATUS
-------------------- ------- ----------- --------- --------------- ------------- ---------- ---------- ----------- ----------
07-DEC-2012 13:22:37 2       stby_db01   VALID     OPEN_READ-ONLY  IDLE          162482     162481     1           NO GAP

SQL:PRIMARY>

Environment: Oracle 11.2.0.3 64-bit on Solaris 10 SPARC64.

About these ads

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 301 other followers

%d bloggers like this: