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

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

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

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

1) Правильно ли я понимаю, что эту процедуру надо запускать на той же базе, где и лежит источник.
2) Если у меня например 5-ть баз, в каждой из которых по одному NICNAME, связанных с источником - то обновится статистика для всех 5-ти баз?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2013, 11:09
    #38147348
Ivan Ivanich
Ivan Ivanich
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация запроса (теория)
1) Я, всё же полагаю, что запускать там где псевдоним.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2013, 11:14
    #38147361
medoed
medoed
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация запроса (теория)
Да я это напутал на радостях)) Конечно!
Иван, вы по всем сразу обновляете статистику или по выборочным и как часто?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2013, 11:23
    #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, 12:34
    #38147522
Ivan Ivanich
Ivan Ivanich
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация запроса (теория)
Mark BarinsteinNNSTAT запускаете с параметром METHOD=1 - брать статистику из каталога удалённой системы.


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

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

.
На больших таблицах идёт от 1-ой до 5ти минут. У пользователей работающих в это время на базе возникают блокировки. Как можно избежать таких блокировок?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2013, 21:13
    #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
| Ответить | Цитировать | Написать  
13.02.2013, 09:34
    #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:57
    #38148907
medoed
medoed
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация запроса (теория)
>>A.Panskikh,
Спасибо! У меня тогда такой вопрос - если на таблице источнике (таблица DB2) - собирается статистика (RUNSTAT) раз в сутки , и построены нужные индексы. Нужно ли для NICKNAME собирать статистику c помощью NNSTAT (возможно чаще) и строить точно такие же индексы?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2013, 13:50
    #38149430
CawaSPb
CawaSPb
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация запроса (теория)
medoed,

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

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

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

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

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

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

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

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

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

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

PS Для никнеймов индексы только "SPECIFICATION ONLY" и бывают. Это только подсказки оптимизатору.
Спасибо, теперь насчет индексов все более менее ясно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2013, 22:21
    #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
| Ответить | Цитировать | Написать  
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Оптимизация запроса (теория) / 25 сообщений из 25, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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