2011-02-10 28 views
9

Durante la compilación de un paquete, me encontré con un mensaje de error:PLS-00123: El programa es demasiado grande (nodos Diana) al intentar compilar un paquete

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

El paquete en cuestión tiene aproximadamente 1k líneas (especificación) + 13k líneas en el cuerpo. Si bien la investigación sobre este tema, me encontré con this Ask Tom question

Al compilar una unidad de PL/SQL, el compilador construye un árbol de análisis sintáctico. El tamaño máximo de de una unidad PL/SQL es determinado por el tamaño del árbol de análisis . En este árbol existe una cantidad máxima de diana nodos .

Hasta 7.3, usted podría tener 2**14 (16K) nodos diana, y de 8.0 a 8.1.3, se permitió a los nodos 2**15 (32K) diana. Con 8.1.3, este límite ha sido relajado, por lo que ahora puede tener 2**26 (es decir, 64M) nodos de diana en este árbol para paquetes y tipos de cuerpos.

Aunque no existe una manera fácil de traducir los límites en términos de líneas de código fuente, que ha sido nuestra observación que ha habido aproximadamente 5 a 10 nodos por línea de código fuente. Antes de 8.1.3, el compilador podía compilar limpiamente hasta alrededor de 3.000 líneas de código.
Comenzando con 8.1.3, el límite era relajado para cuerpos de paquete y cuerpos que ahora pueden tener aproximadamente hasta aproximadamente 6,000,000 líneas de código.

Esta es una estimación aproximada. Si su código tiene muchos espacios, identificadores largos , etc., puede terminar en con un código fuente mayor que este.

Ahora, incluso si se toma en consideración la última lista de muchos espacios & grandes identificadores, creo que es razonable concluir que no está cerca, donde los límites mencionados anteriormente.

Adicionalmente, en

Cómo comprobar el tamaño actual de un paquete:

Para comprobar el tamaño de un paquete, el número más cercano relacionado que puede utilizar es PARSED_SIZE en el diccionario de datos ver USER_OBJECT_SIZE. Este valor proporciona el tamaño de DIANA en bytes almacenado en las tablas SYS.IDL_xxx$ y NO es el tamaño en el grupo compartido .

[...]

Por ejemplo, es posible que comience problemas que experimentan con un límite de 64 K cuando el PARSED_SIZE en USER_OBJECT_SIZE es no más de 50 mil.

La consulta de esta vista da un resultado de 48929 - entonces supongo que es justo para el tamaño es 47k?

La parte más extraña es, obtener el mismo objeto de otro esquema y ejecutarlo en el área que estoy teniendo resultados problemáticos en una compilación exitosa.

Entonces, ¿por qué esta área en particular causa problemas?

+1

Sé que es una posibilidad remota, pero a la vista del problema, tengo que preguntar: ¿son sus líneas muy, muy grandes? –

+1

Son, de ninguna manera, muy grandes – Sathya

Respuesta

5

¿El programa que compila su código con agrega información de depuración? Aparentemente hace la diferencia ilustrada en this forum post.

El problema cuando se hace una compilación de depuración es el código adicional que se añade en para la depuración.

Puede probar estas consultas para ver:

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'; 

Tenga en cuenta las diferencias en la code_size al compilar para la depuración.

Si está compilando con DEPURADOR, intente compilar en condiciones normales para que no genere código adicional que pueda generar su error.

+0

+1 Gracias por señalarme hacia este enlace. – Sathya

Cuestiones relacionadas