So far ...

• 
  Please note that this comes at the expense of more CPU cycles and time, so using the new compression level needs to be carefully planned if you are short of either or both of these 2 resources on a live server.
  
  Thanks.

  petey June 04, 2009 12:18

  - 0 +
• 
  Petey,
  
  I agree with everything you say and would certainly advise users to consider the effects of the settings they choose.
  
  In my scenario we are only shipping the whole backup to another site on a weekly basis while the is server quiet over the weekend, our biggest problem is getting the file transferred quickly over our network so that other processes (NTFS backups etc) can take place. Making it a smaller file is a big gain for the small price of a busy CPU for a few minutes (our test server took 15 m to backup and verify, live takes 2m but the h/w is very different). Currently scheduling this and recovering where they clash is an all too common problem.
  
  Jonathan

  fatherjack2 June 05, 2009 03:50

  - 0 +
• 
  My concern was that other users might get the wrong impression that the new compression level (4) compresses better without incurring any additional resource costs, compared to the existing compression levels.
  
  In your case, you have a backup window that can tolerate the higher resource requirements, so it works out for you. BTW, you have some serious hardware if you can back up a 17.2 GB database in 2 minutes using compression level 4!

  petey June 05, 2009 09:09

  - 0 +
• 
  Noted, and thanks for making it clear.
  
  Live is still in v5, I am testing v6 on our, poorly spec'd, test rig. Live uses compression level 3 from v5.
  
  I wouldnt say our live hardware is anything special, 2xDual Core Xeons 20GB RAM, 8xHDD (2 RAID 1 for OS+logs, 2 RAID 0 for OLAP DB, 4 RAID 5 for OLTP DB)
  
  The backup goes straight off the server to a network share (beware risks here as network failure will crash backup with no recovery) and then gets copied to DR site. I think the fact that we have multiple cores and plenty of RAM means we gets great speed. SQL Backup uses 3 threads. Also the server is almost unused when the job takes place.
  
  Jonathan

  fatherjack2 June 08, 2009 04:52

  - 0 +
• 
  Hi,
  
  This is the exact scenario we are are trying to support with our new Network Resilience capability. You can configure how long to wait when a network outage happens.
  
  Do give it a try and let us know if it helps you in your case.
  
  Thanks,
  Priya

  priyasinha June 08, 2009 05:35

  - 0 +

Add comment

Please sign in to leave a comment.