Oracle
 sql >> Database >  >> RDS >> Oracle

Chi ha inventato il termine nodo DIANA e come hanno calcolato che 6.000.000 LOC sono circa 67108864 (2**26) nodi DIANA?

Come da Documentazione Oracle ,

PL/SQL è basato sul linguaggio di programmazione Ada.PL/SQL utilizza una variante di Descriptive Intermediate Attributed Notation for Ada (DIANA), un linguaggio intermedio strutturato ad albero. È definito utilizzando una meta-notazione chiamata Interface Definition Language (IDL) .DIANA viene utilizzato internamente da compilatori e altri strumenti.

In fase di compilazione, il codice sorgente PL/SQL viene tradotto in codice m leggibile dalla macchina. Sia il codice DIANA che il codice m per una procedura o un pacchetto sono archiviati nel database. In fase di esecuzione, vengono caricati nel pool di memoria condivisa. Il DIANA viene utilizzato per compilare procedure dipendenti; l'm-code viene semplicemente eseguito.

Sfortunatamente, non è possibile stimare il numero di nodi DIANA dalla dimensione analizzata. Due unità di programma con la stessa dimensione analizzata potrebbero richiedere 1500 e 2000 nodi DIANA, rispettivamente perché, ad esempio, la seconda unità contiene istruzioni SQL più complesse.

Chiedi a tom dice

Per ulteriori informazioni sui calcoli dei nodi DIANA, leggi questo libro "Ada-Europe '93:12th Ada-Europe International Conference, "Ada Sans Frontieres", Parigi, Francia, 14-18 giugno 1993. Atti"

La seguente nota di supporto tratta bene questo argomento...

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:         

Panoramica

Questo articolo contiene informazioni sulle limitazioni delle dimensioni del pacchetto PL/SQL. Quando i limiti vengono raggiunti, viene visualizzato il seguente messaggio di errore:

PLS-123 Program too large

Limiti di dimensione sui pacchetti PL/SQL

Nelle versioni precedenti alla 8.1.3, i programmi di grandi dimensioni generavano l'errore PLS-123. Ciò si è verificato a causa di limiti autentici nel compilatore; non come risultato di un bug.

Quando si compila un'unità PL/SQL, il compilatore crea un albero di analisi. La dimensione massima dell'unità aPL/SQL è determinata dalla dimensione dell'albero di analisi. In questo albero esiste un numero massimo di nodi diana.

Fino a 7.3, potresti avere 2 * * 14 (16K) nodi diana e da 8.0 a 8.1.3 erano consentiti 2 * * 15 (32K) nodi diana. Con 8.1.3, questo limite è stato allentato in modo che ora puoi avere 2 * * 26 (cioè, 64M) nodi diana in questo albero per i pacchetti e i corpi dei tipi.

Limiti del codice sorgente

Sebbene non ci sia un modo semplice per tradurre i limiti in termini di righe di codice sorgente, è stata la nostra osservazione che ci sono stati circa 5-10 nodi per riga di codice sorgente. Prima della 8.1.3, il compilatore poteva compilare in modo pulito fino a circa 3.000 righe di codice.

A partire da 8.1.3, il limite è stato allentato per i corpi dei pacchetti e dei tipi che ora possono avere fino a circa 6.000.000 di righe di codice.

Note:questo nuovo limite si applica solo ai corpi pacchetto e ai corpi tipo. Inoltre, ora puoi iniziare a raggiungere altri limiti del compilatore prima di raggiungere questo particolare limite del compilatore.

In termini di dimensione del codice sorgente, si supponga che i token (identificatori, operatori, funzioni, ecc.) siano lunghi in media quattro caratteri. Quindi, il massimo sarebbe:

   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

Questa è una stima approssimativa. Se il tuo codice ha molti spazi, identificatori lunghi, ecc., potresti ritrovarti con un codice sorgente più grande di questo. Potresti anche ritrovarti con un codice sorgente più piccolo di questo se le tue fonti utilizzano identificatori molto brevi, ecc.

Si noti che questo è per unità di programma, quindi è più probabile che i corpi dei pacchetti incontrino questo limite.

Come verificare la dimensione attuale di un pacco

Per controllare le dimensioni di un pacchetto, il numero correlato più vicino che puoi utilizzare è PARSED_SIZE nella vista del dizionario dati USER_OBJECT_SIZE. Questo valore fornisce la dimensione degli inbyte DIANA come memorizzati nelle tabelle SYS.IDL_xxx$ e NON è la dimensione nel pool condiviso.

La dimensione della porzione DIANA del codice PL/SQL (usata durante la compilazione) è MOLTO maggiore nel pool condiviso di quanto non lo sia nella tabella di sistema.

Ad esempio, potresti iniziare a riscontrare problemi con un limite di 64 KB quando PARSED_SIZE inUSER_OBJECT_SIZE non supera i 50 KB.

Per un pacchetto, la dimensione analizzata o la dimensione del DIANA ha senso solo per l'intero oggetto, non separatamente per la specifica e il corpo.

Se si seleziona parsed_size per un pacchetto, si ottengono sorgenti separate e dimensioni del codice per la specifica e il corpo, ma solo una dimensione analizzata significativa per l'intero oggetto che viene emesso sulla riga per la specifica del pacchetto. Viene emesso uno 0 per parsed_size sulla riga per il corpo del pacchetto.

L'esempio seguente mostra questo comportamento:

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 memorizza sia DIANA che MCODE nel database. MCODE è il codice effettivo che viene eseguito, mentre DIANA per una particolare unità di libreria X contiene le informazioni necessarie per compilare le procedure utilizzando l'unità di libreria X.

Di seguito sono riportate diverse note:

a) DIANA è rappresentata in IDL. La versione lineare di IDL è memorizzata su disco. L'albero di analisi effettivo viene creato e archiviato nel pool condiviso. Questo è il motivo per cui la dimensione di DIANA nel pool condiviso è in genere maggiore di quella su disco.

b) DIANA per le procedure chiamate è richiesto nel pool condiviso solo quando si creano procedure. Nei sistemi di produzione non c'è bisogno di DIANA nel pool condiviso (ma solo per l'MCODE).

c) A partire dalla release 7.2, il DIANA per i corpi dei colli viene gettato via, non utilizzato e non viene archiviato nel database. Questo è il motivo per cui PARSED_SIZE (cioè la dimensione di DIANA) di PACKAGE BODIES è 0.

Un pacchetto viene memorizzato in DIANA nel database, proprio come una procedura. Tuttavia, un pacchetto può essere utilizzato per interrompere la catena delle dipendenze, magari facendola sparire. Sono convinto che TUTTO il codice di produzione (reale) debba essere contenuto in un pacchetto, mai in una procedura o funzione autonoma.