Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> PLS-00123: Program Too Large, как побороть? 
:(
    Опции темы
batigoal
Дата 26.9.2006, 12:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 2
Всего: 151



При компиляции заголовка пакета получаю ошибку PLS-00123: Program Too Large.

Компилирую из SQL Plus (пробовал также из PL/SQL Developer'а).

Дебаг отключен (alter session set plsql_debug=false).

Последний вариант - разбивка пакета, но это СВЕРХнежелательно.

Добавлено @ 12:10 
Размер исходника - 7500 строк, 345 Кб.


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
jsa
Дата 27.9.2006, 04:18 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 704
Регистрация: 19.1.2006
Где: Новосибирск

Репутация: 1
Всего: 20



Цитата

Overview
--------

This article contains information on PL/SQL package size limitations.
When limits are reached, you receive the following error:

    PLS-123 Program too large


Size Limitations on PL/SQL Packages
-----------------------------------

In releases prior to 8.0.4, large programs resulted in the PLS-123 error.
This occurred because of genuine limits in the compiler; not as a result
of a bug.

When compiling a PL/SQL unit, the compiler builds a parse tree.  The 
maximum size of a PL/SQL unit is determined by the size of the parse tree.  
A maximum number of diana nodes exists in this tree.

Up to 7.3, you could have 2**14 (16K) diana nodes, and from 8.0.4 to 8.0.6, 
2**15 (32K) diana nodes were allowed. From 8.1.5 to 8.1.7, 2**16 (64K) diana 
nodes were allowed. From 9i onwards, this limit has been relaxed so that you can now
have 2**26 (i.e., 64M) diana nodes in this tree for package and type bodies.


Source Code Limits
------------------

While there is no easy way to translate the limits in terms of lines of 
source code, it has been our observation that there have been approximately 
5 to 10 nodes per line of source code.  Prior to 8.1.3, the compiler could 
cleanly compile up to about 3,000 lines of code.
  
Starting with 8.1.3, the limit was relaxed for package bodies and type bodies 
which can now have approximately up to about 6,000,000 lines of code.  

   Notes:  This new limit applies only to package bodies and type bodies.  
           Also, you may now start hitting some other compiler limits 
           before you hit this particular compiler limit.

In terms of source code size, assume that tokens (identifiers, operators, 
functions, etc.), are on average four characters long.  Then, the maximum 
would be:

   Up to 7.3           : 4*(2**14)=64K
   From 8.0.4 to 8.0.6 : 4*(2**15)=128K
   From 8.1.5 to 8.1.7 : 4*(2**16)=256K
   From 9.2 onwards    : 4*(2**25)=256M

This is a rough estimate.  If your code has many spaces, long identifiers, 
etc., you may end up with source code larger than this.  You may also end 
up with source code smaller than this if your sources use very short 
identifiers, etc.

Note that this is per program unit, so package bodies are most likely to
encounter this limit. 


How to Check the Current Size of a Package
------------------------------------------

To check the size of a package, the closest related number you can use is 
PARSED_SIZE in the data dictionary view USER_OBJECT_SIZE.  This value 
provides the size of the DIANA in bytes as stored in the SYS.IDL_xxx$ tables 
and is NOT the size in the shared pool.  

The size of the DIANA portion of PL/SQL code (used during compilation) is 
MUCH bigger in the shared pool than it is in the system table.  
 
For example, you may begin experiencing problems with a 64K limit when the 
PARSED_SIZE in USER_OBJECT_SIZE is no more than 50K.  
 
For a package, the parsed size or size of the DIANA makes sense only  
for the whole object, not separately for the specification and body.  
 
If you select parsed_size for a package, you receive separate source and 
code sizes for the specification and body, but only a meaningful parsed size 
for the whole object which is output on the line for the package 
specification.  A 0 is output for the parsed_size on the line for the package 
body.  
 
The following example demonstrates this behaviour:  
  
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';  
  
  
NAME                           TYPE         SOURCE_SIZE PARSED_SIZE  CODE_SIZE  
------------------------------ ------------ ----------- ----------- ----------  
ERROR_SIZE  
----------  
EXAMPLE                        PACKAGE               51         185         62  
         0  
  
EXAMPLE                        PACKAGE BODY          70           0         80  
         0 
 
 
Oracle stores both DIANA and MCODE in the database.  MCODE is the actual code  
that runs, while DIANA for a particular library unit X contains information  
that is needed to compile procedures using library unit X.  

The following are several notes:  
  
a) DIANA is represented in IDL.  The linear version of IDL is stored on disk.  
   The actual parse tree is built up and stored in the shared pool. This
   is why the size of DIANA in the shared pool is typically larger than on 
   disk.   
  
b) DIANA for called procedures is required in the shared pool only when you 
   create procedures.  In production systems, there is no need for DIANA  
   in the shared pool (but only for the MCODE). 
   
