DIANAノードという用語を思いついたのは誰ですか。6,000,000LOCが約67108864（2 ** 26）DIANAノードであるとどのように計算しましたか。

Oracleドキュメントによる、

PL / SQLは、プログラミング言語Adaに基づいています。PL/ SQLは、ツリー構造の中間言語であるAdaの記述的中間属性表記（DIANA）のバリアントを使用します。これは、インタフェース定義言語（IDL）と呼ばれるメタ表記を使用して定義されます。 .DIANAは、コンパイラやその他のツールによって内部的に使用されます。

コンパイル時に、PL / SQLソースコードはマシン可読のmコードに変換されます。プロシージャまたはパッケージのDIANAとmコードの両方がデータベースに格納されます。実行時に、それらは共有メモリプールにロードされます。 DIANAは、依存するプロシージャをコンパイルするために使用されます。 mコードは単純に実行されます。

残念ながら、解析されたサイズからDIANAノードの数を見積もることはできません。たとえば、2番目のユニットにはより複雑なSQLステートメントが含まれているため、解析されたサイズが同じ2つのプログラムユニットには、それぞれ1500と2000のDIANAノードが必要になる場合があります。

トムに聞いてください>

DIANAノードの計算の詳細については、この本をお読みください "Ada-Europe '93：12th Ada-Europe International Conference、" Ada Sans Frontieres "、Paris、France、June 14-18、1993. Proceedings"

次のサポートノートは、このトピックを十分にカバーしています...

Article-ID:         <Note:62603.1>
Folder:             PLSQL
Topic:              General Information Articles
Title:              'PLS-123 Program too Large' - Size Limitations on PLSQL 
                    Packages
Document-Type:      BULLETIN
Impact:             MEDIUM
Skill-Level:        NOVICE
Server-Version:     07 to 08
Updated-Date:       13-JUN-2000 17:41:01
References:

概要

この記事には、PL/SQLパッケージのサイズ制限に関する情報が含まれています。制限に達すると、次のエラーが発生します。

PLS-123 Program too large

PL/SQLパッケージのサイズ制限

8.1.3より前のリリースでは、大きなプログラムでPLS-123エラーが発生していました。これは、コンパイラの真の制限が原因で発生しました。バグの結果ではありません。

PL / SQLユニットをコンパイルするとき、コンパイラは解析ツリーを構築します。 aPL / SQLユニットの最大サイズは、解析ツリーのサイズによって決まります。このツリーには最大数のダイアナノードが存在します。

7.3までは、2 * * 14（16K）のダイアナノードを持つことができ、8.0から8.1.3までは、2 * * 15（32K）のダイアナノードが許可されていました。 8.1.3では、この制限が緩和され、パッケージとタイプのボディ用にこのツリーに2 * * 26（つまり、64M）のダイアナノードを含めることができるようになりました。

ソースコードの制限

ソースコードの行に関して制限を変換する簡単な方法はありませんが、ソースコードの行ごとに約5〜10個のノードがあることがわかりました。 8.1.3より前は、コンパイラは最大約3,000行のコードをクリーンにコンパイルできました。

8.1.3から、パッケージ本体とタイプ本体の制限が緩和され、最大で約6,000,000行のコードを含めることができるようになりました。

注：この新しい制限は、パッケージ本体とタイプ本体にのみ適用されます。また、この特定のコンパイラ制限に達する前に、他のコンパイラ制限に達し始める可能性があります。

ソースコードのサイズに関しては、トークン（識別子、演算子、関数など）が平均4文字の長さであると想定します。その場合、最大値は次のようになります。

   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

これは概算です。コードに多くのスペースや長い識別子などがある場合、これよりも大きいソースコードになってしまう可能性があります。ソースが非常に短い識別子などを使用している場合は、ソースコードがこれよりも小さくなる可能性もあります。

これはプログラム単位ごとであるため、パッケージ本体でこの制限が発生する可能性が高いことに注意してください。

パッケージの現在のサイズを確認する方法

パッケージのサイズを確認するために使用できる最も近い関連番号は、データディクショナリビューUSER_OBJECT_SIZEのPARSED_SIZEです。この値は、SYS.IDL_xxx $テーブルに格納されているDIANAのサイズをバイト単位で提供し、共有プールのサイズではありません。

PL / SQLコードのDIANA部分（コンパイル時に使用される）のサイズは、システム表よりも共有プールの方がはるかに大きくなります。

たとえば、USER_OBJECT_SIZEのPARSED_SIZEが50K以下の場合、64Kの制限で問題が発生し始める可能性があります。

パッケージの場合、解析されたサイズまたはDIANAのサイズは、仕様と本体に個別にではなく、オブジェクト全体にのみ意味があります。

パッケージにparsed_sizeを選択すると、仕様と本体に別々のソースサイズとコードサイズが表示されますが、パッケージ仕様の行に出力されるオブジェクト全体の意味のある解析サイズのみが返されます。パッケージ本体の行のparsed_sizeに0が出力されます。

次の例は、この動作を示しています。

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';  

  .....

Oracleは、DIANAとMCODEの両方をデータベースに格納します。 MCODEは実行される実際のコードですが、特定のライブラリユニットXのDIANAには、ライブラリユニットXを使用してプロシージャをコンパイルするために必要な情報が含まれています。

以下はいくつかの注意事項です：

a）DIANAはIDLで表されます。 IDLの線形バージョンはディスクに保存されます。実際の解析ツリーが構築され、共有プールに格納されます。これが、共有プールのDIANAのサイズが通常ディスクよりも大きい理由です。

b）呼び出されたプロシージャのDIANAは、プロシージャを作成する場合にのみ共有プールで必要になります。実動システムでは、共有プールにDIANAは必要ありません（ただし、MCODEのみ）。

c）リリース7.2以降、パッケージ本体のDIANAは破棄され、使用されず、データベースに保存されません。これが、PACKAGE BODIESのPARSED_SIZE（つまり、DIANAのサイズ）が0である理由です。

パッケージは、プロシージャと同じように、データベースのDIANAに保存されます。パッケージを使用して依存関係の連鎖を断ち切ることができますが、おそらくこれはなくなります。 ALLproduction（実際の）コードは、スタンドアロンのプロシージャや関数ではなく、パッケージに含める必要があると私は信じています。