You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
From a CPU subsystem perspective, it is not possible to increase scalability by somehow splitting a single Oracle server process activity onto multiple CPU cores. Our only option is to decrease total service time to use faster CPUs. Because of cost and budgetary timing issues, we do not want to entertain this option unless absolutely necessary. So at this point, we will not seek to improve performance by increasing the CPU subsystem capacity.
Based solely on the v$sysstat performance view, the IO subsystem is receiving read requests at nearly 530 MB/s. Oracle read requests (db file scattered read) are being satisfied in less than 1 ms, which indicates the Oracle blocks reside in the operating system buffer cache! While not shown in Figure 9-22, the average IO device utilization is around 2%, meaning they are idle.
The Oracle and application tuning strategies are intended to reduce the number of IO read calls, making an increase in IO activity and subsequent IO performance issues highly unlikely.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|