cancel
Showing results for 
Search instead for 
Did you mean: 

Restoring SQL Server 2008 database to SQL Server 2012

wsutton
Level 3
Accredited

Environment is NetBackup 7.6.0.3 (Linux master and media servers, the client in this case is running Windows 2012).

Someone wants me to restore one of our SQL Server 2008 R2 databases to a test SQL Server 2012 instance.  I've researched everything I could to this point on my own; at this point, my Google-fu is failing and I need some advice.  The following is a snippet (edited to obfuscate sensitive data) from my dbclient log during the restore (which fails with status 2809):

15:34:04.064 [11476.11036] <4> Dbbackrec::CreateSQLcmdSyntax: INF - restore database "TESTDB" from VIRTUAL_DEVICE='VNBU0-11476-11036-1423514044' with  stats = 10, blocksize = 65536, maxtransfersize = 4194304, buffercount = 2, replace , norecovery, move 'TESTDB' to 'E:\LDF\TESTDB.ldf', move 'TESTDB' to 'F:\LDF\TESTDB.mdf', replace
15:34:04.064 [11476.10408] <4> DBthreads::dbprocessbufs: INF - DBPROCESSBUFS Started.
15:34:04.066 [11476.11036] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:34:04.067 [11476.11036] <2> logconnections: BPRD CONNECT FROM [dest_client].58036 TO [source_client].1556 fd = 812
15:34:04.067 [11476.6076] <4> DBthreads::dbclient: INF - DBCLIENT Started Stripe #0
15:34:04.071 [11476.6076] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:34:04.072 [11476.6076] <2> logconnections: BPRD CONNECT FROM [dest_client].58037 TO [source_client].1556 fd = 844
15:34:04.117 [11476.11036] <4> Dbbackrec::CreateSQLcmdSyntax: INF - Number of stripes: 1, Number of buffers per stripe 2.
15:34:04.118 [11476.11036] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:34:04.119 [11476.11036] <2> logconnections: BPRD CONNECT FROM [dest_client].58038 TO [source_client].1556 fd = 844
15:34:04.170 [11476.11036] <4> DBConnect: INF - Logging into SQL Server with DSN <NBMSSQL_11476_5188_1>, SQL userid <sa> handle <0x00c79ea0>.
15:34:04.267 [11476.11036] <4> CDBbackrec::InitDeviceSet(): INF - Created VDI object for SQL Server instance <[dest_client_name]>. Connection timeout is <300> seconds.
15:34:04.269 [11476.11036] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:34:04.269 [11476.11036] <2> logconnections: BPRD CONNECT FROM [dest_client].58040 TO [source_client].1556 fd = 956
15:34:04.376 [11476.6076] <4> DBthreads::dbclient: INF - wait for addr assigned 0
15:34:04.379 [11476.6076] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:34:04.380 [11476.6076] <2> logconnections: BPRD CONNECT FROM [dest_client].58041 TO [source_client].1556 fd = 964
15:34:04.463 [11476.6076] <4> DBthreads::dbclient: INF - Alternate buffer restore rejected because backup did not use alternate method.
15:34:04.463 [11476.6076] <4> DBthreads::dbclient: INF - starttime 1423191669 - endtime:1423364469

I have highlighted what looks to me to be the closest thing I have to an actual error message.

 

The closest thing I've found on Google, based on the NBU console and other logs, was http://www.symantec.com/business/support/index?page=content&id=TECH206956, which pertains to backwards-compatibility between different versions of SQL Server 2008.  I supposed I could see something similar being the case between 2008 and 2012, but would

  1. like to find a solution, if possible
  2. like to see some sort of official documentation that this isn't possible, otherwise
1 ACCEPTED SOLUTION

Accepted Solutions

Abesama
Level 6
Partner

Hi,

It could be simply from your log-sanitizing but I wanted to point out that I see this at the beginning of your dbclient log.

move 'TESTDB' to 'E:\LDF\TESTDB.ldf', move 'TESTDB' to 'F:\LDF\TESTDB.mdf',

