cancel
Showing results for 
Search instead for 
Did you mean: 

SQL script restore error

Dollypee
Moderator
Moderator
   VIP    Certified

SQL version: 2008 R2

NBU version: 7.6.0.3

I am task to restore sql db to an alternate location. I have created the script using usual MS SQL client gui & move template. ( I have done this countless time to restore alternate client request without issue)

But for some reason, i found that quite a lot of info/lines such as "MOVE, TO, source database path are all missing in the script.

Can any please advise why the above required lines are missing ? Thank you

 

 

Below is how the script appeared


#  This is a template for the database MOVE command.

OPERATION RESTORE
OBJECTTYPE DATABASE
RESTORETYPE MOVE

#  Replace the database name in the following line with the name of the database that you
#  want to move to. Also remove the hash mark <#> which precedes the keyword <DATABASE>.

#DATABASE "ARSystem"
# The following image is type: Full
NBIMAGE "CRPPMS2-SQLD-N4.MSSQL7.CRPVSQLREMPRDS\REMPRD.db.ARSystem.~.7.001of001.20151003060014..C"
SQLHOST "CRPVMS2SQLCP2" ==================================> Destination
NBSERVER "VERITAS.NYCHHC.ORG"
BROWSECLIENT "CRPVSQLREMPRDs.central.nychhc.org" ===========> Source DB
MAXTRANSFERSIZE 6
BLOCKSIZE 7
RECOVEREDSTATE RECOVERED
NUMBUFS 2
ENDOPER TRUE

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Dollypee
Moderator
Moderator
   VIP    Certified

This issue has been resolved.

Method: 1

There's a bug in  NBU version 7.6.0.3 assocated with Etrack3747591.The official fix is in Netbackup versions 7.6.1.2 & 7.7.1. For environment on 7.6.0.3, patch affect client to 7.6.0.4 & applied official EEBs from veritas. The EEBs can only be retrieve by opening a case with Symantec.

Method: 2

The alternate way to resolve this issue is by manually inserting missing keywords in the script.

View solution in original post

6 REPLIES 6

Yasuhisa_Ishika
Level 6
Partner Accredited Certified

#  Replace the database name in the following line with the name of the database that you
#  want to move to. Also remove the hash mark <#> which precedes the keyword <DATABASE>.

As stated above, at least, you have to set database name.

Dollypee
Moderator
Moderator
   VIP    Certified
Hi Yasuhisa, I totally understand those instructions. Like I said, I have performed countless SQl restore. As a matter of fact, i just completed another similar request just a while ago.
 

But my concern is basically related to this particular restore. For some reason, the script came up with no usual remove # mark from "MOVE, TO, source database path" in the script. This is very strange as I have'nt seen such in my 7 years of performing related restores. Usually, an administrators is expected to manually edit this lines in the script to point to new path when performing an alternate restore. But these lines do not even appear in this my move template script.
 

I hope you got my point here. Thank you

DG-2005
Level 5

This appears to be an in-place restore of a full backup, this is the correct script for that type of restore. 

Ensure sure you are selecting the move template option when generating the restore script.

Dollypee
Moderator
Moderator
   VIP    Certified

Hi DG-2005, Yes am using a move template. but script won't come up as I stated above.

Dollypee
Moderator
Moderator
   VIP    Certified

The issue is that, after the template is created using "move template" by default - the MOVE, TO parameters needs to be in the template which will be edited to point to new path.  But in this case, this parameters are missing in the bash script. 

This particular scenerio appears to be occuring for a specific sql instance not all my instance.

Am I by any chance missing something from SQL end?

Dollypee
Moderator
Moderator
   VIP    Certified

This issue has been resolved.

Method: 1

There's a bug in  NBU version 7.6.0.3 assocated with Etrack3747591.The official fix is in Netbackup versions 7.6.1.2 & 7.7.1. For environment on 7.6.0.3, patch affect client to 7.6.0.4 & applied official EEBs from veritas. The EEBs can only be retrieve by opening a case with Symantec.

Method: 2

The alternate way to resolve this issue is by manually inserting missing keywords in the script.