Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
Добрый день. Достался по наследству сервер с SQL 2008R2. Можно сказать, что я accidental DBA. Я пока что настроил систему резервного копирования, потому что до этого бекапы вообще не производились. Затем на simple talk прочитал про утилиту PAL. Собрал метрики за день с 8 до 22, проанализировал. Что с этой системой можно сделать, учитывая то, что оптимизировать запросы некому? (команда разработчиков развалилась). Заранее спасибо вам, и с праздником святой пасхи!
PAL Reports
12 апр 15, 12:25    [17504718]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
Что с этой системой можно сделать, учитывая то, что оптимизировать запросы некому? (команда разработчиков развалилась).
В любом случае нужна новая команда. Конечно, есть шанс, что DBA может всё поправить, создав какой-нибуть недостающий индекс, но этот шанс маленький - нужно вмешательство разработчиков.

Вангую, что команда развалилась после того, как за три года наваяла супер-систему, а она с реальными пользователями не заработала? :-)

Данные ваши подробно не анализировал, но сразу видно, что некоторые счётчики внушают сильные опасения, допустим, Lock Timeouts/sec в таких количествах - просто катастрофа.
13 апр 15, 09:32    [17506694]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
alexeyvg, спасибо за ответ. По поводу новой команды, это зависит не от меня. Приложение разрабатывали москвичи, я же на периферии. История была такая: эта база работает уже четвертый год, разработчик даже одно время пытался поддерживать приложение (хотя такая поддержка тут звучит с натягом), но ровно два года назад все заглохло, участники команды работают все по разным местам, мне придется видимо отыскивать среди них самого "рулевого" и дергать.

Что касаемо нынешней ситуации, мне нужно получить какой то примерный baseline, иначе я не знаю как с этой балалайкой буду справляться.
13 апр 15, 15:05    [17508484]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
Что касаемо нынешней ситуации, мне нужно получить какой то примерный baseline, иначе я не знаю как с этой балалайкой буду справляться.
Ну, анализ системы начинается с того, как она соответствует бизнес-требованиям.
Может, там у вас 10000 пользователей, а приложение написано так, что при таймауте перезапрашивает сервер незаметно для пользователя, и вобще, обработка ведётся асинхронными очередями, пользователи ничего не ждут? Тогда 30 Lock Timeouts/sec может быть не так уж и много...
То есть нужно понять, пользователи то довольны? Не тормозит? Может, всё не так страшно?

Но вообще конечно отчёт выглядит не очень хорошо.
hwrd1
Приложение разрабатывали москвичи, я же на периферии. История была такая: эта база работает уже четвертый год, разработчик даже одно время пытался поддерживать приложение (хотя такая поддержка тут звучит с натягом), но ровно два года назад все заглохло, участники команды работают все по разным местам, мне придется видимо отыскивать среди них самого "рулевого" и дергать.
Да можно и распределённой командой работать, не проблема, вопрос в мотивации и организации работы.

Просто без доступа к коду приложения и возможности его менять ничего не получится, особенно, если нет деления на логические уровни (допустим, нет хранимых процедур, запросы зашиты в код) - тогда придётся держать задорого большую команду разрабов, чисто для поддержки.
13 апр 15, 16:28    [17508917]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
alexeyvg, пользователей всего 7. И я бы не сказал, что пользователи сильно довольны, все таки определенные притормаживания есть.

автор
Может, всё не так страшно?

Я вот и не знаю, как раз пытаюсь выяснить это с вашей помощью. Кстати, в статистике ожиданий, в топе у меня WRITELOG.

На какие алерты из этого отчета мне стоит еще обратить внимание ?
13 апр 15, 22:11    [17510055]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
На какие алерты из этого отчета мне стоит еще обратить внимание ?
Да в общем всё, что пишет этот отчёт, можно проанализировать. Допустим, Page Splits 100 штук в секунду - много.

Но большинство вне контекста использования обсуждать не имеет смысла. Всё нужно сравнивать с нагрузкой на сиквел, а нагрузку на сиквел - с бизнес-нагрузкой, то есть с интенсивностью бизнес-транзакций.

Система написана хорошо, и работает штатно, если пользователи довольны, при этом на бизнес-транзакции приходится адекватная нагрузка на сервер, а для этой нагрузки на сервер разумные значения счётчиков из обсуждаемого отчёта.

Вот например, Page Splits - 100 в секунду много для 100 бизнес-транзакций в секунду, и мало для 100 тысяч.
hwrd1
И я бы не сказал, что пользователи сильно довольны, все таки определенные притормаживания есть.
Ну вот с этого начинайте анализировать. Смотрите профайлером, что происходит на сервере, как действия пользователей в итоге трансформируются в работу сервера.

