Oracle common data file backup and restore

It refers to a common data file: the non-file system data tablespace, UNDO_TABLESPACE table space, and a read only temporary table space tablespace. They cause damage user data can not be accessed, will not lead to abnormal db itself, instance crashes, the database does not restore the situation can not be started.

Such data files can be restored using high availability strategy, in the OPEN state database

10.1 ordinary data file corruption consequences

After normal data file is corrupted, just business users can not access data to varying degrees (query and modify), an error

ORA-01578, the session will not be interrupted execution of the command, even if the data file is corrupted checkpoint occurs when the head does not crash Examples

When --1 instance starts, if the common data files are missing, inaccessible or head damage, startup command can only state started to mount.

--2 runtime instance, if the common data file is damaged, after a checkpoint occurs, because the data is no longer the checkpoint file header is completed, the status of this data file are automatically set in the control file is off, examples does not crash, alert log has ORA-01171 failed because the checkpoint leading to the error log file off the assembly line, to access the data file ORA-00376 errors, instance is no longer trying to access the file, then restart the instance can be successful.

--3 runtime instance, if non-normal data file block header data corruption, will cause damage to need access to data line command can not be executed, the data file is not automatic logoff.

Scenario 1: When starting the normal data files test01.dbf found does not exist, the data block to the mount state can only be activated

Scene 2: find common data file header test01.dbf damage during startup, db state started to mount only

SQL> startup force
Database mounted.
ORA-01122: database file 5 tailed verification check
ORA-01110: data file 5 :  /u01/app/oracle/oradata/orcl/test01.dbf
ORA-01210: data file header is media corrupt

If you use alter database datafile 5 offline, so test01 data files offline, db still open, data test01 data file can not be accessed after opening

SQL> alter database datafile 5 offline;
SQL> alter database open;

--1 corrupted data files that belong to the history of partition information stored in the table space, online businesses do not need or do not need to visit temporarily

--2 corrupted data file or table space belongs to a few specific applications, but other relatively independent of the other table spaces used by the application is still healthy, this can enable other applications to provide services to ensure local high availability database

Scenario 3: Common file header data corruption during operation, it will be forced offline when the transmission check point data file, alter log in

ORA-01171: datafile 5 going offline due to error advancing checkpoint
ORA-01122: database file 5 failed verification check
ORA-01110: data file 5 : /u01/app/oracle/oradata/orcl/test01.dbf
ORA-01210: data file header is media corrupt

All services are unable to access the data within the file, such as querying test.t1

SQL> select * from test.t1;
ERROR at line 1:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5 : /u01/app/oracle/oradata/orcl/test01.dbf

If this time restart the instance, db can be opened, but No. 5 is still in the data files offline, you need to manually restore.

SQL> startup force;
SQL> select * from v$datafile where file#=5;
ERROR at line 1:
ORA-01135: file 5 accessed for DML/query is offline
ORA-01110: data file 5 : /u01/app/oracle/oradata/orcl/test01.dbf

Scenario 4: If the area management table space is LOCAL, at runtime, the data files are not Bitmap Area (biimap) management block corrupted

SQL> create table t2 (id number) tablespace test;
ORA-01658: unable to create INITIAL extent for segment in tablespace TEST

Scenario 5: running instance, tables, indexes, header segment damaged, resulting in the need to read, modify the operation of the head section failure

 

