September 4, 2009 at 4:40 am
Hi All, need some suggestions...
Scenario:
For our DR site, we are using Double Take for Replication between sites.
File replication.
Now some weeks ago, with a DR Test replication some how was interrupted, and he log on Live was backed.
The link was quite slow,so the backlog didn't complete in time fr testing.
Resulted in out of Sync DB & Log. = Fail.
Now the question was asked, why we didn't use shipping.
My answer was, if the link was of, neither replication, nor shipping would succeed.
Our solution to this unforseen issue, daily backup to portable drive as well, but this is also a issue to
copy/restore a 120gb bak file.
Any one with ideas on this?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
September 4, 2009 at 4:51 am
Henrico Bekker (9/4/2009)
Hi All, need some suggestions...Scenario:
For our DR site, we are using Double Take for Replication between sites.
File replication.
Now some weeks ago, with a DR Test replication some how was interrupted, and he log on Live was backed.
The link was quite slow,so the backlog didn't complete in time fr testing.
Resulted in out of Sync DB & Log. = Fail.
Now the question was asked, why we didn't use shipping.
My answer was, if the link was of, neither replication, nor shipping would succeed.
Our solution to this unforseen issue, daily backup to portable drive as well, but this is also a issue to
copy/restore a 120gb bak file.
Any one with ideas on this?
What type of replication are you using? You mentioned file replication? is it something related to moving backup files between primary and secondary OR moving the data and the log file OR are you using actual replication (snapshot/transactional/merge)?
Are you also using secondary for reporting purposes or is it only for DR purpose?
September 4, 2009 at 4:59 am
no its basically just mdf and ldf replication.
the app doing the replication couldn't tell the difference between a mdf or a mp3 😛
it's replication is amost real time, but takes a while to dump on the destination server as a result of a slow wlan link.
no SSRS, just the engine.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
September 4, 2009 at 5:06 am
Henrico Bekker (9/4/2009)
no its basically just mdf and ldf replication.the app doing the replication couldn't tell the difference between a mdf or a mp3 😛
it's replication is amost real time, but takes a while to dump on the destination server as a result of a slow wlan link.
no SSRS, just the engine.
Why copy paste the entire mdf/ldf after detaching it every time? it would be a time consuming process, more so, since u said the network bandwidth is low.
You can setup log shipping where you'll have to restore the entire database only once and then only log files on an ongoing basis. The size of the log file would be relatively much smaller than mdf/ldf combined together. I'm assuming your database is in full recovery mode.
http://msdn.microsoft.com/en-us/library/ms187103(SQL.90).aspx This site should give you an overview of log shipping. It's fairly simple to implement.
September 4, 2009 at 5:13 am
The problem at hand is: the DT replication software (and this has been confirmed with the vendor)
has to replicate the whole file. We tried differential replication, but it stars the whole MDF and LDF from 0 bytes.
Like I said, it doesnt recognize application type files, only files.
Setting up the log shipping has been declined, as we pay a good sum of money for the replication software, which according to mangement, must work... I'm sure you get the idea....
Well, some feedback, restoring our 120 odd gb database and log from a 5400rpm external, took about 40minutes....
Dont judge our methods.. 🙂 they work in sme odd weird and wicked way...but they always do...
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This thing is addressing problems that dont exist. Its solution-ism at its worst. We are dumbing down machines that are inherently superior. - Gilfoyle
September 4, 2009 at 5:21 am
If the management doesn't listen to technical voices, nothing much can be done. You got to continue with the DT software... It looks like copying the entire file system/or select files... It's not designed to be used especially for databases...
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply