Red Gate forums: SQL Storage Compress 5

RE: Index file consuming drive space

twain — Thu, 24 Nov 2011 05:10:11 GMT

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 ?

RE: Index file consuming drive space

eddie davis — Thu, 04 Aug 2011 18:32:37 GMT

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

RE: Largest successful restore from .SQB ?? (4TB failed)

epetro — Wed, 03 Aug 2011 12:51:04 GMT

For the latest restore attempt, I adjusted some file locations in the 'MOVE TO' segment of the restore. Combined with the latest server components for SQL Backup, this was a success !

Now on to load testing.

(Note: I only found that I missed the server components because support requested a log file. When I previewed it, I immediately saw the 6.3 )

RE: Index file consuming drive space

goldmedal — Wed, 03 Aug 2011 09:25:28 GMT

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?

Index file consuming drive space

goldmedal — Tue, 02 Aug 2011 07:19:12 GMT

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

RE: SQL DBs with HyperBac files suspect after server restart

javen — Mon, 01 Aug 2011 22:23:25 GMT

There was an issue relating to startup sequence, whereby SQL would attempt to recover the SSC or SVR databases before the HyperBac service was fully loaded, this would result in the databases being flagged as suspect, when in fact they were not. This has been resolved in the latest build which is due for release within days. However to workaround this, and to greatly reduce recovery times, if you have a planned shutdown, take all SSC databases offline manually before the shutdown, then bring them back online once both the SQL and HyperBac services are fully up and running.

RE: Largest successful restore from .SQB ?? (4TB failed)

epetro — Mon, 01 Aug 2011 15:23:35 GMT

The log (which is located)

Code:

C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\(local)

Shows that the backup was performed as v.6.3.0.48.

I missed updating the server components manually.
I will now try creating another backup file.

My backup takes about 6 hours

RE: SQL DBs with HyperBac files suspect after server restart

epetro — Mon, 01 Aug 2011 14:06:50 GMT

This issue appears to still exist. We recently began testing this product on a server with 6 databases. I converted them all from native SQL to SSC. We made the effort to stop SQL services, set to manual, and then stop HyperBac prior to the reboot. We then waited about 5 min after the server was up and we had a remote connection before starting SQL. This should be more than ample delay for a simple service(HyperBac) to be ready.

Is this issue still being addressed?
Am I the only 1 seeing IN RECOVERY for at least 45 min after restart?
What is the current version others are successful with?

RE: Largest successful restore from .SQB ?? (4TB failed)

epetro — Mon, 01 Aug 2011 13:11:22 GMT

I forwarded the requested files short of the restore log. The request assumed I was utilizing the wizard(and the window was still open). I know they use a hidden database, hopefully this file is local.

RE: Largest successful restore from .SQB ?? (4TB failed)

eddie davis — Mon, 01 Aug 2011 10:58:42 GMT

Thank you for your posts into the forum and sorry that you are encountering a problem.

A support call has been created for this problem, the call reference number is F0050646.

Can you please send to support@red-gate.com the following files:

You will find the HyperBac service.log and if generated error log files in the \Red Gate\HyperBac\logs folder.

You will find the HyperBac status.dat, hyperbac.conf and openstatus.dat files in the \Red Gate\HyperBac\bin folder.

Please include the Call reference number above in the subject field of your e-mail.

Many Thanks
Eddie

RE: Largest successful restore from .SQB ?? (4TB failed)

epetro — Fri, 29 Jul 2011 19:26:06 GMT

After upgrading SQL Backup, the only change is that the error 5171 now references a different file.

RE: Largest successful restore from .SQB ?? (4TB failed)

epetro — Thu, 28 Jul 2011 19:54:08 GMT

It looks like this server is still on 6.3.0.48. The latest available version of SQL Backup is 6.5.1.
I'm going to update and see if that is any assistance. My other servers are on 6.4.0.56

Largest successful restore from .SQB ?? (4TB failed)

epetro — Wed, 27 Jul 2011 18:38:05 GMT

I am looking for data regarding largest successful restore from a .SQB to compressed files (.mdfx, .ndfx, .ldfx)

We are wanting to utilize this tool on our reporting warehouse, but the 4TB database, when backed up to a 589GB backup using compression=1, will not restore properly. I was able to restore to a virtual database using similar technology.

I have ran a full DBCC checkDB against the source.
I am unable to run a normal restore of the database due to disk space.
I was able to complete a restore VERIFYONLY.

