New Hyperbac build is twice as slow

digitaloxdigitalox Posts: 5
edited December 3, 2012 9:41AM in SQL HyperBac 5
I've installed the lastest build ( 5.9.0.13) recently and noticed that the restores I/O is twice as low as the original version ( 5.2.1.7 ). This is impacting our servers as we have some somewhat large DBs. Nightly development restores, logshipping etc has slowed to the point of being useless. What can I do? Is anyone else experiencing this?


Thanks
Scott

Comments

  • Hi Scott,

    This forum post has raised a support request in our support system. I am shortly responding to this with a few quick questions to address your issues. We can leave this post open for other current users to post their comments and feedback.

    Thanks for your feedback in this matter.

    Regards,
    Raj.
  • Same experience after upgrade from 4.0.31 to 5.9.0.13. Average backup time has increases by a factor of 2.5.
    We have not changed the configuration option:
    Not using zip compatible or fast compression.
    Not using encryption
    Dynamic file updates disabled and not formating as virtual restore source or Oracle backup
  • Will add that this is a 64-bit OS.
  • Hi ecdba,

    Are you able to please send an email to support@red-gate.com with your contact details and mention for the attention of rajk in the subject?

    Some of the performance issues are configuration specific and I will need to request some logs. Email will be better for this exchange.

    On receipt of the email I will contact you back via email to help you with this issue.

    Thanks for your patience in this matter.
  • Hi,

    Are you able to please send an email to support@red-gate.com with your contact details and mention for the attention of rajk in the subject?

    Some of the performance issues are configuration specific and I will need to request some logs. Email will be better for this exchange.

    On receipt of the email I will contact you back via email to help you with this issue.

    Thanks for your patience in this matter.
  • As I mentioned, our configuration has not changed between the two versions (4.0.31 to 5.9.0.13). That is at least if one can assume that the meainig of UI fields has not changed. We also don't have the cycles to spend on testing earlier 5.x releases.
    We will remain on 4.0.31 until we migrate to SQL Server native compression to reduce our configuration footprint in the year ahead.
Sign In or Register to comment.