Saturday, April 7, 2018

Data Block Corruption


ORA-00756: recovery detected a lost write of a data block

We could see the below error in the alert log of GDG database :--

ERROR: ORA-00756 detected lost write of a data block
#56 Slave exiting with ORA-756 exception
Slave exiting with ORA-756 exception
ORA-00756: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 43, block# 3036635, file offset is 3401277440 bytes)
ORA-10564: tablespace GEN_DATA_L
ORA-01110: data file 43: '/GDG/data01/GDG/datafile/o1_mf_gen_data_55rje0qr_.dbf'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 91232



Steps taken to fix the same :---


Primary database (GPRD)
========================

[GPRD1]-->rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Wed Sep 27 20:47:54 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: GPRD (DBID=2031510687)

RMAN> run
{
ALLOCATE CHANNEL ch11 DEVICE TYPE DISK format '/stage/sandeep/sandy/inc_GEN_DATA_L_%U';
backup datafile 43;
release channel ch11;
}2> 3> 4> 5> 6>

using target database control file instead of recovery catalog
allocated channel: ch11
channel ch11: SID=4360 instance=GPRD1 device type=DISK

Starting backup at 27-SEP-17
channel ch11: starting full datafile backup set
channel ch11: specifying datafile(s) in backup set
input datafile file number=00043 name=+DATA/GPRD/DATAFILE/gen_data_l.815.925827889
channel ch11: starting piece 1 at 27-SEP-17
channel ch11: finished piece 1 at 27-SEP-17
piece handle=/stage/sandeep/sandy/inc_GEN_DATA_L_g0sfhlbv_1_1 tag=TAG20170927T204759 comment=NONE
channel ch11: backup set complete, elapsed time: 00:01:05
Finished backup at 27-SEP-17

Starting Control File and SPFILE Autobackup at 27-SEP-17
piece handle=+RECO/GPRD/AUTOBACKUP/2017_09_27/s_955831745.14675.955831747 comment=NONE
Finished Control File and SPFILE Autobackup at 27-SEP-17

released channel: ch11

RMAN>


Standby database (GDG)
=========================

1.       STOP the MRP process (our scenario the mrp was not starting)
2.       Since we took the backup of the piece in the stage location there was no need to scp the file to the target host amxd1dbadm01 .
3.       Catalog the backup piece

[GDG1]-->rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Wed Sep 27 20:20:07 2017

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: GPRD (DBID=2031510687, not open)

RMAN> catalog start with '/stage/sandeep/sandy/';

using target database control file instead of recovery catalog
searching for all files that match the pattern /stage/sandeep/sandy/

List of Files Unknown to the Database
=====================================
File Name: /stage/sandeep/sandy/inc_GEN_DATA_L_g0sfhlbv_1_1

Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /stage/sandeep/sandy/inc_GEN_DATA_L_g0sfhlbv_1_1

RMAN>

4.       Restore the datafile

RMAN> restore datafile 43;

Starting restore at 27-SEP-17
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=50 instance=GDG1 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Data Domain Boost API
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=96 instance=GDG1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00043 to /GDG/data01/GDG/datafile/o1_mf_gen_data_55rje0qr_.dbf
channel ORA_DISK_1: reading from backup piece /stage/sandeep/sandy/inc_GEN_DATA_L_g0sfhlbv_1_1
channel ORA_DISK_1: piece handle=/stage/sandeep/sandy/inc_GEN_DATA_L_g0sfhlbv_1_1 tag=TAG20170927T204759
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:25
Finished restore at 27-SEP-17

RMAN> exit


Recovery Manager complete.
[oracle@amxd1dbadm01:/home/oracle]
[GDG1]-->

5.       Start the MRP process and let the MRP catch the lag .








No comments:

Post a Comment