powered by simpleCommunicator - 2.0.57     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Периодические тормоза на простых запросах у ASE15
21 сообщений из 21, страница 1 из 1
Периодические тормоза на простых запросах у ASE15
    #36753020
Eugene-n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
База ASE15.
Периодически простейшие запросы у заказчика начинают сильно тормозить. Вот типичный пример:
Таблица:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE AOBATOP
    (
        AObjOpAttr_SysNo T_ISYS,
        AObjOpAttr_AOBOPRef T_ISYS,
        AObjOpAttr_VOATTRAssc T_ISYS,
        AObjOpAttr_Val LONG_DESC,
        AObjOpAttr_Index SMALLINT NULL,
        CONSTRAINT PK_AOBATOP PRIMARY KEY (AObjOpAttr_SysNo),
        CONSTRAINT AK_AOBATOP UNIQUE (AObjOpAttr_AOBOPRef, AObjOpAttr_VOATTRAssc)
    );
Запрос:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SELECT
    AOBATOP.AObjOpAttr_AOBOPRef,AOBATOP.AObjOpAttr_Val,AOBATOP.AObjOpAttr_Index,
  AOBATOP.AObjOpAttr_SysNo,AOBATOP.AObjOpAttr_VOATTRAssc
FROM
    AOBATOP
WHERE
    AOBATOP.AObjOpAttr_AOBOPRef IN ( 1000000431294 , 1000000437048 , 804000000647013 )
ORDER BY  1 


План запроса у заказчика, в таблице AOBATOP 24млн записей:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
|ROOT:EMIT Operator (VA =  3 )
       |
       |   |SORT Operator (VA =  2 )
       |   | Average Row width is  44 . 584686 
       |   | Using Worktable1 for internal storage.
       |   |
       |   |   |RESTRICT Operator (VA =  1 )( 0 )( 0 )( 0 )( 1 )( 0 )
       |   |   |
       |   |   |   |SCAN Operator (VA =  0 )
       |   |   |   |  FROM TABLE
       |   |   |   |  AOBATOP
       |   |   |   |  Table Scan.
       |   |   |   |  Forward Scan.
       |   |   |   |  Positioning at start of table.
       |   |   |   |  Using I/O Size  64  Kbytes for data pages.
       |   |   |   |  With MRU Buffer Replacement Strategy for data pages

План запроса на базе разработчика, в таблице 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.
|ROOT:EMIT Operator (VA =  4 )
       |
       |   |NESTED LOOP JOIN Operator (VA =  3 ) (Join Type: Inner Join)
       |   |
       |   |   |SCAN Operator (VA =  0 )
       |   |   |  FROM OR List
       |   |   |  OR List has up to  3  rows of OR/IN values.
       |   |
       |   |   |RESTRICT Operator (VA =  2 )( 0 )( 0 )( 0 )( 10 )( 0 )
       |   |   |
       |   |   |   |SCAN Operator (VA =  1 )
       |   |   |   |  FROM TABLE
       |   |   |   |  AOBATOP
       |   |   |   |  Index : AK_AOBATOP
       |   |   |   |  Forward Scan.
       |   |   |   |  Positioning by key.
       |   |   |   |  Keys are:
       |   |   |   |    AObjOpAttr_AOBOPRef ASC
       |   |   |   |  Using I/O Size  2  Kbytes for index leaf pages.
       |   |   |   |  With LRU Buffer Replacement Strategy for index leaf pages.
       |   |   |   |  Using I/O Size  2  Kbytes for data pages.
       |   |   |   |  With LRU Buffer Replacement Strategy for data pages.
Каждую ночь выполняется update all statistics для этой таблицы у заказчика.
В чем может быть причина тупизны и работы через table scan? Может есть смысл на ночь запускать перестройку индексов каждый раз?
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753066
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а индекс то у заказчика есть? может дропнули случайно?
а его селективность для данных значений какая?

что у заказчика с этим ?
Код: plaintext
sp_spaceused AOBATOP, 1 
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753207
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753214
Eugene-n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
komradа индекс то у заказчика есть? может дропнули случайно?

