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@xxxxxxxxx> 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@xxxxxxxxx
<mailto:mark.brinsmead@xxxxxxxxx>> 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@xxxxxxxxx
<mailto:georgelza@xxxxxxxxx>> 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@xxxxxxxxx
<mailto:oracle.blog3@xxxxxxxxx>> 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!
