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

 

Содержание номера за Август 2009 год

SQL Server
для администраторов

Август 2009
№ 8 (38)

Майк Рутраф

Диагностика проблем производительности журнала транзакций и ограничения диспетчера журналов

Пол С. Рэндал

Основы протоколирования и восстановления в SQL Server

Углубленная диагностика с помощью расширенных событий (Extended Events). Часть 2

Санджай Мишра, Майк Рутраф

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Часть 2

 

 Диагностика проблем производительности журнала транзакций и ограничения диспетчера журналов

Майк Рутраф (Mike Ruthruff)

 

Для транзакционных рабочих нагрузок производительность ввода-вывода при записи в журнал транзакций SQL Server критична как с точки зрения пропускной способности, так и с точки зрения времени отклика приложения. В этом документе дается краткое пояснение, как определить, является ли ввод-вывод в файл журнала транзакций узким местом с точки зрения производительности, и связано ли это с хранилищем; ограничение возникло из-за диспетчера журналов или это комбинация обоих факторов. Рассмотренные в этой статье концепции и вопросы касаются главным образом версий SQL Server 2005  и SQL Server 2008.

Мониторинг производительности журнала транзакций

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

Вот их перечень:

•    Динамические административные представления (Dynamic Management Views, DMV) сервера SQL Server:

•    ys.dm_os_wait_stats-Это представление обеспечивает информацию об ожиданиях нескольких типов, его описание находится здесь: http://msdn.microsoft.com/en­us/library/ms179984.aspx. Самым важным с точки зрения настоящего обсуждения является ожидание типа WRI­TE­LOG. Информация об ожиданиях типа WRITE­LOG позволяет узнать время ожидания завершения журнальных операций ввода­вывода после выполнения транзакцией команды COMMIT. Наблюдение за ожиданиями WRITE­LOG должно подсказать, каких величин для производительности и характеристик ввода­вывода следует добиваться при записи в журнал транзакций.

•    sys.dm_io_pending_io_requests-Это представление обеспечивает сведения об ожидающих выполнения запросах ввода­вывода на уровне отдельных операций ввода­вывода. Документацию для представления sys.dm_io_pending_io_requests можно найти здесь: http://msdn.microsoft.com/en­us/library/ms188762.aspx. В сценариях, где файл журнала транзакций сервера SQL Server находится на томе, не являющемся выделенным, это представление можно использовать для мониторинга количества операций ввода­вывода, ждущих выполнения на уровне файла. Если журнал транзакций находится на выделенном логическом томе, эту информацию можно получить с помощью счетчиков системного монитора Performance Monitor. Оба варианта подробнее рассматриваются ниже.

•    Объект «SQL Server:Databases» системного монитора Window Performance Monitor. Этот объект монитора производительности содержит несколько отдельных счетчиков производительности журнала транзакций конкретной базы данных. Во многих случаях эти счетчики могут предоставить более подробную информацию о производительности журнала, поскольку детализация осуществляется на уровне журнала, безотносительно логической конфигурации хранилища. Вот эти специальные счетчики:

•    Log Bytes Flushed/sec (Объем данных в байтах, записываемых в журнал в секунду).

•    Log Flushes/sec (Количество записей, вносимых в журнал в секунду) (т. е. количество операций ввода­вывода, выполняемых для «сброса» записи в журнал транзакций).

•    Log Flush Wait Time (Совокупное время ожидания записи в журнал в миллисекундах).

•    Объекты «Logical Disk» и «Physical Disk» монитора Windows Performance Monitor. Имеется пять счетчиков, которые всегда следует учитывать при анализе ввода­вывода:

•    Current Disk Queue Length (Текущая длина очереди диска).

•    Avg. Disk/sec Read (Среднее время считывания с диска в секундах), Avg.Disk/Write (Среднее время записи на диск в секундах).

•    Avg. Disk Bytes/Read (Средний объем в байтах данных, считываемых в одной операции чтения), Avg. Disk Bytes/Write (Средний объем в байтах данных, записываемых в одной операции
записи).

