Re: database network performance requirements
Date: Sat, 6 Feb 2010 09:31:31 -0800 (PST)
Message-ID: <01b97da5-0d78-4230-8fea-c165b455a8d4_at_u41g2000yqe.googlegroups.com>
On Feb 4, 2:47 pm, Tim X <t..._at_nospam.dev.null> wrote:
> joel garry <joel-ga..._at_home.com> writes:
> > On Feb 3, 2:28 pm, vsevolod afanassiev <vsevolod.afanass..._at_gmail.com>
> > wrote:
> >> Requirements vary from application to application. Well-written
> >> application cache static data.
> >> There are several network-related statistics, this is from Statspack
> >> report for 9.2.0.8 database:
>
> >> Statistic Total per Second
> >> per Trans
> >> --------------------------------- ------------------ --------------
> >> ------------
> >> SQL*Net roundtrips to/from client 15,714,040
> >> 436.5 22.2
> >> bytes received via SQL*Net from c 5,056,985,913
> >> 140,475.7 7,144.4
> >> bytes sent via SQL*Net to client 3,173,523,378
> >> 88,155.9 4,483.5
>
> > A single application is the wrong level to determine this. The dba
> > presumably is responsible for allocuting all Oracle related network
> > usage. So, at a minimum, it would need to be statistics as above for
> > all applications current and contemplated, projected forward, plus the
> > likelihood of disaster or distributed usage. The latter means
> > archiving transport, and rman usage over the net (among other
> > possibilities). For example, to build a standby database you have to
> > figure how much data there is uncompressed (in case there happens to
> > be some bug that disallows the compression option), and how fast you
> > will need to rebuild such a beast from scratch should the archive gap
> > become untenable. If management's view is "no, we will never lose our
> > computer room due to the upstairs crapper overflowing," get an
> > experienced consultant in there.
>
> This is very critical. Estimating growth is almost always udner
> estimated. come up with a figure and then multiply by PI and you may be
> getting closer to what reality is. I've frequently seen analysis that
> has focused on the app performance and completely overlooked network
> requirements for backups. If you expect to have, lets say, one full
> backup per week and incremental backups each day, then you need to be
> able to perform them within at least one 24 hour period - this means all
> your databases AND other critical data, such as file servers, mail
<snip>
> hehehe! Tell them they need not just video conferencing, but the full
> video grid stuff (aka VC inspired by Star Trek's holodeck).
>
> --
> tcross (at) rapttech dot com dot au- Hide quoted text -
>
> - Show quoted text -
Thanks for the response. Agreed, a latency figure for example is dependant on how large of a pipe you've purchased specific to the issue of getting your backup completed in the time you have allotted. The larger the latency (typically distance between source and backup), the larger the pipe you'll need to compensate. Loss plays a factor here too, since TCP can provide recovery for a lossy connection; but only so far before throughput is significantly degraded.
Can you comment on SYNC backup (realtime)? Is there a particular latency and loss threshold you wouldn't want to exceed; since these directly impact the application response for the client?
I've found a variety of marketing names the db vendors use for SYNC and ASYNC backups. I'm curious if there are generic names DBA's use for these functions? I was thinking 'hot standby' for SYNC and perhaps 'WAN replication' for ASYNC.
Thanks! Received on Sat Feb 06 2010 - 11:31:31 CST