Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Fav. Urban Legend...Mem vs Disk

Re: Fav. Urban Legend...Mem vs Disk

From: Anjo Kolk <anjo_at_oraperf.com>
Date: Wed, 20 Mar 2002 06:48:37 -0800
Message-ID: <F001.0042E717.20020320064837@fatcity.com>


Yapp, feel the new tuning force ;-)

DENNIS WILLIAMS wrote:

> Connor - Cary Millsap presented the results of 10 trace files in a Hotsos
> seminar I attended. The ratio ranged from a high of 108.57 down to a low of
> 0.79. The point is that the ratio is nowhere near the oft-quoted 10,000.
> This means that logical I/Os are not insignificant. Even if physical I/O
> were eliminated (all blocks cached, 100% cache hit ratio), response time
> would not drop to zero. This is why the emphasis in tuning is shifting from
> simple ratios to examining wait times. If the most significant wait time is
> physical I/O, then changing that will improve overall performance. But if
> the most significant wait time lies in another area, then you may make
> significant improvements in physical I/O and still not improve overall
> performance. I certainly wouldn't claim to be an Oracle tuning expert, but I
> believe that the new ideas on tuning that are emerging provide a significant
> step forward in making Oracle tuning more of a logical process than a
> collection of rules of thumb.
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
> -----Original Message-----
> Sent: Wednesday, March 20, 2002 3:49 AM
> To: Multiple recipients of list ORACLE-L
>
> Some rudimentary testing on a laptop here (500Mhz,
> 512M RAM, typical single disk)
>
> a) visiting a single block via 4,000,000 logical IO's
> got me approx 35000 gets/sec
>
> b) repeated full table scans similar system got me
> approx 350 phys reads/sec
>
> After this extensive, thorough and exhaustive
> exercise, I can definitely say that memory access
> versus disk access (as it pertains to Oracle) is 100
> times faster on this machine in single user mode
>
> I think we can generalise this to be the rule for all
> servers under all conditions :-)
>
> Connor
>
> --- "Freeman, Robert " <Robert_Freeman_at_csx.com>
> wrote: > I've heard the disk vs. memory arguments
> before, but
> > never have seen
> > quantifiable data either way... if anyone has any,
> > I'd love to see it.
> >
> > RF
> >
> > Robert G. Freeman - Oracle8i OCP
> > Oracle DBA Technical Lead
> > CSX Midtier Database Administration
> >
> > The Cigarette Smoking Man: Anyone who can appease a
> > man's conscience can
> > take his freedom away from him.
> >
> >
> >
> > -----Original Message-----
> > Sent: Monday, March 18, 2002 5:54 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Robert - So THAT is the title of your next book. I'm
> > primed to buy it
> > already.
> > I just recalled a legend, maybe. "Disk is 10,000
> > times slower than memory,
> > so memory access times are infinitesimal compared to
> > disk access". Cary
> > Millsap covers this in his Hotsos Clinic. He has run
> > tests that prove "ain't
> > so". The point is that you can't just use ratios to
> > tune Oracle, but need to
> > look at wait times.
> > Dennis Williams
> > DBA
> > Lifetouch, Inc.
> > dwilliams_at_lifetouch.com
> >
> >
> > -----Original Message-----
> > Sent: Monday, March 18, 2002 1:04 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > So, does the CoO (Church of Oracle) have an
> > infallibility doctrine then???
> >
> > ... From the Book of Oracle, chapter 5 ...
> >
> > ...and the DBA did look upon his database, and he
> > saw it was good.
> > His tablespace datafiles being distributed tither
> > and fro, spread amongst
> > the
> > platters of his disks. And he did complete that
> > which was called
> > documentation,
> > and then he rested from his labors, and drank
> > Mountain Dew Code Red...
> >
> >
> > :-)
> >
> > Robert G. Freeman - Oracle8i OCP
> > Oracle DBA Technical Lead
> > CSX Midtier Database Administration
> >
> > The Cigarette Smoking Man: Anyone who can appease a
> > man's conscience can
> > take his freedom away from him.
> >
> >
> >
> > -----Original Message-----
> > Sent: Monday, March 18, 2002 12:25 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> >
> > Hey, you're an author!
> >
> > I expect perfection, grace and infallibility. ;)
> >
> > Jared
> >
> > On Monday 18 March 2002 07:33, Freeman, Robert
> > wrote:
> > > And hey, it was Sunday morning at 0700
> > something... what do you
> > > expect from me anyways??? :-)))))))
> > >
> > > RF
> > >
> > > Robert G. Freeman - Oracle8i OCP
> > > Oracle DBA Technical Lead
> > > CSX Midtier Database Administration
> > >
> > > The Cigarette Smoking Man: Anyone who can appease
> > a man's conscience can
> > > take his freedom away from him.
> > >
> > >
> > >
> > > -----Original Message-----
> > > Sent: Sunday, March 17, 2002 6:43 PM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > > On Sunday 17 March 2002 07:53, Freeman, Robert
> > wrote:
> > > > 1. You do not open the database to users until
> > AFTER you do a backup
> > (hot
> > > > or cold, dosen't mater) at point t2.
> > >
> > > Well, yeah, that was the point. It doesn't have
> > to be a cold backup, but
> > > since you can't do any work, it may as well be a
> > cold backup.
> > >
> > > Jared
> > >
> > > > 2. There is a method of recovering a database
> > (8i +) after RESETLOGS has
> > > > been
> > > > issued with archived redo logs. I discussed it
> > in my DBA World Tour
> > > > backup and
> > > > recovery presentation. To do this, you MUST have
> > the control file for
> > the
> > > > database from BEFORE the resetlogs operation,
> > and backup of the control
> > > > file from AFTER the same operation. I've done
> > this about 3 times in
> > >
> > > testing
> > >
> > > > and it works fine but it very very picky about
> > the control file images.
> > > >
> > > > RF
> > > >
> > > > Robert G. Freeman - Oracle8i OCP
> > > > Oracle DBA Technical Lead
> > > > CSX Midtier Database Administration
> > > >
> > > > The Cigarette Smoking Man: Anyone who can
> > appease a man's conscience can
> > > > take his freedom away from him.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > Sent: Friday, March 15, 2002 7:28 PM
> > > > To: Multiple recipients of list ORACLE-L
> > > >
> > > >
> > > > Hi Jared,
> > > >
> > > > > > * You *have* to take a COLD backup of the
> > database after using
> > > > >
> > > > > resetlogs.
> > > > >
> > > > > > (Not required - a Hot backup and archive
> > logs is adequate. All hot
> > > > >
> > > > > backups /
> > > > >
> > > > > > archive logs prior to that are invalid,
> > though...)
> > > > >
> > > > > Consider the following:
> > > > >
> > > > > Time:
> > > > >
> > > > > t0: database restored
> > > > > t1: database opened with RESETLOGS
> > > > > t2: hot backup started ( database in archive
> > log mode )
> > > > > t3: users input very important transactions
> > > > > t4: database crashes, and must be restored
> > > > >
> > > > > How will you recover the transactions from
> > time t3?
> > > >
> > > > As long as the online redologs are available,
> > this should be no problem.
> > > > I have successfully recovered databases where a
> > log switch did not occur
> > > > and recovery had to use an online redo log. (I
> > am assuming that the lost
> > > > datafiles will be restored from this hot backup
> > fresh off the tapes)
> > > >
> > > > On the other hand, if the online redolog is
> > hosed you have lost the
> > > > transactions anyway, _regardless_ of the fact
> > that a Cold backup was
> > >
> >
> === message truncated ===
>
> =====
> Connor McDonald
> http://www.oracledba.co.uk (mirrored at
> http://www.oradba.freeserve.co.uk)
>
> "Some days you're the pigeon, some days you're the statue"
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: =?iso-8859-1?q?Connor=20McDonald?=
> INET: hamcdc_at_yahoo.co.uk
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Anjo Kolk
  INET: anjo_at_oraperf.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Mar 20 2002 - 08:48:37 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US