it's Quick IO! google for qio and ODM.. ODM replaced qio. AFAIK, you don't need qui for archive logs, but for datafiles. -a
_____ From: Craig Simpson [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 2:06 PM To: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] vxstat data Questions Does anyone know what the “qio” is in my mount command feedback? /oradata/archive2 on /dev/vx/dsk/oraarchdg/oraarchvol03 read/write/setuid/log/largefiles/qio/cluster/ioerror=disable/crw/dev=44c afca on Sun Mar 30 02:12:14 2008 I don’t see any issues as far as my filesystems are mounted that would slow things down for Oracle. But not sure what the qio is. Thanks! Craig -- Craig Simpson Visto Corporation Operations Team [EMAIL PROTECTED] “In the circle the beginning and the end are common” ~ Heraclitis (540-480BC) _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien DAUBIGNE Sent: Tuesday, April 01, 2008 7:57 AM Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] vxstat data Questions vxstat displays statistics collected by VxVM ; VxVM doesn't "see" filesystem management Application Layer <===== Oracle statistics Filesystem Layer <====== VMM statistics (vmstat) Volume manager Layer <===== VxVM statistics (vxstat) Device Layer <===== OS statistics (sar, iostat) vmstat will display some filesystem management statistics, but you won't have so such things like "filesystem service times". Usually, file cache contention will generate high %SYS cpu because cache management work is done in kernel space. In that case, you can notice a big difference between Oracle service time and VxVM service time, and it can be helpfull to mount filesystems with Direct I/O enabled to eliminate cache management. Craig Simpson a écrit : Wouldn't vxstat being seeing that? Is there a way to measure what you are saying? Seems like the best I can do as an SA on the box is run vxstat and "See what I see" Thanks! Craig -----Original Message----- From: [EMAIL PROTECTED] on behalf of Sebastien DAUBIGNE Sent: Tue 4/1/2008 5:01 AM To: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] vxstat data Questions Don't forget de filesystem layer : Unless you use direct I/O or rawdevices, filesystem cache management will add extra latency that will be counted by Oracle as I/O service time : Oracle sends I/O via read/write/pread/pwrite/aoiread/aiowrite syscalls which are at last manager by the filesystem layer . Also filesystem mappings can produce Oracle I/O breakups that could also add latency. At last, all these kernel latencies which are not counted as I/O time by VxVM will be counted as I/O time by Oracle. Craig Simpson a écrit : > > The Volumes below pretty much explain their purpose. > > What I am running into is my DBA's say that they are not getting the > read/write times that I see via vxstat. > > What are "AVG TIME(ms) READ WRITE" ??? > > These mean the time it takes to a read or write to start, or is it the > time a read or write takes to complete? > > >From below it looks likes Oracle is getting really good read/write > times. > > Is it fair to say that, "Hey DBA'S this is what you are getting > read/write Veritas says so" ??? > > > > OPERATIONS BLOCKS AVG TIME(ms) > TYP NAME READ WRITE READ WRITE READ WRITE > > Tue Apr 01 00:36:22 2008 > vol data01vol 735 1762 24400 41497 2.9 0.8 > vol data02vol 390 1374 6544 25307 7.0 0.7 > vol redo1 533 11635 1083396 233640 0.9 1.1 > vol redo2 4 11635 4 233640 2.5 1.1 > > Tue Apr 01 00:38:22 2008 > vol data01vol 381 10665 18624 297160 4.1 3.1 > vol data02vol 636 1783 10432 31760 11.1 3.8 > vol redo1 495 16961 1011046 200950 0.2 1.1 > vol redo2 0 16960 0 200934 0.0 1.0 > > Tue Apr 01 00:40:22 2008 > vol data01vol 333 13108 17504 313880 5.2 0.7 > vol data02vol 328 1745 5568 31208 15.6 0.8 > vol redo1 0 4773 0 63931 0.0 0.7 > vol redo2 0 4773 0 63931 0.0 0.7 > > Tue Apr 01 00:42:22 2008 > vol data01vol 310 9324 17184 227240 3.3 0.7 > vol data02vol 334 1524 5632 27338 10.7 0.6 > vol redo1 0 4042 0 46028 0.0 0.8 > vol redo2 0 4042 0 46028 0.0 0.7 > > -- > > Craig Simpson > Visto Corporation > Operations Team > [EMAIL PROTECTED] > > > "In the circle the beginning and the end are common" > ~ Heraclitis (540-480BC) > > > > _______________________________________________ > Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > > > -- Sebastien DAUBIGNE [EMAIL PROTECTED] - +33(0)5.57.89.31.09 AtosOrigin Infogerance - AIS/D1/SudOuest/Bordeaux/IS-Unix _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx -- Sebastien DAUBIGNE [EMAIL PROTECTED] - +33(0)5.57.89.31.09 AtosOrigin Infogerance - AIS/D1/SudOuest/Bordeaux/IS-Unix
_______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
