With Oracle, someone is listing to the PC side of the house.
That is, inexpensive MIPS, inexpensive memory, expensive I/O. Hence you want
SGA to be as big as possible.
On the IFL side, MIPS are still relatively expensive, memory is still
relatively expensive, and assuming you are on FICON,
cc
System
ib...@listserv.u Subject
ARK.EDU Re: Testing Linux Z/vm
It would also be interesting to know the response from a:
CP Q SRM STORBUF
Mike Hammock
- Original Message -
From: August Carideo august.cari...@avon.com
To: IBMVM@LISTSERV.UARK.EDU
Sent: Friday, June 26, 2009 11:54 AM
Subject: Re: Testing Linux Z/vm
yes we are ficon, also
: August Carideo august.cari...@avon.com
To: IBMVM@LISTSERV.UARK.EDU
Sent: Wednesday, June 24, 2009 4:02 PM
Subject: Testing Linux Z/vm
We are preparing for a test and loading the database is taking forever.
Paging is high. I/O devices are less than 5% busy. CPU is never more than
20%. An Oracle
On Thu, Jun 25, 2009 at 5:56 AM, Marcy
Your guest is bigger than your real storage. If you need to do that
overcommitting (and you may not - see Rich's question about SGA sizes),
Overcommitting resources is good, because it is the only way to
enforce sharing resources. But defining a single
We are preparing for a test and loading the database is taking forever.
Paging is high. I/O devices are less than 5% busy. CPU is never more than
20%. An Oracle file import is taking over 14 hours. Any Idea's with this
little bit of info to go on
Also is there a reason for the TCPIP machine to
August Carideo wrote:
We are preparing for a test and loading the database is taking forever.
Paging is high. I/O devices are less than 5% busy. CPU is never more than
20%. An Oracle file import is taking over 14 hours. Any Idea's with this
little bit of info to go on
Also is there a reason
[mailto:ib...@listserv.uark.edu] On Behalf
Of August Carideo
Sent: Wednesday, June 24, 2009 1:03 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Testing Linux Z/vm
We are preparing for a test and loading the database is taking forever.
Paging is high. I/O devices are less than 5% busy. CPU is never more
