Re: database network performance requirements

From: joel garry <joel-garry_at_home.com>
Date: Thu, 4 Feb 2010 09:07:41 -0800 (PST)
Message-ID: <2d02b9a9-6804-4f23-ae7a-940e9e6e9230_at_t31g2000prh.googlegroups.com>



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.

Another way to get around penny-pinching network resources is to get a video conferencing project, that means big pipes for everyone.

jg

--
_at_home.com is bogus.
That darn internet! http://www.signonsandiego.com/news/2010/feb/04/man-pleads-guilty-in-la-to-posting-film-online/
Received on Thu Feb 04 2010 - 11:07:41 CST

Original text of this message