Re: limiting number of sessions in multitenant PDB

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_at_gmail.com> 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_at_gmail.com> 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_at_pachot.net> wrote:
>>
>>> Hi,
>>> 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_at_gmail.com>
>>> 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
>>>
>>> --
>> Sincerely,
>>
>> WoodyMcKay
>>
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

-- 
Sincerely,

WoodyMcKay

--
http://www.freelists.org/webpage/oracle-l