SQL Backup taking down a SAN!

dazzerb

interesting scenario where a single restore using red-gate and SQL 2005 can take down an entire enterprise class SAN. Whatever is going on the I/O caused by the restore can overwhelm the entire array and degrade performance for all 20+ connected systems that have nothing to do with the restore. No other activity on the array will cause degradation like this.

We are working with our storage vendor and am somewhat grasping at staws with this post but work a shot in the dark to see if anyone reading this has any insight as to whether or not Red-gate could be the culprit. Obviously the SAN/Arrays should not be degraded and the issue is probably testament to how well red-gate actually works!

Anyway if anyone has any insight of thoughts please let me know.

Thank you

PS: is it possible to trottle/slow down redgate?

dazzerb

There is a really nice document called "Optimizing the speed of SQL Backup".

Does anyone know if this relate to both backup AND restore operations or just backups?

Can the "Thread" syntax be used to limit restore bandwidth? Documentation is not clear that it can be.

http://www.red-gate.com/Products/SQL_Ba ... _speed.htm

WesBrown

You can't reduce the thread count on the restore side or limit the through put that I know of.

The only way to limit the I/O of the restore would be to reduce the number of threads the backup is using but that would also slowdown the backup as well.

Also, Is this sql 2000 or 2005?

Cheers,
Wes

dazzerb

so the restore threads follows the backup threads and there is no way to change after the fact?

How about thread priority? Would that help?