•    Disk Reads/sec (Количество операций считывания с диска, выполняемых в секунду), Disk Wri­tes/sec (Количество операций записи на диск, выполняемых в секунду).

•    Disk Read Bytes/sec (Объем в байтах данных, считываемых с диска в секунду), Disk Write Bytes/sec (Объем в байтах данных, записываемых на диск в секунду).

Ключевыми для мониторинга производительности журнала транзакций являются счетчики Current Disk Queue Length и Avg. Disk/sec Write.

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

Основы протоколирования и восстановления в SQL Server

Пол С. Рэндал (Paul S. Randal)

В перечень компонентов SQL Server, неправильное понимание которых встречается чаще всего, входят механизм протоколирования (logging) и механизм восстановления (recovery). Тот факт, что журнал транзакций существует и в случае некорректного его использования может стать причиной возникновения проблем, по-видимому, приводит в замешательство многих «администраторов БД поневоле». Почему размер журнала транзакций может возрастать без ограничений? Почему иногда так долго не удается вернуть базу данных в рабочее состояние после аварийного сбоя системы? Почему нельзя совсем отключить протоколирование? Почему я не в состоянии надлежащим образом восстановить мою базу данных? В конце концов, что это такое — журнал транзакций, и зачем он нужен?

Все эти вопросы снова и снова встречаются на форумах и в новостных группах, посвященных SQL Server, поэтому в своей статье я хочу дать общее представление о системе протоколирования и восстановления и объяснить, почему она является неотъемлемой частью механизма SQL Server Storage Engine. Я разъясню, как устроен журнал транзакций, и расскажу о том, как могут повлиять на функциональное поведение этого компонента и на процесс протоколирования имеющиеся в нашем распоряжении три модели восстановления баз данных. Наряду с этим я также предоставлю некоторые ссылки на ресурсы с материалами, в которых рассматривается практическая сторона ведения журнала транзакций.

Подводя итоги

Эта статья, вообще говоря, в большей степени является академическим толкованием того, как работает жизненно важная часть SQL Server. Надеюсь, мне удалось прояснить все ошибочные представления, которые у вас, возможно, имелись. Если это ваше первое знакомство с протоколированием и восстановлением, вот те ключевые моменты, которые мне хотелось бы, чтобы вы извлекли из этой статьи:

•    Не создавайте несколько файлов журнала, поскольку это не приведет к росту производительности.

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

•    Разберитесь с возможностями увеличения размеров журнала транзакций, с факторами, провоцирующими такое увеличение, и с тем, как обеспечить контроль над этим процессом.

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

В моем блоге представлены значительно более обширные сведения о журнале транзакций и о влияющих на него факторах: подробности ищите в записях из категории «Transaction Log» (Журнал транзакций). Очень полезны также различные разделы документации Books Online, касающиеся журнала транзакций, начиная с раздела Transaction Log Management (Управление журналом транзакций).

•    8 шагов по повышению пропускной способности журнала транзакций (8 Steps to Better Transaction Log­ Throughput) (http://sqlskills.com/blogs/kimberly/post/8­Steps­to­better­Transaction­Log­throughput.
aspx).

