|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
База ASE15. Периодически простейшие запросы у заказчика начинают сильно тормозить. Вот типичный пример: Таблица: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Код: plaintext 1. 2. 3. 4. 5. 6. 7.
План запроса у заказчика, в таблице AOBATOP 24млн записей: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
План запроса на базе разработчика, в таблице AOBATOP 3млн записей: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
В чем может быть причина тупизны и работы через table scan? Может есть смысл на ночь запускать перестройку индексов каждый раз? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 16:41 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
а индекс то у заказчика есть? может дропнули случайно? а его селективность для данных значений какая? что у заказчика с этим ? Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 17:02 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-n wrote: Тут не срабатывает применение OR-strategy почему-то. Сколько вообще записей удовлетворяет в таблице AOBATOP условию WHERE AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013) ? На тестовом и рабочем серверах данные одинаковые ? Запускается в тестовом случае РОВНО ТАКОЙ ЖЕ запрос ? Точные причины, почему не выбирается индекс для запроса вам нужно узнавать путём простановки трейс-флагов по выборке индексов оптимизатором. Не помню, какой номер. > Каждую ночь выполняется update all statistics для этой таблицы у заказчика. OPTDIAG не пускали на боевой сервер ? Есть там статистика ИМЕННО ПО ЭТОМУ ПОЛЮ ? Может есть > смысл на ночь запускать перестройку индексов каждый раз? Именно перестройку индексов вообще никогда нет смысла запускать. Разве что раз в год чтобы индекс сжать (убрать фрагментацию). update XXX statistics -- может быть есть смысл, если таблица сильно меняется за день. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:04 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
komradа индекс то у заказчика есть? может дропнули случайно? Точно есть, да и проблема не только в данном случае, перидически начинают тормозить подобные простейшие запросы. И проблема во внезапно возникающем table scan при том, что для поля есть индекс. а его селективность для данных значений какая? Селективность хорошая для значений из in может быть максимум с десяток записей. komrad что у заказчика с этим ? Код: plaintext
К сожалению индекс по двум полям был разбит на 2 индекса по отдельности и проблема ушла. В следующий раз посмотрю. А что может быть c sp_spaceused? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:08 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
В таких случаях жёстко прописывал абстрактный план. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:08 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-n wrote: > Точно есть, да и проблема не только в данном случае, перидически > начинают тормозить подобные простейшие запросы. 1) Не такой он и простой, как тебе кажется. Тут нужно оптимизатору решить, применять ли OR-стратегию И проблема во внезапно > возникающем table scan при том, что для поля есть индекс. 2) а такие проблемы бывают вообще повсеместно. И не только в ASE. Оптимизатор стоимостной, что ж ты хочешь ? > К сожалению индекс по двум полям был разбит на 2 индекса по отдельности > и проблема ушла. В следующий раз посмотрю. По каким таким 2-м полям ? Ты вообще давай-ка лучше индксы показывай, какие там есть. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:12 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
MasterZiv Eugene-n wrote: Тут не срабатывает применение OR-strategy почему-то. Сколько вообще записей удовлетворяет в таблице AOBATOP условию WHERE AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013) ? До 20-30, каждому номеру где-то по 5-10. На тестовом и рабочем серверах данные одинаковые ? Запускается в тестовом случае РОВНО ТАКОЙ ЖЕ запрос ? Данные совсем разные. Бекап у заказчика получить нельзя и прямой доступ к базе получить тоже нельзя. Через переписку получаю планы запросов и.т.д. OPTDIAG не пускали на боевой сервер ? Есть там статистика ИМЕННО ПО ЭТОМУ ПОЛЮ ? Попробую. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:38 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
MasterZiv > К сожалению индекс по двум полям был разбит на 2 индекса по отдельности > и проблема ушла. В следующий раз посмотрю. По каким таким 2-м полям ? Ты вообще давай-ка лучше индксы показывай, какие там есть. Один уникальный индекс по AObjOpAttr_SysNo Один уникальный был по двум полям 1 поле: AObjOpAttr_AOBOPRef, 2 поле: AObjOpAttr_VOATTRAssc. Теперь стало 3 индекса по 3 полям: AObjOpAttr_SysNo уникальный AObjOpAttr_AOBOPRef не уникальный AObjOpAttr_VOATTRAssc не уникальный ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2010, 18:44 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-n wrote: > условию > WHERE > AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013) > До 20-30, каждому номеру где-то по 5-10. Забыл спросить очевидное. Сама таблица-то большая, конечно ? (AOBATOP) > На тестовом и рабочем серверах данные одинаковые ? Запускается в тестовом > случае РОВНО ТАКОЙ ЖЕ запрос ? > > > Данные совсем разные. Так тогда не удивительно, что планы разные. Разные данные -- разные статистики, разные планы. Бекап у заказчика получить нельзя и прямой доступ > к базе получить тоже нельзя. Через переписку получаю планы запросов и.т.д. Ну... в таких условиях вообще нельзя работать DBA. Не дело это. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 08:26 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-n wrote: > Один уникальный индекс по AObjOpAttr_SysNo Этого поля в запросе не было. > Один уникальный был по двум полям 1 поле: AObjOpAttr_AOBOPRef, 2 поле: > AObjOpAttr_VOATTRAssc. Ты бы DDL давал, а то я так только приблизительно понимать могу. > Теперь стало 3 индекса по 3 полям: > AObjOpAttr_SysNo уникальный > AObjOpAttr_AOBOPRef не уникальный > AObjOpAttr_VOATTRAssc не уникальный А почему индексы меняли ? Что-то мне уже перестаёт нравится этот разговор. Ты что сейчас хочешь ? Выяснить, почему "периодически простейшие запросы у заказчика начинают сильно тормозить" ? Тормозят не все запросы, а конкретный запрос, каждый конкретный запрос тормозит по-своему и по своим конкретным причинам, и именно с каждым запросом надо разбираться. Нельзя решить сразу все проблемы. Т.е. надо брать конкретный запрос, таблицу, DDL её, с индексами, планы, и смотреть. А если у тебя сегодня одни индексы, завтра -- другие совсем, послезавтра -- третьи -- это у тебя и запросы будут вести себя каждый раз по-разному. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 08:34 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-n, Проверьте включен ли у заказчика statement cache? Какой будет план у заказчика, если перед выполнением запроса сделать Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 08:40 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-nkomradа индекс то у заказчика есть? может дропнули случайно? Точно есть, да и проблема не только в данном случае, перидически начинают тормозить подобные простейшие запросы. И проблема во внезапно возникающем table scan при том, что для поля есть индекс. а его селективность для данных значений какая? Селективность хорошая для значений из in может быть максимум с десяток записей. десяток записей на 24 млн записей! имхо, кол-во шагов статистики (histogram steps) может быть таким (малым) и, как следствие, вес диапазона значений, в который попадают SARG, может быть таким большим, что поиск достаточно уникальных значений сервер мог делать не через index seek, а через table scan надо смотреть таблицу opdiag-ом. Eugene-n А что может быть c sp_spaceused? этот запрос показал бы размер таблицы и индексов приблизительно стало бы понятно соотношение весов "данные-индексы" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 10:50 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
komrad wrote: > десяток записей на 24 млн записей! > имхо, > кол-во шагов статистики (histogram steps) может быть таким (малым) > и, > как следствие, > вес диапазона значений, в который попадают SARG, может быть таким большим, > > что поиск достаточно уникальных значений сервер мог делать не через > index seek, а через table scan > > надо смотреть таблицу opdiag-ом. Ты не перепутал ? По идее внутри диапазона должна приниматься гипотеза о равномерном распределении и вычисляться, сколько записей падает НА ОДНО ЗНАЧЕНИЕ поля, а не НА ВЕСЬ ДИАПАЗОН. Т.е. кол-во записей в диапазоне делиться на кол-во уникальных значений в диапазоне. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 12:36 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
MasterZiv Ты не перепутал ? По идее внутри диапазона должна приниматься гипотеза о равномерном распределении и вычисляться, сколько записей падает НА ОДНО ЗНАЧЕНИЕ поля, а не НА ВЕСЬ ДИАПАЗОН. Т.е. кол-во записей в диапазоне делиться на кол-во уникальных значений в диапазоне. Understanding histogram output цитатаAdaptive Server uses equi-height histograms, where the number of rows represented by each cell is approximately equal. в общем - диапазоны и их плотности если кол-во диапазонов мало, то и трудоемкость поиска по ним велика по умолчанию - 20 шагов, а это потенциально (мы ведь не знаем уникальности значений в столбце)на 24 млн - по 1200000 значений на диапазон Весьма вероятно, конечно, что и 20 шагов достаточно, но реальных данных нет. Поэтому трудно определенно сказать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 12:54 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Та, что вы мучаетесь, "обхинтуйте" запрос и все. SELECT AOBATOP.AObjOpAttr_AOBOPRef,AOBATOP.AObjOpAttr_Val,AOBATOP.AObjOpAttr_Index, AOBATOP.AObjOpAttr_SysNo,AOBATOP.AObjOpAttr_VOATTRAssc FROM AOBATOP (index AK_AOBATOP) WHERE AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013) ORDER BY 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 14:28 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
komrad wrote: > в общем - диапазоны и их плотности > если кол-во диапазонов мало, то и трудоемкость поиска по ним велика > по умолчанию - 20 шагов, а это потенциально (мы ведь не знаем > уникальности значений в столбце)на 24 млн - по 1200000 значений на диапазон Что-то тебя совсем заносит. Как кол-во диапазонов гистограммы влияет на трудоёмкость поиска по индексу ? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2010, 16:32 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
What is T_ISYS type ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2010, 10:09 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2010, 13:04 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
komradMasterZiv, how many histogram steps? ну и до кучи : ASE 15 and the Optimizer Statistics – More Influential Than Ever ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2010, 13:17 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
cherrex_DenEugene-n, Проверьте включен ли у заказчика statement cache? Какой будет план у заказчика, если перед выполнением запроса сделать Код: plaintext
Удалось получить базу заказчика. Дело таки было в set statement_cache. Практически все запросы при включенном statement_cache идут либо table scan либо index scan positioning at index start. При выключении кеша запросы начинают работать нормально. Я не очень понимаю как такое может быть. Кеш находится в памяти, по идее после перезагрузки базы данных, вроде все должно идти с чистого листа. Или этот кеш хранится в каких-то сиcтемных таблицах и пришел вместе с базой? Какой-то театр абсурда пока. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2010, 15:47 |
|
Периодические тормоза на простых запросах у ASE15
|
|||
---|---|---|---|
#18+
Eugene-ncherrex_DenEugene-n, Проверьте включен ли у заказчика statement cache? Какой будет план у заказчика, если перед выполнением запроса сделать Код: plaintext
Удалось получить базу заказчика. Дело таки было в set statement_cache. Практически все запросы при включенном statement_cache идут либо table scan либо index scan positioning at index start. При выключении кеша запросы начинают работать нормально. Я не очень понимаю как такое может быть. Кеш находится в памяти, по идее после перезагрузки базы данных, вроде все должно идти с чистого листа. Или этот кеш хранится в каких-то сиcтемных таблицах и пришел вместе с базой? Какой-то театр абсурда пока. После перезагрузки сервера у меня кэш очищается, а что такое "после перезагрузки базы данных ", это я не знаю. Этот процесс легко проверить через мониторную таблицу monCachedStatement . Также там можно увидеть кто и когда закэшировал конкретный стэйтмент. Ну и show_cached_plan и show_cached_text в помощь. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2010, 20:17 |
|
|
start [/forum/topic.php?fid=55&msg=36754215&tid=2010541]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 320ms |
total: | 475ms |
0 / 0 |