Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
19.12.2014, 11:56
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
Добрый день. Сразу скажу, что я не администратор DB2, а SAP Basis администратор. В компании САП крутится на ДБ2 (09.07.0007, OS Linux), к сожалению администратора БД нет, а с ней иногда случаются странные вещи и специалистов по ней как назло не найти... Ладно, перейду к сути проблемы. Есть запрос в ABAP'е к одной табличке, причем в условиях WHERE достаточно много значений. К этой табличке есть так же много стандартных индексов, причем в многих из них эти условия встречаются. По не понятной причине оптимизатор БД стал использовать "плохой" индекс и прямые чтения по этой табличке взлетели до небесь и процесс по сути встал. Пробовал пересобирать статистику, как по индексу, так и по табличке, не помогало. Помогало сделать rubuild index но теперь и это не помогает. Вот так этот запрос выглядит в БД: Код: sql 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. Оптимайзер использует индекс LOT со следующими полями: MANDT LOT_ID ACCOUNTING_CODE VALUATION_AREA VALUATION_CLASS Я считаю, что он должен использовать другой индекс, SEC с полями: MANDT CONTEXT ACCOUNTING_CODE VALUATION_AREA VALUATION_CLASS PORTFOLIO ACCOUNT_GROUP SECURITY_ACCOUNT SECURITY_ID А index adviser говорит вообще о третьем индексе FUT с полями: MANDT CONTEXT ACCOUNTING_CODE VALUATION_AREA VALUATION_CLASS POSITION_ACCOUNT SECURITY_ID FLAG_LONG_SHORT Я решил попробовать прописать в коде хинты на использование нужного мне индекса. Прочитал САПовские ноты 724614 - DB2-z/OS: Database hints in Open SQL as of Kernel Rel 6.20 150037 - Database hints in Open SQL for DB6 (DB2 for LUW) 868888 - DB6: Optimization Guidelines так же еще нашел ноты, где прямо в коде указывался хинт для db2. Честно говоря, как я не пробовал и не менял синтаксис, все равно хинт не работает и берет старый индекс. Исходный запрос в АБАПе выглядит так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. сейчас у меня такой синтаксис у хинта: Код: sql 1. пробовал менять DB2 на DB6, INDEX на SAP_INDEX, так же пробовал вот такой синтаксис (это в саповских нотах встречал) Код: sql 1. 2. 3. 4. ничего не помогло. Так же встретил упоминание, что должен быть включен какой-то параметр: авторDB2 ZPARM OPTHINTS must be set to YES но как там же написано, это до 9-й версии, выше 9-ки он включен по умолчанию Прошу помощи, как побороть этот недуг, очень надо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2014, 13:00
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
MerCOOL, Я не SAP специалист, но если у вас DB2 for Linux, Unix and Windows, а не DB2 for Z/OS, то вам везде надо использовать DB6, а не DB2. Судя по нотам, в ктороых описывается синтакис хинтов для DB2 for LUW в SAP, у вас должно быть: %_HINTS DB6 '<IXSCAN TABLE=''DIFT_POS_IDENT'' INDEX=''"DIFT_POS_IDENT~SEC"'' />' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2014, 13:11
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
И еще попробуйте использовать алиас таблицы, а не её имя. Код: sql 1. По крайней мере в натуральных хинтах в DB2 для запросоы с алиасами надо именно их использовать, а не имена самих таблиц. Не знаю, изменяет ли САП пользовательский хинт сам при трансляции его текста в DB2-шный синтаксис... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2014, 14:43
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
Mark Barinstein, Марк огромнейшее вам спасибо, с алиасом 'T_00' все заработало, теперь запрос летает! А можно как-то понять, почему он выбирает другой индекс? В оракле есть такое понятие, как качество индекса, может как-то можно и в ДБ2 это посмотреть и поправить без хинтов в коде? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.12.2014, 18:21
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
MerCOOL, На план запроса, конечно, много чего влияет, но вкратце так. Статистику по индексам можно посмотреть в: Код: sql 1. 2. 3. 4. 5. 6. там кардинальность (кол-во разных значений) как всего индекса, так и первых одного, двух, трех и четырех полей. В вашем случае эти индексы отличаются по большому счету 2-мя первыми полями, поэтому посмотрите, какие для них будут FIRSTKEYCARD, FIRST2KEYCARD, FULLKEYCARD. Кроме того, оно может смотреть на статистику распределения данных в этих полях Код: sql 1. 2. 3. 4. Большего, наверное, оно не может использовать (ну, еще может цену i/o исходя из размеров индексов), т.к. у вас параметры используются, т.е. на момент компиляции запроса непонятно, какие там актуальные значения будут. То, что вы можете попробовать, это заставить запрос компилироваться каждый раз при выполнении, когда актуальные значения будут известны. Наверное, это у САП делается хинтом со словами REOPT ALWAYS или как-то по-другому ему где-то в настройках этого запроса указывать. Либо попробовать собрать групповую статистику на пару полей типа: Код: sql 1. И посмотреть, что получится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2014, 10:18
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
Mark Barinstein, Результат первого запроса: Код: sql 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. А это второго: Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.12.2014, 20:27
|
|||
|---|---|---|---|
|
|||
SAP vs DB2, использование %_HINTS |
|||
|
#18+
MerCOOL, Код: sql 1. 2. 3. 4. Кардинальность всего индекса SEC гораздо выше, чем LOT, все поля индекса SEC в условиях выборки. Хотя для SEC первые 4 поля дают низкую кардинальность (всего 5 разных значений). Может быть, это и влияет на выбор оптимизатора. Тут можно сравнить планы запросов, использующих эти индексы, и посмотреть, как оно оценивает их стоимость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=43&tablet=1&tid=1600917]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
2ms |
| others: | 275ms |
| total: | 427ms |

| 0 / 0 |
