Still, Well, Users are happy. but in the morning when they run large batch jobs, yeah couple of guys do face some problems. As per my observations ,highest waits were DB_SEQUENTIAL_WAITS. So have done rebuilding of indexes as Sequential reads can be high because of the FTS on the tables. Even for the 40GB Database, we have only 250 MB SGA so which I am planning to increase. In normal day operation no query is getting locked or taking very long to execute. But with the help of OEM, these guys can see that ratio is LOW and that is where I have to take care. I think increase the size to 400 MB for now and then reanalyze and rebuilding the indexes will help me to see this down. This is what I have planned for now. v$system_event has following high waits. Hope after my operations it will be down. db file scattered read 40262440 3990102 SQL*Net message from client 98729463 8838908158 SQL*Net message to client 98729537 19876 db file sequential read 224733173 15513002 Regards - Chirag On 9/13/05, Jared Still <jkstill@xxxxxxxxx> wrote: > > On 9/13/05, Chirag DBA <chiragdba@xxxxxxxxx> wrote: > > > > Did someone mean that RATIOS are absolete now and those should not be > > considered now. > > They are not *completely* useless, but they do not tell you much. > > Some ratios are less useless than others - this is just about the DBCHR. > > If your DBCHR (database cache hit ratio) is unusually low, it tells > you that something may be different. > > Or it may just mean you've never seen it that low because you observed > it at the wrong time. > > Or it may mean nothing at all. > > The DBCHR does not give you any idea what on your database needs > to be corrected, or even *if* anything needs corrected. > > This is more of an advanced topic. You need to learn how Oracle works > before delving into this. > > If your users are happy, don't worry about fixing things that probably > are not broken. :) > > -- > Jared Still > Certifiable Oracle DBA and Part Time Perl Evangelist > 11+ years of trying to appear to know what I'm doing. >