Re: Scalable Performace - Inserts/Updates

In article <3A421198.6975D1D7_at_edcmail.cr.usgs.gov>,   Brian Peasland <peasland_at_edcmail.cr.usgs.gov> wrote:
> Thanks for the correction and admission! Different vendor terminology
> can be a killer sometimes!
>

Time to fire Nuno! (Just kidding, he 'fessed up! :-)

> You were thinking of redo log MEMBERS, not GROUPS (in Oracle-speak).
 You
> need at least two GROUPS, but each group can have only one MEMBER, or
> more.
>
> I'm still not convinced that going with one member for each group is
 the
> way to go. Personally, I like redundancy and would even go so far as
 to
> let Oracle multiplex the groups with multiple members at the same
 time
> letting hardware mirror the disk files. But then I'm not looking for
> 1000 commits/second. And I know that this has been an often debated
> topic in the DBA community.
>
> So I'll leave it at that!

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?"

An Oracle Corp contractor DBA using another hardware platform to the same SANS couldn't be convinced to do it, is the only reason I haven't. Hitachi's uptime guarantee on the SANS is better than the service agreements with the unix vendors...

>
> Thanks,
> Brian
>
> > And here I am blurting out without doing a swap out of all the
 other
> > database software I'm working with.
> >
> > My apologies Brian, you are of course quite CORRECT!
> >
> > That's what I get for working with so many other databases. Should
> > ignore them and concentrate in ORACLE all the time. I knew there
 was
> > a reason why I left the mainframe makers arena 15 years ago: they
> > blunt one's intelect...
> >
> > In ORACLE, the groups are always there. More than 2, preferably.
 What
> > you can get is more than one redo log file per group. In that case,
> > you're doing what is called redo "multiplexing". (Their term, not
> > mine...).
> >
> > I'll try and rephrase the original, now using the proper ORACLE
> > terminology:
> >
> > What you can't have if you want 1000 commits per second is more
 than
> > one redo log file (or member) per group. They will slow you down
 no
> > end. Use the hardware fail-safe features to ensure recoverability,
 not
> > the software.
> >
> > Once again, pardon the late night swap-out. It's groups in ORACLE,
> > darn it! Not files!
> >
> > <groan>
> >
> > Cheers
> > Nuno Souto
> > nsouto_at_bigpond.net.au.nospam
> > http://www.users.bigpond.net.au/the_Den/index.html
>
> --
> ========================================
> Brian Peasland
> Raytheons Systems at
> USGS EROS Data Center
> These opinions are my own and do not
> necessarily reflect the opinions of my
> company!
> ========================================
>

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/