It may have happened to many. For those who did not got the clue, since the oracle 10.2.0.4 update it looks like the default behavior of the database is to think it is running on a NUMA machine, where NUMA stands for Non Uniform Memory Architecture. I do not know many NUMA machines. Sequent had some machines running on dynix/pts that had a NUMA architecture. I am sure IBM - that bought sequent a few years ago - is going to do smart things with it.
For those who are not running on a NUMA machine (I guess for most) there are a few settings that can be applied to return to normal behavior.
alter system set "_enable_NUMA_optimization"=FALSE scope = spfile;
alter system set "_db_block_numa"=1 scope = spfile;
Both parameters are static.
The symptoms can vary. In my case a database that had a custom resource manager plan suddenly did not perform all to well when making a compressed disk backup, using 16 channels.
Before the upgrade to 10.2.0.4 the backup ran with 32MB/s output.
After the upgrade to 10.2.0.4 the backup crawled with 3 MB/s and at the same time other sessions did not get any cpu cycle at all.
It looked like resource manager was holding cp cycles for itself since the system had plenty cpu resources available (80% idle).
After applying the afore mentioned settings the output performance went back to normal and at the same time, other session could get services.
I hope this little note is of any use for someone, it took 5 months working with oracle support to reach this point.
2 reacties:
You are a god! Thanks for everything you do — especially for your Mac info.
Check this bit out for more info where NUMA applies in high end configs:
http://hosteddocs.ittoolbox.com/Oracle11gArchitecture110507.pdf
It's on page 8 of the PDF.
Een reactie plaatsen