c) Starting with release 7.3.4, the DIANA for package bodies is thrown away,
   not used, and not stored in the database.  This is why the PARSED_SIZE 
   (i.e. size of DIANA) of PACKAGE BODIES is 0.   
  
--> Therefore, large procedures and functions should always be defined within  
packages! 



--------------------
Все мы, на перине с песней, строим небо на земле © Ю. Шевчук
PM MAIL ICQ   Вверх
batigoal
Дата 27.9.2006, 08:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 2
Всего: 151



Цитата(jsa @  27.9.2006,  05:18 Найти цитируемый пост)
diana nodes

Не нашел, что это такое, но смысл понятен.

Цитата(jsa @  27.9.2006,  05:18 Найти цитируемый пост)
To check the size of a package, the closest related number you can use is PARSED_SIZE in the data dictionary view USER_OBJECT_SIZE. 

При возникновении ошибки PLS-00123 в этот столбец записывается 0, это я проверял.

На самом деле, у нас появилась одна идея, как избежать этой ошибки. Потенциально "лишними" операциями (и, как я понимаю, лишними "diana node'ами") являются указания типа через %type. Сегодня я постараюсь переписать генератор, который создает этот пакет, чтобы он использовал явное указание типа, и сообщить о результатах.


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
Marriage
Дата 3.10.2006, 01:10 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 842
Регистрация: 4.5.2004
Где: Таганрог

Репутация: нет
Всего: 2



У меня было тело пакета на 17 000 строк в 8.1.7.4... И как же он долго тормозился,когда компилися  smile .
По этому я бы посоветовал разбить пакет и не заморачиваться. 

Это сообщение отредактировал(а) Marriage - 3.10.2006, 01:11


--------------------
Praemonitus, praemunitus
PM MAIL ICQ   Вверх
batigoal
Дата 3.10.2006, 07:56 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Нелетучий Мыш
****


Профиль
Группа: Участник Клуба
Сообщений: 6423
Регистрация: 28.12.2004
Где: Санктъ-Петербургъ

Репутация: 2
Всего: 151



Цитата(Marriage @  3.10.2006,  02:10 Найти цитируемый пост)
По этому я бы посоветовал разбить пакет и не заморачиваться. 

Так в итоге и сделали... Хотя нехорошо это (с точки зрения архитектуры).


--------------------
"Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли)
ЖоржЖЖ
PM WWW   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Oracle"
Zloxa
LSD

Данный раздел предназначен для обсуждения проблем с Oracle Database, другие продукты Oracle здесь не обсуждаются. Просьба при создании темы, придерживаться следующих правил:

  • при создании темы давайте ей осмысленное название, описывающее суть проблемы
  • указывайте используемую версию базы, способ соединения и язык программирования
  • при ошибках обязательно приводите код ошибки и сообщение сервера
  • приводите код в котором возникла ошибка, по возможности дайте тестовый пример демонстрирующий ошибку
  • при вставке кода используйте соответсвующие теги: [code=sql] [/code] для подсветки SQL и PL/SQL кода, [code=java] [/code] - для Java, и т.д.

  • документация по Oracle: 9i, 10g, 11g
  • книги по Oracle можно поискать здесь
  • действия модераторов можно обсудить здесь

Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Zloxa, LSD.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Oracle | Следующая тема »


 




[ Время генерации скрипта: 0.0654 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.