одинаковые запросы
dmitry grebeniuk
Есть некоторый тяжёлый sql-запрос. Замечено на практике,
что если его выполняют два пользователя одновременно, запрос
выполняется гораздо дольше, чем если бы его выполняли
последовательно. При этом, если выполняется чуть другой
запрос (хотя основные таблицы те же, и сложность запроса
та же), то таких тормозов не наблюдается.
Подскажите, это мне только кажется, или такое может быть,
на самом деле? Если может быть, то почему и как такое
поправить?
--
С уважением,
dmitry mailto:gds-...@moldavcable.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Oleg Vershinin
> Здравствуйте, All.
>
> Есть некоторый тяжёлый sql-запрос. Замечено на практике,
> что если его выполняют два пользователя одновременно, запрос
> выполняется гораздо дольше, чем если бы его выполняли
> последовательно. При этом, если выполняется чуть другой
> запрос (хотя основные таблицы те же, и сложность запроса
> та же), то таких тормозов не наблюдается.
> Подскажите, это мне только кажется, или такое может быть,
> на самом деле? Если может быть, то почему и как такое
> поправить?
>
А нет ли внутри тяжелого запроса вызовов функций с автономными
транзакциями, которые, например, пишут в протокол. Или функций,
содержащих execute immediate/dbms_sql?
В одном случае - блокировки за данные, в другом - за shared pool.
Если нет, то проблема возможно в постоянном выполнении разбора (parse)
этого запроса и конкуренции за library cache latches (это если 2-й и
последующие исполнения запросов так же медленны). Причины этого могут
быть самые разные.
Можно запустить трассировку для обеих сессий (там будет видно parse
count, после tkprof), ну и/или всякие системные представления
посмотреть, типа v$mystat, для каждой сессии до и после запроса.
И, как обычно, телепаты в отпуске :-)
--
Oleg Vershinin
dmitry grebeniuk
Вы писали 3 июля 2007 г., 15:44:41:
OV> А нет ли внутри тяжелого запроса вызовов функций
OV> с автономными транзакциями, которые, например,
OV> пишут в протокол.
Кажется, так оно и есть.
Однако таблица одна и та же, поэтому не понятно
различие для чуть разных запросов (которые выполняются
вместе быстрее, чем два одинаковых).
Тормоза из-за shared pool или library cache latches
маловероятны, однако проверю с помощью трассировки
либо statspack'ом, если словлю.
А вообще, как бороться с блокировками за данные в
подобных случаях, когда две разные сессии выполняют
insert в одну таблицу? Блокировать таблицу
не предлагать, жестоко выйдет.
OV> И, как обычно, телепаты в отпуске :-)
Обычно телепатов и не надо: вот конкретно сейчас
Вашего мнения хватило. Или Вы из отпуска пишете
в фидошку? :)
Oleg Vershinin
> Здравствуйте, Oleg.
>
> Вы писали 3 июля 2007 г., 15:44:41:
>
> OV> А нет ли внутри тяжелого запроса вызовов функций
> OV> с автономными транзакциями, которые, например,
> OV> пишут в протокол.
>
> Кажется, так оно и есть.
Если оно действительно так и есть, и функция находится
в WHERE, а не в SELECT ...
> Однако таблица одна и та же, поэтому не понятно
> различие для чуть разных запросов (которые выполняются
> вместе быстрее, чем два одинаковых).
то для одного запроса оптимизатор может вызвать функцию
во where один раз, а для другого - столько, сколько строк
в таблице, по которой накладывается ограничение.
> А вообще, как бороться с блокировками за данные в
> подобных случаях, когда две разные сессии выполняют
> insert в одну таблицу? Блокировать таблицу
> не предлагать, жестоко выйдет.
Удалить ( по _возможности_ и/или _необходимости_ ) то, что является
причиной блокировки: PRIMARY KEY, UNIQUE CONSTRAINT, триггеры,
выполняющие сходные функции.
Также см. параметр INITRANS в CREATE TABLE
>
> OV> И, как обычно, телепаты в отпуске :-)
Ты бы запрос показал, что-ли :-)
--
Oleg Vershinin
dmitry grebeniuk
Вы писали 4 июля 2007 г., 6:32:59:
>> Кажется, так оно и есть.
OV> Если оно действительно так и есть, и функция находится
OV> в WHERE, а не в SELECT ...
Это понятно.
OV> Также см. параметр INITRANS в CREATE TABLE
Во. Судя по описанию параметра, он мне поможет.
>> OV> И, как обычно, телепаты в отпуске :-)
OV> Ты бы запрос показал, что-ли :-)
Там страшно. Лучше я разберусь сам.
Спасибо за помощь.
Andrey Maximenko
OV>>> А нет ли внутри тяжелого запроса вызовов функций
OV>>> с автономными транзакциями, которые, например,
OV>>> пишут в протокол.
??>>
??>> Кажется, так оно и есть.
грустно и тяжело...
OV> Если оно действительно так и есть, и функция находится
OV> в WHERE, а не в SELECT ...
??>> Однако таблица одна и та же, поэтому не понятно
??>> различие для чуть разных запросов (которые выполняются
??>> вместе быстрее, чем два одинаковых).
OV> то для одного запроса оптимизатор может вызвать функцию
OV> во where один раз, а для другого - столько, сколько строк
OV> в таблице, по которой накладывается ограничение.
??>> А вообще, как бороться с блокировками за данные в
??>> подобных случаях, когда две разные сессии выполняют
??>> insert в одну таблицу? Блокировать таблицу
??>> не предлагать, жестоко выйдет.
OV> Удалить ( по _возможности_ и/или _необходимости_ ) то, что является
OV> причиной блокировки: PRIMARY KEY, UNIQUE CONSTRAINT, триггеры,
OV> выполняющие сходные функции.
1. Удалить PRIMARY KEY и UNIQUE CONSTRAINT ??????????
2. А хотя бы версию Оракла можно и показать...
With best regards, Andrey Maximenko
Oleg Vershinin
> OV> Удалить ( по _возможности_ и/или _необходимости_ ) то, что является
> OV> причиной блокировки: PRIMARY KEY, UNIQUE CONSTRAINT, триггеры,
> OV> выполняющие сходные функции.
>
> 1. Удалить PRIMARY KEY и UNIQUE CONSTRAINT ??????????
А почему бы и нет, если это log-таблица, а ID для нее гарантированно
получается из SEQUENCE (если этот ID там действительно есть).
В данном случае - PK и UNIQUE могут быть причиной сериализации запросов.
Кстати, получение значения из SEQUENCE, у которого занижен CACHE,
тоже приводит к блокировкам.
Естественно, не предлагается удалить PK там, где он действительно нужен,
а также в случаях, где не определено, нужен он или нет.
Тут какой вопрос - такой и ответ :-)
--
Oleg Vershinin
dmitry grebeniuk
Вы писали 4 июля 2007 г., 8:15:21:
OV>> Удалить ( по _возможности_ и/или _необходимости_ ) то,
OV>> что является причиной блокировки: PRIMARY KEY, UNIQUE
OV>> CONSTRAINT, триггеры, выполняющие сходные функции.
AM> 1. Удалить PRIMARY KEY и UNIQUE CONSTRAINT ??????????
Между прочим, иногда можно. Сильно зависит от задачи.
Хотя в "классических" приложениях удалять их неприемлемо.
AM> 2. А хотя бы версию Оракла можно и показать...
9.2.0.3.0.
Впрочем, дальше я сам попробую, и, если вдруг ещё будут
вопросы по данной теме (про торможение одинаковых запросов),
я постараюсь собрать статистику и вообще предоставить
побольше конкретики.
Andrey Bоgdanov
OV> Удалить ( по _возможности_ и/или _необходимости_ ) то, что является
OV> причиной блокировки: PRIMARY KEY, UNIQUE CONSTRAINT, триггеры,
OV> выполняющие сходные функции.
Мешают не уникальные ключи сами по себе, а то что конкурирующие сеансы
добавляют в них записи с близкими значениями ключа (в результате чего
возникает конкуренция за изменение одних и тех же блоков индекса). Имеет смысл
либо строить реверсивный индекс, либо обеспечить вставку "существенно" разных
значений.
OV> Также см. параметр INITRANS в CREATE TABLE
Hу тут скорее параметр FREELISTS (также FREELIST GROUPS) поможет.
Решайте головоломки http://diogen.h1.ru