Проблема блокирования SQL Server

Question

В настоящее время у нас есть проблема, которая возникает примерно один раз в день на сервере базы данных SQL 2005, хотя время, когда это происходит, не согласовано.

По сути, база данных останавливается и начинает отказывать в соединениях со следующим сообщением об ошибке. Это включает в себя вход в систему SSMS:

Соединение с сервером было успешно установлено, но во время входа в систему произошла ошибка. (поставщик: поставщик TCP, ошибка: 0 - указанное сетевое имя больше не доступно.)

Наше использование ЦП для SQL обычно составляет около 15%, но когда БД находится в нерабочем состоянии, она составляет около 70%, поэтому он явно что-то делает, даже если никто не может подключиться. Даже если я отключу веб-приложение, использующее базу данных, процессор все равно не выйдет из строя.

Я не могу перезапустить процесс SQLSERVER, так как он не отвечает, поэтому мне приходится в конечном итоге завершить процесс вручную, после чего БД переводится в режим подозрения / восстановления (что я могу исправить, но это не так). *

Ниже приведена статистика PerfMon, которую я собрал, когда БД находилась в нерабочем состоянии, что может помочь. У меня есть еще куча, если люди захотят их запросить:

• Активных транзакций: 2 (Никогда
• Изменения) Логические соединения: 34 (NC)
• Процесс заблокирован: 16 (NC) Пользователь
• Соединения: 30 (NC) Пакетный запрос: 0
• (NC) Активные задания: 2 (NC) Журнал
• Сокращения: 596 (NC) Сжатие журнала: 24
• (NC) Самая продолжительная транзакция
• Время: 99 (NC)

Полагаю, они выясняют, какая БД использует свой ЦП, но, поскольку я даже не могу войти в SSMS, это невозможно сделать стандартными методами.

К сожалению, я даже не могу использовать выделенное административное соединение для входа в SSMS. Я получаю тот же тайм-аут, что и со всеми другими запросами.

Любой совет, рекомендации или даже сочувствие, очень ценится!

Answer 1

Несмотря на то, что он блокирует нормальные соединения, вы можете попытаться подключиться через соединение с выделенной консолью администратора. Для этого вам нужно быть в роли системного администратора сервера базы данных, в SSMS, когда вы указываете имя сервера с префиксом «admin:» - здесь используется другое соединение, которое с меньшей вероятностью будет заблокировано (но не невозможно, просто принимает экстремальные обстоятельства).

Вы не должны использовать этот ЦАП по умолчанию, вы получаете доступ к системным таблицам и различным другим элементам, которые вы обычно не видите, поэтому вы также можете нанести ему большой урон.

После этого у вас есть обычное окно запроса, и вы можете начать смотреть, что работает, что заблокировано и т. Д.

Answer 2

выделенное административное соединение предназначено для помощи в этих ситуациях

Затем этот скрипт может сказать вам, что имеет открытый транс и SQL работает

SELECT s_tst.[session_id],
   s_es.[login_name] AS [Login Name],
   S_tdt.[database_transaction_begin_time] AS [Begin Time],
   s_tdt.[database_transaction_log_record_count] AS [Log Records],
   s_tdt.[database_transaction_log_bytes_used] AS [Log Bytes],
   s_tdt.[database_transaction_log_bytes_reserved] AS [Log Reserved],
   s_est.[text] AS [Last T-SQL Text],
   s_eqp.[query_plan] AS [Last Query Plan]
FROM sys.dm_tran_database_transactions s_tdt
   JOIN sys.dm_tran_session_transactions s_tst
      ON s_tst.[transaction_id] = s_tdt.[transaction_id]
   JOIN sys.[dm_exec_sessions] s_es
      ON s_es.[session_id] = s_tst.[session_id]
   JOIN sys.dm_exec_connections s_ec
      ON s_ec.[session_id] = s_tst.[session_id]
   LEFT OUTER JOIN sys.dm_exec_requests s_er
      ON s_er.[session_id] = s_tst.[session_id]
   CROSS APPLY sys.dm_exec_sql_text (s_ec.[most_recent_sql_handle]) AS s_est
   OUTER APPLY sys.dm_exec_query_plan (s_er.[plan_handle]) AS s_eqp
ORDER BY [Begin Time] ASC;

Наконец, SQL Server 2005 имеет трассировку по умолчанию : вы можете использовать ее, чтобы узнать, что пошло не так

Answer 3

Вам понадобится использовать Профилировщик, чтобы определить, какие запросы и процессы могут вызывать это.