ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Оптимизация запроса (теория)
25 сообщений из 25, страница 1 из 1
Оптимизация запроса (теория)
    #38146600
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Здравствуйте!
Есть пользовательская функция, которая возвращает table, в функции порядка 20 union, и только с 5-ью проблема - все они обращаются к NickName (таблица на 20 миллионов). Я понял, что проблема именно в них. Делаю select * from TEMP.NICKNAME where id = 122324 - по PK (одна запись) , запрос идёт 5-ть секунд (кешь специально сбрасывал - чтобы замерить). Хотя все остальные 15 union в функции отрабатывают за 2 секунды. MQT - тоже не подходит - так как во время обновления - происходит блокировки.
Есть ли какой то ещё способ решения,хочется чтобы архитектуру не менять (NICKNAME) оставить и в то же время чтобы запрос select * from TEMP.NICKNAME where id = 122324 отрабатывал хотя бы за секунду, нельзя как то NICKNAME посстоянно на связи держать (DB2 = 9.7)?

P.S.
В MSSQL из одной таблички в другую, на одном инстансе вообще проблем нет обратиться, в DB2 - я так понял с этим напряги! Спасибо!
...
Рейтинг: 0 / 0
11.02.2013, 17:58
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38146705
Troglodit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Troglodit
Гость
Смотрите план запроса. При поиске по PK(int) поиск должен происходить менее секунды. Попробуйте собрать статистику, возможно проблема в этом.
...
Рейтинг: 0 / 0
11.02.2013, 19:00
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38146774
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
>>Troglodit
Спасибо! Я тоже понял, что проблема в статистике. Но как ее собрать для nikname, есть по-моему специальная процедура. Но там какой trace нужен. Или же достаточно для таблицы, на которой базируется nikname в другой базе раз в пол часа статистику через runstat собирать? Поделитесь плиз опытом.
...
Рейтинг: 0 / 0
11.02.2013, 19:57
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147163
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Коллеги просьба поделиться опытом, по посту выше. Марк куда то пропал, как назло!
...
Рейтинг: 0 / 0
12.02.2013, 08:48
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147171
Ivan Ivanich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Ivanich
Гость
http://www.ibm.com/developerworks/ru/library/dm-0506lin/
...
Рейтинг: 0 / 0
12.02.2013, 09:03
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147228
Ivan Ivanich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Ivanich
Гость
т.е.

Утилита обновления статистики псевдонима в Control Center или хранимая процедура командной строки SYSPROC.NNSTAT:
И утилита обновления статистики псевдонима в Control Center, и хранимая процедура командной строки SYSPROC.NNSTAT, извлекают внешнюю статистику, хранимую для внешнего объекта, для которого создан псевдоним. Во внутреннем представлении во внешней таблице создается копия псевдонима (shadow nickname). Псевдоним получает самые последние статистические данные на момент его создания. Эта статистика далее переносится из копии в существующий псевдоним. Копия псевдонима потом удаляется.
Для более подробного пояснения об использовании утилиты обновления статистики псевдонима в Control Center или хранимой процедуры, обратитесь к документу IBM DB2 Information Integrator Federated Systems Guide (см. Ресурсы).

Сама хранимая здесь : http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.ii.doc/admin/rfpsts08.htm
...
Рейтинг: 0 / 0
12.02.2013, 09:58
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147231
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Спасибо за ссылку, поизучаю!

У меня конкретный вопрос.
Есть values(current server) , который возвращает DAT8

Пытаюсь обновить статистику для NICKNAME для всего сервера, выдает ошибку:


Код: plsql
1.
2.
3.
4.
5.
6.
begin
      declare OUT_TRACE    VARCHAR(2000) ;
      declare OUT_SQL_CODE INTEGER       ;

CALL SYSPROC.NNSTAT('DAT8',NULL,NULL,NULL,OUT_TRACE,OUT_SQL_CODE);
END



Указанные сервер, схема или NICKNAME не найдены! Что я делаю не так?
...
Рейтинг: 0 / 0
12.02.2013, 09:59
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147257
Ivan Ivanich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Ivanich
Гость
medoed,

