Are PL/SQL Package Body Constants in Shared Area or Private Area

Question

Based on this it not clear to me if PL/SQL Package Body Constants are stored in shared area or private area.
http://docs.oracle.com/cd/B28359_01/server.111/b28318/memory.htm
"PL/SQL Program Units and the Shared Pool
Oracle Database processes PL/SQL program units (procedures, functions, packages, anonymous blocks, and database triggers) much the same way it processes individual SQL statements. Oracle Database allocates a shared area to hold the parsed, compiled form of a program unit. Oracle Database allocates a private area to hold values specific to the session that runs the program unit, including local, global, and package variables (also known as package instantiation) and buffers for executing SQL. If more than one user runs the same program unit, then a single, shared area is used by all users, while each user maintains a separate copy of his or her private SQL area, holding values specific to his or her session.
Individual SQL statements contained within a PL/SQL program unit are processed as described in the previous sections. Despite their origins within a PL/SQL program unit, these SQL statements use a shared area to hold their parsed representations and a private area for each session that runs the statement."
I am also curious what are the fine grained differences from a memory and performance perspective (multi-session) for the two examples below. Is one more efficient?
Example 1.
create or replace
package body
application_util
as
c_create_metadata constant varchar2(6000) := ...
procedure process_xxx
as
begin
end process_xxx;
end application_util;
vs.
Example 2.
create or replace
package body
application_util
as
procedure process_xxx
as
c_create_metadata constant varchar2(6000) := ...
begin
end process_xxx;
end application_util;

Answer 1

>
What i am asking is fairly granular, so here it is again, let's assume latest version of oracle..
In a general sense, is the runtime process able to manage memory more effectively in either case, one even slightly more performant, etc
ie does example 1 have different memory management characteristics than example 2.
Specifically i am talking about the memory allocation and unallocation for the constant varchar2(6000)
Ok, a compiler's purpose is basically to create an optimized execution path from source code.
The constant varchar2(6000) := would exist somewhere in the parse tree/execution path (this is stored in the shared area?).
I guess among the things i'm after is
1) does each session use space needed for an additional varchar2(6000) or does runtime processor simply point to the constant string in the parse tree (compiled form which is shared).
2) if each session requires allocation of space needed for an additional varchar2(6000), then for example 1 and example 2
at what point does the constant varchar allocation take place and when is the memory unallocated.
Basically does defining the constant within the procedure have different memory characteristics than defining the constant at the package body level?
>
Each 'block' or 'subprogram' has a different scope. So the 'constant' defined in your example1 is 'different' (and has a different scope) than the 'constant' defined in example2.
Those are two DIFFERENT objects. The value of the 'constant' is NOT assigned until control passes to that block.
See the PL/SQL Language doc
http://docs.oracle.com/cd/E14072_01/appdev.112/e10472/fundamentals.htm#BEIJHGDF
>
Initial Values of Variables and Constants
In a variable declaration, the initial value is optional (the default is NULL). In a constant declaration, the initial value is required (and the constant can never have a different value).
The initial value is assigned to the variable or constant every time control passes to the block or subprogram that contains the declaration. If the declaration is in a package specification, the initial value is assigned to the variable or constant once for each session (whether the variable or constant is public or private).
>
Perhaps this example code will show you why, especially for the second example, a 'constant' is not necessarily CONSTANT. ;)
Here is the package spec and body
create or replace package pk_test as
  spec_user varchar2(6000);
  spec_constant varchar2(6000) := 'dummy constant';
  spec_constant1 constant varchar2(6000) := 'first constant';
  spec_constant2 constant varchar2(6000) := 'this is the second constant';
  spec_constant3 constant varchar2(6000) := spec_constant;
  procedure process_xxx;
  procedure change_constant;
end pk_test;
create or replace package body pk_test as
procedure process_xxx
as
  c_create_metadata constant varchar2(6000) := spec_constant;
begin
  dbms_output.put_line('constant value is [' || c_create_metadata || '].');
end process_xxx;
procedure change_constant
as
begin
  spec_constant := spec_constant2;
end change_constant;
begin
  dbms_output.enable;
  select user into spec_user from dual;
  spec_constant := 'User is ' || spec_user || '.';
end pk_test;The package init code sets the value of a packge variable (that is NOT a constant) based on the session USER (last code line in package body).
The 'process_xxx' procedure gets the value of it's 'constant from that 'non constant' package variable.
  c_create_metadata constant varchar2(6000) := spec_constant;The 'change_constant' procedure changes the value of the package variable used as the source of the 'process_xxx' constant.
Now the fun part.
execute the 'process_xxx' procedure as user SCOTT.
SQL> exec pk_test.process_xxx;
constant value is [User is SCOTT.].Now execute 'process_xxx' as another user
SQL> exec pk_test.process_xxx;
constant value is [User is HR.].Now exec the 'change_constant' procedure.
Now exec the 'process_xxx' procedure as user SCOTT again.
SQL> exec pk_test.process_xxx;
constant value is [this is the second constant].That 'constant' defined in the 'process_xxx' procedure IS NOT CONSTANT; it now has a DIFFERENT VALUE.
If you exec the procedure as user HR it will still show the HR constant value.
That should convince you that each session has its own set of 'constant' values and so does each block.
Actually the bigger memory issue is the one you didn't ask about: varchar2(6000)
Because you declared that using a value of 6,000 (which is 2 ,000 or more) the actual memory allocation not done until RUN TIME and will only use the actual amount of memory needed.
That is, it WILL NOT pre-allocate 6000 bytes. See the same doc
http://docs.oracle.com/cd/E14072_01/appdev.112/e10472/datatypes.htm#CJAEDAEA
>
Memory Allocation for Character Variables
For a CHAR variable, or for a VARCHAR2 variable whose maximum size is less than 2,000 bytes, PL/SQL allocates enough memory for the maximum size at compile time. For a VARCHAR2 whose maximum size is 2,000 bytes or more, PL/SQL allocates enough memory to store the actual value at run time. In this way, PL/SQL optimizes smaller VARCHAR2 variables for performance and larger ones for efficient memory use.
For example, if you assign the same 500-byte value to VARCHAR2(1999 BYTE) and VARCHAR2(2000 BYTE) variables, PL/SQL allocates 1999 bytes for the former variable at compile time and 500 bytes for the latter variable at run time.
>
So when you have variables and don't know how much space is really needed do NOT do this:
myVar1 VARCHAR2(1000);
myVar2 VARCHAR2(1000);
myVar3 VARCHAR2(1000);The above WILL allocate 3000 bytes of expensive memory even if it those variables are NEVER used.
This may look worse but, as the doc states, it won't really allocate anything if those variables are not used. And when they are used it will only use what is needed.
myVar1 VARCHAR2(2000);
myVar2 VARCHAR2(2000);
myVar3 VARCHAR2(2000);