Re: Create common user in all PDB's

Also very late to the game; but interested. a) 2,500 PDBs with only 10 cores (per node) sounds a little optimistic - are most of those PDBs small and virtually idle? b) How about seeingn what happens if you set parallel_max_servers to zero at the PDB. (which might make it set itself to 1 to allow chat between the CDB and PDBs).

Could you tell from the SQL that failed whether it was an "local" type of statement, or could it have been a statement that was supposed to travel between pdb and cdb >?

Regards
Jonathan Lewis

On Tue, 15 Feb 2022 at 06:24, Martin Berger <martin.a.berger_at_gmail.com> wrote:

> Hi Jacques,
>
> is this still an issue?
> can you check if CONTAINER_PARALLEL_LIMIT is set?
> I can't promise it will help, but at least it somehow limits some
> container-wide activities.
>
> br,
> Martin
>
> Am Fr., 4. Feb. 2022 um 19:09 Uhr schrieb Google <jacques.kostic_at_gmail.com
> >:
>
>> Hi John
>>
>> I'm also an Oracle employee, neither in a support org nor in a role that
>>> relates directly to the internals of technologies discussed in this
>>> thread. Opinions are my own, I don't represent Oracle here, etc, etc.
>>>
>>> It''s an interesting case that I liked to share.
>>> There is an SR and the problem will probably be solved.
>>>
>>> Cheers
>>> Jko
>>>
>>>
>>> On February 4, 2022 18:59:58 John Piwowar <jpiwowar_at_gmail.com> wrote:
>>
>>> Starting with a disclaimer: I'm an Oracle employee, but neither in a
>>> support org nor in a role that relates directly to the internals of
>>> technologies discussed in this thread. Opinions are my own, I don't
>>> represent Oracle here, etc, etc. This is basically what I would've said in
>>> my consulting days, anyway:
>>>
>>> First, I strongly recommend logging an SR for this. A huge number of
>>> PDBs in a single CDB is *unusual, *but it's not unique*. *You certainly
>>> appear to be bumping up against a scale issue with the patch process, and
>>> if so you're unlikely to be the only customer to do so. There may be a
>>> solution already, or if it's actively being worked on, you can at least be
>>> added to any existing bugs to be notified of a solution.
>>>
>>> Second, as you've suggested (and the ORA-12805 errors reinforce), there
>>> are a lot of data dictionary operations that are parallelized when executed
>>> from the CDB$ROOT level; you *might* be running into that here. You
>>> can also probably see the PQ operations heavily represented in AWR/ASH
>>> reports. You may get better results by throttling the PQ settings in your
>>> environment during the patch process...where "better" is "At least the
>>> server doesn't fall down." :) That's only a guess...I don't have that kind
>>> of environment available to conduct experiments.
>>>
>>> Regards,
>>>
>>> John P.
>>>
>>> On Fri, Feb 4, 2022 at 7:23 AM jacques kostic <jacques.kostic_at_gmail.com>
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> Here is a nice one:
>>>>
>>>> Customer is under Exadata CS, 2 nodes with 10 cores in each node.
>>>> He has a CDB with more than 2'500 PDB's.
>>>>
>>>> He needs to patch the Exadata CS tooling and during the patching a
>>>> common user is created into all PDB's.
>>>> At this point, the CPU goes bananas and the process stops with ORA-12805
>>>> (os related)
>>>> The system is just overloaded!
>>>>
>>>> Am I wrong to say that this Create common user goes in // on all PDB
>>>> when add container=all?
>>>>
>>>> We could split the process and proceed by chunks but of course we
>>>> cannot touch the patching scripts...
>>>>
>>>> Any way to avoid this // create common user processing?
>>>>
>>>> Cheers
>>>> jko
>>>>
>>>>
>>
>
> --
> Martin Berger Oracle ♠
> martin.a.berger_at_gmail.com _at_martinberx <https://twitter.com/martinberx>
> ^∆x http://berxblog.blogspot.com
>

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