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<mailto: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
