powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Отработка состояния SQL1585N (слишком длинный запрос)
14 сообщений из 14, страница 1 из 1
Отработка состояния SQL1585N (слишком длинный запрос)
    #38740984
Александр Тарасенко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть запрос, в котором добавляются к фиксированным столбцам куча столбцов - значения с датами.
При достижении определенного предела (количества дат) получаю ошибку SQL1585N.
При этом буфферпул на 32 К (и остальные, 4, 8 и 16) есть.
И тейблспейсы также есть нужные.
Допустим, я хочу выдать сообщение, что мол "слишком большой диапазон дат".
Брал нечто похожее, кусок из другой процедуры:
DECLARE MESSG1 VARCHAR(512) DEFAULT '';
DECLARE TO_LONG_ROW CONDITION FOR SQLSTATE '54048';
DECLARE C_REPORT CURSOR WITH RETURN FOR CUR_TRANSSHIPMENT;
DECLARE CONTINUE HANDLER FOR TO_LONG_ROW SET MESSG1= 'Выбран слишком большой диапазон дат';

где C_REPORT - выполняемый курсор, остальное (насколько я надеюсь) необходимо для выдачи в сообщении об ошибке этого инф. сообщения (Выбран слишком большой диапазон дат).

Однако, в результате выполнения процедуры получаю:
" An error occurred during implicit system action type "2". Information returned for the error includes SQLCODE "-1585", SQLSTATE "54048" and message tokens "". "
В общем-то, если подскажете, что делать, буду благодарен.
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743274
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Александр Тарасенко,

Это ошибка относительно количества колонок во временной таблице. Зависит от размера system temporary tablespace.
Лимиты для 9.7: 500 колонок для 4К табличных пространств, 1012 для всех остальных. Честно, я плохо представляю простыню в 500 колонок, если только это не результат программного (де)генератора.

Andy
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743296
Александр Тарасенко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
A.PanskikhАлександр Тарасенко,

Это ошибка относительно количества колонок во временной таблице. Зависит от размера system temporary tablespace.
Лимиты для 9.7: 500 колонок для 4К табличных пространств, 1012 для всех остальных. Честно, я плохо представляю простыню в 500 колонок, если только это не результат программного (де)генератора.

Andy

Там значения еженедельно в течении 7,5 лет. То бишь 360 колонок. Они потом на вебе режутся по 50 на страницу.
Но очевидно, что где-то они еще больше умножаются ...
Спасибо, буду разбираться дальше.
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743317
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Александр ТарасенкоТам значения еженедельно в течении 7,5 лет. То бишь 360 колонок. Они потом на вебе режутся по 50 на страницу.


"Такое делать надо не" (с) не помню

Может сразу xml?
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743328
Александр Тарасенко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
на xml вариант процедуры сделал уже ))
но что-то там неэффективно как-то выгружает пока на вебе, память как-то вся куда-то уходит на сайтах, поэтому попросили пока с данными в открытом курсоре долбаться. Сделают эффективно выгрузку xml - сразу будет нужный вариант.
Но срок там неясен.
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743397
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Тарасенко,

Там ещё и на длину строки ограничение. Скорее всего нужно дополнительное системное временное табличное пространство сделать с достаточным размером страницы.

По "db2 ? SQL1585N" всё написано:
----------------------------------
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
SQL1585N  A system temporary table space with sufficient page size does
      not exist.

Explanation:

One of the following conditions could have occurred:

1. The row length of the system temporary table exceeded the limit that
   can be accommodated in the largest system temporary table space in
   the database.
2. The number of columns required in a system temporary table exceeded
   the limit that can be accommodated in the largest system temporary
   table space in the database.

The system temporary table space limits depend on its page size. These
values are:

Max          Max   Page size of
Record       Cols  temporary
Length             table space
-----------  ----  ------------
4005  bytes  500   4K
8101  bytes  1012  8K
16293 bytes  1012  16K
32677 bytes  1012  32K

User response:

Create a system temporary table space of a larger page size supported,
if one does not already exist. If such a table space already exists,
eliminate one or more columns from the system temporary table. Create
separate tables or views, as required, to hold additional information
beyond the limit.

 sqlcode: -1585

 sqlstate: 54048
