Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
Дано: Запросы по вставке данных из табличного представления в таблицу с колоночным кластерным индексом, выполняющиеся каждую ночь - сначала запись данных из вьюхи во временную таблицу, а из неё - в таблицу с columnstore. При этом, суммарное время выполнения запросов может колебаться от семнадцати минут до пяти часов. И самое интересное, число записей не коррелирует с временем выполнения запросов. Так как запросы запускаются ночью параллельно с заданием на бэкап всех баз, то вопрос - как может влиять процесс бэкапа базы на скорость выполнения запросов? Встретил на форуме http://www.sql.ru/forum/778661/backup-i-blokirovka-raboty-bazy мнение МуМуНапрямую бэкап не может приводить к блокировке а вот косвенно может приводить к блокировке на ресурсах. В результате бэкапа возникает высокая нагрузка в результате чего увеличивается среднее время транзакций и совместно с ними и время блокировок. И вот как это всё ускорить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 15:40 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryiИ самое интересное, число записей не коррелирует с временем выполнения запросов. Прямо шахерезада какая-то. Сказки рассказывает. Чо, 1 (одна) запись вставляется 5 часов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 16:11 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
вставлять в пустую таблицу без индексов в несколько потоков, затем создать индексы и переключить эту таблицу как секцию в целевую таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 16:12 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryi, ну и проблемы у вас могут быть отнюдь не на вставку, например, одна из таблиц вьюхи заблокирована ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 16:17 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryi, то есть неизвестно - на каком запросе появляются задержки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 16:40 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовDaniilSeryi, то есть неизвестно - на каком запросе появляются задержки? Нет. Завтра доработаю журналирование. КритикDaniilSeryi, ну и проблемы у вас могут быть отнюдь не на вставку, например, одна из таблиц вьюхи заблокирована Вот и у меня такие же подозрения, но тогда как эти блокировки отслеживать без создания лишней нагрузки на сервер? Так как нагрузка на продуктовый сервер мне не нужна, то, по идее, Profiler не подходит. Так как с кем из админов не поговоришь - все утверждают, что профайлер сильно грузит сервер. Другой вариант - sp_configure 'blocked process threshold (s)' + Extended Events. Про то, какую нагрузку создаст этот вариант - не в курсе. Кто подскажет? Третий вариант - раз в 10-15 минут дергать sp_who2 и записывать её отфильтрованный результат в базу. В принципе, можно совместить с получением кода блокированной и блокирующей сессий. Четвёртый вариант - периодическое дёрганье этого скрипта с записью в таблицу: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 17:58 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
aleks222DaniilSeryiИ самое интересное, число записей не коррелирует с временем выполнения запросов. Прямо шахерезада какая-то. Сказки рассказывает. Чо, 1 (одна) запись вставляется 5 часов? Были случаи когда полмиллиона строк вставлялись 5 часов, а два миллиона - 15 минут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 18:04 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryi, Натрави на сервер SQLBlocks, для начальной оценки масштабов блокировок хватит. Если админы знают о проблеме "17 минут-5 часов" и втирают, что профайлер будет сильно грузить сервер, то они либо ленивы, либо заинтересованы в том, чтобы проблема не исследовалась нормальными средствами - ночами майнят эфир :) Не совпадает ли 5 часов с полным бекапом баз, а минуты - с дифференциальными или логами? Не делается ли бекап на тот же диск, где лежат базы и где расположены файлы целевой таблицы? Не зависает ли еще какая-нибудь закачка на "много часов", которая выполняется как раз когда целевая табличка заполняется 5 часов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 18:25 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryiВстретил на форуме мнение Конечно, бакап потребляет ресурсы, и из за этого замедляются выполнение каких то других действий, требующих ресурсов, но объяснить этим колебания "от семнадцати минут до пяти часов" нельзя. Явно тут дело в блокировке какого то ресурса, типа блокировки схемы, при выделении нового сегмента для колумнстор индекса (не изучал, это на уровне фантазий). Вот некая информация о механизмах, блокировках, может, сумеете там что то почерпнуть: https://www.mssqltips.com/sqlservertip/4280/sql-server-2016-columnstore-index-enhancements--system-views-for-diskbased-tables/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 21:49 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryiДано: Запросы по вставке данных из табличного представления в таблицу с колоночным кластерным индексом, выполняющиеся каждую ночь - сначала запись данных из вьюхи во временную таблицу, а из неё - в таблицу с columnstore. При этом, суммарное время выполнения запросов может колебаться от семнадцати минут до пяти часов. И самое интересное, число записей не коррелирует с временем выполнения запросов. Так как запросы запускаются ночью параллельно с заданием на бэкап всех баз, то вопрос - как может влиять процесс бэкапа базы на скорость выполнения запросов? Встретил на форуме https://www.sql.ru/forum/778661/backup-i-blokirovka-raboty-bazy мнение МуМуНапрямую бэкап не может приводить к блокировке а вот косвенно может приводить к блокировке на ресурсах. В результате бэкапа возникает высокая нагрузка в результате чего увеличивается среднее время транзакций и совместно с ними и время блокировок. И вот как это всё ускорить? Извините, а полка у вас какая? Ну, дисковая подсистема? Шпиндели, на 4000 иопс суммарно, сферических, в вакууме? И вы запускаете бэкап пары десятков баз и параллельно со всем этим выгрузку и загрузку? Я правильно угадал? Ну, тогда ответ: "Процесс бэкапа баз будет влиять на скорость выполнения запросов - негативно". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 09:45 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryi, sp_whoisactive поставить в расписание, скажем, раз в 10 минут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 18:08 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryiТак как нагрузка на продуктовый сервер мне не нужна, то, по идее, Profiler не подходит. Так как с кем из админов не поговоришь - все утверждают, что профайлер сильно грузит сервер. Другой вариант - sp_configure 'blocked process threshold (s)' + Extended Events. Про то, какую нагрузку создаст этот вариант - не в курсе. Кто подскажет? А чё админы сами не настроят мониторинг? Так то это их работа. XEvents это самый легковесный и точный способ мониторинга блокировок. Немного нагрузки будет только в момент парсинга дурацкого XML. Если там вообще будет что просить. Запускать же что то каждые 15 минут - бред хотя бы потому, а что если блокировка длилась 3 минуты? Отслеживать так долгие запросы - да, ловить так блокировки я бы не стал. Профайлер только по блокировкам не намного хуже, но только не сам профайлер, а просто серверный трейс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 22:30 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
alexeyvgЯвно тут дело в блокировке какого то ресурса, типа блокировки схемы, при выделении нового сегмента для колумнстор индекса (не изучал, это на уровне фантазий).Телепат? Это может быть что угодно, включая слетающие периодически планы. Но блокировки конечно надо проверить. Кстати, совсем забыл. их де можно легко вытащить из логов system health. Даже не настраивая ничего предварительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 22:33 |
|
||
|
Как сократить максимальное время выполнения запроса?
|
|||
|---|---|---|---|
|
#18+
DaniilSeryi, Параллельный бэкап базы, в то время как другой процесс вставляет записи в таблицу этой базы - это просто мега-плохая идея! Вы пробовали потом такой бекап отресторить? Процедура будет идти весьма продолжительно, так как DBE в начале процедуры бекапа работает с базой как в модели FULL, и даже если она SIMPLE - то переключает ее неявно в данный режим, и дописывает все транзакции в журнал, что происходили от точки начала операции резервного копирования и в ее процессе. Если такой бекап потом восстанавливать - то на этапе 100% - DBE начинает накатывать те самые транзакции из журнала что, как сказано выше - может быть весьма долго и затратно. Если бекапы входят в DR-план, который надо по-хорошему тестировать время от времени - то есть риск не уложиться в RTO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2019, 08:57 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39848854&tid=1687404]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
152ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 239ms |
| total: | 503ms |

| 0 / 0 |
