ORA-19511 Vendor specific error: Cannot find requested element ERR(-2)

Applies to:
Oracle Server Enterprise Edition - Version: 10.2 to 10.2
This problem can occur on any platform.

Symptoms
Backup returns error:
RMAN-03009: failure of backup command on sbt_backup channel at 02/23/2009 13:28:40
ORA-19506: failed to create sequential file, name="c-3183778111-20090219-02", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
Vendor specific error: Cannot find requested element ERR(-2)
ORA-19600: input file is backup piece
(+ASM_FRA/ractest/autobackup/2009_02_19/s_679226354.411.679226355)
ORA-19601: output file is backup piece (c-3183778111-20090219-02)

Cause

HP data protector media manager issue. The HP data protector software causes the error. There
is a delay between backupsets which are send to the HP cell server. If the delay is to long the hp
cell server closes the session. The client did not recognise the close and fails with the transfer
of the data.

Cause justified by customer.

Solution
To implement the solution, please execute the following steps:

A solution for me was to set in the configuration file:

On Unix Plattform: /etc/opt/omni/server/options/global
On Windows Plattform: C:\Programme\OmniBack\Config\Server\Options\global

the parameter SmWaitForNewBackupClient to 2 minutes:

# SmWaitForNewBackupClient=WaitForInMinutes
SmWaitForNewBackupClient=2

There are further hints about the SmWaitForNewBackupClientSec parameter. Maybe this parameter also
helps.
# SmWaitForNewBackupClientSec=WaitForInSeconds

Reference

Metalink Doc [ID 785219.1]

Reinstating a Physical Standby Using Backups Instead of Flashback

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.2.0 to 10.2.0.3
Information in this document applies to any platform.
Goal

After a Data Guard failover to a physical standby database, using flashback database is still the MAA recommendation to reinstate the original primary database since it is the simplest and fastest approach. However, if for some reason the flashback data is not available or flashback database was not enabled before the failure, you can use the steps provided in this document to reinstate the original primary database using existing backups instead of flashback database.
Solution

Oracle highly recommends utilizing flashback database to reinstate a physical standby after a Data Guard Failover. The procedure is simpler and safer. When using a controlfile restored from a backup instead of flashing back with the current controlfile, the backup controlfile may not reflect the same files as the data dictionary. However this can be avoided if a standby controlfile is created after each backup.

Prerequisites:
• Backups of all data files exist.
• Standby controlfile backups exist and were taken at the failed primary database using the ALTER DATABASE CREATE STANDBY CONTROLFLE command after each database backup.
• Database version is 10.2.0.2 or higher. Please refer to Alert Note 308698.1 and Note.368276.1.

Step 1: Retrieve STANDBY_BECAME_PRIMARY_SCN after Data Guard Failover
From the new primary:

SQL> select to_char(STANDBY_BECAME_PRIMARY_SCN) from v$database;

Step 2: Remove divergent archivelogs from the original, failed primary database

Remove any archivelogs created at the time of or after the Failover operation. The failed primary, if it was isolated from the standby, could have divergent archive logs not consistent with the current primary database. To ensure you do not ever apply these divergent archive logs, they must be deleted from your backups and flash recovery area. You can use the following RMAN command to delete the relevant archive logs from the flash recovery area.

RMAN> DELETE ARCHIVELOG FROM SCN STANDBY_BECAME_PRIMARY_SCN;

Step 3: Restore backup of the original, failed primary database

RMAN> RESTORE DATABASE;

Step 4: Startup standby database using the physical standby controlfile

If the standby controlfile backup needs to be restored, you will need to ensure the spfile or initialization files point to the standby control file and remount the new standby database.

SQL> startup mount

If a standby controlfile does not exist from the failed primary database, then follow steps 1 and 2.2 through 2.8 in Note 368276.1 to:

1. Clean up the flash recovery area
2. Create a new standby controlfile from the new primary database
3. Restart the new standby database with the new standby controlfile
4. Rename data files and log files

Step 5: Ship a new archive from the primary to the new physical standby database

