Oracle
 sql >> Base de données >  >> RDS >> Oracle

Qui a inventé le terme nœud DIANA et comment a-t-il calculé que 6 000 000 LOC correspondent à environ 6 710 8864 (2**26) nœuds DIANA ?

Selon la documentation Oracle ,

PL/SQL est basé sur le langage de programmation Ada. PL/SQL utilise une variante de la notation intermédiaire descriptive pour Ada (DIANA), un langage intermédiaire structuré en arbre. Il est défini à l'aide d'une méta-notation appelée Interface Definition Language (IDL) .DIANA est utilisé en interne par les compilateurs et autres outils.

Au moment de la compilation, le code source PL/SQL est traduit en code m lisible par machine. La DIANA et le code m d'une procédure ou d'un package sont stockés dans la base de données. Au moment de l'exécution, ils sont chargés dans le pool de mémoire partagée. La DIANA est utilisée pour compiler des procédures dépendantes; le m-code est simplement exécuté.

Malheureusement, vous ne pouvez pas estimer le nombre de nœuds DIANA à partir de la taille analysée. Deux unités de programme avec la même taille analysée peuvent nécessiter respectivement 1 500 et 2 000 nœuds DIANA, car, par exemple, la deuxième unité contient des instructions SQL plus complexes.

Demandez à tom dit

Pour en savoir plus sur les calculs des nœuds DIANA, lisez ce livre "Ada-Europe '93 :12th Ada-Europe International Conference, "Ada Sans Frontieres", Paris, France, June 14-18, 1993. Proceedings"

La note d'assistance suivante couvre bien ce sujet...

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:         

Présentation

Cet article contient des informations sur les limitations de taille des packages PL/SQL. Lorsque les limites sont atteintes, vous recevez l'erreur suivante :

PLS-123 Program too large

Limites de taille sur les packages PL/SQL

Dans les versions antérieures à 8.1.3, les gros programmes provoquaient l'erreur PLS-123. Cela s'est produit en raison de véritables limites dans le compilateur; pas à la suite d'un bogue.

Lors de la compilation d'une unité PL/SQL, le compilateur construit un arbre d'analyse. La taille maximale d'une unité PL/SQL est déterminée par la taille de l'arbre d'analyse. Un nombre maximum de nœuds diana existe dans cet arbre.

Jusqu'à 7.3, vous pouviez avoir 2 * * 14 (16K) nœuds Diana, et de 8.0 à 8.1.3, 2 * * 15 (32K) nœuds Diana étaient autorisés. Avec 8.1.3, cette limite a été assouplie afin que vous puissiez désormais avoir 2 * * 26 (c'est-à-dire 64 Mo) nœuds diana dans cette arborescence pour les corps de package et de type.

Limites du code source

Bien qu'il n'y ait pas de moyen facile de traduire les limites en termes de lignes de code source, nous avons observé qu'il y avait environ 5 à 10 nœuds par ligne de code source. Avant la version 8.1.3, le compilateur pouvait compiler proprement jusqu'à environ 3 000 lignes de code.

À partir de la version 8.1.3, la limite a été assouplie pour les corps de package et les corps de type qui peuvent désormais contenir jusqu'à environ 6 000 000 de lignes de code.

Remarques :Cette nouvelle limite s'applique uniquement aux corps de package et aux corps de type. De plus, vous pouvez maintenant commencer à atteindre d'autres limites du compilateur avant d'atteindre cette limite particulière du compilateur.

En termes de taille de code source, supposons que les jetons (identifiants, opérateurs, fonctions, etc.) comportent en moyenne quatre caractères. Alors, le maximum serait :

   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

Il s'agit d'une estimation approximative. Si votre code comporte de nombreux espaces, de longs identifiants, etc., vous pouvez vous retrouver avec un code source plus grand que cela. Vous pouvez également vous retrouver avec un code source plus petit que cela si vos sources utilisent des identifiants très courts, etc.

Notez qu'il s'agit d'une unité de programme, les corps de package sont donc plus susceptibles de rencontrer cette limite.

Comment vérifier la taille actuelle d'un paquet

Pour vérifier la taille d'un package, le numéro associé le plus proche que vous pouvez utiliser est PARSED_SIZE dans la vue du dictionnaire de données USER_OBJECT_SIZE. Cette valeur fournit la taille des octets entrants DIANA tels qu'ils sont stockés dans les tables SYS.IDL_xxx$ et N'EST PAS la taille dans le pool partagé.

La taille de la partie DIANA du code PL/SQL (utilisée lors de la compilation) est BEAUCOUP plus importante dans le pool partagé que dans la table système.

Par exemple, vous pouvez commencer à rencontrer des problèmes avec une limite de 64 Ko lorsque PARSED_SIZE dans USER_OBJECT_SIZE n'est pas supérieur à 50 Ko.

Pour un package, la taille analysée ou la taille de DIANA n'a de sens que pour l'objet entier, pas séparément pour la spécification et le corps.

Si vous sélectionnez parsed_size pour un package, vous recevez des tailles de source et de code distinctes pour la spécification et le corps, mais uniquement une taille analysée significative pour l'ensemble de l'objet qui est affiché sur la ligne pour la spécification du package. Un 0 est sorti pour le parsed_size sur la ligne du corps du package.

L'exemple suivant illustre ce comportement :

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 stocke à la fois DIANA et MCODE dans la base de données. MCODE est le code réel qui s'exécute, tandis que DIANA pour une unité de bibliothèque particulière X contient les informations nécessaires pour compiler les procédures à l'aide de l'unité de bibliothèque X.

Voici plusieurs notes :

a) DIANA est représentée dans IDL. La version linéaire d'IDL est stockée sur disque. L'arbre d'analyse réel est construit et stocké dans le pool partagé. C'est pourquoi la taille de DIANA dans le pool partagé est généralement plus grande que sur le disque.

b) DIANA pour les procédures appelées est requise dans le pool partagé uniquement lorsque vous créez des procédures. Dans les systèmes de production, il n'y a pas besoin de DIANA dans le pool partagé (mais uniquement pour le MCODE).

c) À partir de la version 7.2, la DIANA pour les corps de package est jetée, non utilisée et non stockée dans la base de données. C'est pourquoi le PARSED_SIZE (c'est-à-dire la taille de DIANA) de PACKAGE BODIES est 0.

Un package est stocké dans DIANA dans la base de données, tout comme une procédure. Un paquetage peut cependant être utilisé pour briser la chaîne de dépendance, peut-être pour faire disparaître cela. Je suis convaincu que le code ALLproduction (réel) devrait être dans un package, jamais dans une procédure ou une fonction autonome.