As far as I know there is no performance hit at execution time of PLSQL
code itself as all plscope Metadata is extracted at compilation time and
stored separately. The PLSQL code gets compiled the same way. Plsql
optimize level is a separate thing.
On Tue, 19 Oct 2021, 15:01 Jeff Smith, <jeff.d.smith@xxxxxxxxxx> wrote:
Anything extra must have a cost, but I’ve only heard of a ‘compile’ tax
for PL/SQL extend to debug information – as that causes overhead on
EXECUTION of said procedures. I’ve never heard of any sort of performance
tax for plsql objects with Scope data additionally stored in the data
dictionary.
Of course, all things are easy to prove with some A vs B testing using
something like LoadRunner or SwingBench.
Jeff
*From:* oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> *On
Behalf Of *Jacek Gebal
*Sent:* Tuesday, October 19, 2021 7:55 AM
*To:* mcpeakm@xxxxxxxxxxxxxxxxxxxxxxxxxxx
*Cc:* Oracle List <oracle-l@xxxxxxxxxxxxx>
*Subject:* [External] : Re: PLSCOPE_SETTINGS='IDENTIFIERS:ALL' downsides?
The only downside I can think of is one thing that I've heard from one of
DBA when I asked the same question to him.
His concerns were:
- conpilation/recompilation time
- data dictionary growth in vase when you have a,lot of PLSQL source code.
I cannot confirm any of his concerns though.
Regards
Jacek
On Mon, 18 Oct 2021, 19:17 Matt McPeak, <
mcpeakm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Is there a reason (any at all), not to alter all the custom packages in my
database to compile them with PLSCOPE_SETTINGS='IDENTIFIERS:ALL'?
Performance? Security? Anything?
If there are reasons not to do it in production, I'm considering giving
out DBAs a script to turn it on for everything as part of their
instance-cloning procedures, so it would be turned on in all non-production
environments. That script would include an ALTER SYSTEM SET
PLSCOPE_SETTINGS='IDENTIFIERS:ALL', so that PLScope data will be maintained
as developers do their work. Any reasons this is a bad idea?
Thanks,
Matt
