(Возврат на основную страницу)

 

Содержание номера за Декабрь 2012 год

SQL Server

Декабрь 2012 12 (30)

 

  1. Отчет о 10 наиболее значимых ожиданиях
    Руди Панигас (Rudy Panigas)

  2. Неиспользуемые входные параметры
    Шон Смит (Sean Smith)

  3. Получение зарегистрированных заданий с группы серверов
    Дин Кастро (Dean Castro)

  4. Почему переполнен мой журнал транзакций?
    Гэйл Шоу (Gail Shaw)

  5. Размер журнала транзакций увеличивается, а из-за репликации моментального снимка нельзя выполнить его усечение или сжатие.
    Парикшит Савджани (Parikshit Savjani)


Отчет о 10 наиболее значимых ожиданиях
Руди Панигас (Rudy Panigas)
 

Если выполнить предлагаемый код, то вы получите отчет о 10 наиболее значимых типах ожиданий. Для расширения состава информации или, наоборот, ее сокращения, вы можете модифицировать код, как сочтете нужным. Для каждого типа ожидания приведены описания возможных причин возникновения ожиданий.



Неиспользуемые входные параметры
Шон Смит (Sean Smith)

Недавно я натолкнулся на код, в котором многочисленные входные параметры хранимых процедур, будучи объявлены, впоследствии не использовались. Как оказалось, разработчик в некоторый момент начал модифицировать код, удалил ссылки на параметры в теле процедуры, но не убрал их в заголовке процедуры.
Предлагаемая ниже хранимая процедура сканирует имеющиеся в БД объекты и возвращает список неиспользуемых параметров со перечнем дополнительной информации:
• schema_name: имя схемы, которой принадлежит объект, в котором найдены неиспользуемые параметры
• object_name: имя объекта, в котором найдены неиспользуемые параметры
• parameter_name: имя неиспользуемого параметра
• object_type: тип объекта, в котором найден неиспользуемый параметр (например: хранимая процедура, скалярная функция, и т.д.)
• data_type: тип данных неиспользуемого параметра
• is_output: идентификатор, указывающий является ли неиспользуемый параметр выходным (имеет атрибут "OUTPUT")
• definition: код объекта, в котором найден неиспользуемый параметр

Для получения данных, просто вызовите процедуру с указанием имени БД в качестве параметра:
EXECUTE dbo.usp_Unused_Input_Parameters @v_Database = N'my_database'



Получение зарегистрированных заданий с группы серверов
Дин Кастро (Dean Castro)

Мне было необходимо пробежаться по нескольким серверам и собрать с них информацию о зарегистрированных заданиях и графике их исполнения (меня в первую очередь интересовало время следующего исполнения). Я слепил несколько ранее написанных скриптов и получил приведенный ниже результат.
Я признателен Раулю Вайраги (Rahul Vairagi http://sqlserver2005forum.blogspot.com/2011/02/script-to-know-jobs-scheduled.html) и Кишору (Kishore http://www.dev-exchange.com/cms_view_article.php?aid=27) за написание основной части кода.

Код следует запускать с сервера, на котором у вас есть права на доступ к MSDB, на каждом связанном сервере вам также следует иметь те же самые права. Вы можете поместить код в процедуру или выполнить просто в окне SSMS.



Почему переполнен мой журнал транзакций?
Гэйл Шоу (Gail Shaw)
 

Это та ошибка, которая почти наверняка разрушит день любого администратора БД:
Error: 9002, Severity: 17, State: 2.
The transaction log for database 'VeryImportant' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases.
«Но, но, но...», – бормочет администратор БД, – «резервное копирование журнала выполняется, так почему же он переполнен?»
Что ж, создание очередной резервной копии журнала, которое завершается ошибкой или оказывается пропущенным, – это лишь одна из причин переполнения журнала транзакций. Есть также несколько других вероятных причин.



Размер журнала транзакций увеличивается, а из-за репликации моментального снимка нельзя выполнить его усечение или сжатие.
Парикшит Савджани (Parikshit Savjani)
Есть несколько возможных причин увеличения размера журнала транзакций базы данных SQL Server, например, ожидание контрольной точки, резервное копирование в модели полного восстановления, длительно выполняющаяся активная транзакция.

Простейший и самый толковый способ, позволяющий установить причину увеличения размера журнала транзакций в версии SQL Server 2005 – воспользоваться столбцами log_reuse_wait, log_reuse_wait_desc из представлений sys.databases в версиях SQL Server 2005 и 2008.

Итак, мы выполняем следующий запрос, чтобы выяснить причину увеличения размера файла журнала транзакций, и видим следующее:

select log_reuse_wait_desc,name from sys.databases

log_reuse_wait_desc name
--------------------------------------------- -------------
REPLICATION test

К нашему удивлению, в столбце log_reuse_wait_desc указана репликация (REPLICATION) конкретной базы данных, для которой настроена репликация моментального снимка.

Отсюда мы делаем вывод, что увеличение размера журнала объясняется репликацией моментального снимка, что в известной степени является иронией судьбы, поскольку репликация моментального снимка не использует журналы транзакций для репликации данных на удаленный узел.


(Возврат на основную страницу)