Сделайте в Центре Управления по этому псевдониму: статистика -> обновить, введите путь файла журнала, а потом "показать команду" и посмотрите, что он строит.
...
Рейтинг: 0 / 0
12.02.2013, 10:16
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147341
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Ivan Ivanichmedoed,

Сделайте в Центре Управления по этому псевдониму: статистика -> обновить, введите путь файла журнала, а потом "показать команду" и посмотрите, что он строит.

Спасибо, стало полегче, уже жужжит минут 10 - эта процедура(по одной таблице) - как то долго! Но у меня остались сомнения, в связи с чем хочу задать вопросы:

1) Правильно ли я понимаю, что эту процедуру надо запускать на той же базе, где и лежит источник.
2) Если у меня например 5-ть баз, в каждой из которых по одному NICNAME, связанных с источником - то обновится статистика для всех 5-ти баз?
...
Рейтинг: 0 / 0
12.02.2013, 11:05
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147348
Ivan Ivanich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Ivanich
Гость
1) Я, всё же полагаю, что запускать там где псевдоним.
...
Рейтинг: 0 / 0
12.02.2013, 11:09
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147361
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Да я это напутал на радостях)) Конечно!
Иван, вы по всем сразу обновляете статистику или по выборочным и как часто?
...
Рейтинг: 0 / 0
12.02.2013, 11:14
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147384
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
medoedСпасибо, стало полегче, уже жужжит минут 10 - эта процедура(по одной таблице) - как то долго! Но у меня остались сомнения, в связи с чем хочу задать вопросы:

1) Правильно ли я понимаю, что эту процедуру надо запускать на той же базе, где и лежит источник.
2) Если у меня например 5-ть баз, в каждой из которых по одному NICNAME, связанных с источником - то обновится статистика для всех 5-ти баз?

Нет, SYSPROC.NNSTAT запускается на системе, где определён nickname.
Смысл примерно такой: на удаленной системе вы, как и обычно, время от времени собираете статистику (или лучше включить автоматический сбор статистики) на эту и другие таблицы.
NNSTAT запускаете с параметром METHOD=1 - брать статистику из каталога удалённой системы.
Надо бы план запроса посмотреть.
После запуска NNSTAT выполните на федеративной системе, где у вас nickname:

explain all with snapshot for
select ...;

Получите план запроса в текстовом виде из командной строки:
Код: plaintext
 db2exfmt  -d  dbname  -1 -o exfmt.txt -u  user   password
прикрепите файл exfmt.txt
...
Рейтинг: 0 / 0
12.02.2013, 11:23
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147522
Ivan Ivanich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Ivanich
Гость
Mark BarinsteinNNSTAT запускаете с параметром METHOD=1 - брать статистику из каталога удалённой системы.


Насколько желательно устанавливать это значения для этого параметра?
...
Рейтинг: 0 / 0
12.02.2013, 12:34
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147561
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
medoedЗдравствуйте!
Есть пользовательская функция, которая возвращает table, в функции порядка 20 union, и только с 5-ью проблема - все они обращаются к NickName (таблица на 20 миллионов).

Это не теоретический вопрос, это практический вопрос.
Так что до свидания.
...
Рейтинг: 0 / 0
12.02.2013, 12:56
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147574
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Mark BarinsteinmedoedСпасибо, стало полегче, уже жужжит минут 10 - эта процедура(по одной таблице) - как то долго! Но у меня остались сомнения, в связи с чем хочу задать вопросы:

1) Правильно ли я понимаю, что эту процедуру надо запускать на той же базе, где и лежит источник.
2) Если у меня например 5-ть баз, в каждой из которых по одному NICNAME, связанных с источником - то обновится статистика для всех 5-ти баз?

