February 5, 2009 at 1:48 am
Hi All,
We use the standard log shipping in SQL2K to replicate over a wide area network.
Although the mechanism works flawlessly 90% of the time, occasionally we have an issue with the size of transaction files to be shipped. If we could just compress the files before shipping and uncompress before restore it would be ideal.
We have 10 databases scattered around europe and the saving on bandwidth would be substantial if we could just employ compression.
As far as I know, SQLMaint in 2K does not support compression, so we started exploring other possibilities. One idea is to insert a second step on the source database to compress the file after it has been saved on disk. The question is how does one get hold of the filename generated in the backup step?
The same question applies to the destination step. We need to insert a step to uncompress the file just copied, but then again, what's the file name?
If this approach doesn't sound right, then by all means, we are open to suggestions.
Another solution perhaps would be to use "Folder Monitoring" software on both the sending and receiving sides. I just don't like the idea of having independent tasks running in parallel to to the job.
June 4, 2009 at 2:53 pm
Something like Quest LiteSpeed can do the compression for you and is integrated into the job steps.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply