Comments on: Idera SQLsafe Followup: Problems with Restoring Databases http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/ Your technology pain-relief experts. Wed, 08 Feb 2012 16:37:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dan Shargel http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/comment-page-1/#comment-15834 Dan Shargel Wed, 23 Dec 2009 21:39:33 +0000 http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/#comment-15834 Ok, we heard back from Idera support and the recommendation from their development team was to disable the VDB switch which is enabled by default in 6.0. I believe this is to supplement the new Virtual Database application but could be wrong. From support: <i>"Please have the customer run this backup with VDB mapping turned off, but still with level 3 debugging. If he still has the problem with mapping off then I would like to see the log. You can turn off VDB mapping in your scripts by adding " -VDB Off" at the end of the command."</i> We haven't been able to duplicate the backup hang/memory leak issue since we've enabled the switch in a test environment (or without the switch either) but we'll give it some time before upgrading to 6.0 again just in case. Ok, we heard back from Idera support and the recommendation from their development team was to disable the VDB switch which is enabled by default in 6.0. I believe this is to supplement the new Virtual Database application but could be wrong.

From support:

“Please have the customer run this backup with VDB mapping turned off, but still with level 3 debugging. If he still has the problem with mapping off then I would like to see the log.

You can turn off VDB mapping in your scripts by adding ” -VDB Off” at the end of the command.”

We haven’t been able to duplicate the backup hang/memory leak issue since we’ve enabled the switch in a test environment (or without the switch either) but we’ll give it some time before upgrading to 6.0 again just in case.

]]> By: Dan Shargel http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/comment-page-1/#comment-15699 Dan Shargel Fri, 18 Dec 2009 16:55:09 +0000 http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/#comment-15699 Also, in case someone finds in this in a Google search six months from now (after it's resolved right?), the SQLSafe version we are running is 6.0.4 (x64). Also, in case someone finds in this in a Google search six months from now (after it’s resolved right?), the SQLSafe version we are running is 6.0.4 (x64).

]]> By: Dan Shargel http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/comment-page-1/#comment-15697 Dan Shargel Fri, 18 Dec 2009 16:51:14 +0000 http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/#comment-15697 I would hold off on upgrading to SQLSafe 6.0 in case anyone is interested. Upgraded several servers in the past week from 5.0 and seeing memory leaks with the SQLSafe service paging when either a log or full backup gets hung along with time out errors in the event logs connecting to the SQLSafe service. We have one database that is only 10MB which should take a few seconds to backup and it occasionally will stall when backed up overnight (backups up fine later though) and requires a restart of the SQLSafe service. That being said the compression rate with 6.0 improved over 5.0 depending on the database (seen some go from 180GB backups to 160GB for example). Anyway opened a case with Idera and requested our rep follow up with them. In the meantime going to revert a few of these servers back to 5.0 I would hold off on upgrading to SQLSafe 6.0 in case anyone is interested. Upgraded several servers in the past week from 5.0 and seeing memory leaks with the SQLSafe service paging when either a log or full backup gets hung along with time out errors in the event logs connecting to the SQLSafe service. We have one database that is only 10MB which should take a few seconds to backup and it occasionally will stall when backed up overnight (backups up fine later though) and requires a restart of the SQLSafe service. That being said the compression rate with 6.0 improved over 5.0 depending on the database (seen some go from 180GB backups to 160GB for example). Anyway opened a case with Idera and requested our rep follow up with them. In the meantime going to revert a few of these servers back to 5.0

]]> By: Jeff Fandl http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/comment-page-1/#comment-11834 Jeff Fandl Fri, 25 Sep 2009 15:46:51 +0000 http://www.brentozar.com/archive/2007/11/idera-sqlsafe-followup-problems-with-restoring-databases/#comment-11834 It is hard for a DBA or anyone to find out solid information about weakenesses in SQLSafe by doing a net search so I enjoyed reading this article. We have been using 4.5 then 4.8 and now 5.0 We have experienced many bugs which they confirmed such as not being about to backup more than 500 DB's on one server. We have over 800 on one. I have a suspected bug that we have yet to confirm and I wondered if anyone else experienced the problem. We are backing up the DB's in a Win2k3 cluster. When the destination disk for backups is full (because SQLSafe doesn't cleanup old files) it appears that SQLSafe has a memory leak. After so many failed attempts, SQL stops responding and the cluster eventually fails over. In every case, I see consistently in the event logs that it was running a backup when it failed. This seems to be consistent, only when the destination disk fills up. Has anyone else experienced this issue? It is hard for a DBA or anyone to find out solid information about weakenesses in SQLSafe by doing a net search so I enjoyed reading this article. We have been using 4.5 then 4.8 and now 5.0 We have experienced many bugs which they confirmed such as not being about to backup more than 500 DB’s on one server. We have over 800 on one.

I have a suspected bug that we have yet to confirm and I wondered if anyone else experienced the problem. We are backing up the DB’s in a Win2k3 cluster. When the destination disk for backups is full (because SQLSafe doesn’t cleanup old files) it appears that SQLSafe has a memory leak. After so many failed attempts, SQL stops responding and the cluster eventually fails over. In every case, I see consistently in the event logs that it was running a backup when it failed. This seems to be consistent, only when the destination disk fills up. Has anyone else experienced this issue?

]]>