Нет, SYSPROC.NNSTAT запускается на системе, где определён nickname.
Смысл примерно такой: на удаленной системе вы, как и обычно, время от времени собираете статистику (или лучше включить автоматический сбор статистики) на эту и другие таблицы.
NNSTAT запускаете с параметром METHOD=1 - брать статистику из каталога удалённой системы.
Надо бы план запроса посмотреть.
После запуска NNSTAT выполните на федеративной системе, где у вас nickname:

explain all with snapshot for
select ...;

Получите план запроса в текстовом виде из командной строки:
Код: plaintext
 db2exfmt  -d  dbname  -1 -o exfmt.txt -u  user   password
прикрепите файл exfmt.txt

Спасибо, Марк- да вроде все разрешилось - после отработки процедуры, функция стала работать, вместо 11 секунд, 3 секунды - что уже примелимо. Спасибо! Теперь думаю - как часто эту статистику обновлять!
...
Рейтинг: 0 / 0
12.02.2013, 13:01
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38147834
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Обнаглею совсем и задам вопрос по MQT, точнее по его обновлению (это тоже из оперы автоматизации).
Мы делаем обновление MQT командой:
Код: plsql
1.
refresh table TEMPSCH.MQT_T

.
На больших таблицах идёт от 1-ой до 5ти минут. У пользователей работающих в это время на базе возникают блокировки. Как можно избежать таких блокировок?
...
Рейтинг: 0 / 0
12.02.2013, 14:53
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38148549
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
MasterZivmedoedЗдравствуйте!
Есть пользовательская функция, которая возвращает table, в функции порядка 20 union, и только с 5-ью проблема - все они обращаются к NickName (таблица на 20 миллионов).

Это не теоретический вопрос, это практический вопрос.
Так что до свидания.

1) Я с DB2 - 1.5 месяца, так что для меня это больше теория, чем практика, ибо практического опыта ещё недостаточно.
Про процедуру NNSTAT - я вообще на форуме ни одного упоминания не нашел, ибо фича для db2 достаточно свежая.
Раньше у меня был MSSQL , там как я писал - на одном инстансе можно обращаться напрямую к таблицам без всяких NICKNAME к разным базам. Другие СУБД или другие инстансы в MSSQL - мапятся через LINK.

2) У Вас стиль общения какой то странный, вызывающим я называть не стану!
Но имхо такого стиля общения себе Mark Barinstein, несомненный профи по DB2, не позволяет...
Вот Марк подсказал и всё по делу - вопросов нет, хотя конечно вопрос мой возможно полуламерский был.
По его ответу опять же можно судить о профессионализме специалиста.

>> Так что до свидания.
Пока, пока!
...
Рейтинг: 0 / 0
12.02.2013, 21:13
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38148880
A.Panskikh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.Panskikh
Гость
medoed,

nnstat существует с 8-ой версии. По поводу самих никнеймов и планов запросов - в эксплейне показывается текст запроса, который пойдет в удаленную БД. Если никнейм смотрит в DB2, то при создании будет создан не только никнейм, но и определения индексов плюс скопируется статистика. Если индексов, статистики нет или в силу каких-то других причин db2 может послать на удаленный сервер запрос без предиката - т.е. создаст временную таблицу локально и по ней уже будет строиться выборка.

Индексы можно определить самостоятельно. Для этого используется конструкция

CREATE INDEX xxx ON nicname ( columns) SPECIFICATION ONLY

Работа NNSTAT по умолчанию заключается в том, что процедура пытается определить характеристики источника. Если это DB2 - просто скопирует статистику. Если нет, то будет строить статистику самостоятельно - тут будет не самый оптимальный алгоритм, и может быть весьма тяжелым. У нас никнеймы на AS400, база на LUW. На AS400, хоть и таблицы со статистикой практически идентичны с DB2 LUW, заполнено очень мало полей. Я немного поковырялся, но руки до написания замены nnstat не дошли.
Чтобы не нагружать продуктивную систему приходится собирать статистику на копии и потом переносить на прод.

Andy
...
Рейтинг: 0 / 0
13.02.2013, 09:34
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38148907
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
>>A.Panskikh,
Спасибо! У меня тогда такой вопрос - если на таблице источнике (таблица DB2) - собирается статистика (RUNSTAT) раз в сутки , и построены нужные индексы. Нужно ли для NICKNAME собирать статистику c помощью NNSTAT (возможно чаще) и строить точно такие же индексы?
...
Рейтинг: 0 / 0
13.02.2013, 09:57
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38149430
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
medoed,

В дополнение.
Если на источнике статистика актуальна, то NNSTAT в режиме копирования статистики - то, что нужно.
Очевидно, пускать его чаще, чем статистика собирается на источнике, не имеет смысла (будут просто копироваться необновлённые значения).
Если статистика к никнейму на приёмнике более-менее актуальна/планы запросов устраивают, то и морочиться с ней особо не нужно.

Если на источнике происходили более-менее существенные преобразования структур данных и/или добавлялись/удалялись индексы, то проще никнейм грохнуть и пересоздать заново (предварительно польностью актуализировав локальную статистику). При повторном создании будут вытащены все определения индексов и статистика.
Зависимые от никнейма объекты ревалидируются при последующем обращении, но можно (лучше) сделать это самостоятельно:
Код: sql
1.
call admin_revalidate_db_objects();
...
Рейтинг: 0 / 0
13.02.2013, 13:50
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38149491
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
CawaSPb, Спасибо!

Остался один маленький вопрос:

>> На nickname создавать такие же индексы , как и на источнике один в один ( с опцией SPECIFICATION ONLY)?
...
Рейтинг: 0 / 0
13.02.2013, 14:07
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38149918
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
medoedМы делаем обновление MQT командой:
Код: plsql
1.
refresh table TEMPSCH.MQT_T

.
На больших таблицах идёт от 1-ой до 5ти минут. У пользователей работающих в это время на базе возникают блокировки. Как можно избежать таких блокировок?Доступ к каким именно данным блокируется?
Решение может зависит от того, можно ли создать MQT со staging таблицами, например...
...
Рейтинг: 0 / 0
13.02.2013, 16:59
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38149982
CawaSPb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CawaSPb
Участник
medoedОстался один маленький вопрос:

>> На nickname создавать такие же индексы , как и на источнике один в один ( с опцией SPECIFICATION ONLY)?

При пересоздании никнейма все определения индексов вытащатся и создадутся автоматически.

PS Для никнеймов индексы только "SPECIFICATION ONLY" и бывают. Это только подсказки оптимизатору.
...
Рейтинг: 0 / 0
13.02.2013, 17:31
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38150239
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
CawaSPbmedoedОстался один маленький вопрос:

>> На nickname создавать такие же индексы , как и на источнике один в один ( с опцией SPECIFICATION ONLY)?

При пересоздании никнейма все определения индексов вытащатся и создадутся автоматически.

PS Для никнеймов индексы только "SPECIFICATION ONLY" и бывают. Это только подсказки оптимизатору.
Спасибо, теперь насчет индексов все более менее ясно.
...
Рейтинг: 0 / 0
13.02.2013, 20:09
| Ответить | Цитировать | Написать  
Оптимизация запроса (теория)
    #38150354
Фотография medoed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
medoed
Участник
Mark BarinsteinmedoedМы делаем обновление MQT командой:
Код: plsql
1.
refresh table TEMPSCH.MQT_T

.
На больших таблицах идёт от 1-ой до 5ти минут. У пользователей работающих в это время на базе возникают блокировки. Как можно избежать таких блокировок?Доступ к каким именно данным блокируется?
Решение может зависит от того, можно ли создать MQT со staging таблицами, например...
Имеем две базы db2 на одном инстансе. На 1-ой базе сама таблица T. На второй базе MQT_T основанная, на NICKNAME, (select* from T). Например если во второй базе пользователи одновременно берут данные из MQT_T и одновременно проходит системный refresh MQT_T, то происходят локи.Тоесть блокируются в основном запросы использующие MQT! Про staging таблицы я не читал, почитаю...
...
Рейтинг: 0 / 0
13.02.2013, 22:21
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Оптимизация запроса (теория)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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