Точно есть, да и проблема не только в данном случае, перидически начинают тормозить подобные простейшие запросы. И проблема во внезапно возникающем table scan при том, что для поля есть индекс.


а его селективность для данных значений какая?

Селективность хорошая для значений из in может быть максимум с десяток записей.

komrad
что у заказчика с этим ?
Код: plaintext
sp_spaceused AOBATOP, 1 

К сожалению индекс по двум полям был разбит на 2 индекса по отдельности и проблема ушла. В следующий раз посмотрю.
А что может быть c sp_spaceused?
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753215
rmka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В таких случаях жёстко прописывал абстрактный план.
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753219
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Eugene-n wrote:

> Точно есть, да и проблема не только в данном случае, перидически
> начинают тормозить подобные простейшие запросы.

1) Не такой он и простой, как тебе кажется.
Тут нужно оптимизатору решить, применять ли OR-стратегию

И проблема во внезапно
> возникающем table scan при том, что для поля есть индекс.

2) а такие проблемы бывают вообще повсеместно. И не только в ASE.
Оптимизатор стоимостной, что ж ты хочешь ?


> К сожалению индекс по двум полям был разбит на 2 индекса по отдельности
> и проблема ушла. В следующий раз посмотрю.

По каким таким 2-м полям ?
Ты вообще давай-ка лучше индксы показывай, какие там есть.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753259
Eugene-n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv
Eugene-n wrote:

Тут не срабатывает применение OR-strategy почему-то.

Сколько вообще записей удовлетворяет в таблице AOBATOP

условию
WHERE
AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013)

?

До 20-30, каждому номеру где-то по 5-10.


На тестовом и рабочем серверах данные одинаковые ? Запускается в тестовом
случае РОВНО ТАКОЙ ЖЕ запрос ?

Данные совсем разные. Бекап у заказчика получить нельзя и прямой доступ к базе получить тоже нельзя. Через переписку получаю планы запросов и.т.д.



OPTDIAG не пускали на боевой сервер ?
Есть там статистика ИМЕННО ПО ЭТОМУ ПОЛЮ ?

Попробую.
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753272
Eugene-n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv
> К сожалению индекс по двум полям был разбит на 2 индекса по отдельности
> и проблема ушла. В следующий раз посмотрю.

По каким таким 2-м полям ?
Ты вообще давай-ка лучше индксы показывай, какие там есть.

Один уникальный индекс по AObjOpAttr_SysNo
Один уникальный был по двум полям 1 поле: AObjOpAttr_AOBOPRef, 2 поле: AObjOpAttr_VOATTRAssc.
Теперь стало 3 индекса по 3 полям:
AObjOpAttr_SysNo уникальный
AObjOpAttr_AOBOPRef не уникальный
AObjOpAttr_VOATTRAssc не уникальный
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753633
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Eugene-n wrote:

> условию
> WHERE
> AOBATOP.AObjOpAttr_AOBOPRef IN (1000000431294,1000000437048,804000000647013)

> До 20-30, каждому номеру где-то по 5-10.

Забыл спросить очевидное. Сама таблица-то большая, конечно ? (AOBATOP)

> На тестовом и рабочем серверах данные одинаковые ? Запускается в тестовом
> случае РОВНО ТАКОЙ ЖЕ запрос ?
>
>
> Данные совсем разные.

Так тогда не удивительно, что планы разные. Разные данные -- разные
статистики, разные планы.

Бекап у заказчика получить нельзя и прямой доступ
> к базе получить тоже нельзя. Через переписку получаю планы запросов и.т.д.

Ну... в таких условиях вообще нельзя работать DBA.
Не дело это.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753639
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753641
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Eugene-n,

Проверьте включен ли у заказчика statement cache?
Какой будет план у заказчика, если перед выполнением запроса сделать
Код: plaintext
set statement_cache off
?
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36753879
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Eugene-nkomradа индекс то у заказчика есть? может дропнули случайно?

Точно есть, да и проблема не только в данном случае, перидически начинают тормозить подобные простейшие запросы. И проблема во внезапно возникающем table scan при том, что для поля есть индекс.


а его селективность для данных значений какая?

Селективность хорошая для значений из in может быть максимум с десяток записей.

десяток записей на 24 млн записей!
имхо,
кол-во шагов статистики (histogram steps) может быть таким (малым)
и,
как следствие,
вес диапазона значений, в который попадают SARG, может быть таким большим,

что поиск достаточно уникальных значений сервер мог делать не через index seek, а через table scan

надо смотреть таблицу opdiag-ом.


Eugene-n
А что может быть c sp_spaceused?
этот запрос показал бы размер таблицы и индексов
приблизительно стало бы понятно соотношение весов "данные-индексы"
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36754215
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
komrad wrote:
> десяток записей на 24 млн записей!
> имхо,
> кол-во шагов статистики (histogram steps) может быть таким (малым)
> и,
> как следствие,
> вес диапазона значений, в который попадают SARG, может быть таким большим,

>
> что поиск достаточно уникальных значений сервер мог делать не через
> index seek, а через table scan
>
> надо смотреть таблицу opdiag-ом.

Ты не перепутал ?
По идее внутри диапазона должна приниматься гипотеза о равномерном
распределении и вычисляться, сколько записей падает НА ОДНО ЗНАЧЕНИЕ
поля, а не НА ВЕСЬ ДИАПАЗОН. Т.е. кол-во записей в диапазоне
делиться на кол-во уникальных значений в диапазоне.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36754263
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 шагов достаточно, но реальных данных нет. Поэтому трудно определенно сказать.
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36754536
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Та, что вы мучаетесь, "обхинтуйте" запрос и все.

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
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36754950
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
komrad wrote:

> в общем - диапазоны и их плотности
> если кол-во диапазонов мало, то и трудоемкость поиска по ним велика
> по умолчанию - 20 шагов, а это потенциально (мы ведь не знаем
> уникальности значений в столбце)на 24 млн - по 1200000 значений на диапазон

Что-то тебя совсем заносит. Как кол-во диапазонов гистограммы влияет
на трудоёмкость поиска по индексу ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36757619
Фотография Zhora
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
What is T_ISYS type ?
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36759311
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36759356
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36836267
Eugene-n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
cherrex_DenEugene-n,

Проверьте включен ли у заказчика statement cache?
Какой будет план у заказчика, если перед выполнением запроса сделать
Код: plaintext
set statement_cache off
?
Удалось получить базу заказчика.
Дело таки было в set statement_cache. Практически все запросы при включенном statement_cache идут либо table scan либо index scan positioning at index start. При выключении кеша запросы начинают работать нормально.
Я не очень понимаю как такое может быть. Кеш находится в памяти, по идее после перезагрузки базы данных, вроде все должно идти с чистого листа. Или этот кеш хранится в каких-то сиcтемных таблицах и пришел вместе с базой?
Какой-то театр абсурда пока.
...
Рейтинг: 0 / 0
Периодические тормоза на простых запросах у ASE15
    #36838862
cherrex_Den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Eugene-ncherrex_DenEugene-n,

Проверьте включен ли у заказчика statement cache?
Какой будет план у заказчика, если перед выполнением запроса сделать
Код: plaintext
set statement_cache off
?
Удалось получить базу заказчика.
Дело таки было в set statement_cache. Практически все запросы при включенном statement_cache идут либо table scan либо index scan positioning at index start. При выключении кеша запросы начинают работать нормально.
Я не очень понимаю как такое может быть. Кеш находится в памяти, по идее после перезагрузки базы данных, вроде все должно идти с чистого листа. Или этот кеш хранится в каких-то сиcтемных таблицах и пришел вместе с базой?
Какой-то театр абсурда пока.

После перезагрузки сервера у меня кэш очищается, а что такое "после перезагрузки базы данных ", это я не знаю.

Этот процесс легко проверить через мониторную таблицу monCachedStatement .
Также там можно увидеть кто и когда закэшировал конкретный стэйтмент.
Ну и show_cached_plan и show_cached_text в помощь.
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Периодические тормоза на простых запросах у ASE15
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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