Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
_human Member Откуда: Сообщений: 566 |
приветствую вопрос больше к DBA есть некий "тяжелый" запрос который согласно оценке завершиться дней через 30...) там чудо-курсор делающий merge в таблицу 20гб данных + 45гб индексов переписать ничего нельзя собсна, блокировок нет, паралельно ничего не выполняется, фрагментации нет, статистика обновлена, план выполнения ок. Microsoft SQL Server 2017 (RTM-GDR) (KB4293803) - 14.0.2002.14 (X64) Jul 21 2018 07:47:45 32гб ram 16 cores целевая БД хранится на диске HP LOGICAL VOLUME SCSI Maximum server memory 16295MB подскажите какие показатели/счетчики сервера стоит глянуть ? |
8 май 19, 14:53 [21881135] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
_human, в курсоре там позаписная обработка что ли? ну посмотрите общие ОС типа цпу, памяти, очереди к дискам, в сиквеле динамику PLE, к примеру , latency , динамику чекпойтов , кол-во батчей в секунду в errorlog гляньте на предмет delayed IO вот у товарища Глена Берри неплохая подборка диагностических скриптов https://www.sqlskills.com/blogs/glenn/category/dmv-queries/ |
8 май 19, 15:46 [21881253] Ответить | Цитировать Сообщить модератору |
_human Member Откуда: Сообщений: 566 |
komrad,
кусками размером от 20-50'000 Queue length в основном до 2-5-и когда пишет в 1-н файл БД, но бывает и до 20-50-и когда читает/пишет в 2-а о самом storage device инфы нет |
||
8 май 19, 21:27 [21881503] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
А вообще, если "переписать ничего нельзя", следует обращаться к производителю, вряд ли выполнение процедуры за 30 дней - это нормально. |
||
8 май 19, 21:30 [21881505] Ответить | Цитировать Сообщить модератору |
_human Member Откуда: Сообщений: 566 |
alexeyvg, сейчас создаются индексы активная запись в файл БД и лог. очередь до 2000 Response time прыгает 500-600 ms насколько эти показатели вписываются в нормальные показатели ? есть подозрение что оптимизированный код не даст прироста в производительности |
8 май 19, 22:03 [21881520] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34762 Блог |
_human, Если оптимизированный код уберет ваши узкие места, то почему бы и нет? |
8 май 19, 22:53 [21881545] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
+ посмотрите какие waits у вас набегают в процессе работы запроса/сессии https://www.mssqltips.com/sqlservertip/4078/getting-per-session-wait-statistics-in-sql-server-2016/ |
||||
8 май 19, 23:06 [21881553] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
|
||||
8 май 19, 23:28 [21881556] Ответить | Цитировать Сообщить модератору |
_human Member Откуда: Сообщений: 566 |
komrad,
alexeyvg, единственное наколенное решение это ручками переместить весь этот обьем ручками - партиционирование, благо версия позволяет |
|
10 май 19, 11:30 [21882066] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 419 |
Действительно. Если 60 Гб да на 30 дней... Значится 2 Гб в день... 83 мб в час... 1 мб в минуту...
У вас там сервер картошку не чистит параллельно с перекурами? |
||||
10 май 19, 21:05 [21882254] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
судя по данным, у вас сессия сканирует что-то большое (таблица/индекс), которое находится полностью в буфере к подобному может приводить неоптимальный план запроса (nested loops vs hash/merge joins) из-за устаревшей статистики, например |
|||
13 май 19, 12:01 [21883195] Ответить | Цитировать Сообщить модератору |
_human Member Откуда: Сообщений: 566 |
komrad, Так и есть, Только там статистика актуальная А код кривой |
13 май 19, 14:19 [21883380] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
попробуйте ради интереса тот же самый запрос выполнить с хинтом option (maxdop 1, recompile) шанс невелик, но может и быстрее сработать |
||
13 май 19, 14:43 [21883425] Ответить | Цитировать Сообщить модератору |
_human Member Откуда: Сообщений: 566 |
komrad,
1-е что попробовал :D 30+ дней там веб дев sql код написал.. case closed |
||
13 май 19, 15:27 [21883501] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
|
||
13 май 19, 15:38 [21883514] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
почему? |
||||
13 май 19, 15:43 [21883519] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
|
||
13 май 19, 15:47 [21883524] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
не совсем так в выборке джойн серверных (бежевое слева) ожиданий и сессионных (зеленое справа) в зеленой части выделяется преимущественно только CXPACKET К сообщению приложен файл. Размер - 45Kb |
||||
13 май 19, 15:51 [21883530] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
komrad, а CXPACKET это типа чтение из буфера что ли? |
13 май 19, 16:02 [21883539] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
И такое ожидание вообще генерируется всегда при праллельном плане. |
||
13 май 19, 16:09 [21883547] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
invm, остальные _сессионные_ ожидания очень малы, поэтому я и написал, что данные судя по всему в кэше или я неправ? |
13 май 19, 16:17 [21883554] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9646 |
komrad, Посмотрите, например, сессионные для PAGEIOLATCH_SH. |
13 май 19, 16:56 [21883576] Ответить | Цитировать Сообщить модератору |
komrad Member Откуда: Сообщений: 5516 |
это которые 10 тысяч? они же копеечные тогда уж LATCH_EX, которых в 7 раз больше |
||
13 май 19, 17:07 [21883592] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
гадание без запроса, такое себе развлечение, там какой-нить кривой мерж и стоять может совесем не на ожиданиях а на блокировках и тп |
13 май 19, 17:10 [21883595] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
хотя то что нагенеривает 1С лучше и не смотреть |
13 май 19, 17:13 [21883598] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |