Index file consuming drive space

goldmedalgoldmedal Posts: 19
edited November 24, 2011 12:10AM in SQL Storage Compress Previous Versions
Hi

We are having quite a serious issue whereby a single index file created by HyperBac is in a constant state of growth and is totally consuming any free space on the drive.
HyperBac is storing these files on the C drive of the machine as i assume this is the default location as part of the install.
Index file is in:
C:\Program Files (x86)\Red Gate\HyperBac\indexes
Other processes that require space on the C drive are now prevented from completeing there operations. the index file is presently at 125GB and is only stopped due to lack for free space on the drive.

Can anyone advise whether these index files can be removed and how they are being used?

Many Thanks
· Share on Twitter

Comments

  • goldmedalgoldmedal Posts: 19
    Just to add to this. I'm currently trying to attach an mdfx file of 41GB, I moved the index files onto a drive with what I believed to be sufficient space.

    It's now been "attaching" for just over an hour, the index2 file is rapidly growing and currently at 128GB in just over 40 minutes.

    The drive is getting close to full and I'll probably end up having to kill the Hyperbac service when it reaches 200GB.

    This means we now have a 41GB compressed DB that I've no way of getting back online.

    Is this a bug?
    · Share on Twitter
  • Eddie DEddie D Posts: 1,805 Rose Gold 5
    Thank you for your post.

    Can you please try out SQL Storage Compress V6 / HyperBac Components v5.4.0.27 released earlier today?

    Please download the latest HyperBac components V5.4.0.27 / SQL Storage Compress v6 using these links:

    64-bit machines

    32-bit machines

    There have been some major improvement to the stability of storage compress databases, which we believe will help you.

    Many Thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
    · Share on Twitter
  • twaintwain Posts: 2
    I think you should go for the SQL storage compress V6 which effectively will remove most of the issues that you are having. Getting the Hyperback components would also turn to be fruitful since both of them would greatly help in improving the stability of your storage compression databases.Has anyone tried using datanumen file storage's?. is it efficient ?
    “Read Today, Lead Tomorrow”
    · Share on Twitter
Sign In or Register to comment.