RE: [External] : Re: PLSCOPE_SETTINGS='IDENTIFIERS:ALL' downsides?
Date: Tue, 19 Oct 2021 12:00:45 +0000
Message-ID: <SJ0PR10MB46868573A1E572B45E52E9D7A3BD9_at_SJ0PR10MB4686.namprd10.prod.outlook.com>
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_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Jacek Gebal
Sent: Tuesday, October 19, 2021 7:55 AM
To: mcpeakm_at_tempus-consulting-group.com
Cc: Oracle List <oracle-l_at_freelists.org>
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:
I cannot confirm any of his concerns though.
Regards
On Mon, 18 Oct 2021, 19:17 Matt McPeak, <mcpeakm_at_tempus-consulting-group.com<mailto:mcpeakm_at_tempus-consulting-group.com>> 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,
- conpilation/recompilation time
Jacek
Matt
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Oct 19 2021 - 14:00:45 CEST