Ms sql server грузит диск на 100
Обновлено: 07.07.2024
Как понять что проблема именно в SQL Server - Заходим в Диспетчер задач, на вкладке Подробности находим sqlserver и смотрим колонку ЦП.
Если это значение постонно высокое, то значит где-то идет утечка CPU.
В этом руководстве мы собрали различные советы как решать подобную проблему
Поиск проблемных мест в SQL Server по CPU
1. Cмотрим счетчики perfmon
Определяем проблема в Kernel или User запросах.
В perfmon смотрим следующие параметры:
- Processor: % Privileged Time – Percentage of time processor spends on execution of Microsoft Windows kernel commands such as OS activity. (If more than 30% involve Windows Admins)
- Process (sqlservr): % Privileged Time – the sum of processor time on each processor for all threads of the process (SQL Kernel)
- Processor: % User Time – percentage of time the processor spends on executing user processes such as SQL Server. This includes I/O requests from SQL Server
Если это значение % Privileged Time / No of logical cpus больше 30%, то скорее всего дело в системных настройках, возможно антивирус.
2. Ищем проблемные процессы
spID с 1 до 50 - это системные. Мы можем отключать (kill spID) или смотреть запрос только для пользовательских (spID>50).
Также пробуем использовать хранимки exec sp_who, sp_who1, sp_who2, sp_who3 - они позволяют посмотреть все процессы и их текущее состояние.
По spid можно найти этот запрос:
Альтернативно вы можете посмотреть последний запрос, выполняющийся в рамках этого spID:
А также можно убить процесс через kill spID. Убили процесс - и посмотрели как это сказалось на загрузке.
3. Выявление проблем через спец запросы SQL
Также попробуйте выполнить следующие запросы для поиска проблемных мест по CPU
Еще один скрипт для поиска проблемных запросов по CPU:
Для найденных элементов можно удалить план в кеше (подставив sql_handle):
Еще 1 запрос на поиск проблем по CPU:
Также посмотрите правой кнопкой на Сервере > reports> Standard reports > Top CPU queries.
4. Анализ найденных проблемных запросов
В найденных запросах посмотрите execution plan и посмотрите где наибольший cost.
Источники и что почитать по теме утечек CPU
Альтернативная документация по поиску CPU проблем SQL Server
Что проверить в первую очередь:
- Конфигурация железа сервера.
- Дисковая подсистема.
- Свободное место.
- Антивирус на сервере стоит?
- БД (операции) не выполняются / выполняются, как часто.
- Проверка целостности
- Индексы перестройка
- Обновление статистики
- Сжатие (шринк)
Общие рекомендации
Электропитания - использовать «Высокая производительность»
настройка кэширования записи на диск
антивирус, - добавить папку SQL Server и файлов БД в исключения
настройка настроены параметры параллелизма (cost threshold for parallelism, max degree of parallelism)
настройка Hyper-Threading.
Мониторинг SSMS - «Стандартные отчеты»
«Стандартные отчеты» в пользовательском интерфейсе Management Studio
SQL Server Management Studio предоставляет минимальный необходимый набор стандартных отчетов для получения информации в режиме пользовательского интерфейса.
Доступ к этим отчетам может быть выполнен через «Обозреватель объектов» (Object explorer) → Правый клик мыши по базе данных → «Отчеты» (Reports) → «Стандартный отчет» (Standard reports)
Перечень «Стандартные отчеты»:
- Занято место на диске
- Использование дисковой памяти верхними таблицами
- Использование дисковой памяти таблицей
- Использование дисковой памяти секцией
- События резервного копирования и восстановления
- Все транзакции
- Все блокирующие транзакции
- Самые продолжительные транзакции
- Транзакции, блокирующие наибольшее кол-во транзакций при выполнении
- Транзакции с наибольшим кол-вом блокировок
- Статистика блокировки ресурсов по объектам
- Статистика выполнения объектов
- Журнал согласованности баз данных
- Статистика использования индекса
- Физическая статистика индекса
- Журнал изменений схемы
- Статистика пользователей
- Перечень «Пользовательские отчеты»
Мониторинг Activity Monitor - Монитор активности
Открыть монитор активности CTRL+ALT+A или SSMS стандарт. панель инструментов значок.
Монитор активности SQL Server 2008 объединяет данные о процессах, предоставляя наглядную информацию по выполняющимся и недавно выполнявшимся процессам.
Монитор активности предлагает администратору раздел обзора, внешне похожий на Диспетчер задач Windows, а также компоненты детального просмотра отдельных процессов, ожидания ресурсов, ввода-вывода в файлы данных и последних ресурсоемких запросов.
Мониторинг Reporting Services - Performance Dashboard Reports
Для наблюдения за SQL Server есть интересный пакет отчетов Reporting Services, называется он SQL Server Performance Dashboard Reports.
The SQL Server 2012 Performance Dashboard Reports are Reporting Services report files designed to be used with the Custom Reports feature of SQL Server Management Studio.
Высокая загрузка дисковой подсистемы на сервере СУБД MS SQL Server
SELECT
SUM(qs.total_physical_reads) as physical_reads,
SUM(qs.total_logical_reads) as logical_reads
into T1 FROM (
select top 100000 * from
sys.dm_exec_query_stats qs
where qs.last_execution_time > (CURRENT_TIMESTAMP - '01:00:00.000')
order by qs.total_physical_reads desc
) as qs;
select top 100
(qs.total_physical_reads) as physical_reads,
(qs.total_logical_reads) as logical_reads,
qp.query_plan,
st.text,
dtb.name,
qs.*,
st.dbid
INTO T2
FROM
sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
left outer join sys.databases as dtb on st.dbid = dtb.database_id
where qs.last_execution_time > (CURRENT_TIMESTAMP - '01:00:00.000')
order by qs.total_physical_reads desc;
select
(T2.physical_reads*100/T1.physical_reads) as percent_physical_reads,
(T2.logical_reads*100/T1.logical_reads) as percent_logical_reads,
T2.*
from
T2 as T2
INNER JOIN T1 as T1
ON 1=1
order by T2.total_physical_reads desc
;
drop table T2
;
drop table T1
;
WITH DB_Disk_Reads_Stats
AS
(SELECT DatabaseID, DB_Name(DatabaseID) AS [DatabaseName], SUM(total_physical_reads) AS [physical_reads]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY (SELECT CONVERT(int, value) AS [DatabaseID]
FROM sys.dm_exec_plan_attributes(qs.plan_handle)
WHERE attribute = N'dbid') AS F_DB
GROUP BY DatabaseID)
SELECT ROW_NUMBER() OVER(ORDER BY [physical_reads] DESC) AS [row_num],
DatabaseName, [physical_reads],
CAST([physical_reads] * 1.0 / SUM([physical_reads]) OVER() * 100.0 AS DECIMAL(5, 2)) AS [Physical_Reads_Percent]
FROM DB_Disk_Reads_Stats
WHERE DatabaseID > 4 -- system databases
AND DatabaseID <> 32767 -- ResourceDB
ORDER BY row_num OPTION (RECOMPILE);
Как найти самый тяжелый (или несколько тяжелых) запрос в коде конфигурации.
Например, можно настроить технологический журнал с фильтрами только на один запрос. Может выглядеть так:
Смысл в том, чтобы указать такие фильтры
<like property="Sql" value="%Reference5774%"/>,
которые будут включать имена таблиц в найденном вами на предыдущем шаге запросе. Если всё аккуратно сделаете, то в полученном технологическом журнале запрос у вас будет только тот, который нужен. Журнал получится небольшим. Собственно стек из кода на встроенном языке будет сразу в конце события с запросом.
У меня проблема с MS SQLSERVER на клауд сервере.
Параметры сервера 2 ядра, 4 гб ОЗУ. Server 2009 R2 SP1, SqlServer 2012
Стоит только SQlServer, даже антивируса нет.
Сама проблема:
ЗАпись на SQLSERVER происходит в основном через десктоп-приложение, а отчеты пользователи получает через наш сайт.
Как видно на скриншоте SQLSERVER занимает почти 3 гб ОЗУ и почти 100% ресурсов. В это время было активных около 100 пользователей чтения-записи на SQLSERVER.
Я хотел узнать, это правильно, что со 100 активными пользователями SQLSERVER так занимает ресурсы?
Скоро у нас будут более 500 активных пользователей, какую конфигурацию клауд сервера (или выделенного сервера) вы могли бы порекомендовать?
Помощь в написании контрольных, курсовых и дипломных работ здесь
Можно ли открыть Бд SQLServer 2012 в SQLServer 2005
Добрый вечер. Столкнулся с такой проблемой, пытался загрузить БД созданную в SQL Server 2012 в SQL.
Размер приложения превышает размер ресурсов почти на 100 Мб
Здравствуйте..Столкнулся с такой проблемой: Сейчас пишу Metro-приложения под Windows 8..У меня есть.
Svchest.exe занимает почти 500mb памяти
Короче, нуб в железе. Сразу дико извиняюсь если написал не туда. Ситуация срочная , завтра идти к.
Таймер времени через поток занимает 25 % ресурсов процессора
В сети нашел только этот пример таймера в .h class timer : public TThread < private: void.
Сильно общий вопрос. Это как диагностировать болезнь по фотографии. Один бог знает что у вас там в базе творится, какие запросы посылаются, что и как хранится. Может всё триггерами усеяно, а все запросы имеют вид "SELECT * FROM" + миллионы "JOIN".
В общем, никакой конкретики тут не будет. Профилируйте работу своих приложений с БД, смотрите откуда растут ноги у такого потребления ресурсов.
и пожирание памяти кстати не показатель ничего вообще, забудь о ней
он сожрет столько сколько дадут, запросто может пожирать даже больше чем сама БД на диске, а может и не пожирать если ограничить и ничего от этого никуда не отвалится
Добавлено через 4 минуты
причем порой даже не можно, а нужно ограничивать, т.к у винды начинается паника когда кончается память
сам по себе сервер умеет вовремя остановится (толи 80, толи 90 процентов), но вот учитывать другие приложения он ясное уже не может
так что если какой-нибудь w3wp.exe тоже захочет памяти там начнется драка и в итоге все участники скатятся в своп, нагрузят диск, повиснут запросы и понеслась
Если отключить всех клиентов - сервер будет столько кушать?
Клиентское ПО не может ввергать его пучину "трудолюбия"?
Спасибо за ответы.
Попробую объяснить работу сервера.
На сервере находится база данных учеников. Клиентское ПО отправляет данные посещаемости учеников за день.
Таблица посещаемости маленькая конечно, там только код ученика и время посещения занятий. Таблица посещаемости отправляется на сервер с помощью функции SQLBULKCOPY.
Таких учебных заведений, т.е. клиентов сервера около 500 (будет еще больше).
На сайте с помощью SQL запросов создаются отчеты и вычисляются проценты посещаемости по каждому учебному заведению. Любой пользователь может зайти на сайт и посмотреть отчет.
Таким образом, о количестве одновременных подключений к серверу остается только догадываться.
Я сам еще новичок по работе с MS SQL сервером. У меня возник вопрос: все форумы говорят об индексации. У меня все таблицы не индексированы. Я опасаюсь, может это влияет на производительность сервера?
Может всё триггерами усеяно, а все запросы имеют вид "SELECT * FROM" + миллионы "JOIN".Триггеров нету, я сам не знаю что такое триггер
А насчет запросов, "select *" я избегаю, а JOIN ы там несколько, т.е. "ученик+посещаемость+школа+город+область" вот как-то так.
Клиентское ПО не может ввергать его пучину "трудолюбия"?
Если отключить всех клиентов - сервер вообще ничего не кушает.
Одно клиентское подключение с инсертом SQLBULKCOPY заставляет работать сервер на 15-20% ресурсов, но это только, когда запрос активен.
Именно так и случается, т.е клиент отправляет данные на сервер (функцией SQLBULKCOPY если не забыли), прога пишет что успешно отправила на сервер. Я на сервер отправляю запрос с инсертом. Результат: записи не добавлены!
Что можете посоветовать?
Добавлено через 10 минут
Кстати, после перезапуска SQL сервера все работает отлично полдня, а потом потребление ресурсов этим процессом достигает почти 100%, а занимаемая память увеличивается больше 3 гб и запросы висят и отправленные данные начинают пропадать.
SQLBULKCOPY это предел производительности позволяющий добавлять >=10 тысяч записей в секунду, а со смешными 500 строк справится обычный insert за мгновение(разумеется если там нет blob на 10мб)
мне думается если 50 человек сделают такую вставку вполне возможен такой треш. Одно клиентское подключение с инсертом SQLBULKCOPY заставляет работать сервер на 15-20% ресурсов,
Вот тебе и первый источник проблемы. Как уже выше порекомендовали, попробуй заменить SQLBULKCOPY на SELECT и посмотреть, что получится.
А вот с индексами не всё так просто. Они действительно скажутся на производительности, но не обязательно в лучшую сторону. Создание и обновление индекса - процедура ни разу не бесплатная в плане затрат процессорного времени. Индексировать имеет смысл только те таблицы, данные в которые заносятся редко, и в основном происходит чтение. И колонки индексировать нужно только с уникальными значениями, иначе от индекса толку не будет. Рекомендую основательно об этом почить, прежде, чем браться.
Кстати, большое количество JOIN-ов можно заменить индексированной вьюшкой (VIEW), что даст прирост производительности, но это, опять же, при должном понимании вопроса.
А в остальном, пока что, всё тоже - профилируй, смотри что где да как.
Umrbek79, на глупости про, якобы, проблемы с SQLBULKCOPY можете не обращать внимания. Не в этом дело.
Для начала, запустите Activity Monitor и наблюдайте за происходящим.
1. 2 ядра на 100 активных пользователей - катастрофически мало. Если не хватает процессорных ресурсов, в Activity Monitor в Resource Waits в топе будет тип ожидания SOS_SCHEDULER_YIELD
Итого: вам, судя по всему, придется наращивать аппаратные ресурсы сервера, проводить редизайн БД в части индексов и заниматься оптимизацией запросов.
Т.к. необходимых опыта и знаний у вас пока что нет, оптимальным будет разово нанять специалиста для этой работы. Заодно и поучитесь у него.
Добавлено через 7 минут
Если таблица, куда заливаются данные, будет проиндексирована, SQLBULKCOPY, без включения флага трассировки 610, станет эквивалентен обычному INSERT.
Продолжать пользоваться BULK COPY или нет, зависит от объема добавляемых данных.
С проблемой повышенной нагрузки на диски (дисковые хранилища и массивы, далее просто диски), сталкиваются почти все администраторы и специалисты технической поддержки при эксплуатации средних и крупных информационных систем на базе SQL Server (от 50 активных пользовательских сессий). Но всегда ли правильно идет интерпретация проблемы, попробуем разобраться на нескольких практических примерах.
Как правило, повышенную нагрузку на диски можно определить различными способами. Основной из них – это получение счетчика «Средней длины очереди к диску»:
Рис.1. Средняя длина очереди к диску для чтения и записи
На рис. 1 можно наблюдать типичную ситуацию с повышенной очередью к диску, «на пальцах» этот параметр можно объяснить, как среднее количество пакетных заданий для физического диска в очереди к выполнению. В моменты повышенной очереди к диску возникают задержки на всех, даже минимальных операциях с диском, что в ряде случаев приводит к общему падению производительности. Следует учитывать возможности каждого диска по параллельной обработке, так как от этого зависит критичность проблемы. В случае, если средняя очередь к диску больше, чем возможности диска, то проблема стоит очень остро и повлияет в общем на скорость всех операций и информационной системе. Если же средняя очередь к диску больше 1, но меньше возможностей диска, то диск справляется с нагрузкой за счет своих ресурсов, но это не значит, что проблемы не существует вообще, – повышенная нагрузка на диск может привести к уменьшению срока жизни механизмов диска.
Рассмотрим несколько основных причин повышенной нагрузки на диски для систем на базе MS SQL Server.
- Нагрузка на диски обусловлена быстрым вытеснением данных из кеша SQL Server.
Рис.2. Демонстрация вытеснения данных из кеша SQL Server
На рисунке 2 показаны 3 условных этапа различной нагрузки на диск. На этапе 1 и этапе 3 – очереди к диску были минимальны. Почему же на этапе 2 очередь резко возросла и это привело к появлению проблем производительности у пользователей? Ответ на этот вопрос легко найти на втором графике рисунка 2: «Ожидаемый срок жизни страницы памяти», который показывает предполагаемое время нахождения страницы данных в кеше SQL Server. Между двумя этапами видим резкое понижение этого графика со значения 3000 до 200. С точки зрения логики работы SQL Server это означает, что данные будут находится к кеше не 3000 секунд как раньше, а 200 секунд, следовательно, если пользователь запросит данные через 300 секунд, то SQL Server с почти 100% вероятностью не найдет их в оперативной памяти (кеше) и придется выполнять операцию чтения с диска. Этими операциями обеспечивается рост очереди к диску. В течение всего этапа 2 кеш «прогревался» (заполнялся данными) и на этапе 3 нагрузка на диск упала.
Мы определили вид проблемы, теперь рассмотрим варианты решения.
Что надо сделать:
- Найти тяжелые неоптимальные запросы, которые вытеснили данные из кеша SQL Server. Прошу обратить внимание, что это не всегда равносильно поиску длительных запросов, так как зачастую быстрые, но неоптимальные запросы SQL приводят к подобным проблемам.
- Возможно проблема в качестве обслуживания статистик и индексов MS SQL Server.
Что не надо делать:
- Не надо покупать новые диски (дисковые массивы), это не решает проблему, а скорее ее усугубляет.
Для написания материала мы использовали инструмент для мониторинга производительности PerfExpert, позволяющий обеспечить возможность сбора и глубокого анализа данных.
Рассмотрим еще несколько практических ситуаций с повышенной нагрузкой на диск, где причиной являются совершенно различные по природе причины.
2. Нагрузка на диски, обусловленная свопированием памяти на диски вследствие нехватки свободной памяти.
Рис.1. Практический пример повышенной нагрузки на диск
На рисунке 1 показана практическая ситуация на сервере БД SQL Server у клиента в течение 1,5 часов. Как видно по счетчику «Средней длины очереди к диску» диск нагружен и не справляется с количеством обращений к нему.
На рисунке также показаны два других показателя: «Нагрузка CPU», «Свободная оперативная память» для поиска причин торможения диска. Условно делим ситуацию на два этапа: первый этап – очередь к диску практически равна 0 и пользователи работают в обычном режиме, и второй этап – в течение которого очередь к диску поднимается до максимальных значений (342) и пользователи не могут качественно работать. Чем же обусловлена такая нагрузка на диск?
Нагрузка обусловлена процессом свопированием оперативной памяти на диск, при котором при нехватки оперативной памяти некоторые страницы записываются в специальную область на физический диск. При этом скорость работы с такими страницами падает, повышается нагрузка на диск и замедляются все операции в системе.
Показатель «Свободная оперативная память» как раз показывает доступность реальной оперативной памяти для других процессов, а, следовательно, чем его значение больше, тем меньше вероятность свопирования. На рисунке 1 значение свободной оперативной памяти на сервере баз данных постоянно уменьшается до 500 Мб, далее до 200 Мб, это в свою очередь и привело к нагрузке на диск (на этапе 2).
Встает вопрос – а зачем на рисунке 1 мы показали счетчик «Нагрузка CPU»? Все просто, на этапе 1 средняя загрузка CPU была около 50%, на этапе 2 – 40%, при этом в системе работало аналогичное количество пользователей. Такое уменьшение значения говорит о том, что процессор недозагружен и узкое место в производительности сместилось в сторону диска (он не справляется).
Для исправления этой ситуации достаточно правильно распределить потребление оперативной памяти и не допустить уменьшение ее объема до 500Мб (как рекомендация). Неправильным вариантом решения была бы покупка более производительного физического диска или хранилища.
3. Нагрузка на диски, обусловленная внутренними механизмами работы SQL Server.
Рис. 2. Периодическая нагрузка на диск
Как видно из рисунка 2, периодически очередь к диску увеличивается, причем эти «скачки» происходят через одинаковые временные интервалы. Это может говорить о том, что есть периодически повторяемые регламентные операции.
Из нашего опыта это могут быть следующие операции:
- Увеличение размера файлов данных и лога транзакций (особенно если указан фиксированный размер прироста).
- Резервная копия файла данных или журнала транзакций.
Сбор и анализ данных осуществлялся с использованием мониторинга производительности PerfExpert.
В этой статье мы рассмотрим популярные инструменты, T-SQL запросы и скрипты для обнаружения и решения различных возможных проблем с производительностью SQL Server. Эта статья поможет вам разобраться, когда вашему SQL Server недостаточно ресурсов (памяти, CPU, IOPs дисков), найти блокировки, выявить медленные запросы. Посмотрим какие есть встроенные инструменты и бесплатные сторонние скрипты и утилиты для анализа состояния Microsoft SQL Server.
Инструменты для диагностики SQL Server
Если вы правильно диагностировали проблему, то половина работы уже сделана. Рассмотрим какие инструменты обычно используются системным администратором для диагностики различных проблем в SQL Server:
Обнаружение и решение проблем с производительностью SQL Server
Самой распространенной проблемой с которой сталкивается системный администратор, работающий с SQL Server, это жалобы пользователей на производительность запросов и самого сервера: “тормозит”, “долго выполняется запрос“, и так далее.
Прежде всего нужно убедиться, что серверу хватает ресурсов. Рассмотрим, как в SQL Server быстро проанализировать использование памяти, CPU, дисков и наличие блокировок.
Анализ использования оперативной памяти SQL Server
Для начала нужно определить сколько памяти доступно SQL Server. Для этого запустите SSMS (SQL Server Management Studio), зайдите на сервер и зайдите в свойства сервера (ПКМ по названию сервера в Обозревателе объектов).
Сам по себе доступный объём RAM вам ничего не скажет. Нужно сравнить это число с используемой памятью в Диспетчере Задач и самим движком SQL Server с помощью DMV.
В Диспетчере задач, во вкладке Подробности, найдите sqlservr.exe и посмотрите сколько оперативной памяти использует этот процесс.
- Если на сервере, например, 128 GB оперативной памяти, а процесс sqlservr.exe использует 60 GB и ограничений по RAM у SQL Server нет, то оперативной памяти вам хватает.
- Если SQL Server использует 80-90% RAM от заданной или максимальной, то в таком случае нужно смотреть DMV. Имейте в виду, что sqlservr.exe не сможет использовать всю оперативную память. Если на сервере 128 GB, то sqlservr.exe может использовать только 80-90% (100-110 GB), так как остальная память резервируется для операционной системы.
Имейте в виду, что процесс SQL Server’a не отдаёт оперативную память обратно в систему. Например, ваш SQL Server обычно использует 20 GB памяти, но при месячном отчете он увеличивает потребление до 100 GB, и даже когда вычисление отчета закончится и сервер будет работать в прежнем режиме, процесс SQL Server’a всё равно будет использовать 100 GB до перезагрузки службы.
Даже если вы уверены, что оперативной памяти серверу хватает, не будет лишним точно знать объём потребляемой RAM.
Узнать реальное использование RAM можно с помощью Dynamic Management Views. DMV это административные вьюверы (представления). С помощью DMV можно диагностировать практически любую проблему в SQL Server.
Посмотрим sys.dm_os_sys_memory, для удобства используем запрос:
Рассмотрим каждый выводимый параметр:
Все эти данные полезны, если вы хотите точно определить сколько ваш SQL Server потребляет RAM. Чаще всего это используют, если есть подозрения что для экземпляра выделено слишком много оперативной памяти.
Если Вам нужно убедиться, что серверу хватает RAM, вы можете смотреть только на поля system_low_memory_signal_state, system_high_memory_signal_state и system_memory_state_desc. Если system_low_memory_signal_state = 1, то серверу явно не хватает оперативной памяти.
Загрузка процессора в SQL Server
Нагрузку на процессор определить проще, так как это можно сделать в Диспетчере задач. Чтобы узнать текущую нагрузку на процессор, найдите в Диспетчере задач процесс sqlservr.exe
Если вы хотите узнать нагрузку за прошедшее время, можно воспользоваться запросом:
Не забудьте поменять @lastNMin на нужное вам число в минутах.
В результате мы получим поминутную статистику использования процессора.
Анализ нагрузки на диск SQL Server
Посмотрим на загрузку дисков в операционной системе. Для этого запустите resmon.exe.
Нам нужна вкладка Disk. В секции Disk Activity отображаются файлы, к которым идёт обращение, и их скорость read/write на текущий момент. Отфильтруйте эту секцию по Total (кликните на Total). На самом верху будут файлы, которые на данный момент максимально используют диск. В случае с SQL Server это может быть полезно чтобы определить какая база больше всего нагружает диск на текущий момент.
В секции Storage отображаются все диски в системе. В этой секции нам нужны 2 параметра – Active Time и Disk Queue. Active Time в процентах отображает нагрузку на диск, то есть если вы видите на диске C:\ Active Time равный 90, это значит что ресурс чтения/записи диска на текущий момент используется на 90%. Столбец Disk Queue отображает очередь обращений к диску, и если значение очереди не равно нулю, то диск загружен на 100% и не справляется с нагрузкой. Так же если Active Time близок к 100, то диск используется практически на пределе своих возможностей по скорости.
Просмотр блокировок в SQL Server
После того как мы убедились, что серверу хватает ресурсов, можно переходить к просмотру блокировок.
Блокировки можно посмотреть через Activity Monitor в SSMS, но мы воспользуемся T-SQL, так как этот вариант более удобен и нагляден. Выполняем запрос:
Этот запрос возвращает список блокировок в виде дерева. Это удобно в работе, так как обычно, если возникает одна блокировка, она провоцирует за собой другие. Аналогично в Activity Monitor или в выводе sp_who2 можно увидеть поле “Blocked By”.
Если запрос ничего не вернул, то блокировок нет.
Если запрос вернул какие-то данные, то нужно проанализировать цепочку.
HEAD значит что этот запрос является причиной всех остальных блокировок ниже по дереву. 64 – это идентификатор процесса (SPID). После этого пишется тело запроса, который вызвал блокировку. Если у вас хватает ресурсов сервера, то скорее всего дело в самом запросе и во взаимном обращении к каким-то объектам. Для того чтобы сказать точнее, нужно анализировать конкретный запрос, который вызвал блокировку.
Политики SQL Server
Даже когда у вас всё работает хорошо и жалоб нет, на самом деле может быть много проблем, которые всплывут позже. Для этого в SQL Server есть политики.
Политика в SQL Server это, грубо говоря, проверка правила на соответствие заданному значению. Например, с помощью политик вы можете убедиться, что на всех базах на сервере выключен Auto Shrink. Рассмотрим пример импорта и выполнения политики
В SSMS, подключитесь к серверу, на котором хотите выполнять политики (Management -> раздел Policy Management).
Импортируем файл Database Auto Shrink.xml. Жмём Evaluate
На экземпляре node1 две базы данных, test1 и test2. На test2 включен autoshrink. Посмотрим детали.
Политика определила включенный параметр AutoShrink, в описании обычно пишется объяснения к правилам. В данном случае дается объяснение почему auto shrink лучше отключать.
Политики могут выполняться либо по расписанию, либо по требованию (разово). Результаты выполнения политики можно посмотреть в журнале политик.
При установке SQL Server нужно выбирать только используемые компоненты СУБД, и указывать настройки в соответствии с конфигурацией “железа” вашего сервера. Всегда следите чтобы серверу хватало ресурсов, и чтобы на сервере не было блокировок
Самым мощным инструментом для диагностики SQL Server является T-SQL и DMV. Так же рекомендуется построить круглосуточный мониторинг над SQL Server и над обслуживающей его инфраструктурой для обнаружения всех возможных проблем.
Читайте также: