2011-02-10 6 views
9

Durante la compilazione di un pacchetto, mi sono imbattuto in un messaggio di errore:PLS-00123: programma troppo grande (nodi Diana) durante il tentativo di compilare un pacchetto

Error: PLS-00123: program too large (Diana nodes) 
Line: 1 

Il pacchetto in questione ha circa 1k linee (spec) + 13k linee nel corpo. Mentre la ricerca su questo, mi sono imbattuto in this Ask Tom question

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

Fino a 7,3, si potrebbe avere 2**14 (16K) nodi Diana, e da 8.0 a 8.1.3, nodi 2**15 (32K) diana erano ammessi. Con 8.1.3, questo limite è stato rilassato in modo che ora è possibile avere i nodi diana 2**26 (ovvero 64 M) in questo albero per corpi di tipo e pacchetto.

Mentre non v'è alcun modo semplice per tradurre i limiti in termini di linee del codice sorgente, è stato il nostro osservazione che ci sono stati di circa 5 a 10 nodi per linea del 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 era rilassato per i corpi dei pacchetti e digitare corpi che ora possono avere circa fino a circa 6.000.000 di righe di codice .

Questa è una stima approssimativa. Se il tuo codice ha molti spazi, lunghi identificatori , ecc., Potresti finire con con codice sorgente più grande di questo.

Ora, anche se si prende in considerazione l'ultimo elenco su molti spazi & grandi identificatori, penso che sia ragionevole concludere che non c'è dove chiudere i limiti di cui sopra.

ulteriormente più,

Come controllare la dimensione attuale di un pacchetto:

Per controllare la dimensione di un pacchetto, il numero più vicino correlati è possibile utilizzare è PARSED_SIZE nel dizionario dei dati visualizza USER_OBJECT_SIZE. Questo valore fornisce le dimensioni del DIANA nei byte come memorizzato nelle tabelle e NON è la dimensione nel pool condiviso .

[...]

Ad esempio, è possibile iniziare a problemi vivendo con un limite di 64 KB quando il PARSED_SIZE in USER_OBJECT_SIZE è non più di 50K.

Interrogare questa vista dà un risultato di 48929 - quindi presumo che sia giusto dimensionare è 47k?

La parte strana è, recuperare lo stesso oggetto da un altro schema ed eseguirlo nell'area sto riscontrando problemi nella compilazione riuscita.

Quindi perché questa particolare area causa problemi?

+1

So che si tratta di un campo lungo, ma di fronte al problema, ho bisogno di chiedere: le tue linee sono molto, molto grandi? –

+1

Non sono molto, molto molto grandi – Sathya

risposta

5

fa il programma si compila il codice con le informazioni di debug aggiuntivo? Apparentemente fa la differenza illustrata su this forum post.

Il problema quando si fa una compilazione per di debug è il codice in più che viene aggiunto in per il debug.

Si può cercare queste query per vedere:

ALTER PACKAGE debug COMPILE; 
SELECT type, source_size, parsed_size, code_size 
FROM user_object_size 
WHERE name = 'DEBUG'; 

ALTER PACKAGE debug COMPILE DEBUG; 
SELECT type, source_size, parsed_size, code_size 
FROM user_object_size 
WHERE name = 'DEBUG'; 

osservare le differenze nel code_size quando si compila per il debug.

Se si sta compilando con DEBUG, provare a compilare in modo normale in modo che non generi codice aggiuntivo in grado di generare il proprio errore.

+0

+1 Grazie per avermi indirizzato verso questo link. – Sathya

Problemi correlati