SQL> insert into test.t1(id,name) vales (2,’xxx’);
ORA-01578: ORACLE data block corrupted (file # 5,block # 202)
SYS@ orcl >conn yhqt/***
Connected.
YHQT@ orcl >select * from yhqtest_1;
select * from yhqtest_1
              *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 10, block # 135)
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'

 

Scenario 6: bad blocks store data blocks (file # 10, block # 143)

YHQT@ orcl >select * from yhqtest_2;
select * from yhqtest_2
              *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 10, block # 143)
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'

- For more details see for DSI data corruption Kuaikuai physical block and the logical block damage damage

10.2 Backup

 

RMAN> backup as compressed backupset tablespace test;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "test": expecting one of: "double-quoted-string, identifier, single-quoted-string"
RMAN-01007: at line 1 column 43 file: standard input
RMAN>  backup as compressed backupset tablespace yhqt;
Starting backup at 18-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00010 name=/u01/app/oracle/oradata/orcl/yhqt01.dbf
channel ORA_DISK_1: starting piece 1 at 18-JUL-19
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 07/18/2019 17:59:04
ORA-19566: exceeded limit of 0 corrupt blocks for file /u01/app/oracle/oradata/orcl/yhqt01.dbf

 

 

SQL> select * from v$database_block_corruption;
    FILE#    BLOCK#      BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
    10      135          1          0 FRACTURED
    5    2199          1        9533291 CORRUPT
    5    2207          1        9579846 CORRUPT
    5    2231          1        9620379 CORRUPT

 

RMAN> run {
set maxcorrupt for datafile 10 to 135;
backup tablespace yhqt;
}2> 3> 4>
executing command: SET MAX CORRUPT
Starting backup at 18-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00010 name=/u01/app/oracle/oradata/orcl/yhqt01.dbf
channel ORA_DISK_1: starting piece 1 at 18-JUL-19
channel ORA_DISK_1: finished piece 1 at 18-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/backupset/2019_07_18/o1_mf_nnndf_TAG20190718T180019_gm0jsmbb_.bkp tag=TAG20190718T180019 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 18-JUL-19
Starting Control File and SPFILE Autobackup at 18-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013968820_gm0jsndn_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 18-JUL-19

SYSAUX table space for the backup image replication

RMAN> backup as copy tablespace sysaux;
Starting backup at 18-JUL-19
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
output file name=/u01/app/oracle/fra/ORCL/datafile/o1_mf_sysaux_gm0jwl05_.dbf tag=TAG20190718T180153 RECID=2 STAMP=1013968917
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 18-JUL-19
Starting Control File and SPFILE Autobackup at 18-JUL-19
piece handle=/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013968921_gm0jws37_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 18-JUL-19

When you run the above command RMAN command to ensure that the database in mount state or open state, under the open state also need to open the archive log mode.

10.3 recovery

To restore normal heart data file: the data file is offline, backup and restore (Restore or switch) or from the use of incremental recovery redo log (Recover command), and finally the file so that the line

The main features of the normal data may be file recovery is recovery (not available during db) in the database mount state can be maintained recovery db (db locally available) in the open state. Case file header corruption of data may require special handling.

10.3.1 Preparation before recovery

And recovery of critical data files, like the premise of recovery when entering the mount state, to ensure the normal parameters and control files.

If the key data file (system, undo) damage, you should first restore critical data files.

This is a case where the content of the discussion based on parameter files, control files, critical data files normally.

If the repair of the common data files in the open state, we must first ensure that the file is being restored already offline.

10.3.2 non-recovery of damaged file header

As long as there is no damage to the file header (including the file is missing), the file will not be automatically off the assembly line, ORA-01210 error does not occur, the steps in this section can be used to restore the database in mount state available for the low recovery strategy, database in the open state restore policies for high availability.

--1 closed instance using shutdown abort

--2 execution startup mount state started to mount

--3 RMAN performs restore (or switch) restoration of normal data files

--4 redo log file to restore data through RMAN to recover database using the archive and online logs

--5 alter database open Open Database


To yhqt01.dbf data file, for example

--mount state recovery

RMAN> run {
shutdown abort;
startup mount;
restore datafile '/u01/app/oracle/oradata/orcl/yhqt01.dbf';
recover database;
alter database open;}

--open state recovery, examples not closed

RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10;
recover datafile 10;
sql'alter database datafile 10 online';
}

--open state, examples Closed

 

RMAN> run {
startup mount;
sql'alter database datafile 10 offline';
alter database open;
restore datafile 10;
recover datafile 10;
sql'alter database datafile 10 online';
}

 

10.3.3 File recovery after damage to the head

After the data file header corruption, but also in the offline state if, in the future when you execute the restore command channel would "not recognize" this file, resulting in the reduction can not be completed. ORA-01210 Alert log appear

Scene: yhqt01.dbf file header has been corrupted, then the checkpoint has occurred, ORA-01210 and ORA-01171 error occurred alarm log, and has been modified to the offline state in the control file yhqt01.dbf file,

User access yhqt table space objects are returned ORA-00376: file 10 can not be read at this time

At this point with the restore command to restore files accidentally triggered yhqt01.dbf RMAN-06010 error, because the control file indicates that the file is offline, restore found yhqt01.dbf exist, the channel will still access yhqt01.dbf file header,

To verify whether it is consistent with the information in the control file, the file header is corrupted, the command fails.

solve:

--1 delete head corrupted data files, so it will not try to check the channel header file, as files are missing treatment

--2 mount state in the db alter database datafile ... online with the modified data file online, and then using the restore

RMAN> restore datafile 10;
ORA-01135: file 10 accessed for DM/query is offline
ORA-01110: datafile 10 :/u01/app/oracle/oradata/orcl/yhqt01.dbf
RMAN-06010: error while looking up datafile 10
删除该数据文件
$ rm /u01/app/oracle/oradata/orcl/yhqt01.dbf
RMAN> restore datafile 10;
RMAN> recover datafile 10;
SQL> alter database open;
SQL> alter database datafile 10 online;

So the data file header corruption repair steps should be based on low available policies and strategies on availability, then according to the relevant data file is already offline distinction, a total of three kinds:

--1 not available offline low recovery strategy (online, mount)

--2 available policy has been off the assembly line low recovery (offline, mount)

--3 recovery strategy has been highly available offline (offline, open)

The main steps to recover 1

--1 off using shutdown abort instance
--2 instance to perform startup mount boot mount state
--3 RMAN perform common data file or restore switch restoration of
--4 RMAN recover database using the execution log file and restore the data file online log
- -5 alter database open to open the database, the restoration is complete
the RMAN> RUN {
the shutdown ABORT;
Startup Mount;
restore datafile 10;
recover database;
ALTER open database;}

2 main steps of recovery

--1 off using shutdown abort instance
--2 startup mount to mount state
--3 alter databse datafile 10 online file status data in the control file is modified on-line
--4 RMAN> restore datafile 10; restore data files
- the RMAN. 5> Recover Database;
--6 the SQL> ALTER Open Database;
the RMAN> RUN {
the shutdown ABORT;
Startup Mount;
sql'alter Online Database 10 ';
Restore datafile 10;
Recover Database;
ALTER Open Database;}

3 main steps of recovery

--1 using the operating command to remove corrupted data file header ordinary, if not head damage omit this step
--2 if the instance has stopped, startup mount state started to mount, if the database open state, ignore this step
--3 Offline database 10 the ALTER;
--4 if they meet the conditions of the second step, open the database using the alter database open, otherwise ignore this step
--5 use RMAN> Restore datafile 10;
--6 RMAN> Recover TABLESPACE or recover datafile, with the filing and redo log file restoration data
--7 10 performs datafile Database Online ALTER;
$ /u01/app/oracle/oradata/orcl/yhqt01.dbf RM
- example not closed
the RMAN> RUN {
sql'alter Offline Database datafile 10 ';
10 datafile Restore;
Recover datafile 10;
sql'alter Database Online datafile 10 ';
}
- example off
the RMAN> RUN {
Startup Mount;
sql'alter Database datafile 10 Offline';
ALTER Open Database;
restore datafile 10;
recover datafile 10;
sql'alter database datafile 10 online';
}

Guess you like

Origin www.linuxidc.com/Linux/2019-07/159591.htm
Recommended