----------------------------------
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743423
Александр Тарасенко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
читал этот материал ).
авторПри этом буфферпул на 32 К (и остальные, 4, 8 и 16) есть.
И тейблспейсы также есть нужные.
Делать на 64Кб?
а есть ли вообще такие?
пока либо ставить ограничение на кол-во столбцов (ну пускай клиенты за 2 раза возьмут инфу), либо ...
вот другого варианта пока и не придумал
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743763
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Александр Тарасенкопока либо ставить ограничение на кол-во столбцов (ну пускай клиенты за 2 раза возьмут инфу), либо ...


ограничение есссно должно быть. Завтра захотят данные за столетие и никаких лимитов уже не хватит.
Да и памяти у них может не хватать, поскольку у парсилски тоже может стоять ограничение на кол-во столбцов.

Я не понимаю, зачем на стороне приклада заниматься формированием из селекта xml, если базюка может отдать его готовым?
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743874
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Александр Тарасенко...
Однако, в результате выполнения процедуры получаю:
" An error occurred during implicit system action type "2". Information returned for the error includes SQLCODE "-1585", SQLSTATE "54048" and message tokens "". "
-1585 не перехватывается обработчиком исключений по какой-то причине.
Не знаю, так задумано, или это дефект.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
begin
  declare i int;
  declare exit handler for sqlexception
  begin
  end;

  set i = (
  select count(1)
  from (
  select t.*, lpad(t.tabname , 32600) c
  from syscat.tables t
  order by c) t
  );
--  values 1/0 into i;
end@
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38743932
Александр Тарасенко,

Насчет работы с XML - тут нужно смотреть каким образом его парсят при получении. Если целиком грузят в память (DOM-доступ) - то да, там памяти не напасешься. Если же используется последовательный (stream) способ преобразования (SAX, StAX) - то там потребление памяти весьма небольшое. Т.е. в такой ситуации лучше из СУБД отдавать XML, а на стороне клиента уже делать преобразования. Те же XSLT-шаблоны отлично работают на последовательном доступе.

Для JDBC-драйвера можно дополнительно включить оптимизацию, чтобы XML от DB2 к приложению (драйверу) передавался в "бинарном" виде ( там теги передаются в упакованном виде, плюс передается "словарь" тегов).
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38748882
Александр Тарасенко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Евгений ХабаровАлександр Тарасенко,

Насчет работы с XML - тут нужно смотреть каким образом его парсят при получении. Если целиком грузят в память (DOM-доступ) - то да, там памяти не напасешься. Если же используется последовательный (stream) способ преобразования (SAX, StAX) - то там потребление памяти весьма небольшое. Т.е. в такой ситуации лучше из СУБД отдавать XML, а на стороне клиента уже делать преобразования. Те же XSLT-шаблоны отлично работают на последовательном доступе.

Для веб-приложений используется IBM Lotus Notes 7.
Насколько я понял наших веб-программистов, проблема в отсутствии библиотеки, которая обрабатывает xml и допустим, загружает его в Excel. Или получает из него данные для загрузки их на формы на сайте.
Есть ли общедоступные библиотеки, наиболее оптимальные для задачи загрузки кода xml в Excel?
И какой из способ парсировки оптимален?

Евгений ХабаровАлександр Тарасенко,
Для JDBC-драйвера можно дополнительно включить оптимизацию, чтобы XML от DB2 к приложению (драйверу) передавался в "бинарном" виде ( там теги передаются в упакованном виде, плюс передается "словарь" тегов).

то бишь я правильно понимаю, что эта оптимизация должна включаться не в самом DB2, а в настройках JDBC-драйвера? а уже там (на конечном этапе) xml можно будет распаковать?
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38749080
Александр ТарасенкоЕвгений ХабаровАлександр Тарасенко,

Насчет работы с XML - тут нужно смотреть каким образом его парсят при получении. Если целиком грузят в память (DOM-доступ) - то да, там памяти не напасешься. Если же используется последовательный (stream) способ преобразования (SAX, StAX) - то там потребление памяти весьма небольшое. Т.е. в такой ситуации лучше из СУБД отдавать XML, а на стороне клиента уже делать преобразования. Те же XSLT-шаблоны отлично работают на последовательном доступе.

Для веб-приложений используется IBM Lotus Notes 7.
Насколько я понял наших веб-программистов, проблема в отсутствии библиотеки, которая обрабатывает xml и допустим, загружает его в Excel. Или получает из него данные для загрузки их на формы на сайте.
Есть ли общедоступные библиотеки, наиболее оптимальные для задачи загрузки кода xml в Excel?
И какой из способ парсировки оптимален?

