RMAN Related

• Restoring Oracle database items from the Restore database option is not supported for the Replicate, Replicate to a remotely-managed RPS, and Copy Recovery Points secondary tasks. As a workaround, use the Export backup to disk option, dump the Oracle data, and perform a manual Oracle recovery.
• The Oracle node addition may fail to validate the user if the UDP installation is performed with a user other than <domain>\administrator or <local>\administrator.
• Symptom
• While adding the Oracle RMAN Linux node to the Backup: Oracle Database task, the node addition fails, and the following error occurs:
• Invalid Non-Root credentials. Please verify and try again.
• Solution
• As a workaround, perform the following steps within the UDP Console and RPS to disable the Windows UAC prompt for the installation user.
1. Open the command prompt with elevated privileges (domain or local administrator), and then run the gpedit.msc command.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
3. Locate the following policy:
4. User Account Control: Run all administrators in Admin Approval Mode
5. This policy is enabled by default.
4. Double-click the policy, click Disabled, and then click OK.
5. To update the group policy from the elevated command prompt, run the gpupdate /force command.
6. Reboot the server.
7. The Oracle RMAN Linux node gets added successfully.

Note: Arcserve UDP does not recommend you perform the above steps within the Oracle server.

• The SPFILE from source location gets overwritten when the restore to an alternate location job is performed.
• Symptom
• When you restore database to an alternate location using the Recover All option, the SPFILE gets overwritten from the original location.
• Solution
• As a workaround, we recommend you that keep a copy of the SPFILE before you start the recovery. You can retrieve the location of original SPFILE using the following commands:
• SQL> SHOW PARAMETER spfile;
• select value from v$parameter where name = 'spfile';
• Note: This issue is applicable to both Windows and Linux Oracle RMAN protection.
• The restore of Windows Oracle node to an alternate node fails.
• Symptom
• When you protect the source Oracle database using a low privileged local user on the RPS installed on a workgroup, the restore of Windows Oracle node to an alternate node fails, and the following error occurs:
• “No AUTOBACKUP found or specified handle is not a valid copy or piece”
• Solution
• After the Restore to the alternate node job fails, perform the following manual workaround:
1. Log into the alternate Oracle server as a local administrator/low privileged local user.
2. Within the local/domain administrator remote session, change the failed database instance service logon to an administrator user/low privileged local user from the logical user.
3. Cache the RPS agent login credentials under Credential Manager.
4. Re-run the restore to an alternate node job.
• The restore of Windows Oracle node to an alternate node is successful.
• A block corruption is reported when the RESTORE or VALIDATE command is executed on the backed-up file during Assured Recovery or registry enabled Restore validation.
• Symptom
• When you execute the RESTORE or VALIDATE command on the backed-up file during Assured Recovery or registry enabled Restore validation on Windows node, the following block corruption error is logged:
• ORA-19599: block number 4216 is corrupt in archived log \\RPS_server\MOUNTBACKUPDB{B9170D5E-F4C3-11E5-976B-000C298CC68D-0926447031}WER\BACKUPDATA\LOG_ARCH_D-DB_ID-1726457973_S-363_T-1_A-1727425508_S6VVVN01
• Solution
• As a workaround, follow these steps:
1. Check the FILESYSTEMIO_OPTIONS parameter value using the following command:
2. SQL> SHOW PARAMETER FILESYSTEMIO_OPTIONS
2. If the FILESYSTEMIO_OPTIONS parameter value is NONE, SETALL, or empty, set the value to ASYNCH using the following command:
3. SQL>ALTER SYSTEM SET FILESYSTEMIO_OPTIONS=ASYNCH SCOPE=SPFILE;
3. Restart the database using the following commands:
4. SQL> SHUTDOWN IMMEDIATE
5. SQL> STARTUP
6. Note: If the FILESYSTEMIO_OPTIONS parameter is already configured as ASYNCH, maybe a valid block corruption gets reported. In this case, contact Oracle support.
4. Verify if the FILESYSTEMIO_OPTIONS parameter is set to ASYNCH using the following command:
5. SQL> SHOW PARAMETER FILESYSTEMIO_OPTIONS NAME TYPE VALUE
6. -----------------------------------------------------------------------------
7. Output:
8. filesystemio_options string ASYNCH
• Note: As the block corruption is reported for one of the data files, the corruption may persist within the upcoming backup sessions if the incremental schedules exist. Therefore, run a full backup job after setting the FILESYSTEMIO_OPTIONS parameter to ASYNCH.
• An incremental backup fails when the offline tablespaces are restored using restore to an alternate location for Linux Oracle nodes.
• Symptom
• When you restore the backed-up source of Linux Oracle Node with offline tablespaces to an alternate location, the datafiles of those tablespaces still point to the source location leading to an incremental backup failure.
• Solution
• As a workaround, follow these steps:
1. From Recovery Point, export the backed-up data using the Export to Disk option.
2. Copy the missing datafile of the tablespace from the source location to an alternate location. To copy, run the following command:
3. alter database rename file <full source path of datafile> <full destination path of datafile>
3. Make the tablespace online as needed, and then retrigger the backup.
4. The backup gets completed successfully.
• An incremental backup fails when the offline tablespaces are restored using restore to an alternate node for Windows and Linux Oracle nodes.
• Symptom
• When you restore the backed-up source of Windows and Linux Oracle Nodes with offline tablespaces to an alternate node, the datafiles of those tablespaces still point to the source location leading to an incremental backup failure when it runs from an alternate node.
• Solution
• As a workaround, follow these steps:
1. From Recovery Point, export the backed-up data using the Export to Disk option.
2. Copy the missing datafile of the tablespace from the source location to an alternate location on the alternate node. To copy, run the following command:
3. alter database rename file <full source path of datafile> <full destination path of datafile>
3. Make the tablespace online as needed, and then retrigger the backup.
4. The backup gets completed successfully on the alternate server.
• When No recovery option is selected while performing restore to alternate node, the manual recovery cannot be performed in the destination node.
• Symptom
• While performing restore to alternate node with No recovery option selected, the restore operation completes but the destination database gets into a mount state where the manual recovery cannot be performed.
• Solution
• As a workaround, select the Switch Database option while performing restore to alternate node with No recovery option selected.
• When No recovery option is selected while performing restore to alternate location, the manual recovery cannot be performed.
• Symptom
• While performing restore to alternate location with No recovery option selected, the restore operation completes but the database gets into a mount state where the manual recovery cannot be performed.
• Solution
• As a workaround, select the Switch Database option while performing restore to alternate location with No recovery option selected.
• Manual recovery of the restored Oracle database fails due to the unavailability of the archive logs.
• Symptom
• When you select the No recovery and Switch Database options while performing the manual recovery of the Oracle database restored to an alternate node or alternate location on the original server, the mount point is inaccessible after the restore job gets completed. This activity causes the unavailability of the archive logs. Hence, the manual recovery of the Oracle database fails, and the following error messages occur in the activity log:
• RMAN-03002: failure of recover command at <timestamp>
• RMAN-06053: unable to perform media recovery because of missing log
• RMAN-06025: no backup of archived log for thread X with sequence Y and starting SCN of Z found to restore
• Solution
• When you select the Delete archive logs from the source database after a successful backup option while creating a backup plan for Oracle database, the archive logs get deleted from the Oracle server after a successful backup to the recovery point. This activity causes unavailability of archive logs during the manual recovery of Oracle database restored to an alternate location on the original server.
• If you restore the Oracle database to an alternate node, the alternate server will not have the archive logs required for manual database recovery.
• As part of a restore job, UDP does not restore archive logs to the Oracle server. Instead, the archive logs from RPS mount point are cataloged with RMAN to use them during the recovery process.
• As a workaround, do the following:
1. Perform export to disk. For more information about how to perform export backup to disk, see Export backup to disk.
2. Connect to the database that you want to recover and run the following crosscheck commands:
Copy

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
RMAN> RUN
{
CROSSCHECK BACKUP DEVICE TYPE DISK;
CROSSCHECK COPY DEVICE TYPE DISK;
CROSSCHECK BACKUP OF DATABASE DEVICE TYPE DISK;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED COPY;
DELETE NOPROMPT EXPIRED BACKUP OF DATABASE;
}
RMAN> RELEASE CHANNEL;

3. Catalog the exported backup files.
4. Example:
5. RMAN> CATALOG START WITH '\\serverX\ExportBackup\' NOPROMPT;
6. RMAN> CATALOG START WITH '/mnt/ExportedBackup/' NOPROMPT;
4. Run the following recovery and reset log commands:
5. RMAN> RECOVER DATABASE;
6. RMAN> ALTER DATABASE OPEN RESETLOGS;
5. If the command to recover database still fails due to the unavailability of the archive logs, perform the PIT recovery using sequence number.
6. Note: You can get the sequence number required for the PIT recovery in one of the following ways:
• From the backup job activity logs for the respective session.
• Example: Backup information - SCN: 7148365, log sequence number: 79
• From the backed-up archive log list that displays with the browse recovery point.
• Example: LOG_ARCH_D-ORCL1_ID-1539984856_S-79_T-1_A-1542815267_FA2JIS03.
7. On the RMAN restore browse UI, identify the backed-up archive log file that contains the maximum sequence number for the session from where the restore job is performed, and use that sequence number while performing the PIT recovery.
8. Example:
Copy

RMAN> RUN
{ 
SET UNTIL SEQUENCE 79 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE UNTIL SEQUENCE 79 THREAD 1;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;