RMAN recovery from different machines -- backup set permission problems

Source: Internet
Author: User

I received an email this morning and saw the failed rman recovery email sent by Master. The content is as follows:

 

The data has been decompressed. Under/orabak/Oracle_bak

However, an error is always reported when the backup file is read during restoration.

Channel dev1: reading from backup piece/orabak/oracle_bak/fullrac_EPTDB_820_1_20130802

ORA-19870: error reading backup piece/orabak/oracle_bak/fullrac_EPTDB_821_1_20130802

ORA-19587: error occurred reading 0 bytesat block number 1

ORA-27091: unable to queue I/O

ORA-27067: size of I/O buffer is invalid

Additional information: 2

ORA-19870: error reading backup piece/orabak/oracle_bak/fullrac_EPTDB_820_1_20130802

ORA-19587: error occurred reading 0 bytesat block number 1

ORA-27091: unable to queue I/O

ORA-27067: size of I/O buffer is invalid

Additional information: 2

 

System logs can also be seen

Fri Aug 9 00:30:04 2013

When upt block 1 found during reading backuppiece, file =/orabak/oracle_bak/fullrac_EPTDB_820_1_20130802, pai_type = 1

Fri Aug 9 00:30:41 2013

When upt block 1 found during reading backuppiece, file =/orabak/oracle_bak/fullrac_EPTDB_819_1_20130802, pai_type = 1

Fri Aug 9 00:30:41 2013

 

Confirm that there is no problem during transmission.

 

It seems that on this machine, RMAN cannot properly read the backup part...

 

Dizzy.

 

My first response was a backup set problem, so I checked it under the backup directory.

-R -- 1 oracle oinstall 20611072 Aug 08 ctl_eptdb_1__201720130802
-R -- 1 oracle oinstall 21474836480 Aug 08 fullrac_EPTDB_818_1_20130802
-R -- 1 oracle oinstall 21474836480 Aug 08 fullrac_EPTDB_818_2_20130802

-- They all have read-only permissions. I think there is a problem. I can think about it. rman backup reads the backup set, so there should be no impact if you don't need to write it. But it is strange to think so.

 

So I checked the MOS, which is indeed a permission issue:

 

Applies:

Oracle Database-Enterprise Edition-Version 10.2.0.1 to 10.2.0.4 [Release 10.2]
Oracle Database-Enterprise Edition-Version 10.1.0.2 to 10.2.0.1 [Release 10.1 to 10.2]
Information in this document applies to any platform.
* ** Checked for relevance on 06-May-2013 ***


SYMPTOMS

 

RMAN restore of read only backuppieces fails as follows:
.

ORA-19870: error reading backup piece
/Bugmnt/am/ceaixcb5/tar5619852.992/app/oracle/oradata/TARCS/bkup_03hp58dk_1_1
ORA-19587: error occurred reading 0 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27067: size of I/O buffer is invalid
Additional information: 2
Failover to previous backup
.
RMAN-571: ========================================================== ==============================
RMAN-569: ==================== error message stack follows ==========================
RMAN-571: ========================================================== ==============================
RMAN-3002: failure of restore command at 13:13:17
RMAN-6026: some targets not found-aborting restore
RMAN-6023: no backup or copy of datafile 4 found to restoreCAUSE

The backuppiece is in read only status at the operating system level.

SOLUTION

Make the RMAN backuppiece not only readable but also writable. See Bug 5412531 for other details.

-- Write permission is required!

REFERENCES

BUG: 5412531-rman fails restoring readonly backups: ORA-19870 ORA-19587 ORA-27091 ORA-27067

 

Solution: grant the write permission.

 

After the permission is modified, no error will be reported after verification.

Cd/orabak/oracle_bak

Chmod775 * 20130802

 

RMAN> restore controlfile validate;

 

Startingrestore at 09-AUG-13

Usingchannel ORA_DISK_1

 

ChannelORA_DISK_1: starting validation of datafile backupset

ChannelORA_DISK_1: reading from backup piece/orabak/oracle_bak/ctl_eptdb_assist_20120130802

ChannelORA_DISK_1: restored backup piece 1

Piecehandle =/orabak/oracle_bak/ctl_EPTDB_824_1_20130802 tag = TAG20130802T210600

ChannelORA_DISK_1: validation complete, elapsed time: 00:00:02

Finishedrestore at 09-AUG-13

 

There is no problem with subsequent recovery.

 

Note: The Recovery fails in the middle, or after the manual stop, The rman-related process should be killed and then restored, otherwise there will be problems in the future. Maybe in the second recovery process, the first process stops, and then the relevant files are deleted. In fact, the files that are restored for the second time are deleted (because the file names are the same ).

Recommended reading:

Basic Oracle tutorial-copying a database through RMAN

Reference for RMAN backup policy formulation

RMAN backup learning notes

Oracle Database Backup encryption RMAN Encryption

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.