cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Bare metal restore with Oracle client

Cedric_S
Level 3

We are currently testing our backup strategy with Symantec and so far so good.

Since last week I have been trying to do a bare metal restore of an oracle server. this is what I did so far:

  • Convert original machine to Virtual machine Point in Time.
  • Rename server + assign new IP + new SID
  • remove oracle broken database instance (oradim -delete)
  • Create new instance with same SID (oradim -new)
  • generate new password file (orapwd file=path\pwdsid.ora password=<password>)
  • change DBID to the original (rman: SETDBID<dbid ID>)
  • Reconfigure backup exec agent utility, restore trust, reconfigure oracle instance and database access.
  • Add 'new' virtual server to backup exec interface and configure password
  • create restore job in old 'broken' server that uses last available control file.
  • restore to a different Oracle server, with the server name, correct log on account and database log on account.

when I execute this job i get the RMAN error:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 11/18/2013 14:47:45 ORA-27191: sbtinfo2 returned an error

 

when I enable server side debugging this is the last entry i see in my log:


BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.725 [engapi]             - Record                    - 7
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.725 [engapi]             -    resource               - Oracle-Win::\\mlinetstsvr02-vm.itnet.hosp\mlineTEST
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    account name           -
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    account ID             - 00000000-0000-0000-0000-000000000000
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource ID            - 00000000-0000-0000-0000-000000000000
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource Container ID  - 00000000-0000-0000-0000-000000000000
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    server                 - mlinetstsvr02-vm.itnet.hosp
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    server ID              - 00000000-0000-0000-0000-000000000000
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource OS ID         - 39
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource OS Ver        - 0
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource Type          - 14
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    resource Sub Type      - 2
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    flags                  - 0x5
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    update date time       - 11/18/2013 1:47:07 PM
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    No password Found
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             - *****************************************************************
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [server]             - Removing 'MLINETSTSVR02.itnet.hosp Restore 00060' from status update list
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [server]             - Updating status for: 'MLINETSTSVR02.itnet.hosp Restore 00060' (0x18 0x0)
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.727 [server]             - Status for: 'MLINETSTSVR02.itnet.hosp Restore 00060' updated
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.730 [server]             - Merging of BE / VSR Job Logs not necessary for this Type of Job
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.730 [server]             - EndJob() criticalVolumeError - 0x0
BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.730 [server]             - Ending job 'MLINETSTSVR02.itnet.hosp Restore 00060' with error status (-536870080)

 

to clarify, mlinetstsvr02 is the original server that is broken. mlinetstsvr02-vm is the new machine.

Does anybody have any idea how I can resolve this? Or is there a good step by step guide to do this?
I used the administrators guide but this is not that clear imho.
 

1 ACCEPTED SOLUTION

Accepted Solutions

Cedric_S
Level 3

 An update on this problem.

Although it is not resolved we have a workaround that actualy suits our needs better.

We made our own rman scripts and use this as a pre-script to the actual backup task.
BU2012 now only backups the location of our generated backup files. This gives us more freedom in rman configuration (file retention etc) and in how and what we backup.

@Sasha, thank you for your time and energy
 

Kind regards,
C

View solution in original post

5 REPLIES 5

Vishal_Shinde
Level 5
Employee Accredited Certified

Hello,

Please find the steps in sequence below:

 

To recover the complete Oracle instance to use a new or alternate Oracle server for the recovery

 

1 Recreate the Oracle database using the same name you used for the original database

that was lost.

 

2 Find and rename the pwd<SID>.ora file.

 

3 Create a new pwd<SID>.ora file.

 

To create a new pwd<SID>.ora file

1 Open a command prompt.

2 Type the following command:

orapwd file=path\pwdsid.ora password=<password>

 

 

To continue the disaster recovery

1 In the command prompt, do the following:

 

2 Type the following command:RMAN

3 Type CONNECT TARGET <sys/password@sid>;

4 Type SHUTDOWN ABORT;

5 Type STARTUP NOMOUNT;

6 Type SET DBID<dbid ID>;

 

7 Move to the Backup Exec media server.

 

8 On the navigation bar, click the arrow next to Restore.

 

9 Click New Restore Job.

 

