Re: DataGuard Bandwidth requirements
Date: Wed, 13 May 2015 10:12:25 -0400
Message-Id: <7D1AD2CA-2536-48A6-A8A0-B64EC0EA7608_at_gmail.com>
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 <mailto: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 <mailto: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 <mailto: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:12:25 CEST