Skip to main content
Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

slemburg

6 Posts

660

March 13th, 2006 07:00

Replicating large SQL database

We are currently trying to replicate a large database across a T-1 connection from our main office to our disaster recovery site. Our MDF file is about 66 gigs but what is very frustrating is that on a daily basis, our log file (LDF) can grow so much that our replication falls way behind. For example, we shrunk our LDF file down to 760 mb and in one day it grows to 13 gigs. There is no way we can ever keep up with the replication.

Does anyone else have these issues and where would we start to fix this problem? Before we ran our first shrink on the LDF, it was about 88 gigs in size. What do you guys/gals recommend we do at this point?

Our T-1 is dedicated only for Replistor. There is no other traffic over this line. Thanks.

tribicic

157 Posts

March 13th, 2006 08:00

If I understand correctly the specification is already in sync and the mirroring is taking place?
If so, there are situations where the replication speed simply cannot keep up with the amount of data that needs to be sent over to the remote site, and there is really nothing you can do except increasing the available bandwidth. :( Have you monitored the Performance Monitor to see what kind of throughput you get and what is the rate of the kernel log filling up? Does database get less busy overnight so Replistor can catch up, or is it so busy that the data that needs to be sent over constantly grows?

slemburg

6 Posts

March 13th, 2006 09:00

Yes, our specification is in sync and we get it to a replicated status and everything looks for for a little while. Then, we will come in to work in the morning and we'll have as many as 80000 OC$ files that are in the data directory folder. It seems that our DB people have maintenance jobs that run on the databases once a week and then they run the shrink db job nightly. We have over 80000 entries to the database on Sunday morning that caused us to get this far behind.

I would imagine that what you are telling me about the bandwidth is our issue. Why we have so many transactions I have no idea. The T-1 line is definitely not cutting it. This is what I am afraid of. Thanks for your reply.

slemburg

6 Posts

March 13th, 2006 10:00

I ran performance monitor on the transfer rate and it seems we are getting an average transfer rate of 166 Kb/s. Is that the speed we should be getting without any other data going across the line?

tribicic

157 Posts

March 14th, 2006 00:00

Sounds about right.
All is not lost though - if the cache overflows only during these regulary scheduled maintenance jobs, you can schedule Replistor to stop mirroring before this operation occurs, and when it gets finished you restart the sync in the incremental mode. That way all the action that took place during the shrink DB operation will not be sent to the remote side, and the resync should not be that long.
You may also create a seperate specification that will cover just these "problem" files. There are a lot of possibilities.

dramjass

151 Posts

June 9th, 2006 08:00

If you are concerned about the DR of your SQL box, setup a local RepliStor Target in your local LAN to send the SQL data to. Then from the 2nd LAN Target, send that data to your DR location across the T1. If you see that your source cannot keep up with the replication in your local LAN Target node, you may be trying o replicate too much data for the application to handle.

IMPORTANT:
Remember a manual Sync operation can handle several connection at one time (up to 16). However, when the Mirroring function takes over after the Sync, this drops to one connection.

Was this post helpful?

View All

No Events found!

Top