SQL> alter system set log_archive_dest_state_n = ENABLE;
SQL> alter system archive log current;

From the primary, you can verify if the standby received the archive by querying:

SQL> select dest_id, dest_name, status, type, error, destination
2 > from v$archive_dest_status
3 > where dest_id = ;

Step 6: Restart managed recovery

SQL> recover managed standby database using current logfile through all switchover disconnect;

Step 7: Verify the new standby’s data files and control file are in sync

Once the standby is in sync with the primary, you can do a quick validation check to ensure all the data files are present. The following steps stop managed recovery and open the physical standby read only. The query checks if any data files found in the data dictionary do not match exactly the data files listed in the control file.

SQL> recover managed standby database cancel;
SQL> alter database open;
SQL> select file#, CRSCNBAS from file$
2> MINUS
3> select file#, creation_change# from v$datafile;

If no rows are returned, the data dictionary and controlfile metadata are in sync. Restart managed recovery as described in step 6.

References

Metalink Doc ID: [ID 416310.1]

NOTE:308698.1 - ALERT: Reinstating physical standby databases after a Data Guard Failover
NOTE:368276.1 - Steps to workaround issue described in Alert 308698.1
NOTE:416314.1 - Reinstating a Logical Standby Using Backups Instead of Flashback Database

How To Use RMAN For Backup And Restore In A Standby Database Environment

RMAN can back up the standby database and its associated archived redo logs.

Standby backups of datafiles and archived redo logs are fully interchangeable

with primary database backups. In other words, you can run the RESTORE command

to restore a backup of a standby datafile to the primary database, and you can

restore a backup of a primary datafile to the standby database. The standby

control file and primary control file, however, are not interchangeable.

Prerequisites:

- The standby database is created and fully functioning.

- An Rman catalog is established. Use the same Rman catalog for the primary

database and the standby database. Do not create a separate Rman catalog for

the standby database.

- Do not register the standby database in the Rman catalog, only the primary

database is to be registered.

To take backup on the standby database:

- The standby database should preferably be in 'mount standby' mode, not in

'recover managed standby' mode. On ver. 9.0.1 the subsequent redo log

applications fail with ORA-01157 ORA-01110 if the database was in 'recover

managed standby' mode during backup, after which "alter database recover

managed standby database;" must be reissued.

- The standby database is the target database

- Connect to the Rman catalog

- Run backup

- On ver. 8.1.7, run 'resync catalog' after the backup

- Check with 'list backupset of database' that the new backupset is stored in

the Rman catalog

On ver. 8.1.7 it is necessary to manually resync the catalog in order to get

the backupset taken on the standby database stored in the Rman catalog. The

resync will do a partial resynchronization, this is updating the catalog with

the changed information in the control file.

To run restore on the standby database:

- The standby database is in 'mount standby' mode (not in 'recover managed

standby' mode)

- The standby database is the target database

- On ver. 8.1.7, connect nocatalog to Rman; do not connect to the Rman

catalog as the restore will be run against the primary database if connected to

the Rman catalog

- On rel. 9i, connecting to the Rman catalog as well as connecting nocatalog

works

- Run restore

To run restore on the primary database:

- The primary database is the target database

- Connect to the Rman catalog

- Check with 'list backupset of database' that the backupset taken on the

standby database is accessible

- Run restore

Reference:

Metalink Doc ID: 203980.1

For Oracle ver. 8.1.7:

Oracle8i Documentation Addendum Release 3 (8.1.7),

Chapter 7 Recovery Manager, Backing Up Files at the Standby Site Using RMAN

For Oracle ver. 9.0.1:

Oracle9i Recovery Manager User's Guide Release 1 (9.

0.1), Chapter 9 Making Backups and Copies with Recovery Manager, Backing Up

Files at a Standby Database Site with RMAN

For Oracle ver. 9.2.0.1:

Oracle9i Recovery Manager User's Guide Release 2 (9.

2), Chapter 9 Making Backups and Copies with Recovery Manager, Backing Up Files

at a Standby Database Site with RMAN