powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Мимо индексов на AS/400
20 сообщений из 20, страница 1 из 1
Мимо индексов на AS/400
    #34102841
astepano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Может кто сталкивался? Потратил уже 2 дня на эксперименты :(
- Есть join по двум таблицам (сам join не привожу, т.к. то же самое наблюдается на нескольких разных джойнах). Одна таблица довольно большая 2500000 записей.
- Обращение идет через .NET провайдера от IBM.
- Версия ОС 5.2 (но то же самое наблюдаю и на 5.3 на другой машине)
при выполнении join, время получается безумное....
Анализ с помощью SQL Performance Monitor показал, что обращение к обеим базам идет путем сканирования одной (большой) и построением временного индекса по другой. advisor предлагает построить индекс по паре полей, но такой индекс УЖЕ есть.
- есть еще индексы по тем полям, по которым идет join и которые участвуют в выборке.
- права на индексы розданы правильные.
- добавили трассировку в джоб, под которым идет запрос. получили сообщение:
CPI432C All access paths were considered for file ACCBAL.
ause . . . . . : The OS/400 Query optimizer considered all access paths built over member ACCBAL of file ACCBAL in library FINANCE. The list below shows the access paths considered. If file ACCBAL in library FINANCE is a logical file then the access paths specified are actually built over member ACCBAL of physical file ACCBAL in library FINANCE. Following each access path name in the list is a reason code which explains why the access path was not used. A reason code of 0 indicates that the access path was used to implement the query. FINANCE/PK_ACCBAL 6, FINANCE/ACCBALL1 6. The reason codes and their meanings follow:
...
6 - The keys of the access path did not match the fields specified for the join criteria.
ну т.е. констатация факта, что ключи не подходят.

- и САМОЕ интересное . тот же самый запрос с теми же параметрами (взятыми из SQL Performance Monitor) выполняется в Run SQL Script абсолютно правильно, т.е. идет по тем индексам, что доктор прописал. И план запроса абсолютно другой. При этом обращение идет от такого же QZDASOINIT и от одинаковых Current User.
Может кто подскажет, где еще порыть? Обойти эту ситуацию можно, но мне не нравится такая непредсказуемость и хочется ее разрешить.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103033
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Все-таки напишите хотя бы 1 запрос.
Есть ли в нем маркеры параметров или запрос полностью динамический?
Я как-то получал такое в Run SQL Scripts, случайно установив
Connections -> JDBC Setup -> Language -> Sort based on в Language ID вместо Job profile по умолчанию.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103239
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mark BarinsteinВсе-таки напишите хотя бы 1 запрос.
Есть ли в нем маркеры параметров или запрос полностью динамический?
Я как-то получал такое в Run SQL Scripts, случайно установив
Connections -> JDBC Setup -> Language -> Sort based on в Language ID вместо Job profile по умолчанию.

было у меня такое
необъяснимый глюк нового оптимизатора
у Вас только джоин или есть еще where или order?

Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103303
astepano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mark BarinsteinВсе-таки напишите хотя бы 1 запрос.
Есть ли в нем маркеры параметров или запрос полностью динамический?
Я как-то получал такое в Run SQL Scripts, случайно установив
Connections -> JDBC Setup -> Language -> Sort based on в Language ID вместо Job profile по умолчанию.
Да запрос-то доброго слова не стоит...
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103318
astepano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да запрос-то доброго слова не стоит...

SELECT FLP003.ACCN03, FLP003.ACDESC
FROM FLP003 INNER JOIN
ACCBAL
ON FLP003.ACCN03 = ACCBAL.LVCD01 AND ACCBAL.CONO=FLP003.CONO
WHERE ACCBAL.ACCTYP = ? AND ACCBAL.PRVAL = ? AND FLP003.CONO = ? AND FLP003.LEDNO = 'БК'

А насчет sort sequence мысль интересная....
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103385
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lazy-beaverу Вас только джоин или есть еще where или order?where есть, order нет.
2 astepano:
Попробуйте вместо маркеров реальные значения подставить при работе с .NET.
Что получилось?
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103567
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mark Barinstein lazy-beaverу Вас только джоин или есть еще where или order?where есть, order нет.
2 astepano:
Попробуйте вместо маркеров реальные значения подставить при работе с .NET.
Что получилось?

Марк, давайте устроим мозговой штурм
оттакая табличка:

select count(*) from arksysd/trhistory
COUNT ( * )
52,320,073

SELECT * FROM arksysd/trhistory
where fdpstd<20060501
время вывода первой записи на экран после нажатия enter - ~120 сек
в джоблоге следующие сообщения:
All access paths were considered for file TRHISTORY.
Additional access path reason codes were used.
Arrival sequence access was used for file TRHISTORY.
Message . . . . : All access paths were considered for file TRHISTORY.
Cause . . . . . : The OS/400 Query optimizer considered all access paths
built over member ZTRHIST of file TRHISTORY in library ARKSYSD.
The list below shows the access paths considered. If file TRHISTORY in
library ARKSYSD is a logical file then the access paths specified are
actually built over member ZTRHIST of physical file TRHISTORY in library
ARKSYSD.
Following each access path name in the list is a reason code which
explains why the access path was not used. A reason code of 0 indicates
that the access path was used to implement the query.
ARKSYSD/FDPSTD 4, ARKSYSD/TRHISTML 17, ARKSYSD/TRHISTLM 17,
ARKSYSD/TRHISTL 17, ARKSYSD/TRHISISL 4, ARKSYSD/TRHISDVL 4,
4 - The cost to use this access path, as determined by the optimizer, was
higher than the cost associated with the chosen access method.

теперь те же яйца с сортировкой
SELECT * FROM arksysd/trhistory
where fdpstd<20060501
order by fdpstd

время появления первой записи ~3 сек
All access paths were considered for file TRHISTORY
Additional access path reason codes were used.
Access path of file FDPSTD was used by query.

ну и:
DSPFD Command Input
File . . . . . . . . . . . . . . . . . . . : FILE FDPSTD
Library . . . . . . . . . . . . . . . . . : ARKSYS
Type of information . . . . . . . . . . . . : TYPE *ALL
File attributes . . . . . . . . . . . . . . : FILEATR *ALL
System . . . . . . . . . . . . . . . . . . : SYSTEM *LCL
ile Description Header
File . . . . . . . . . . . . . . . . . . . : FILE FDPSTD
Library . . . . . . . . . . . . . . . . . . : ARKSYSD
...
Data Base File Attributes
Externally described file . . . . . . . . . : Yes
SQL file type . . . . . . . . . . . . . . . : INDEX
...
Access Path Description
Access path maintenance . . . . . . . . . . : MAINT *IMMED
Unique key values required . . . . . . . . : UNIQUE No
Key order . . . . . . . . . . . . . . . . . : Not specified
Select/omit specified . . . . . . . . . . . : No
Access path journaled . . . . . . . . . . . : No
Access path . . . . . . . . . . . . . . . . : Keyed
Number of key fields . . . . . . . . . . . : 1
Record format . . . . . . . . . . . . . . . : RFDSTL
Key field . . . . . . . . . . . . . . . . : FDPSTD
Sequence . . . . . . . . . . . . . . . : Ascending
Sign specified . . . . . . . . . . . . : SIGNED
Zone/digit specified . . . . . . . . . : *NONE
Alternative collating sequence . . . . : No
Files accessed by logical file PFILE
.+....1....+....2....+....3....+....4....+....5....+....6....+
File Library LF Format
TRHISTORY ARKSYSD RFDSTL
Sort Sequence . . . . . . . . . . . . . . . : SRTSEQ *HEX
Language identifier . . . . . . . . . . . . : LANGID ENU
и тд
чивойта етот дурной оптимизатор при отборе индекс не юзает?
зы. началось все ето после агрейда на 5.2


Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34103950
astepano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Подстановка вместо параметров их значений ничего не дала.

Проблему удалось локализовать , убрав из строки подключения слова про сортировку (спасибо Марку :)) : SortSequence=SharedWeight;SortLanguageId=RUS;

Теперь по крайней мере понятно, где собака порылась. Приведем таблицы-индексы к правильному знаменателю в плане сортировок....
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34104162
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 lazy-beaver:
Ну, скорость появления первой записи - это еще не показатель.
А можно засечь время получения всех записей (в файл, например) по обоим запросам?
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34104992
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mark Barinstein2 lazy-beaver:
Ну, скорость появления первой записи - это еще не показатель.
А можно засечь время получения всех записей (в файл, например) по обоим запросам?
дык, можно
но там русским англицким языком указано, что в первом случае используется arrival sequence, а во втором - индекс

Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34105164
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lazy-beaverдык, можно
но там русским англицким языком указано, что в первом случае используется arrival sequence, а во втором - индекс(Не) использование индекса опять же - не показатель. Если запрос возращает достаточно большой процент (кстати, какой?) записей, табличное сканирование может оказаться эффективнее. Я понимаю еще, если бы надо было сделать
select fdpstd from ... (только индексный доступ), но когда надо
select * from ...
тут от распределения данных многое зависеть будет.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34105222
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Марк прав, говоря, что оптимизатор оценивает процент строк, что надо вывести к общему кол-ву строк в таблице. Если больше 20%, то может уйти в full table scan. Если есть ORDER BY, то будет использоваться индекс на эти поля по-любому, т.к. сортировка - процедура дорогая.

