Re: Create common user in all PDB's

From: Google <jacques.kostic_at_gmail.com>
Date: Fri, 04 Feb 2022 19:09:00 +0100
Message-ID: <17ec5ecd660.27a0.f39e3e69b57dc29d82f1c76ed37cd589_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

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Feb 04 2022 - 19:09:00 CET

Original text of this message