Cached Quick IO gives you pre-fetch capabilities similar to EMC devices, of course, not nearly as good, but it certainly does help on reads.
 
If you have Veritas license, Quick IO is great.  But raw is certainly still the most effective.  But Veritas gives you 95% of the advantages of Raw and none of the disadvantages.
"Walking on water and developing software from a specification are easy if both are frozen."

Christopher R. Spence
Oracle DBA
Fuelspot

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 08, 2001 7:20 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: Veritas Quick I/0 and Oracle/ Asynchronous I/O


Ian
        Quick IO does bypass the unix buffer cache completely, thereby avoiding few problems such as double buffering, double copying, vnode locks associated with the ufs,xfs or veritas non-quick I/O files. Oracle can use Quick I/O capability and asynchrous I/O on these Quick I/O files are also supported.
        As per the veritas benchmarks Quick I/O is very close in performance with raw volumes. Raw volumes are marginally better than quick I/O as per veritas.
        IMHO, I would vote for raw, even though Quick I/O is a viable option too.
 Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA
i2 technologies   www.i2.com



"MacGregor, Ian A." <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]

06/08/01 02:30 PM
Please respond to ORACLE-L

       
        To:        Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc:        
        Subject:        Veritas Quick I/0 and Oracle/ Asycnchronous I/O



Will Oracle use the Quick I/O capability of Veritas on database writes; that is, will it bypass any file system buffer cache and write directly to disk?   Is the  implementation of asynchronous I/O  imnproved in Solaris 8;  does one have to use raw disks or does it now work properly with UFS or Veritas?

I need to configure a machine to provide for the maximum number of transactions per second.  Our Accelerator Controls folks are at it again, testing how much data they can push into Oracle.  They have backed off the plan of having 6000 Beam Position  Monitors sampling at 120 Hz write into the database; although., 720,000 transactions per seconds might be fun to try.  But they do want to see what they can do.  Obviously, the programs which collect the data from BPM's and other sensors needs to do some buffering.  But when they dump to the database I need the writes to happen as quickly as possible.

The current method of handloing this via ring buffers and doubly-linked lists.  They want to look at replacing the lists with an Oracle database.   Our initial tests will be done using a 4 processor ES-450.

Ian MacGregor
Stanford Linear Accelerator Center
[EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: MacGregor, Ian A.
 INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).


Reply via email to