Backup and restore data 11 read-only file
Read-only data file is a data file read-only tablespace data block includes a header file to allow for changes in the interior
SQL> alter tablespace yhqt read only;
SQL> alter tablespace yhqt read write;
11.1 read-only data file corruption consequences
When a table space from the read / write status changes to read-only status, dirty block its data file must be written to disk DBWn process, incomplete complete a full check points within the table space data file is called read-only data files.
And its data block header information includes a checkpoint is not changed, each time you open the database instance does not check the synchronization checkpoint SCN whether the read-only files or other data files online log, but the objects within the data file being given access
- Examples of runtime file is missing
- corrupted data block instance is running
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'
- found file is missing instance startup
SQL> startup
Database mounted
ORA-01157: cannot identify/lock data file 10 - see DBWR trace file
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
- find the file header damage instance startup
SQL> startup
Database mounted
ORA-01122: database file 10 failed verification check
ORA-01110: data file 10: '/u01/app/oracle/oradata/orcl/yhqt01.dbf'
ORA-01210: data file header is media corrupt
After the read-only file is damaged, all the while sending the checkpoint process does not ignore it, will not collapse Examples (other consequences of critical file system corrupted), the file is not automatic logoff (Effect of Common file header data corrupted ), read-only file generally normal, but when the operation is performed only need to access the head of an error in the alert log in
SQL> select checkpoint_change# from v$datafile where file#=10;
Alarm log error
Corrupt block relative dba: 0x014000 (file 10,block 135)
Fractured block found during kcvxfh v10
In this case all the objects that can be queried or internal (as long as the corresponding data block is not corrupted), but after alter tablespace ... read write and alter tablespace ... offline to online ora-01120 being given data file is corrupted header.
11.2 Backup
RMAN> backup as backupset tablespace yhqt;
RMAN> backup as backupset datafile 10;
Since there is no data file read only data blocks can be modified, so it did not have a backup repeated.
Read-only data backup files can also use the cp command
$ cp /u01/app/oracle/oradata/orcl/yhqt01.dbf /home/oracle/backup/yhqt01.bak
Note: When a table space is modified from read only read only read write, you should back up their data files and control files immediately. Otherwise, if the control file and data file corruption may occur ORA-01152 in the recovery process in the future: data the old file is not wrong.
11.3 recovery
Other types of data file recovery comprising: reducing (Restore) and recovery (recover), for read-only files, do not need to redo log, no recover operation at the time of recovery
--Mount state recovery steps of
--1 SQL> startup mount
--2 RMAN> restore datafile 10;
--3 SQL> alter database open;
Recovery steps under --open
--1 SQL> alter database datafile 10 offline;
--2 RMAN> restore datafile 10;
--3 SQL> alter database datafile 10 online;
11.3.1 Preparation before recovery
Can be restored in the mount and open state, parameter files, and control files must be normal, critical data files must be normal.
11.3.2 recover under control files without damage
Recovery under the control file means without damage: the control file is not corrupted when read-only data file is corrupted
Scenario 1: read-only data files yhqt01.dbf loss, db not start properly, stay in the mount, ORA-01157 can not identify / lock data file 10 - see DBWR trace file
Just use RMAN performs restore (for backup set) restore the data file, and then open the database
RMAN> restore datafile 10;
SQL> alter database open;
Scenario 2: read-only data files yhqt01.dbf instance is running in loss, resulting in the data inaccessible
SQL> select * from yhqt.t1;
ORA-01116: error in opening database file 10
ORA-01110: data file 10 : /u01/app/oracle/oradata/orcl/yhqt01.dbf
ORA-27041: unable to open file
LINUX-X86-64 Error: 2: No such file or directory
--open
RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10;
sql'alter database datafile 10 online';
}
Scenario 3: run-time read-only data files within yhq01.dbf data block is damaged, resulting in data inaccessible, but the file still exists
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'
--open
RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10 force;
sql'alter database datafile 10 online';
}
Use a mirror copy of the recovery
RMAN> run {
sql'alter database datafile 10 offline';
switch datafile 10 to datafilecopy
'/u01/app/oracle/fra/ORCL/autobackup/2019_07_23/o1_mf_s__glzrwsd5_.dbf';
sql'alter database datafile 10 online';
}
Scenario 4: yhqt01.dbf data files when the backup is read-only (read only), where the table space yhqt later be modified to read write state, but there is no backup, and now the data file is damaged
--open
RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10;
recover datafile 10;
sql'alter database datafile 10 online';
}
Scenario 5: yhqt01.dbf data file during the backup is read write, later modified to be read only state, no backup, the current data file is corrupted
--open
RMAN> run {
sql'alter database datafile 10 offline';
restore datafile 10 force;
recover datafile 10;
sql'alter database datafile 10 online';
}
Use keywords in force in order to restore the order to cope with the case file, although damage is still present.
11.3.3 recover under control file damage
Recovery files under a so-called damage control means: at failure recovery with the read-only data files and control files
--1 start to nomount
--2 with restore restore the control file
--3 start to Mount
--4 with read-only data file restore to restore
--5 use recover restore the entire database
--6 open the database with resetlogs
Damage control and read-only data files yhqt01.dbf or missing files together, db can only start to nomount status, error reporting:: Scene 1 ORA-00205: error in identifying control file, check alert log more info
RMAN> run {
startup nomount;
restore controlfile from autobackup;
mount database;
restore datafile 10;
recover database;
alter database open resetlogs;
}
## recover database is to restore normal operation of the control file, the read-only data file 10 has no effect, the output corresponding to the command is displayed in the "information file 10 unprocessed"
using channel ORA_DISK_1
datafile 10 not processed because file is read-only
Scene 2: yhqt01.dbf data file is read-only, the files and control files backed up, then the tablespace yhqt (data file contains yhqt01.dbf) modified to read write, but the data file and the control file is not backup, and now yhqt01.dbf controlfile also damaged.
ORA-00205: error in identifying control file ,check alert log more info
RMAN> run {
startup nomount;
restore controlfile from '/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013968921_gm0jws37_.bkp';
mount database;
restore datafile 10;
recover database;
alter database open resetlogs;
}
Oracle Error
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error blew
ORA-01152: file 10 was not restored from a sufficiently old backup
ORA-01110: data file 10 :'/u01/app/oracle/oradata/orcl/yhqt01.dbf'
Cause of this problem is the same information in the data file header and control files indicating yhqt01.dbf should be read-only file, causing performed a recover database, yhqt01.dbf did not file should be included in the scope of recovery.
But as for recovery, redo log there is a change in the record yhqt01.dbf revised to read write state, then unaware of the channel should not be excluded from yhqt01.dbf file recovery, then an error during recover.
Solution: to perform a recover database
The right solution
RMAN> run {
startup nomount;
restore controlfile from '/u01/app/oracle/fra/ORCL/autobackup/2019_07_18/o1_mf_s_1013968921_gm0jws37_.bkp';
mount database;
restore datafile 10;
recover database;
recover database;
alter database open resetlogs;
}
When the control file and data file (read only once or read-only) damage simultaneously.
RMAN> run {
startup nomount;
restore controlfile from autobackup;
mount database;
restore datafile 10;
recover database;
recover database;
alter database open resetlogs;
}