Enligt Oracle-dokumentation ,
PL/SQL är baserat på programmeringsspråket Ada.PL/SQL använder en variant av Descriptive Intermediate Attributed Notation for Ada (DIANA), ett trädstrukturerat mellanspråk. Det definieras med en meta-notation som kallas Interface Definition Language (IDL) .DIANA används internt av kompilatorer och andra verktyg.
Vid kompilering översätts PL/SQL-källkoden till maskinläsbar m-kod. Både DIANA och m-koden för en procedur eller ett paket lagras i databasen. Vid körning laddas de in i den delade minnespoolen. DIANA används för att sammanställa beroende procedurer; m-koden exekveras helt enkelt.
Tyvärr kan du inte uppskatta antalet DIANA-noder från den analyserade storleken. Två programenheter med samma analyserade storlek kan kräva 1500 respektive 2000 DIANA-noder, eftersom till exempel den andra enheten innehåller mer komplexa SQL-satser.
Mer om DIANA nodberäkningar, läs den här boken "Ada-Europe '93:12th Ada-Europe International Conference, "Ada Sans Frontieres", Paris, Frankrike, 14-18 juni 1993. Proceedings"
Följande supportanteckning täcker detta ämne väl...
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:
Översikt
Den här artikeln innehåller information om begränsningar för PL/SQL-paketstorlek. När gränserna nås får du följande felmeddelande:
PLS-123 Program too large
Storleksbegränsningar på PL/SQL-paket
I utgåvor före 8.1.3 resulterade stora program i PLS-123-felet. Detta inträffade på grund av äkta begränsningar i kompilatorn; inte som ett resultat av en bugg.
Vid kompilering av en PL/SQL-enhet bygger kompilatorn ett analysträd. Den maximala storleken på aPL/SQL-enheten bestäms av storleken på analysträdet. Ett maximalt antal diana-noder finns i detta träd.
Upp till 7.3 kunde du ha 2 * * 14 (16K) diananoder, och från 8.0 till 8.1.3 var 2 * * 15 (32K) diananoder tillåtna. Med 8.1.3 har denna gräns släppts så att du nu kan ha 2 * * 26 (dvs. 64M) diananoder i detta träd för paket- och typkroppar.
Källkodsgränser
Även om det inte finns något enkelt sätt att översätta gränserna i termer av rader med källkod, har det varit vår observation att det har funnits cirka 5 till 10 noder per rad med källkod. Före 8.1.3 kunde kompilatorn rent kompilera upp till cirka 3 000 rader kod.
Från och med 8.1.3 lättades gränsen upp för paketkroppar och typkroppar som nu kan ha ungefär upp till cirka 6 000 000 rader kod.
Anmärkningar:Denna nya gräns gäller endast för paketkroppar och typkroppar. Dessutom kan du nu börja nå några andra kompilatorgränser innan du når denna speciella kompilatorgräns.
När det gäller källkodsstorlek, antag att tokens (identifierare, operatorer, funktioner, etc.), är i genomsnitt fyra tecken långa. Då skulle det maximala vara:
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
Detta är en grov uppskattning. Om din kod har många mellanslag, långa identifierare, etc., kan du få en källkod som är större än så här. Du kan också få källkod som är mindre än så här om dina källor använder mycket korta identifierare, etc.
Observera att detta är per programenhet, så paketkroppar kommer troligen att stöta på denna gräns.
Hur man kontrollerar den aktuella storleken på ett paket
För att kontrollera storleken på ett paket är det närmaste relaterade numret du kan använda PARSED_SIZE i datalexikonvyn USER_OBJECT_SIZE. Det här värdet anger storleken på DIANA-inbyte som lagras i SYS.IDL_xxx$-tabellerna och är INTE storleken i den delade poolen.
Storleken på DIANA-delen av PL/SQL-koden (används under kompilering) är MYCKET större i den delade poolen än den är i systemtabellen.
Till exempel kan du börja uppleva problem med en gräns på 64K när PARSED_SIZE iUSER_OBJECT_SIZE inte är mer än 50K.
För ett paket är den analyserade storleken eller storleken på DIANA endast meningsfull för hela objektet, inte separat för specifikationen och kroppen.
Om du väljer parsed_size för ett paket får du separata käll- och kodstorlekar för specifikationen och texten, men bara en meningsfull analyserad storlek för hela objektet som matas ut på raden för paketspecifikationen. En 0 matas ut för parsed_size på raden för paketets kropp.
Följande exempel visar detta beteende:
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 lagrar både DIANA och MCODE i databasen. MCODE är den faktiska koden som körs, medan DIANA för en viss biblioteksenhet X innehåller information som behövs för att kompilera procedurer med hjälp av biblioteksenhet X.
Följande är flera anmärkningar:
a) DIANA är representerat i IDL. Den linjära versionen av IDL lagras på disk. Det faktiska analysträdet byggs upp och lagras i den gemensamma poolen. Det är därför storleken på DIANA i den delade poolen vanligtvis är större än på disken.
b) DIANA för anropade procedurer krävs i den delade poolen endast när du skapar procedurer. I produktionssystem finns det inget behov av DIANA i den delade poolen (men bara för MCODE).
c) Från och med version 7.2 slängs DIANA för paketkroppar, används inte och lagras inte i databasen. Det är därför PARSED_SIZE (dvs. storleken på DIANA) för PACKAGE BODIES är 0.
Ett paket lagras i DIANA i databasen, precis som en procedur. Ett paket kan dock användas för att bryta beroendekedjan, vilket kanske gör att detta försvinner. Det är min övertygelse att ALLproduction (riktig) kod ska finnas i ett paket, aldrig i en fristående procedur eller funktion.