Oracle 9i performance

[Ben Dehner]

Well, I'll throw in my 2 cents.

In my experience, most Oracle performance problems aren't caused by kernel settings. For the most part, kernel tweaking is a matter of simply giving Oracle the resources it wants. If Oracle doesn't have those resources, its not that it runs slowly, it simply doesn't run at all. It fails with a failure to allocate some IPC resource or fork a process or whatever. Although I have seen I/O get hung for extreme IO loads if the scsi_queue_depth setting was too low on fibre adapters.

Likewise, few performance issues are caused by Oracle parameter settings, for the same reasons. For the things that can be checked, make sure that db_cache_size and shared_pool are high enough. Also make sure that the database stats are analyzed about once a week.

The best place to start looking is within the database; and the best tool to start looking with is statspack. It will identify the top wait events within the database, as well as the SQL statement causing the highest disk I/O. I have seen a lot of performance problems caused by SQL that was not properly optimized for Oracle.

[Yogeeraj_1]

Hi shiv,

also check in your Database control (Enterprise Manager), you have many advisors to help as well as ADDM.

hope this helps too!

kind regards
yogeeraj

[Shivkumar]

Can someone explain what is STATSPACK data ?
I don't have access to the database and hence this question. I am contributing by reading and imagination.

Thanks,
Shiv

[Alzhy]

Shivkumar,

Why do you think or claim that you have a Disk I/O performance issue? I say - first establish that you indeed have an I/O problem. And this is 2 pronged:

(1) DBA approach -- ask your DBA to ascertain if there really is an obvious I/O problem. Ask what volumes/filesystems/files suffer from "slow" performance.

(2) On your end - SysAdmin, check the volume's/filesystem's in question -- check the component disks via "sar -d" if you indeed have I/O issues -- which should manifest via qdepths > 1.0

If (1) or (2) confirms you indeed have an I/O issue, then look at how your XP1024 LUNs are used to build your Oracle storage. It does not matter whether you use RAW or cooked storage -- best pracice for the XP array is to always stripe accross 4 or 8 LUNs with each LUN coming from different ACP and array group and prefereably on each own Fibre Channel Path...

Follow the above recipe and you will alwyas have proof that your I/O configuration is not at fault..

[Yogeeraj_1]

hi shiv,

more information on statspack is available at:

http://www.oracle.com/technology/deploy/performance/pdf/statspack.pdf


if you have further queries, please do let us know

kind regards
yogeeraj

[Eric Antunes]

Hi Shiv,

Some basic stats you should monitor:

select (bbc.total_waits*100/(cg.value+dbg.value)) "Buff busy ratio ind. <= 0,007"
from v$system_event bbc,
v$sysstat cg, v$sysstat dbg
where bbc.event='buffer busy waits'
and cg.name ='consistent gets'
and dbg.name='db block gets';

select (1-(sum(getmisses)/sum(gets))) * 100 "Hit Ratio > 95%"
from v$rowcache;

select round((congets.value+dbgets.value-physreads.value)*100/
(congets.value+dbgets.value),4) || '%' "Buffer Cache Hit Ratio >= 95%"
from v$sysstat congets, v$sysstat dbgets, v$sysstat physreads
where congets.name='consistent gets'
and dbgets.name='db block gets'
and physreads.name='physical reads';

select round(100 * sum(reloads) / sum(pins), 2) "Reloads Pct < 1%"
from v$librarycache;

Best Regards,

Eric Antunes

[Michael Kupfer]

Shiv,

I agree with one of the posts above about Solid state disk to an extent. It is a great solution for I/O issues, however you do not need to put your entire dbase on the SSD. So it can be affordable.

I own a company that sells SSD SANS, and the added benefit of putting your most accessed data on them is that they are no longer accessed from the array...making the array work more efficiently as well. We have found that usually 2-5% of your data can cause 80%-90% of your IO problems. If you would like to learn more, please send me an e-mail mike@bdtstorage.com.

MLK