Sunday, January 16, 2005
Thanks to Mladen Gogola for pointing out that it was indeed a configuration issue, though as it turns out an Oracle one and not an OS level issue.
The large elasped time that I was experiencing for LOG_BUFFER waits are of course caused by LGWR being slower on linux than it was on Windows. lgwr uses directIO if it can (DBWR by the way uses asynch IO.) The default installation of Oracle does not enable either of these. The solution
1. Make sure that you actually have the asynchronous io libraries loaded. on red-hat and fedora rpm -qa|grep libaio will tell you, you should have both libaio and libaio-devel install these as root if need be
2. as the owner of the oracle software relink Oracle to enable asynch io
make -f ins_rdbms.mk asynch_on
make -f ins_rdbms.mk ioracle
3. set filesystemio_options init.ora parameter to setall for both to be used.
restart Oracle.
Having followed these steps the good news was that my elapsed time for Linux was now 84s, this is still about 15% slower than windows for this test, but certainly in the right area.
more tests to follow in the coming weeks.
0 Comments
The large elasped time that I was experiencing for LOG_BUFFER waits are of course caused by LGWR being slower on linux than it was on Windows. lgwr uses directIO if it can (DBWR by the way uses asynch IO.) The default installation of Oracle does not enable either of these. The solution
1. Make sure that you actually have the asynchronous io libraries loaded. on red-hat and fedora rpm -qa|grep libaio will tell you, you should have both libaio and libaio-devel install these as root if need be
2. as the owner of the oracle software relink Oracle to enable asynch io
3. set filesystemio_options init.ora parameter to setall for both to be used.
restart Oracle.
Having followed these steps the good news was that my elapsed time for Linux was now 84s, this is still about 15% slower than windows for this test, but certainly in the right area.
more tests to follow in the coming weeks.
0 Comments:
Post a Comment
