VMware Cloud Community
patrickroberts
Contributor
Contributor

VCB and SQL Server 2005

Hi,

I have a Windows 2003 (5.2.3790), SQL Server 2005 SP2 - Cumulative Update 7 (9.0.3239) .I am running ESX 3.5 with Virtual Center 2.5. VMware tools running are 3.5.0 build 64607.

We have just set VCB to backup this TEST database server and when the backed kicked off for the first time it killed TEMPDB. The SQL errorlog shows the following error message.

2008-06-19 19:01:15.660 spid3s Error: 17053, Severity: 16, State: 1.

2008-06-19 19:01:15.660 spid3s LogWriter: Operating system error 1784(The supplied user buffer is not valid for the requested operation.) encountered.

2008-06-19 19:01:15.660 spid3s Write error during log flush.

2008-06-19 19:01:15.660 spid88 Error: 9001, Severity: 21, State: 4.

2008-06-19 19:01:15.660 spid88 The log for database 'TEMPDB' is not available. Check the event log for related error messages. Resolve any errors and restart the database.

SQL Server was up however TEMPDB became unavailable and I had to end up killing the process to even stop it. The backup kicked off at 7pm and by the time I started investigating the following morning at 9.30am the errorlog had grown to 1.6gb. Thankfully TEMPDB is recreated upon startup so the error cleared after a service restart.

I then performed a VCB test again however this time a user database (WSUS) had the same errors. Thankfully this time it recovered.

2008-06-19 10:13:44.950 spid83 The log for database 'SUSDB' is not available. Check the event log for related error messages. Resolve any errors and restart the database.

2008-06-19 10:13:44.950 spid83 Error: 3314, Severity: 21, State: 5.

2008-06-19 10:13:44.950 spid83 During undoing of a logged operation in database 'SUSDB', an error occurred at log record ID (8722:203:1). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.

2008-06-19 10:13:45.190 spid23s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.

2008-06-19 10:13:45.250 spid23s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.

2008-06-19 10:13:45.270 spid23s SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.

2008-06-19 10:13:45.280 spid23s Starting up database 'SUSDB'.

2008-06-19 10:13:45.490 spid23s 165 transactions rolled forward in database 'SUSDB' (6). This is an informational message only. No user action is required.

2008-06-19 10:13:45.500 spid23s 0 transactions rolled back in database 'SUSDB' (6). This is an informational message only. No user action is required.

2008-06-19 10:13:45.500 spid23s Recovery is writing a checkpoint in database 'SUSDB' (6). This is an informational message only. No user action is required.

2008-06-19 10:13:45.530 spid23s CHECKDB for database 'SUSDB' finished without errors on 2008-06-15 00:00:30.670 (local time). This is an informational message only; no user action is required.

I have read a couple of posts on these forums that for SQL and Exchange you should really stop the service before the snapshot backup however that isn't feasable a lot of the time in a PROD environment.

Is this a bug that I am experiencing with the SYNC driver or is it something that I will have to live with (If it is I will not use VCB on SQL Virtual Servers)

Regards,

Patrick

Reply
0 Kudos
2 Replies
dmaster
VMware Employee
VMware Employee

Hi Patrick,

This is as designed and not a bug. VMware VCB creates a crash consistent backup. you can use pre and post scripts to disable and enable services etc.

Reply
0 Kudos
patrickroberts
Contributor
Contributor

To help other people if they see the same error, It appears that VCB and SQL Server doesn't play well together. The only way to get a consistant backup without destroying SQL Server in the process is to stop the SQL Server service before taking the snapshot. Maybe this will change in future versions but not at the moment.

Regards,

Patrick.

Reply
0 Kudos