Home » RDBMS Server » Backup & Recovery » Duplex Backups
Duplex Backups [message #255679] Wed, 01 August 2007 08:33 Go to next message
box@ucmo.edu
Messages: 2
Registered: August 2007
Location: Missouri
Junior Member
I have discovered what I think is a problem duplexing backups.

RMAN-00571: ===============================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===============================================
RMAN-03002: failure of backup command at 07/30/2007 06:32:12
ORA-19502: write error on file

RMAN-00571: ===============================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===============================================
RMAN-03002: failure of Duplicate Db command at 07/27/2007 03:50:13
RMAN-03015: error occurred in stored script Memory Script
ORA-19608

If either side of the duplex backup set has a problem reading or writing, then RMan quits.

In response to an Oracle SR, I am told:

Is normal behaviour that RMAN stop if any error is reported. Observe the following information in Oracle9i Recovery Manager User's Guide Release 2 (9.2) ---> Chapter 5. RMAN Concepts I: Channels, Backups, and Copies :

Backup Errors
-------------------
RMAN can handle the two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces cause the system to terminate the jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates the backup.

If an RMAN job produces more than one separate backup set and an error occurs, then RMAN needs to rewrite the backup sets that it was writing at the time of the error.

SO, if I make two backups in stead of duplexing the backup set I double my chances of having a good backup and half my chance of failure.

Having a duplexed backup set will not increase my chances of having a good recovery because if RMan has a problem reading the set it does not look at the other copy of the backup piece in the backup set.

Am I missing something - or is duplexing a bad idea?
Re: Duplex Backups [message #255718 is a reply to message #255679] Wed, 01 August 2007 10:23 Go to previous messageGo to next message
DreamzZ
Messages: 1666
Registered: May 2007
Location: Dreamzland
Senior Member
Post your rman script.?

Quote:
SO, if I make two backups in stead of duplexing the backup set I double my chances of having a good backup and half my chance of failure.


Two backup commands will need more resources as compratatively to DUPLEX.How you can say that by taking one by one backup you would have good backup.
May be some flaw in your script?

Quote:
Having a duplexed backup set will not increase my chances of having a good recovery because if RMan has a problem reading the set it does not look at the other copy of the backup piece in the backup set


Y NOT?
As in Duplex oracle generates different UNIQUE name for backup like (0tcm8u2s_1_1 and 0tcm8u2s_1_2).Then you can use these names for Recovery.
Re: Duplex Backups [message #255731 is a reply to message #255718] Wed, 01 August 2007 10:49 Go to previous message
box@ucmo.edu
Messages: 2
Registered: August 2007
Location: Missouri
Junior Member
/u01/app/oracle/product/9.2.0/bin/rman
connect target
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/PROD_%F';
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 1G FORMAT '/backup01/PROD_%T_s%s_p%p_c%', '/backup02/PROD_%T_s%s_p%p_c%c';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/backup/snapcf_PROD.f';
BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
EXIT
EOF
Previous Topic: RMAN script
Next Topic: HOW CAN GET SPACE FROM PERCENT_SPACE_RECLAIMABLE COLUMN OF V$Flash_Recovery_Area_Usage
Goto Forum:
  


Current Time: Tue Dec 06 14:26:28 CST 2016

Total time taken to generate the page: 0.10807 seconds