•    Operations that Can Be Minimally Logged (http://msdn.microsoft.com/library/ms191244).

•    Transaction Log (http://sqlskills.com/BLOGS/PAUL/category/Transaction­Log.aspx).

•    Transaction Log Management (http://msdn.microsoft.com/library/ms345583).

•    Видеозаписи на сайте technetmagazine.com/videos (http://technetmagazine.com/videos).

•    Диагностика и устранение проблем заполненного журнала транзакций (ошибка 9002) (Troub­le­shooting a Full Transaction Log) (Error 9002) (http://msdn.microsoft.com/library/ms175495).

•    Журнал транзакций (Transaction Log) (http://sqlskills.com/BLOGS/PAUL/category/Transaction­
Log.aspx).

•    Индекс советов журнала TechNet Magazine — Tech­Net Magazine Tips index (http://technet.microsoft.com/en­us/magazine/dd310316.aspx).

•    Операции, допускающие неполное протоколирование (Operations that Can Be Minimally Logged) (http://msdn.microsoft.com/library/ms191244).

•    Раздел « ACID­свойства» («ACID Properties») в библиотеке MSDN Library (http://msdn.microsoft.com/library/aa719484).

•    Советы по работе с SQL Server из журнала TechNet Ma­ga­zine — TechNet Magazine SQL Server Tips (http://technet.microsoft.com/en­us/magazine/dd391795.
aspx).

•    Управление журналом транзакций (Transaction Log Management) (http://msdn.microsoft.com/library/ms345583).

•    Факторы, способные препятствовать усечению журнала транзакций (Factors that Can Delay Log Truncation) (http://msdn.microsoft.com/library/ms345414).

 

Углубленная диагностика с помощью расширенных событий (Extended Events). Часть 2*

Пол С. Рэндал (Paul S. Randal)

Расширенные события

Возможности, предоставляемые системой расширенных событий, намного превышают то, что предлагает любой из механизмов отслеживания событий и диагностики, которые сервер SQL Server обеспечивал до этого. По­моему, наиболее яркими чертами системы расширенных событий являются следующие:

•    События наступают синхронно, но обрабатываться могут синхронно или асинхронно.

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

•    «Интеллектуальные» предикаты позволяют формулировать сложные правила с помощью булевой логики.

•    Все управление сеансами расширенных событий можно осуществлять с помощью языка Transact­SQL.

•    Мониторинг критичного по производительности программного кода можно осуществлять, не снижая его производительности.

Прежде чем продолжить, я потрачу минуту на то, чтобы определить некоторые новые термины.

Event (событие) — это определенная точка в программном коде. Примерами могут служить точка, в которой завершается выполнение предложения языка T­SQL, или точка, в которой снимается запрошенная блокировка. Каждое событие обеспечивает получение определенных полезных данных (payload) (набор столбцов, возвращаемых этим событием) и определяется с помощью модели ETW (где каждое событие возвращает помимо прочих данных канал и ключевое слово), чтобы обеспечить возможность интеграции с этой моделью. Изначально в поставку версии SQL Server 2008 были включены 254 предопределенных события, и предполагается, что со временем будут добавлены новые.

*-См. Пол С. Рэндал. Углубленная диагностика с помощью расширенных событий (Extended Events). Часть 1 // SQL Server для администраторов. 2009. № 7.

Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Часть 2*

Санджай Мишра (Sanjay Mishra), Майк Рутраф (Mike Ruthruff)

Это вторая часть статьи «Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008» (Tuning the Performance of Backup Compression in SQL Server 2008). В первой части мы рассмотрели преимущества, которые обеспечивает сжатие резервной копии, методологию настройки процедуры сжатия резервной копии в целях повышения производительности и поделились некоторыми практическими приемами. Во второй части мы рассматриваем некоторые дополнительные условия, учитываемые при настройке операции сжатия резервной копии, а также взаимодействие резервного копирования со сжатием с другими важными функциональными возможностями версии Microsoft SQL Server 2008.

Точнее говоря, мы рассмотрим следующие вопросы:

•    Настройка параметров BUFFERCOUNT и MAX­TRANS­FERSIZE.

•    Оперативная память, используемая операцией резервного копирования со сжатием.

•    Сжатие резервных копий и доставка журналов.

•    Сжатие резервных копий и сжатие данных.

•    Сжатие резервных копий и прозрачное шифрование данных.

Знание методик настройки и понимание того, как резервное копирование со сжатием взаимодействует с другими рассматриваемыми в этой статье возможностями, могут помочь вам извлечь максимальную пользу из резервного копирования со сжатием.

*-См. Майк Рутраф, Санджай Мишра и др. Как повысить производительность резервного копирования со сжатием в версии SQL Server 2008. Часть 1 // SQL Server для администраторов. 2008. № 9.

 

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

Hosted by uCoz