Hi,
Thanks. I'll read that link when I get into work this morning. The
existing config is 96 individual SIDs on a monolithic Windows server with a
listener per SID (96 cpu, 1+TB RAM, etc.). The Ops team wants to move to
CBD/PDB on RedHat now. Trying to work out all the details and changes that
need to be fleshed out. On the windows side, they used cpu grouping and
assigned each SID to a cpu group. They also used the Resource Manager with
each SID for the application schemas. They want to keep the isolation and
control in the multitenant environment and I'm fleshing out the details...
just don't have much experience in multitenant and so many things change
with each version. Glad to see 12.2 came out this month. The non engineered
12.1 didn't have nearly as much isolation capability.
On Mon, Mar 6, 2017 at 10:15 AM, Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:
The sessions parameter is separately settable from processes.
http://docs.oracle.com/database/122/REFRN/SESSIONS.htm#REFRN10197
I'd be *extremely* wary of consolidating 96 separate databases onto a
single CDB with 96 PDBs unless those 96 single instance databases already
share hardware. Consolidation *will* give you noisy neighbours, I see
Franck already suggested using CPU_COUNT to control CPU usage, but even
with a CPU_COUNT of 1 per server that implies an allocation of 48
cpus worth of resource.
Now it's likely of course that you'll be running RAC with a subset of
databases on each node, rather than high core count servers, but then you
need to plan for failure modes, what happens if one node of your 4 node RAC
dies and you end up with each node having an unexpected 33% increase in
workload.
Instead, it makes a lot of sense to plan your capacity (and outside of
engineered systems there isn't a lot you can do about I/O) . I suggest
starting with https://ardentperf.com/2013/10/28/operationally-
scalable-practices/ and thinking about to what extent the advent of PDBs
and/or public cloud might mandate some different choices.
In addition, an often overlooked consideration is what to do about
application downtime for database/server maintenance. With single server
systems, you likely have one set of stakeholders to talk to, with 96 the
problem could well become unmanageable.
I apologise if this is all well known to you. Even better if you've
successfully consolidated at this scale and can write about it I'd love to
read about what you've done.
On Mon, Mar 6, 2017 at 2:38 PM, Woody McKay <woody.mckay@xxxxxxxxx> wrote:
In 13.2, is processes modifiable at the PDB level? Sessions is derived
fro processes, right?
On Fri, Mar 3, 2017 at 4:10 PM Franck Pachot <franck@xxxxxxxxxx> wrote:
Hi,Sincerely,
The session parameter is PDB modifiable. It limits the number of
sessions in the PDB.
If you want to limit the concurrent sessions running in CPU then in 12.2
you can set cpu_count.
Regards,
Franck.
On Fri, Mar 3, 2017 at 9:38 PM Woody McKay <woody.mckay@xxxxxxxxx>
wrote:
I'm looking at the new 12.2 multitenant on Linux 64x.
So many new features and settings pushed down from CBD to PDB.
Does anyone have the best solution for limiting the number of user
sessions per PDB?
PDB level profile, resource management or lock down?
Looking to put 96 customer SIDs into 96 PDB's and want to keep high
isolation.
Thoughts???
--
Sincerely,
WoodyMcKay
--
WoodyMcKay
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