Usually, it's supposed to say move database_log to ldf, while your log is stating that the same "TESTDB" is being moved to both of ldf and mdf.

If your move script has lines as

MOVE "TESTDB"
TO "F:\LDF\TESTDB.mdf"
MOVE "TESTDB"
TO "E:\LDF\TESTDB.ldf"

then modify the lines to read,

MOVE "TESTDB"
TO "F:\LDF\TESTDB.mdf"
MOVE "TESTDB_log"
TO "E:\LDF\TESTDB.ldf"

Also we could look at the full restore dbclient logs to find out if there are any of <8> or <16> lines which would tell us more about the higher severity conditions.

As you know, NetBackup log files say lots of "not matching" "rejected" "not found" lines and they are mostly just part of cross-checking or routine verification steps, not necessarily being the root cause of the failure.

Hope this helps.

A

View solution in original post

4 REPLIES 4

Abesama
Level 6
Partner

Hi,

It could be simply from your log-sanitizing but I wanted to point out that I see this at the beginning of your dbclient log.

move 'TESTDB' to 'E:\LDF\TESTDB.ldf', move 'TESTDB' to 'F:\LDF\TESTDB.mdf',

Usually, it's supposed to say move database_log to ldf, while your log is stating that the same "TESTDB" is being moved to both of ldf and mdf.

If your move script has lines as

MOVE "TESTDB"
TO "F:\LDF\TESTDB.mdf"
MOVE "TESTDB"
TO "E:\LDF\TESTDB.ldf"

then modify the lines to read,

MOVE "TESTDB"
TO "F:\LDF\TESTDB.mdf"
MOVE "TESTDB_log"
TO "E:\LDF\TESTDB.ldf"

Also we could look at the full restore dbclient logs to find out if there are any of <8> or <16> lines which would tell us more about the higher severity conditions.

As you know, NetBackup log files say lots of "not matching" "rejected" "not found" lines and they are mostly just part of cross-checking or routine verification steps, not necessarily being the root cause of the failure.

Hope this helps.

A

Rob_Small
Level 2

This one is my go to for redirected restores (making a move template) for sql, or even upgrading/migrating apps to newer revs of sqlserver. It's 10 years old, but still relevant: http://www.symantec.com/business/support/index?page=content&id=TECH35995

For 2008 & 2012, I've seen it get really cranky about not running it as Admin.

Make sure you have the altnames set right so you can restore to a different box (or have the no.restrictions touchfile).

I've also seen it get touchy if you're sqlserver is direct-backup like a media or enterprise client where it owns the backup media where the databases are stored. You'll need to find find a way to either make your master own them or have your media/entclient serve up the restore.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Please post entire dbclient log as File attachment (copy to dbclient.txt).

There may be insufficient info in the log if logging level is 0.
I encountered an issue where DB on a test machine was restored with no useful info in the logs (NBU and MS-SQL ). 
Level 3 logging on the client revealed that the DB was 'in use'. 
This TN helped to identify/resolve the issue: http://www.symantec.com/docs/TECH44445 

 

wsutton
Level 3
Accredited

Abesama got part of it right, so I've marked that response as a solution.  I had to make one other change to my script.  I had to change the BROWSECLIENT directive to ALTCLIENT.  The final, sanitized script follows:

OPERATION RESTORE
OBJECTTYPE DATABASE
DATABASE "TESTDB"

MOVE "TESTDB_log"
TO "E:\LDF\TESTDB.ldf"

MOVE "TESTDB"
TO "F:\MDF\TESTDB.mdf"

# The following image is type: Full
NBIMAGE "SOURCE_HOST.MSSQL7.SOURCE_HOST.db.TESTDB.~.7.001of001.20150206220109..C"
SQLHOST "DEST_HOST"
NBSERVER "MASTER_SERVER"
ALTCLIENT "SOURCE_HOST"
MAXTRANSFERSIZE 6
BLOCKSIZE 7
RESTOREOPTION REPLACE
RECOVEREDSTATE NOTRECOVERED
TRACELEVEL MID
NUMBUFS 2
ENDOPER TRUE