Some Oracle Limitations Version ~8i

Item Limit
Various
Database Size 512 Petabytes
Users and Roles 2 147 483 638
Tables, per database Unlimited
SQL Statement Length 64K
Nested queries 255
No of experssions in a list (IN clause)
e.g. SELECT * FROM table1 WHERE col1 IN ('1', '2', ...,'1000')
1000
No arguments in decode function 255
No of Tablespaces 64K
No of Datafiles per Tablespace 1022
No of Partitions Per Table 64K
No of columns per Table 1000
Indexes per table Unlimited
No of columns per B-Tree index 32
No of columns per Bitmap index 30
No of columns in Primary or Unique Key 32
Constraints per column Unlimited
Size of trigger 32K
No of cascading triggers 32 Note1
Size of SGA OS dependent, 2-4 G for 32-bit O/S, more than 4 G for 64-bit O/S
Built-in-datatypes (NOT for PL/SQL)
Char, NChar, Raw 2000
Varchar2, NVarchar2 4000
Long, Long Raw 2G
Number 38
BLOB,CLOB,NCLOB, BFile 4G
Date from January 1, 4712 BCE to December 31, 4712 CE ("A.D.")
PL/SQL Compiler Limits Note2
Bind variables passed to a program unit 32K
Exception handlers in a program unit 64K
Fields in a record 64K
Levels of block nesting 255
Levels of record nesting 32
Levels of subquery nesting 254
Levels of label nesting 98
Magnitude of a BINARY_INTEGER value 2G
Magnitude of a PLS_INTEGER value 2G
objects referenced by a program unit 64K
parameters passed to an explicit cursor 64K
parameters passed to a function or procedure 64K
precision of a FLOAT value (binary digits) 126
precision of a NUMBER value (decimal digits) 38
precision of a REAL value (binary digits) 63
size of an identifier (characters) 30
size of a string literal (bytes) 32K
size of a dynamic statement (EXECUTE IMMEDIATE) (bytes) 32K
size of a CHAR, NCHAR value (bytes) 32K
size of a LONG, LONG RAW value (bytes) 32K - 7
size of a RAW value (bytes) 32K
size of a VARCHAR2, NVARCHAR2 value (bytes) 32K
size of a BIFLE, BLOB, CLOB, NCLOB, value (bytes) 4G
 Size Limitations on PL/SQL Packages
 -----------------------------------
 In releases prior to 8.1.3, large programs resulted in the PLS-123 error.
 This occurred because of genuine limits in the compiler; not as a result of a bug.

 When compiling a PL/SQL unit, the compiler builds a parse tree.  The 
 maximum size of a PL/SQL unit is determined by the size of the parse tree.
 Source Code Limits
 ------------------
 While there is no easy way to translate the limits in terms of lines of 
 source code, it has been our observation that there have been approximately
 5 to 10 nodes per line of source code.  Prior to 8.1.3, the compiler could 
 cleanly compile up to about 3,000 lines of code.
   
 Starting with 8.1.3, the limit was relaxed for package bodies and type bodies 
 which can now have approximately up to about 6,000,000 lines of code.  

    Notes:  This new limit applies only to package bodies and type bodies.  
            Also, you may now start hitting some other compiler limits 
            before you hit this particular compiler limit.

 In terms of source code size, assume that tokens (identifiers, operators, 
 functions, etc.), are on average four characters long.  Then, the maximum 
 would be:

    Up to 7.3:         4*(2**14)=64K
    From 8.0 to 8.1.3: 4*(2**15)=128K
    With 8.1.3:        4*(2**25)=256M

 This is a rough estimate.  If your code has many spaces, long identifiers, 
 etc., you may end up with source code larger than this.  You may also end 
 up with source code smaller than this if your sources use very short 
 identifiers, etc.

 Note that this is per program unit, so package bodies are most likely to
 encounter this limit. 


 How to Check the Current Size of a Package
 ------------------------------------------

 To check the size of a package, the closest related number you can use is 
 PARSED_SIZE in the data dictionary view USER_OBJECT_SIZE.  This value 
 provides the size of the DIANA in bytes as stored in the SYS.IDL_xxx$ tables 
 and is NOT the size in the shared pool.  

 The size of the DIANA portion of PL/SQL code (used during compilation) is 
 MUCH bigger in the shared pool than it is in the system table.  
  
 For example, you may begin experiencing problems with a 64K limit when the 
 PARSED_SIZE in USER_OBJECT_SIZE is no more than 50K.  
  
 For a package, the parsed size or size of the DIANA makes sense only  
 for the whole object, not separately for the specification and body.  
  
 If you select parsed_size for a package, you receive separate source and 
 code sizes for the specification and body, but only a meaningful parsed size 
 for the whole object which is output on the line for the package 
 specification.  A 0 is output for the parsed_size on the line for the package 
 body.  
  
 The following example demonstrates this behaviour:  
   
 CREATE OR REPLACE PACKAGE example AS  
   PROCEDURE dummy1;  
 END example;  
 /  
 CREATE OR REPLACE PACKAGE BODY example AS  
   PROCEDURE dummy1 IS  
   BEGIN  
     NULL;  
   END;  
 END;  
 /  
   
 SQL> start t1.sql;  
   
 Package created.  
   
   
 Package body created.  
   
 SQL> select parsed_size from user_object_size where name='EXAMPLE';  
   
   
 PARSED_SIZE  
 -----------  
         185  
           0  
   
  
 SQL> select * from user_object_size where name='EXAMPLE';  
   
   
 NAME                           TYPE         SOURCE_SIZE PARSED_SIZE CODE_SIZE  
 ------------------------------ ------------ ----------- ----------- ----------  
 ERROR_SIZE  
 ----------  
 EXAMPLE                        PACKAGE               51         185 62  
          0  
   
 EXAMPLE                        PACKAGE BODY          70           0 80  
          0 
 
 Oracle stores both DIANA and MCODE in the database.  MCODE is the actual code  
 that runs, while DIANA for a particular library unit X contains information
 that is needed to compile procedures using library unit X.  
 The following are several notes:  
   
 a) DIANA is represented in IDL.  The linear version of IDL is stored on disk.  
    The actual parse tree is built up and stored in the shared pool. This
    is why the size of DIANA in the shared pool is typically larger than on 
    disk.   
   
 b) DIANA for called procedures is required in the shared pool only when you

    create procedures.  In production systems, there is no need for DIANA  
    in the shared pool (but only for the MCODE). 
    
 c) Starting with release 7.2, the DIANA for package bodies is thrown away,
    not used, and not stored in the database.  This is why the PARSED_SIZE 
    (i.e. size of DIANA) of PACKAGE BODIES is 0.   
   
 --> Therefore, large procedures and functions should always be defined within  
 packages! 
  

Note1:
Someone said this number is 255. I could not find it in a short time in Oracle docs so I decided to test this limitation myself. I created similar tables table0..table300 with one number column and similar triggers that insert a value in the next table. And the result was...
Error message ORA-00036: maximum number of recursive SQL levels (50) exceeded. So, as you can see the real number is 50.
I tested it on 8.0.3, 8.1.6 and 8.1.7 with the same results.
However in the real life I usually didn't need more than 2 or 3, so don't worry. And at last I found that it is O/S DEPENDENT, usually 32.

Note2:
From PL/SQL User's Guide and Reference Release 8.1.6