We have one SQL Server 2005 server in a DPM pilot. 

Backups generate the errors messages below in the SQL Server log. If these errors are not expected how I do resolve them? 

Thanks,

Tom Morris

05/17/2011 20:04:22,spid53,Unknown,I/O was resumed on database InternalXML. No user action is required.

05/17/2011 20:04:21,spid53,Unknown,I/O is frozen on database InternalXML. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.

05/17/2011 20:03:47,Backup,Unknown,Database backed up. Database: Escrow<c/> creation date(time): 2010/05/21(11:13:32)<c/> pages dumped: 1<c/> first LSN: 20:41:37<c/> last LSN: 20:57:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{1783131A-15C9-443F-814D-AD2104EE1C95}1'}). This is an informational message only. No user action is required.

05/17/2011 20:03:46,spid53,Unknown,I/O was resumed on database Escrow. No user action is required.

05/17/2011 20:03:46,spid53,Unknown,I/O is frozen on database Escrow. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.

05/17/2011 20:02:46,Backup,Unknown,Database backed up. Database: USAF4<c/> creation date(time): 2010/12/10(16:25:08)<c/> pages dumped: 1<c/> first LSN: 31:42:37<c/> last LSN: 31:58:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{22C16D43-7087-4781-ABD2-65A074B9CB33}1'}). This is an informational message only. No user action is required.

05/17/2011 20:02:45,spid53,Unknown,I/O was resumed on database USAF4. No user action is required.

05/17/2011 20:02:45,spid53,Unknown,I/O is frozen on database USAF4. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.

05/17/2011 20:02:28,Backup,Unknown,Database backed up. Database: USAFXML4<c/> creation date(time): 2010/12/10(16:25:19)<c/> pages dumped: 1<c/> first LSN: 21:202:37<c/> last LSN: 21:218:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{04C32DE3-E827-4000-AB0A-1EF431804E0D}1'}). This is an informational message only. No user action is required.

05/17/2011 20:02:27,spid53,Unknown,I/O was resumed on database USAFXML4. No user action is required.

05/17/2011 20:02:27,spid53,Unknown,I/O is frozen on database USAFXML4. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.

05/17/2011 20:01:31,Backup,Unknown,Database backed up. Database: TSG2<c/> creation date(time): 2009/05/29(13:38:35)<c/> pages dumped: 1<c/> first LSN: 1657:477:36<c/> last LSN: 1657:493:1<c/> number of dump devices: 1<c/> device information: (FILE=1<c/> TYPE=VIRTUAL_DEVICE: {'{9C565EA6-6BAE-44B8-85B1-C173A1287C80}1'}). This is an informational message only. No user action is required.

05/17/2011 20:01:30,spid52,Unknown,I/O was resumed on database TSG2. No user action is required.

05/17/2011 20:01:29,spid52,Unknown,I/O is frozen on database TSG2. No user action is required. However<c/> if I/O is not resumed promptly<c/> you could cancel the backup.

Hi RCOTom,

Are you getting any error in the DPM side for the backup job?

DPM does not report errors.

Does it show that the backup job completed successfully?

Yes. I have no reason to think the backup is not good. The problem is database users are frozen also. Something undesirable in a high-availability server. This is isn't normal operation is it?

Tom

Hi RCTom,

This is the way VSS works.

I/O on the database is frozen in order for VSS (Volume Shadowcopy Service) to take a snapshot of the volume containing the database. This is done to make sure that the database is consistent inside the snapshot. Once the snapshot is taken, the I/O on the database resumes, and then DPM starts copying data from the snapshot to DPM server. I would encourage you to watch the webcast on how DPM protects SQL server.
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032384076&CountryCode=US

If you are seeing performance degradation during backups I recommend you contact the Microsoft SQL team.

Thanks. Basically DPM is not ready for operational deployment.

When users are stopped that is serious performance degradation. But as you said, this is expected behaviour.

Our DBAs will never let this product on their servers. Effectively this program is blocking users throughput. I don't understand why any shop with a serious SLA would use this product; native SQL Server backups are a better solution. 

Tom

While I don't agree with Tom that DPM isn't ready for deployment or that native SQL backups are a better solution I too worry about the locks.

Lets say that we have a very taxing database job that rebuilds tables based on externally collected data and that this job for some reason is taking a lot longer to execute than anticipated.

What would happen with this job when VSS locks the DB in order to take a snapshot?

Thanks.

Folks,

To set more context on how the VSS backup operation happens, refer to http://msdn.microsoft.com/en-us/library/aa384589(v=VS.85).aspx.

Application who enable VSS writers are expected to handle the Freeze and Thaw events between which the shadow copy is taken. The operation typically has a limit of 60 secs. Even between this time, tha application (SQL in this case) should be able to handle any IO that might come through. This doesn't mean the application DB is actually down, it simply means, further flushes to disk are avoided to allow the shadow copy to be taken in a consistent manner by VSS.

Can I stop VSS on my sql server machine.

Is VSS mandatory for backup to be happen?

DPM uses VSS infrastructure to backup data.

If you stop (disable) VSS then all backups for that machine won't work

check this link this might help you

http://www.sqldbadiaries.com/2010/11/28/io-is-frozen-on-database-no-user-action-is-required/

Folks,

To set more context on how the VSS backup operation happens, refer to http://msdn.microsoft.com/en-us/library/aa384589(v=VS.85).aspx.

Application who enable VSS writers are expected to handle the Freeze and Thaw events between which the shadow copy is taken. The operation typically has a limit of 60 secs. Even between this time, tha application (SQL in this case) should be able to handle any IO that might come through. This doesn't mean the application DB is actually down, it simply means, further flushes to disk are avoided to allow the shadow copy to be taken in a consistent manner b