astepano, у меня сложилось впечатление, что у вас не SQL таблица и индексы (SQL DDL), а DDS. Я прав?
На выбор оптимизатора влияет тип индекса - SQL Index м.б. предпочтительнее Keyed Logical File, т.к. читается быстрее (64К logical page size vs. 8K)

Код: plaintext
1.
2.
--
Антон
Per rectum ad astrum
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34107147
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anton DemidovМарк прав, говоря, что оптимизатор оценивает процент строк, что надо вывести к общему кол-ву строк в таблице. Если больше 20%, то может уйти в full table scan. Если есть ORDER BY, то будет использоваться индекс на эти поля по-любому, т.к. сортировка - процедура дорогая.

astepano, у меня сложилось впечатление, что у вас не SQL таблица и индексы (SQL DDL), а DDS. Я прав?
На выбор оптимизатора влияет тип индекса - SQL Index м.б. предпочтительнее Keyed Logical File, т.к. читается быстрее (64К logical page size vs. 8K)

Код: plaintext
1.
2.
--
Антон
Per rectum ad astrum


в моем случае физ. файл - DDS, а индекс SQL
почему-то остальные логические файлы после агрейда на 5.2 оптимизатор перестал видеть _вообще_

Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34107665
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lazy-beaverв моем случае физ. файл - DDS, а индекс SQL
почему-то остальные логические файлы после агрейда на 5.2 оптимизатор перестал видеть _вообще_

Serge Reva
Нас учили делать так: удаляем старые LF, создаём SQL индексы по их определениям, пересоздаём LF. В этом случае они "подхватят" индекс и не будут строить путь заново. К сожалению, про 5R2 я не погу подсказать ничего - у нас 5.1 и 5.3 - может там баг был какой при агрейде ...

P.S.
Нам ещё дали на курсах следующую общую рекомендацию: если используете SQL для доступа к данным, то система будет работать быстрее, если PF и LF пересоздать как SQL Tables + SQL Indexes + LFs.

P.P.S.
Чем старше версия (5.3 или 5.4), тем умнее оптимизатор SQL. Обновляйтесь, если есть возможность.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34108726
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anton Demidov lazy-beaverв моем случае физ. файл - DDS, а индекс SQL
почему-то остальные логические файлы после агрейда на 5.2 оптимизатор перестал видеть _вообще_

Serge Reva
Нас учили делать так: удаляем старые LF, создаём SQL индексы по их определениям, пересоздаём LF. В этом случае они "подхватят" индекс и не будут строить путь заново. К сожалению, про 5R2 я не погу подсказать ничего - у нас 5.1 и 5.3 - может там баг был какой при агрейде ...

P.S.
Нам ещё дали на курсах следующую общую рекомендацию: если используете SQL для доступа к данным, то система будет работать быстрее, если PF и LF пересоздать как SQL Tables + SQL Indexes + LFs.

P.P.S.
Чем старше версия (5.3 или 5.4), тем умнее оптимизатор SQL. Обновляйтесь, если есть возможность.

SQL у нас только в 20% случаев доступа к данным.

Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34110356
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lazy-beaverSQL у нас только в 20% случаев доступа к данным.

Serge Reva
Если у вас есть таблицы, которые вы в основном читаете, то всё равно можете выиграть в производительности за счет большего размера страницы (64К) - быстрее index scan.

Ho учтите что IBM - SQL indexes compared with Keyed LFNo support for Select/Omit filtering or join logical files
В общем как всегда - надо пробовать в каждом конктретном случае.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34111583
lazy-beaver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anton Demidov lazy-beaverSQL у нас только в 20% случаев доступа к данным.

Serge Reva
Если у вас есть таблицы, которые вы в основном читаете, то всё равно можете выиграть в производительности за счет большего размера страницы (64К) - быстрее index scan.

Ho учтите что IBM - SQL indexes compared with Keyed LFNo support for Select/Omit filtering or join logical files
В общем как всегда - надо пробовать в каждом конктретном случае.

из какого документа цитата, хотелось бы его почитать целиком

Serge Reva
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34113720
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lazy-beaverиз какого документа цитата, хотелось бы его почитать целиком
DB2 UDB for iSeries SQL and Query performance Tuning and Monitoring Workshop.
Rochester, MN October 2005
Dan Cruikshank

Это материалы курсов.
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34113770
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Антон, а эти материалы доступны в электронной форме?
Я не смог в свое время найти их...
...
Рейтинг: 0 / 0
Мимо индексов на AS/400
    #34113948
Фотография Anton Demidov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mark BarinsteinАнтон, а эти материалы доступны в электронной форме?
Я не смог в свое время найти их...
Если бы были, то я бы поделился. А так - 5см талмуд на полке.
...
Рейтинг: 0 / 0
20 сообщений из 20, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Мимо индексов на AS/400
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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