Lotus Notes - это клиент, насколько мне помнится. Возможно, речь идет о Lotus Domino.
Про Lotus Domino ничего не скажу, т.к. практически не знаком с ним.

Для Java точно есть готовые библиотеки, которые умеют XML преобразовывать в другие форматы. Пример: Apache POI .
Для более-менее современных версий MS Office можно вообще генерировать XML-файл определенного формата ( Microsoft Office XML formats ), который будет открываться как документ Excel или Word.

Т.е. в самом простом случае можно выполнять цепочку База данных ->XML(данные)->XLST-преобразование->XML(для MS Office).
XSLT-преобразование можно выполнять как на стороне сервера приложений, так и на стороне СУБД ( Lesson 8: Transforming with XSLT stylesheets ).
XSLT-трансформация на стороне сервера приложений (Java) не требует доп.библиотек, т.к. все встроено в сам JDK.
Самое сложное - это создать шаблон (XML-файл специальной структуры).
Сложность - условная, т.к. документации и примеров - полно. Нужно просто понять как работает эта технология.
Преобразование по шаблону последовательное(потоковое), нагрузка на память не очень большая.

Александр ТарасенкоЕвгений ХабаровАлександр Тарасенко,
Для JDBC-драйвера можно дополнительно включить оптимизацию, чтобы XML от DB2 к приложению (драйверу) передавался в "бинарном" виде ( там теги передаются в упакованном виде, плюс передается "словарь" тегов).

то бишь я правильно понимаю, что эта оптимизация должна включаться не в самом DB2, а в настройках JDBC-драйвера? а уже там (на конечном этапе) xml можно будет распаковать?
Да, использование упакованного формата передачи настраивается на уровне свойств драйвера JDBC.
Передача XML в упакованном виде позволяет экономить на объеме передаваемых данных по соединению с СУБД.
Драйвер автоматом "распакует" XML при передаче его приложению. Т.е. конечное приложение получит уже распакованный XML.

В случае XSLT на стороне сервера приложений можно использовать такую цепочку:
Код: java
1.
2.
3.
java.sql.SQLXML sqlxml = rs.getSQLXML(1);
SAXSource saxSource = sqlxml.getSource(SAXSource.class);
//Далее SAXSource  "скармливается" XSLT-трансформации


Главное, следить, чтобы на всем пути "следования" нигде не случилось промежуточного сохранения всего "файла" в памяти. Для этого нужно использовать потоковые парсеры и потоковую запись в выходной поток с буферизацией или (возможно, если нужно) с промежуточным сохранением на диск. Тут нужно устраивать тестирование на практике в конкретных условиях.

PS:
1. Работать с XML и XSLT сейчас умеют очень многие языки программирования и другие программные средства и программно-аппаратные комплексы.
2. Таблица по возможностям парсеров (Java): Why StAX?
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38749622
anton.k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark Barinstein-1585 не перехватывается обработчиком исключений по какой-то причине.
Не знаю, так задумано, или это дефект.

Нет, не дефект. Ошибка вылетает на этапе компиляции, до среды выполнения дело просто не доходит.
...
Рейтинг: 0 / 0
Отработка состояния SQL1585N (слишком длинный запрос)
    #38749813
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
anton.kMark Barinstein-1585 не перехватывается обработчиком исключений по какой-то причине.
Не знаю, так задумано, или это дефект.

Нет, не дефект. Ошибка вылетает на этапе компиляции, до среды выполнения дело просто не доходит.Да, я ошибся. Спасибо, что поправили.
Ошибка в динамическом запросе перехватывается
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
set serveroutput on@

begin
  declare i int default -1;
  declare stmt varchar(128);
  declare exit handler for sqlstate '54048'
  begin
  end;

  set stmt = 
  'set ? = (
  select count(1)
  from (
  select t.*, lpad(t.tabname , 32600) c
  from syscat.tables t
  order by c) t
  )';
  prepare s1 from stmt;
  execute s1 into i;
  call dbms_output.put_line(i);
end@


Код: plaintext
DB20000I  The SQL command completed successfully.

Поэтому, скорее всего, проблема ТС с тем, что его процедура возвращает ошибку, несмотря на попытку перехвата с выдачей сообщения, в том, что перехват делается неправильно.
...
Рейтинг: 0 / 0
14 сообщений из 14, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Отработка состояния SQL1585N (слишком длинный запрос)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]