Re: Scalable Performace - Inserts/Updates

In article <3a448748.1187547_at_news-server>,   nsouto_at_nsw.bigpond.net.au.nospam (Nuno Souto) wrote:
> On Fri, 22 Dec 2000 19:41:27 GMT, Joel Garry <jgarry_at_my-deja.com>
> wrote:
>
> >
> >Time to fire Nuno! (Just kidding, he 'fessed up! :-)
> >
>
> thanks, Joel! Got fired long ago.... ;-D

Never actually got fired myself. For various reasons (like their perceived liability) they always couched it in other verbiage... :-)

>
> >I won't. I've got a situation which works ok now, but eventually
 will
> >scale. I have the redo logs on the local disks. However, the data
> >files are on a humungo SANS. The thing that is strange - the SANS
 is
> >over fibre, and is quite a bit faster than the local disks. So
 should
> >I move them there? My head says yes, my gut says "huh? Network
> >faster than local disk?"
> >
>
> Not surprised. Those fibre connections are wickedly fast. Another
> thing you'll find is the SANS probably has an absolutely ginormous
> battery-backed cache, making for incredible throughput.

Yep. Of course, I've seen the results of when people flip levers on those thingees... :-O

>
> Dunno what your uptime constraints are, but on face value I'd go for
> the SANS. Here is what I'd do:

The users wouldn't ever want to here me say it, but currently uptime is not a real big deal - the package is migrated from old COBOL stuff, jammed uncomfortably into Oracle, batch jobs and all. I expect to get to 6/24 in a few months.

>
> - create "devices" for each redo log file.
> - mount them as file systems, one for each redo log file.
>
> This will give you max cache access for the redo logs, backed by
> battery. Only thing faster than that would be a file system mounted
 on
> local memory! And I've got a feeling you wouldn't be getting too
 many
> failures in that kind of hardware. Those things are more reliable
> than your local disks...

This is a very interesting concept. I'm running it past my sysadmindemigods to see what they say. I'm expecting an answer of the type "that is ridiculous since there's such-and-such limits on volume group segmentation" while another says "no problem" or some such.

>
> I think the days of native disks are gone. Most of the optimisations
> and features for that sort of environment nowadays cannot be
> justified. These boxes are totally dedicated to manage the disks and
> they do a darn good job of it. Personally, I like the idea of
> isolating disk-spread and optimisation from the design of the
> database. Most of my clients run EMCs. I just recommend basic
> tablespace spreading (by size). The disk-level optimization I now do
> at the EMC box and file system layer and leave the database alone.

You perhaps saw my post a few years ago about how Veritas got confused by a bogus controller. It's always something...

> Most of the time it's third-party software anyway, with "locked-in"
> tablespace names...

Get this: the installation of the package gives you three choices (for hundreds of tables, some small and a few very large): 1. Everything in one tablespace. 2. All tables in one tablespace and all indexes in another. 3. Each table/index in its own tablespace. All in _csh_ scripts too! (At least I was able to make something reasonable with editing)

>
> Anyways, 'nuff ranting. Merry Christmas and a Happy millenium to
> youse all. Logging off for the Christmas break...
>

Hope ya had a good one!

> Cheers
> Nuno Souto
> nsouto_at_bigpond.net.au.nospam
> http://www.users.bigpond.net.au/the_Den/index.html
>

jg

--
These opinions mine
mailto:joel-garry_at_nospam.home.com
Remove nospam to mail
http://ourworld.compuserve.com/homepages/joel_garry


Sent via Deja.com
http://www.deja.com/