sql >> Database >  >> RDS >> Oracle

Wie bedacht de term DIANA-knooppunt en hoe kwamen ze erachter dat 6.000.000 LOC ongeveer 67108864 (2**26) DIANA-knooppunten is?

Volgens Oracle-documentatie ,

PL/SQL is gebaseerd op de programmeertaal Ada.PL/SQL gebruikt een variant van Descriptive Intermediate Attributed Notation for Ada (DIANA), een boomgestructureerde tussentaal. Het wordt gedefinieerd met behulp van een metanotatie genaamd Interface Definition Language (IDL) .DIANA wordt intern gebruikt door compilers en andere tools.

Tijdens het compileren wordt de PL/SQL-broncode vertaald in machineleesbare m-code. Zowel de DIANA- als de m-code voor een procedure of pakket worden in de database opgeslagen. Tijdens runtime worden ze in de gemeenschappelijke geheugenpool geladen. De DIANA wordt gebruikt om afhankelijke procedures samen te stellen; de m-code wordt gewoon uitgevoerd.

Helaas kunt u het aantal DIANA-knooppunten niet schatten op basis van de geparseerde grootte. Twee programma-eenheden met dezelfde geparseerde grootte kunnen 1500 en 2000 DIANA-knooppunten nodig hebben, respectievelijk omdat de tweede eenheid bijvoorbeeld complexere SQL-instructies bevat.

Vraag het aan Tom zegt

Lees dit boek voor meer informatie over DIANA-knooppuntberekeningen "Ada-Europe '93:12th Ada-Europe International Conference, "Ada Sans Frontieres", Parijs, Frankrijk, 14-18 juni 1993. Proceedings"

De volgende ondersteuningsnota behandelt dit onderwerp goed...

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:         

Overzicht

Dit artikel bevat informatie over PL/SQL-pakketgroottebeperkingen. Wanneer de limieten zijn bereikt, krijgt u de volgende foutmelding:

PLS-123 Program too large

Groottebeperkingen op PL/SQL-pakketten

In releases vóór 8.1.3 resulteerden grote programma's in de PLS-123-fout. Dit gebeurde vanwege echte limieten in de compiler; niet als gevolg van een bug.

Bij het compileren van een PL/SQL-eenheid bouwt de compiler een ontledingsboom. De maximale grootte van een aPL/SQL-eenheid wordt bepaald door de grootte van de ontledingsboom. Er bestaat een maximum aantal diana-knooppunten in deze boom.

Tot 7.3 kon je 2 * * 14 (16K) diana-knooppunten hebben, en van 8.0 tot 8.1.3 waren 2 * * 15 (32K)diana-knooppunten toegestaan. Met 8.1.3 is deze limiet versoepeld, zodat u nu 2 * * 26 (d.w.z. 64M) diana-knooppunten in deze structuur kunt hebben voor pakket- en typelichamen.

Broncodelimieten

Hoewel er geen gemakkelijke manier is om de limieten te vertalen in termen van regels broncode, is het onze observatie dat er ongeveer 5 tot 10 knooppunten per regel broncode zijn. Vóór 8.1.3 kon de compiler tot ongeveer 3.000 regels code netjes compileren.

Met ingang van 8.1.3 werd de limiet versoepeld voor de body's van pakketten en type body's, die nu ongeveer 6.000.000 regels code kunnen bevatten.

Opmerkingen:Deze nieuwe limiet is alleen van toepassing op colli's en type body's. U kunt nu ook andere compilerlimieten bereiken voordat u deze specifieke compilerlimiet bereikt.

Wat betreft de grootte van de broncode, neem aan dat tokens (identifiers, operators, functies, enz.) gemiddeld vier tekens lang zijn. Dan zou het maximum zijn:

   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

Dit is een ruwe schatting. Als uw code veel spaties, lange identifiers, enz. heeft, kan het zijn dat u een broncode krijgt die groter is dan dit. U kunt ook eindigen met een kleinere broncode als uw bronnen zeer korte identifiers gebruiken, enz.

Merk op dat dit per programma-eenheid is, dus pakketinstanties zullen deze limiet het meest waarschijnlijk tegenkomen.

Hoe u de huidige grootte van een pakket kunt controleren

Om de grootte van een pakket te controleren, is het dichtstbijzijnde gerelateerde nummer dat u kunt gebruiken PARSED_SIZE in de datadictionary-weergave USER_OBJECT_SIZE. Deze waarde geeft de grootte van de DIANA-inbytes zoals opgeslagen in de SYS.IDL_xxx$-tabellen en is NIET de grootte in de gedeelde pool.

De grootte van het DIANA-gedeelte van de PL/SQL-code (gebruikt tijdens compilatie) is VEEL groter in de gedeelde pool dan in de systeemtabel.

U kunt bijvoorbeeld problemen krijgen met een limiet van 64K wanneer de PARSED_SIZE inUSER_OBJECT_SIZE niet meer dan 50K is.

Voor een pakket is de geparseerde grootte of grootte van de DIANA alleen zinvol voor het hele object, niet afzonderlijk voor de specificatie en de hoofdtekst.

Als u parsed_size selecteert voor een pakket, ontvangt u afzonderlijke bron- en codegroottes voor de specificatie en de hoofdtekst, maar alleen een betekenisvolle geparseerde grootte voor het hele object dat wordt uitgevoerd op de regel voor de pakketspecificatie. Er wordt een 0 uitgevoerd voor de parsed_size op de regel voor de hoofdtekst van het pakket.

Het volgende voorbeeld demonstreert dit gedrag:

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 slaat zowel DIANA als MCODE op in de database. MCODE is de eigenlijke code die wordt uitgevoerd, terwijl DIANA voor een bepaalde bibliotheekeenheid X informatie bevat die nodig is om procedures te compileren met bibliotheekeenheid X.

Hier volgen enkele opmerkingen:

a) DIANA is vertegenwoordigd in IDL. De lineaire versie van IDL wordt op schijf opgeslagen. De werkelijke ontledingsboom wordt opgebouwd en opgeslagen in het gedeelde zwembad. Dit is de reden waarom de grootte van DIANA in de gedeelde pool meestal groter is dan op schijf.

b) DIANA voor aangeroepen procedures is alleen vereist in de gedeelde pool wanneer u procedures aanmaakt. In productiesystemen is DIANA niet nodig in de gedeelde pool (maar alleen voor de MCODE).

c) Vanaf release 7.2 wordt de DIANA voor de inhoud van pakketten weggegooid, niet gebruikt en niet opgeslagen in de database. Dit is de reden waarom de PARSED_SIZE (d.w.z. de grootte van DIANA) van PACKAGE BODIES 0 is.

Een pakket wordt in DIANA opgeslagen in de database, net als een procedure. Een pakket kan echter worden gebruikt om de afhankelijkheidsketen te doorbreken, waardoor dit misschien verdwijnt. Ik ben van mening dat ALLproduction (echte) code in een pakket moet zitten, nooit in een op zichzelf staande procedure of functie.




  1. Selecteer zoekopdracht naar resultaten alle 12 maanden, zelfs als er geen gegevens bestaan

  2. Converteer Google map v2 naar google map v3

  3. MySQL C++ Connector onopgelost extern symbool _get_driver_instance

  4. Hoe maak ik een stap in mijn SQL Server Agent Job die mijn SSIS-pakket zal uitvoeren?