В общем, этот репорт - просто счётчики сиквела, всего навсего. Их нужно смотреть, разбирая конкретные проблемы системы, а не сами по себе.
13 апр 15, 23:32    [17510263]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
пользователей всего 7
Для 7 пользователей нагрузка по счётчикам большая.
13 апр 15, 23:33    [17510268]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
alexeyvg, ясно, спасибо.

автор
Для 7 пользователей нагрузка по счётчикам большая.

Основную сиквелную активность генерят не пользователи, в базу данных пишутся данные с другого сервера, передаются по технологии SOAP (насколько я знаю). Вероятно из-за этого все и тормозит.

автор
Да в общем всё, что пишет этот отчёт, можно проанализировать.

Допустим проанализирую. Я смогу на это повлиять не переписывая запросы ?
По поводу профайлера, пока не представляю как я им буду анализировать, там даже с фильтрацией событий очень много накидывает. Третье, я с таким типом задач еще не сталкивался, наставник нужен.
14 апр 15, 08:29    [17510828]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
Допустим проанализирую. Я смогу на это повлиять не переписывая запросы ?
По всякому бывает. Смотрите запросы, планы, может, просто каких то индексов не хватает.
Но, как правило, в запущенных случаях приходится менять код.

Одно только отсутствие бакапов на работающей системе даёт уверенность, что случай запущенный :-)
hwrd1
По поводу профайлера, пока не представляю как я им буду анализировать, там даже с фильтрацией событий очень много накидывает.
Результат работы профайлера можно складывать в табличку (желательно в другой базе, а можно и на другом сервере, или на рабочей станции, на которой запущен профайлер), или в файлы, а потом анализировать в этой табличке, запросами. Припотоке запросов очень удобно.

Ещё у сиквела есть стандартные отчёты производительности, можно посмотреть нагружающие запросы и всякую статистику.
hwrd1
Третье, я с таким типом задач еще не сталкивался, наставник нужен.
Ну, понятно, всё это делать лучше опытным разработчикам и DBA. Вселяет надежду то, что вы сразу проверли и сделали бакап, и задаёте вопросы, значит, получится :-) Просто времени потребуется немало.
14 апр 15, 11:42    [17511852]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
alexeyvg, понял. Еще одна проблем, которые я увидел с ходу, это то что выключены все ограничения FK. Т.е они созданы, но на "включить использование ограничения внешнего ключа" везде "Нет". Так мне кажется не может быть, зачем то же эту штуку создали. Хотя думаю вряд ли это может как то влиять на производительность.

Картинка с другого сайта.
15 апр 15, 08:48    [17516394]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
alexeyvg, понял. Еще одна проблем, которые я увидел с ходу, это то что выключены все ограничения FK. Т.е они созданы, но на "включить использование ограничения внешнего ключа" везде "Нет". Так мне кажется не может быть, зачем то же эту штуку создали. Хотя думаю вряд ли это может как то влиять на производительность.

Картинка с другого сайта.
А это что за окошко на картинке? Не могу распознать, никогда конструкторами не пользовался...
15 апр 15, 09:13    [17516466]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
o-o
Guest
alexeyvg
А это что за окошко на картинке?

это такое вылазит при двойном щелчке на FK в ОЕ

К сообщению приложен файл. Размер - 23Kb
15 апр 15, 09:57    [17516644]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
o-o
Guest
и не знаю, при чем там Table Designer,
но изменение этого в ГУИ приводит к ALTER TABLE .. CHECK CONSTRAINT .. / ALTER TABLE .. NOCHECK CONSTRAINT ..
15 апр 15, 10:06    [17516690]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Crimean
Member

Откуда:
Сообщений: 13147
hwrd1
выключены все ограничения FK. Т.е они созданы, но на "включить использование ограничения внешнего ключа" везде "Нет". Так мне кажется не может быть, зачем то же эту штуку создали. Хотя думаю вряд ли это может как то влиять на производительность.


на производительность - не особо. сам по себе факт нехороший. могут быть (и запросто будут) "несогласованные данные" в результате
15 апр 15, 10:09    [17516706]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Glory
Member

Откуда:
Сообщений: 104751
o-o
и не знаю, при чем там Table Designer,

Потому что это же окно можно вызвать и в Table Designer

Crimean
на производительность - не особо

non-trusted FK может повлиять на оптимизатор при выборе стратегии соединения.
15 апр 15, 10:20    [17516765]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Glory
non-trusted FK может повлиять на оптимизатор при выборе стратегии соединения.


