One solution I would have thought appropriate here would be to implement
the instance caging feature of Oracle. There's an 11g white paper on this
http://www.oracle.com/technetwork/database/performance/instance-caging-wp-166854.pdf
. You've got a 64 core server and are proposing 96 instances so you are
planning on over provisioning - there's nothing wrong with that - but you
do rely on the assumption that the database instances will be mostly idle,
or at least not busy at the same time. If this doesn't prove valid then in
an instance caging environment you will have waits for cpu, and in a non
caged environment you will likely have nasty cases where db1 effectively
kills db 2-96 :).
Given that you've gone with a separate listener and ip for each database,
I'd also give serious consideration to using virtualization with one db per
vm. You can then allow the hypervisor to do the cpu scheduling.
On Wed, Nov 4, 2015 at 6:40 PM, Woody McKay <woody.mckay@xxxxxxxxx> wrote:
Hi,
Our hosting unit is designing a large server and want to put about 96
SID's on it. They've worked through I/O and RAM considerations. This is
on Win 64 2012 R2.
However, they are not sure about cpu/core count and usage. They currently
have 64 cores and need to know how many of the cores will each SID
(oracle.exe) can/will use. If a SID can't use all cores, then what's the
best way to spread the SIDs across all the cores. I talked about cpu
groups, but they said that Oracle always picks cpu group 0 on startup and
they have to manually reassign the groups to each oracle.exe process.
I've only had about 40 SIDs on a box with 24 cores, so I don't really have
the experience to provide the best answers.
Any thoughts? Thanks
--
Sincerely,
WoodyMcKay
