RE: Concurrent I/O (AIX 5.2)
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <stuart.clowes@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 29 Jun 2006 16:14:49 -0700
I don't know of a metric regarding the large memory pages. I just did
it based on the published recommendations of both Oracle and IBM, and
the reasoning they provide, e.g. - see the following:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b15658/tuni
ng.htm
http://www-03.ibm.com/servers/enable/site/peducation/wp/9a46/9a46.pdf
http://www.sioug.si/sioug2005/datoteka.jsp?filename=Tomaz%20Vincek%20-%2
0Oracle%2010g%20Performance%20Tuning%20v%20UNIX%20okolju.pdf
Regards,
Brandon
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Stuart Clowes
Sent: Thursday, June 29, 2006 3:10 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Concurrent I/O (AIX 5.2)
We have minperm=10%, maxperm=20%, maxclient=20%. Will look to reduce
these even further.
Our db_cache_size has increased from 1 GB to 2 GB, and we are still
gently increasing it.
We are, at the moment, not memory constrained, although I am starting to
chew up our spare memory by increasing db_cache_size. (use it or lose
it.... ;) )
agblksize=512 for the redo logs.
In fact, agblksize=512 for the database files as well - any comments on
whether this is 'wrong'?
Filesystems for redo and dbf are mounted cio.
FILESYSTEM_IO_OPTIONS=SETALL.
Only thing we haven't done is implemented large memory pages. Do you
know of a metric that would reveal whether this could be beneficial for
us?
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions and
other information in this message that do not relate to the official business
of this company shall be understood as neither given nor endorsed by it.
Other related posts:
