we are using the quick I/O and as well as cached quik I/O also. I had configured this a quite long time ago I have forgotten about temp files issues which u people are talking about. But We did have issues by just using quick I/O cause it acts like a cooked raw file system and hence is write intensive but not read intensive this screws up ur database or u will see lot of sequential reads due to this which at one time brought our database to its knees, This caching can be done online also even when the database is running.Once we enabled cached we were able to breadth. u can cache each file itself or the whole file system. the monitoring io can been done thro qiostat which will tell u about the i/o being performed. I can say if u are implementing this on oltp better use cached i/o or one more way where i was reading some where was to increase ur sga to a good amount( which i would not recommend). i have seen the performance improvement to around 30 to 40%. But after this i started seeing file open event very heavily i even asked on this issue to steve adams once
-----Original Message----- Sent: Friday, May 31, 2002 4:28 PM To: Multiple recipients of list ORACLE-L Kathy, > We are using Veritas Quick IO on our Solaris Box 6500 with > Oracle Apps 11.5.6 on 8.1.7.2 database. > > Right now we do not have the temp files converted to quick io > and wonder if we should. The guy who installed Quick IO > didn't seen to think we could but he was a pretty junior person. In addition to the many execllent and right answers that have been given, make sure that a DBBS (DataBase Baby Sitter) doesn't inadvertly extend a Database file via RESIZE or (horrors!) enable AUTOEXTEND on any QIO based datafile! You will have to use the qiomkfile with the -e (extend by the delta) or the -r (resize to this value) options to extend/resize a datafile prior to this RESIZE action. Effectively, AUTOEXTEND cannot be used :( A question to the others using QIO: * Has anyone measured the performance improvement brought about by using QIO for Oracle? (I have already read the Oracle report that compares QIO and Raw: The report concluded that they are both the same as far as perf goes. I am interested in plain vs qio, but don't want to start another raw vs plain war :) * I assume that DISK_ASYNC_IO was allowed to default to TRUE (on Solaris). In this case, I assume that you would track the wait times for the 'direct path read' and 'direct path write'? * I assume you have put in place procedures to make sure that a file is NOT resized via ALTER DATABASE without a qio resize. The question is: Do you have any way of checking that there has NOT been such a resize? The manual suggests that you pre-allocate the filesize and take it up (via DATABASE/RESIZE) as it grows, but thats as good (bad!) as actually resizing it right in the beginning! * Is anyone using 'Cached Quick I/O'? Any gotchas? One question leading to another here, but I hope we can all learn from this :) John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 The manuals for Oracle are here: http://tahiti.oracle.com The manual for Life is here: http://www.gospelcom.net ** The opinions and statements above are entirely my own and not those of my employer or clients ** -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Kanagaraj 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Arun Chakrapani 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).
