On Aug 13, 12:54 pm, DA Morgan <damor..._at_psoug.org> wrote:
> dean wrote:
> > On Aug 13, 11:54 am, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net>
> > wrote:
> >> On Aug 13, 12:10 am, dean <deanbrow..._at_yahoo.com> wrote:
>
> >>> 10g
> >>> select * from V$SYSTEM_WAIT_CLASS order by TIME_WAITED desc;
> >>> WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED
> >>> ------------- ----------- -------------- ----------- -----------
> >>> 2723168908 6 Idle 15742538 990583927
> >>> 1740759767 8 User I/O 1501104 541245
> >>> 2000153315 7 Network 35587647 227757
> >>> 4108307767 9 System I/O 690084 194154
> >>> 3386400367 5 Commit 70951 23803
> >>> 3875070507 4 Concurrency 11212 13790
> >>> 4217450380 1 Application 12112 5730
> >>> 1893977003 0 Other 7106 5411
> >>> 3290255840 2 Configuration 171 1979
> >>> This is the first time I have looked at this view, and I'm trying to
> >>> understand it - does this indicate performance issues with the disk i/
> >>> o?
> >>> Thanks!
> >>> Dean
> >> Not necessarily; the TIME_WAITED values are in centiseconds (1/100 of
> >> a second) and are cumulative for all sessions for as long as the
> >> database is running uninterrupted. The User I/O number you posted
> >> represents roughly 90 minutes of wait time for ALL sessions since the
> >> database started. Presuming you have more than one connected session
> >> and that the database has been up and running for more than two hours
> >> I'd say no; follow Daniel's advice and file this away for future
> >> reference. When and if a user (or group of users) decides to complain
> >> about performance you can resurrect these values and compare them to
> >> the current numbers (again, presuming you haven't shut down the
> >> database between now and then) and possibly find the area or areas
> >> which have changed.
>
> >> There is no need to create problems where none currently exist.
>
> >> David Fitzjarrell- Hide quoted text -
>
> >> - Show quoted text -
>
> > Ok thanks to both. There is no problem here on the development server,
> > I just wanted to familiarize myself. I wasn't sure if this was
> > indicating we could use a faster set of drives (forgot it was in
> > centiseconds).
>
> These days drives are less relevant as most disk arrays come with a
> cache managed by its own operating system.
> --
> Daniel A. Morgan
> University of Washington
> damor..._at_x.washington.edu (replace x with u to respond)
> Puget Sound Oracle Users Groupwww.psoug.org- Hide quoted text -
>
> - Show quoted text -
Even with disk cache, doesn't Oracle wait for confirmation of a
physical write to disk?
Received on Mon Aug 13 2007 - 12:35:31 CDT