At this point I do not suspect the backup file of corruption nor the source database.

Here is the code I run (which includes 22 filegroups) and the error received.
EXECUTE master..sqlbackup '-SQL "RESTORE DATABASE [Reporting01_Compress]
FROM DISK = ''G:\DatabaseBAK\REPORTING01\FULL_(local)_REPORTING01_20110716_060000.sqb''
WITH RECOVERY,
MOVE ''REPORTING01'' TO ''K:\MDF\Reporting01_Compress.MDFX'',
MOVE ''REPORTING01_Log'' TO ''E:\LDF\Reporting01_Compress.LDFX'',
MOVE ''REPORTING01_PKEBC'' TO ''I:\IDF\Reporting01_Compress_PKEBC.NDFX'',
MOVE ''REPORTING01_MrgChargeActive'' TO ''E:\NDF\Reporting01_Compress_MrgChargeActive.NDFX'',
MOVE ''REPORTING01_ChargeActive'' TO ''I:\NDF\Reporting01_Compress_ChargeActive.NDFX'',
MOVE ''REPORTING01_LogTapeCharge_Indexes'' TO ''K:\IDF\Reporting01_Compress_LogTapeCharge_Indexes.NDFX'',
MOVE ''REPORTING01_Transactions'' TO ''J:\NDF\Reporting01_Compress_Transactions.NDFX'',
MOVE ''REPORTING01_TapeTempDemo'' TO ''J:\NDF\Reporting01_Compress_TapeTempDemo.NDFX'',
MOVE ''REPORTING01_ChargeAudit'' TO ''J:\NDF\Reporting01_Compress_ChargeAudit.NDFX'',
MOVE ''REPORTING01_RemitPostBatches'' TO ''J:\NDF\Reporting01_Compress_RemitPostBatches.NDFX'',
MOVE ''REPORTING01_LogChargeActive'' TO ''J:\NDF\Reporting01_Compress_LogChargeActive.NDFX'',
MOVE ''REPORTING01_LogInsuranceProfile'' TO ''J:\NDF\Reporting01_Compress_LogInsuranceProfile.NDFX'',
MOVE ''REPORTING01_LogWorkfileUserActivity'' TO ''K:\NDF\Reporting01_Compress_LogWorkfileUserActivity.NDFX'',
MOVE ''REPORTING01_PKDS'' TO ''J:\IDF\Reporting01_Compress_PKDS.NDFX'',
MOVE ''REPORTING01_LogTapeCharge'' TO ''I:\NDF\Reporting01_Compress_LogTapeCharge.NDFX'',
MOVE ''REPORTING01_ClaimLog'' TO ''I:\NDF\Reporting01_Compress_ClaimLog.NDFX'',
MOVE ''REPORTING01_Indexes01'' TO ''K:\IDF\Reporting01_Compress_Indexes01.NDFX'',
MOVE ''REPORTING01_ChargeAudit_Indexes'' TO ''K:\IDF\Reporting01_Compress_ChargeAudit_Indexes.NDFX'',
MOVE ''REPORTING01_LogChargeActive_Indexes'' TO ''K:\IDF\Reporting01_Compress_LogChargeActive_Indexes.NDFX'',
MOVE ''REPORTING01_ChargeActive_Indexes'' TO ''J:\IDF\Reporting01_Compress_ChargeActive_Indexes03.NDFX'',
MOVE ''REPORTING01_Transactions_Indexes'' TO ''J:\IDF\Reporting01_Compress_Transactions_Indexes.NDFX'',
MOVE ''REPORTING01_MrgTables'' TO ''E:\NDF\Reporting01_Compress_MrgTables.NDFX''"'

ERROR
Msg 5171, Level 16, State 2, Line 1
J:\NDF\Reporting01_Compress_RemitPostBatches.NDFX is not a primary database file.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

RE: SQL DBs with HyperBac files suspect after server restart

rthsw — Thu, 07 Jul 2011 07:38:00 GMT

Hi, we are hosting a Archive-server with over 40 Databases (one Copy of the productive System per Day of the Month). After everey restart we loose 1-3 Databases.

NEVER Use Storage Compress for productive Systems!!!
But after we buy this tool, we would like to use it, WITHOUT pulling out hairs.

RE: Compressed vs. uncompressed sizes

cnilsson — Fri, 17 Jun 2011 08:20:18 GMT

You could always use xp_cmdshell and DIR from within SQL to view the sizes of the files on disk.