согласен. даже видел вживую. но слишком редкий случай.
15 апр 15, 10:37    [17516860]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
Вот черт. Ладно, сейчас попробую через графику все взад вернуть.
Спасибо за ответы.
15 апр 15, 11:04    [17517048]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
А как-то оперативно выяснить произошла ли несогласованность можно ? У них так база давно уже крутиться.
15 апр 15, 11:05    [17517057]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
Начал прощупывать базу профайлером. Взял для начала эту статью.
С ходу наткнулся пока что вот на такое. Это хранимка. Это излечимо вообще ?
DECLARE @OD_ID int = 128
SELECT PATP_OrderData.personnel_id, dbo.SYS_SecondToString(sum(PATP_OrderDataDay.time_count_sec)) as TimeCount FROM PATP_OrderData
  LEFT JOIN PATP_OrderDataDay ON PATP_OrderData.id=PATP_OrderDataDay.order_data_id 
  AND PATP_OrderData.order_id=@OD_ID
  WHERE 
  --PATP_OrderData.order_id=64 
  --AND 
  PATP_OrderDataDay.id is not NULL
  GROUP BY PATP_OrderData.personnel_id


Картинка с другого сайта.

В общем если, долгоиграющих запросов я пока не нашел. У меня почему то складывается впечатление, что сервер нагружен большим количеством мелких запросов, уж очень много строчек накидывает профайлер, когда выполняется определенные действия в приложении.
24 апр 15, 11:23    [17557892]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Glory
Member

Откуда:
Сообщений: 104751
hwrd1
Это излечимо вообще ?

А почему вы решили, что это надо лечить ?
24 апр 15, 11:27    [17557922]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
o-o
Guest
или у меня пятница, или зачем LEFT JOIN, если все равно фильтр PATP_OrderDataDay.id is not NULL?
24 апр 15, 11:32    [17557953]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31863
hwrd1
С ходу наткнулся пока что вот на такое. Это хранимка. Это излечимо вообще ?
DECLARE @OD_ID int = 128
SELECT PATP_OrderData.personnel_id, dbo.SYS_SecondToString(sum(PATP_OrderDataDay.time_count_sec)) as TimeCount FROM PATP_OrderData
  LEFT JOIN PATP_OrderDataDay ON PATP_OrderData.id=PATP_OrderDataDay.order_data_id 
  AND PATP_OrderData.order_id=@OD_ID
  WHERE 
  --PATP_OrderData.order_id=64 
  --AND 
  PATP_OrderDataDay.id is not NULL
  GROUP BY PATP_OrderData.personnel_id
Написано несколько кривовато. В условиях LEFT подключения таблицы стоит условие на другую таблицу. Что хотел этим сказать автор?

При этом LEFT отключён условием запроса.

Что за стиль написания?

Далее, такой запрос должен выполняться поиском по индексам, быстро (судя по названию полей, таблиц, смыслу запроса). Такое подозрение, что элементарно нет нужных индексов.
hwrd1
В общем если, долгоиграющих запросов я пока не нашел
Долгоиграющих - это сколько? Приведённый запрос должен отрабатывать за миллисекунды, судя по его логике (получение неких данных по заказу).
hwrd1
У меня почему то складывается впечатление, что сервер нагружен большим количеством мелких запросов, уж очень много строчек накидывает профайлер, когда выполняется определенные действия в приложении.
Смотрите действия приложения, смотрите профайлер.
Такое часто бывает, когда программируют "мышкой", когда в команду по разработке приложения с БД не берут специалиста по БД.
24 апр 15, 11:40    [17558018]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
hwrd1
Member

Откуда:
Сообщений: 18
alexeyvg,

автор
Что хотел этим сказать автор?

автор
Что за стиль написания?

Не известно. Связи с этими разработчиками нет.

Запрос этот если выполнить из SSMS выполняется быстро. Но если в приложении его сделать и в профайлер поглядеть, будет так:
Картинка с другого сайта.

Само действие выполняется так же примерно по времени, что и в поле Duration, хотя как вы говорите, предполагается что будет мгновенно. Выполнение одного этого действия - 37 000 строчек профайлера. Или это нормально ?
24 апр 15, 11:59    [17558133]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8570
Написано несколько кривовато. В условиях LEFT подключения таблицы стоит условие на другую таблицу. Что хотел этим сказать автор?
При этом LEFT отключён условием запроса.

Замысловатая реализация фильтра where exists()...
24 апр 15, 12:12    [17558237]     Ответить | Цитировать Сообщить модератору
 Re: Отчет в performance analysis of logs (PAL), алерты.  [new]
Crimean
Member

Откуда:
Сообщений: 13147
o-o
или у меня пятница, или зачем LEFT JOIN, если все равно фильтр PATP_OrderDataDay.id is not NULL?


игры с планом, конечно же. ибо exists скорее свалит в loop а inner заставит оптимизатор "слишком рано" обработать это соединение
24 апр 15, 12:53    [17558474]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить