在不提供精度和比例的情况下，Oracle PL\\SQL 中 Number 数据类型的大小是多少？

Question

One of the guidelines in my new project is to specify precision & scale along with the NUMBER in Oracle PL\\SQL. The developer handbook says if this is not specified a default size of 22 bytes is allocated for every variable.

While I understand it is important to specify precision & scale where ever possible. I don't seem to agree that 22 bytes are allocated if the precision is not supplied.

http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1834

From the Oracle documentations:

" Internal Numeric Format

Oracle Database stores numeric data in variable-length format. Each value is stored in scientific notation, with 1 byte used to store the exponent and up to 20 bytes to store the mantissa. The resulting value is limited to 38 digits of precision. Oracle Database does not store leading and trailing zeros.
For example, the number 412 is stored in a format similar to 4.12 x 10 ² , with 1 byte used to store the exponent(2) and 2 bytes used to store the three significant digits of the mantissa(4,1,2). Negative numbers include the sign in their length."

I sent the above documentation to the database architect, but he doesn't seem to agree with me.

If we don't specify precision & scale for a NUMBER datatype in oracle pl\\sql will it take 22 bytes or just enough bytes to store the value assigned to it?

Answer 1

NUMBER is equivalent of NUMBER(*) . Precision and scale are only restrictions for accepted values and have no impact of the memory allocation.

HUSQVIK@HQ_PDB_TCP> DECLARE
  2      item_count CONSTANT NUMBER := 10000000;
  3      TYPE t_collection IS TABLE OF NUMBER(38);
  4      data t_collection := t_collection();
  5
  6      PROCEDURE print_allocated_memory IS
  7          allocated_memory NUMBER;
  8      BEGIN
  9          SELECT
 10              value INTO allocated_memory
 11          FROM
 12              v$statname
 13              JOIN v$mystat ON v$statname.statistic# = v$mystat.statistic#
 14          WHERE
 15              name = 'session pga memory';
 16
 17          dbms_output.put_line('Allocated memory: ' || round(allocated_memory / 1048576, 1) || ' MB');
 18      END;
 19  BEGIN
 20      print_allocated_memory;
 21
 22      data.extend(item_count);
 23
 24      print_allocated_memory;
 25
 26      FOR i IN 1..item_count  LOOP
 27          data(i) := 1.00000000000000000000000000000000000011;
 28      END LOOP;
 29
 30      print_allocated_memory;
 31  END;
 32  /
Allocated memory: 3.5 MB
Allocated memory: 483.8 MB
Allocated memory: 483.8 MB

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.04
HUSQVIK@HQ_PDB_TCP>

You can experiment with NUMBER constraints and see that it makes no difference on memory allocation The memory is allocated before any value is actually set and it doesn't change after that. In the example one entry in the collection is approximately 48 bytes but I expect some significant overhead of collection entry itself.

Associative arrays and nested tables allocate the same space (so I expect the nested table internally to be implemented same as associative array which is B-tree), with VARRAY I got to 410 MB so it's slightly more efficient (and faster too).

Answer 2

but he doesn't seem to agree with me.

Show him a documentation of vsize function: http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions213.htm#i80071

VSIZE returns the number of bytes in the internal representation of expr. If expr is null, then this function returns null.

And simply prove him that 412 occupies 3 bytes, while -412 takes 4 bytes:

select vsize( 412), vsize( -412) from dual;
VSIZE(412)                             VSIZE(-412)
---------- ---------------------------------------
         3                                       4

Another test proves that @Husquick's answer is true:

select vsize( 0.00000000000000000000000000000000000011 ), 
       vsize( 1.00000000000000000000000000000000000011)
from dual;
VSIZE(0.0000000000000000000000000000000 VSIZE(1.0000000000000000000000000000000
--------------------------------------- ---------------------------------------
                                      2                                      21