10 On the Properties pane, under Source, click Selections.

 

11 Select the appropriate ControlFile to restore.

 

12 On the Restore job properties pane, under Destination, click Oracle Redirection.

 

13 Check the check box for the option, Restore Oracle instance to server.

 

14 Enter account credentials to access the new or alternate Oracle server.

 

15 Check the check box for the option, Restore datafiles to the following path:

 

16 Type a path to the new database.

 

17 Check the check box for the option, Restore archived log files to the following path:

 

18 Click Run Now.

 

The restore job will fail because the recovery portion encounters inconsistent archive

logs. This is a normal occurrence during a disaster recovery.

 

19 Move to the Oracle server.

 

20 Type Alter database open resetlogs;

 

21 Do one of the following:

If an error is encountered while Oracle tries to open the database Note the online redo log path and then update the path

using the steps below.

To update the online redo log file path

1 At the Oracle server, open a command prompt.

2 Type the following command:

SQLPLUS /nolog

3 Type connect<sys/password@SID>;

4 Type the following SQLPlus command:

SQLPLUS ALTER DATABASE RENAME FILE <old path from backup to any redolog file name> to

<path to expected restored redolog file name>;

For example,

ALTER DATABASE RENAME FILE β€˜D:\ORACLE\ORADATA\JACOB\REDO01.LOG’ to

β€˜C:\ORACLE\ORADATA\JACOB\REDO01.LOG’;

5 In the command prompt, type RMAN.

6 Type the following command at the RMAN prompt:

Alter database open resetlogs;

7 Close the command prompt.

 

The recovery should be  finished.

 

Kind Regards,

S

Cedric_S
Level 3

Sasha, thank you for your reply!

Sadly I already found this tutorial/how to and this does not work for me.
We are using backup exec 2012 and we do not have the option 'oracle redirection', i guess this option has been renamed to 'restore to different Oracle server'

I followed all the steps described above but that keeps generating the described error.

Meanwhile we found in the eventlog on the client that it had a problem authenticating. This because the name was to long. After changing the name we still have the same issue as above.

any advice?

Vishal_Shinde
Level 5
Employee Accredited Certified

Hi,

We are going to need some more information on the problem.

Please follow instructions below on running the restore in Debug mode. This diagnostic information is crucial to determine where the problem lies.

on Oracle server, where the data is restored:

You will need to stop the Remote Agent for Windows Servers

Then go into the registry to enable VXBSA debugging.

HKLM\Software\Symantec\Backup Exec for Windows\Backup Exec\Debug
Dword Key = VXBSADebug
Value = 5

Now restart the Remote Agent for Windows Servers in debug mode

The debug files will be saved by default to c:\program files\symantec\Backup Exec\RAWS\Logs

In this folder there is 1 folder called dbagents and several xml files. These can all be ignored.
These are the files that you will want to capture:

ServerName-vxbsaXX.log
Stubtrac.pid=XXXX.tid=XXXXXX.XXXXXXXXXX.log
ServerName-beremoteXX.log
TAOCli.log

This registry change do not have any implications on the oracle database.

Please attach the files, if this is fine with you.


Note:
This debug logs may contain information about the server, so please check for any security constrains at your end.

or probably you can open a ticket with the support to troubleshoot the issue.


Kind regards,
S

 

 

Cedric_S
Level 3

Again Thank you for your reply Sasha!

I followed the steps you describe and the log files are generated but they are empty. I put the -debug parameter in the backup exec Remote agent serice to generate the files. these too are empty

I tried collecting data with the VxGather tool to, but these are not that usefull.

Meanwhile I tried reinstalling my agent and services on the destination machine but this to no avail.
 

I keep receiving the BENGINE:  [11/18/13 14:47:55] [9512]     2013-11-18T14:47:54.726 [engapi]             -    No password Found
message in my backup exec server log.


 

Cedric_S
Level 3

 An update on this problem.

Although it is not resolved we have a workaround that actualy suits our needs better.

We made our own rman scripts and use this as a pre-script to the actual backup task.
BU2012 now only backups the location of our generated backup files. This gives us more freedom in rman configuration (file retention etc) and in how and what we backup.

@Sasha, thank you for your time and energy
 

Kind regards,
C