Re: DataGuard Bandwidth requirements
Date: Wed, 13 May 2015 10:26:37 -0400
Message-ID: <CAAaXtLCjS4mTao_Gp86xY9AZUuOkHuaOnzg=HynkRKG-sP6N_A_at_mail.gmail.com>
Yes. This is a valid point. When you use ARCH replication, the traffic is going to be subject to "bursts".
You can probably ignore the "bursty" nature of the traffic to an extent (although the network engineers may or may not be able to), but if you do, you may need to expect replication lags around 2x the interval between logfile switches. (If it takes 20 minutes to fill a log, and 20 minutes to transfer it, your standby is likely to lag by at least 40 minutes.)
Usually, we cope with this by shortening the time interval between logfile switches, keeping it below half of the SLA for standby lag. I am sure there are other ways to cope with this, too, but this method is probably the cheapest (as it avoids over provisioning bandwidth).
Different people's needs will definitely vary though, so "bursts" in traffic should probably be considered.
Maybe in this case, it would be a good idea for the OP to sit down with his network engineers and work out the forecasts and requirements together. I bet the network engineers can probably list one or two factors we have not thought about yet. :-)
On Wed, May 13, 2015 at 10:12 AM, Kenny Payton <k3nnyp_at_gmail.com> wrote:
> Also keep in mind if you are capable of staying fairly current with your
> apply there is a pretty big difference between Real Time Apply with Standby
> Redo Logs and ARCH transport. I have underestimated the significance of
> this change, from the IO perspective, before and had to adapt to it after
> the fact. It’s much easier to plan for it at the start.
>
> Kenny
>
>
>
> On May 13, 2015, at 9:52 AM, George <georgelza_at_gmail.com> wrote:
>
> Hi Mark
>
> It is all well we do all this math, come up with complicated models.
>
> In the end the network guys want to know how much / throughput they need
> to cater for.
>
> If synchronous DG is needed, sure make sure you can cover the peak at any
> time, and make sure you have minimal latency.
>
> Things will never exactly work like a model, so a how much per hour, and
> specify it for a 24 hour period, covering the slow part of the month and
> also show the busy part will give networks normally more than enough to
> give you a very close starting point, it will always be just a starting
> point.
>
> G
>
> On Wed, May 13, 2015 at 3:48 PM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
> wrote:
>
>> I am afraid it can be much more complex than this. I'm not an expert on
>> this, but let me take a stab at it...
>>
>> Do you need to replicate synchronously? If so, latency is going to be a
>> critical consideration.
>>
>> How much lag can you tolerate? If you base estimates on "hourly" redo
>> rates, I can easily picture lags of an hour or two. If your estimate is
>> based on an "average" hourly rate, lags of many hours (during/following
>> peak periods) are not unlikely.
>>
>> Are your data volumes subject to seasonal fluctuations? If so, you will
>> want to size for your peak season.
>>
>> If you want to set up a standby with a reasonable expectation of not
>> (often) lagging by more than 5 minutes, then you need to identify the
>> amount of redo generated in your busiest 5-minute interval (or maybe 90th
>> percentile, if you want to save some money and can live with occasionally
>> missing your SLA) and size your network to support that.
>>
>> You also want to ensure that the bandwidth you specify is *guaranteed*
>> to be available to your replication traffic. It benefits you nothing to
>> size the bandwidth properly, and then have it all chewed up by people
>> watching funny cat videos on youtube.
>>
>> On Wed, May 13, 2015 at 9:32 AM, George <georgelza_at_gmail.com> wrote:
>>
>>> I work it out another way...
>>>
>>> Determine redo creation a hour, and then ask Networks to provide the
>>> required bandwidth to transfer that volume in a hour.
>>>
>>> You can use the redo log generation over 24 hours to draw a graph,
>>> showing how it goes up and down and give them the required rate per hour.
>>>
>>> G
>>>
>>> On Wed, May 13, 2015 at 3:29 PM, max scalf <oracle.blog3_at_gmail.com>
>>> wrote:
>>>
>>>> Hello list,
>>>>
>>>> we are in process of deploying a Data guard and i am looking to get a
>>>> bandwidth requirements. While googleing i came across the below formula
>>>> multiple times..my question is what exactly do the below numbers represents
>>>> 0.7, 8, 1000000 ?? i know we can get and redo rate bytes per sec from
>>>> v$sysmetric_history but confused on the numbers...
>>>>
>>>> *Required bandwidth = ((Redo rate bytes per sec. / 0.7) * 8) /
>>>> 1,000,000 = bandwidth in Mbps *
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> You have the obligation to inform one honestly of the risk, and as a
>>> person
>>> you are committed to educate yourself to the total risk in any activity!
>>>
>>> Once informed & totally aware of the risk,
>>> every fool has the right to kill or injure themselves as they see fit!
>>>
>>
>>
>
>
> --
> You have the obligation to inform one honestly of the risk, and as a person
> you are committed to educate yourself to the total risk in any activity!
>
> Once informed & totally aware of the risk,
> every fool has the right to kill or injure themselves as they see fit!
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 13 2015 - 16:26:37 CEST