Veeam restore brackes Oracle backups

[Prog1026]

Currently i have opened support case №01684081

Scenario:
1.We have active SPA base on the host TigreGLXBOXI. Database backup is carried out by using standard Oracle utility RMAN to the remote host 10.119.97.21
2.We have a standby SPA base on the host TigreGLXBOXI02, which is a full bitwise copy of the active base (including configure file – spfile and control file – controlfile). It is obvious that controlfile of this base contains information on all backups of active base.
3.We make a backup of the host TigreGLXBOXI02. After that, Application aware conducts recovery of SPA base to the same host. In the process of recovery in the log work of Veeam we see the following:

Code: Select all

2/1/2016 10:36:11 AM    8 (4812) Executing RMAN script: DROP DATABASE INCLUDING BACKUPS NOPROMPT;
...
2/1/2016 10:36:11 AM    8 (4812)   Executing RMAN script: CONNECT TARGET sys/49a66c1fed ;
DROP DATABASE INCLUDING BACKUPS NOPROMPT;
...
2/1/2016 10:36:11 AM    8 (4812)   RMAN script saved to C:\Windows\TEMP\ora000000000123E8C0.rman
2/1/2016 10:37:23 AM    7 (7212)   sending session keeping notification...
2/1/2016 10:37:44 AM    8 (4812)     RMAN output: 
Recovery Manager: Release 12.1.0.1.0 - Production on Mon Feb 1 10:36:11 2016

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

RMAN> CONNECT TARGET *;
2> DROP DATABASE INCLUDING BACKUPS NOPROMPT;
3> 
connected to target database: SPA (DBID=1078028893, not open)

database name is "SPA" and DBID is 1078028893

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=123 device type=DISK
deleted backup piece
backup piece handle=\\10.119.97.21\BACKUPS\SPA\BACKUPSET\INC1_SPA_7114_902174733.BAK RECID=7095 STAMP=902174733
deleted backup piece
backup piece handle=\\10.119.97.21\BACKUPS\SPA\BACKUPSET\INC1_SPA_7115_902175009.BAK RECID=7096 STAMP=902175009
deleted backup piece
backup piece handle=\\10.119.97.21\BACKUPS\SPA\BACKUPSET\ARCH_SPA_7117_902175081.BAK RECID=7098 STAMP=902175081
…

Therefore, the db recovery from the backup leads to purging of files that are not applicable to Veeam at all (Veeam backups are carried out within other framework, rather than native Oracle backups). In addition, the directories with trace-files are cleared (ADR Home from v$diag_info), which may lead to impossibility to investigate the reasons for db failure, if Veeam backup was used for error recovery. The primitive scenario: the base is down, we have quickly recovered it from the backup, but we cannot analyze reasons for failure, as Veeam has cleared the base log.

Bottom line:
Usage of «DROP DATABASE INCLUDING BACKUPS NOPROMPT» – is a very strange and incorrect solution. It is possible to justify the use of «DROP DATABASE NOPROMPT», but deleting of not Veeam backups by Veeam is, frankly, too much.

IMHO, the entire scheme of base recovery to the original host is incorrect. I understand that the unified script “for all occasions” is used, but to recover a base to the location, where it was in the first place, it is enough to put the data files, control files, setting files and archievelogs to the right directories and start instance. THAT IS ALL. I assume that in 95% of cases the end users have such scenario. All this plainly extra actions regarding dynamic recreating of settings files (section «Trying to start database with full parameters list…» and commands after «Restarting restored database for DBNAME change to SPA (old value: SPA)...» in the log) are excessive and only lead to loss of time upon recovery and some problems (for example, problem with changing of memory control procedure from Automatic Memory Management to manual control).

PS: there is a great command in the log
Copying password file from: C:\VeeamFLR\TIGREGLXBOXI02_ee72f154\Volume0\oracle\ora12c\database\PWDSPA.ora to D:\oracle\ora12c\database\pwdSPA.ora...
The same needs to be done for all the instance files, there is no need to reinvent the wheel (at least for a scenario with the recovery to the original host).