PRIL_3 (663293), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Собирать информацию о параметрах, характеризующих производительность SQL Server удобнее всего с помощью Windows NT Performance Monitor, который позволяет отследить более 30 параметров работы SQL Server. Также важно наблюдать некоторые параметры Windows NT. Основными являются следующие:

• Processor: %Processor Time - преобладающее значение выше 80% говорит о том, что процессор является узким местом. Это может быть вызвано, в частности, неоптимальной структурой базы данных.

• Memory: Pages/sec - должен быть не выше 5-10. Этот параметр характеризует интенсивность вытеснения страниц оперативной памяти на диск (paging).

• SQLServer: Cache Hit Ratio - (процент нахождения требуемой страницы памяти в кэше, а не на диске); должен быть не ниже 80%

• SQLServer: I/O - Page Reads/sec - высокое значение этого параметра говорит о недостаточном размере кэша.

• Physical Disk: Disk Queue Length или Logical Disk: Disk Queue Length - значение выше 2 говорит о том, что узким местом является диск.

• Собирать информацию по данным параметрам следует как в среднем за продолжительный период времени, так и в моменты пиковой нагрузки. Удобным может оказаться запись отслеживаемых параметров в журнальный файл (что позволяет сделать Performance Monitor) с последующим анализом в спокойной обстановке.

Кроме этого, могут помочь такие предложения языка Transact-SQL:

• DBCC MEMUSAGE - информация об использовании кэша данных и процедур

• SET SHOWPLAN ON - просмотр плана выполнения запроса, информация об использовании индексов

• SET STATISTICS TIME ON - показывает, сколько времени было затрачено на выполнение каждой стадии запроса

• SET STATISTICS IO ON - показывает, сколько операций логического и физического чтения было произведено над каждой таблицей при выполнении запроса.

Настройка. Память

Если параметр SQL Server: Cache Hit Ratio (процент попаданий в кэш), доступный для наблюдения через Windows NT Performance Monitor, по величине меньше 80%, то увеличение размера кэша должно повысить производительность. Оценить необходимый размер кэша для процедур и данных можно, выполняя самые часто встречающиеся запросы и хранимые процедуры и анализируя содержимое кэша при помощи предложения DBCC MEMUSAGE. Следует помнить, что хранимые процедуры в SQL Server не являются реентерабельными, т.е. если несколько клиентских процессов одновременно вызывают одну и ту же хранимую процедуру, то в кэше окажется несколько ее копий.

Если же параметр Memory: Pages/sec постоянно выше 5-10, то памяти не хватает системе в целом и нужно либо остановить какие-либо приложения или сервисы, или добавить памяти в компьютер.

Настройка. Запросы и индексы

Предположим, у нас есть запрос, который медленно выполняется. Мы собрали информацию о нагрузке на процессор, память, диски и сеть и выяснили, что узким местом является процессор, т.к. он используется на 100% при выполнении запроса, а остальные ресурсы явно недогружены. Можно, конечно, заменить процессор или перейти на многопроцессорную платформу, но сначала мы проанализируем пути доступа.

Задав перед выполнением запроса опцию "SET SHOWPLAN ON", мы получим информацию об использовании индексов. В первоначальном варианте запроса индексы не используются. Построив индекс по полю, являющемуся аргументом поиска в запросе, мы существенно сокращаем количество операций чтения и, соответственно, время выполнения запроса.

Следует учесть, что оптимизатор запросов SQL Server делает вывод об использовании того или иного индекса при выполнении запроса на основании статистических данных о распределении значений ключей индекса. Эти статистические данные не обновляются при обновлении данных в таблице. Для обновления статистики можно или перестроить индекс, или использовать предложение "UPDATE STATISTICS".

СОПРОВОЖДЕНИЕ MICROSOFT SQL SERVER

В последнем разделе мы рассмотрим задачи, которые приходится выполнять администратору SQL Server в процессе ежедневной эксплуатации сервера. Их можно разбить на две основные группы:

1) работы, которые можно и должно планировать заранее - назовем их регламентными работами

2) обработка различных сбойных ситуаций, которые планировать невозможно, но можно все-таки быть к ним готовым.

Регламентные работы (Планировщик)

В Microsoft SQL Server 6.0 есть все возможности довести выполнение регламентных работ до такой степени автоматизации, что администратор может на них практически не тратить время - все будет выполнять специальный сервис, который называется Планировщик (Scheduling Engine). Вы можете давать ему задания, которые будут выполняться по расписанию, периодически или однократно в назначенное время и о выполнении которых вы можете узнавать, просматривая историю заданий или получая от Планировщика сообщения по электронной почте.

Планировщик используется, в частности, для поддержки тиражирования данных. Он может выполнять несколько типов заданий, из которых нас интересуют два - выполнение последовательности команд на языке Transact-SQL и выполнение команд операционной системы Windows NT Server. Мы рассмотрим использование планировщика на примере типичных и наиболее частых задач - резервного копирования и обновления статистики.

Резервное копирование

Базы данных необходимо периодически копировать - это объяснять не нужно. Копировать нужно как пользовательские базы данных, так и системные - в SQL Server 6.0 к ним относятся, помимо базы "master", еще и появившиеся в SQL Server 6.0, "msdb" и, для серверов-распространителей в процессе тиражирования, - "distribution".

Базу данных "master" следует копировать после таких действий, как создание новой базы данных, нового устройства или сегмента, заведения нового пользователя. Вполне разумно выполнять ее резервное копирование периодически (например, ежедневно), также как и копирование пользовательских баз данных или их журналов транзакций.

Поэтому имеет смысл поручить это занятие Планировщику. Работа с Планировщиком осуществляется при помощи средства SQL Enterprise Manager. Планирование резервного копирования можно задать и не в обычном интерфейсе Планировщика, а в специальной форме, для этого предназначенной. В SQL Server 4.21 тоже можно было сконфигурировать автоматическое резервное копирование, но это было единственное автоматическое действие.

Обновление статистики

Обновление индексной статистики, как мы уже говорили, может существенно повлиять на производительность сервера. Поэтому его тоже имеет смысл делать регулярно и поручить Планировщику. Что мы сейчас и сделаем. Создадим задание типа 'TSQL' (выполнение предложения языка Transact-SQL), выполняющее в базе данных 'pubs' вызов хранимой процедуры 'update_all_stats', которая обновляет статистику по всем таблицам. Пусть статистика обновляется еженедельно, по воскресеньям в 3:00. Сообщения о неудачном завершении задания будут записываться в системный журнал, а также отправляться по электронной почте оператору.

Предвидение сбойных ситуаций

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

Так, например, если вы используете SQL Server в приложении, "жизненно важном" для деятельности вашей фирмы, то вам, скорее всего, необходимо будет делать резервное копирование баз данных минимум раз в день. Копировать данные можно на стриммер или на жесткий диск. Кроме того, следует, очевидно, иметь резервный компьютер с установленным на нем SQL Server и конфигурацией баз данных, полностью соответствующей основному серверу. Тогда в случае выхода из строя основного сервера можно будет с минимальными потерями времени перевести систему на обслуживание резервным сервером. Можно делать резервное копирование баз данных основного сервера на жесткий диск резервного сервера. Для этого нужно, чтобы сервис SQL Server регистрировался в Windows NT под именем пользователя, который имеет права на запись на этот диск.

Менеджер событий

Еще один компонент системы управления SQL Server - менеджер событий (Alert Manager), позволяет запланировать реакцию сервера на все возможные сбойные ситуации. События фиксируются в системном журнале, менеджер событий постоянно читает этот журнал и, при обнаружении заданного кода сообщения, выполняет запланированное администратором действие. Это действие оформляется в виде задания планировщику, аналогичного рассмотренному заданию на обновление статистики, только выполняется оно не по расписанию, а "по требованию". Конфигурируя реакцию на события, администратор указывает, какое задание выполнить в случае наступления этого события. Например, при переполнении журнала транзакций можно вызвать задание, которое осуществит резервное копирование журнала и тем самым очистит его.

Событие можно настроить на конкретное сообщение об ошибке, а можно на группу ошибок, относящихся к одному т.н. "уровню серьезности".

Реакция на событие также предусматривает уведомление указанного списка операторов средствами электронной почты или пэйджинговой связи. Для того, чтобы SQL Server мог отправлять и принимать почту, работая с Microsoft Exchange, необходимо при конфигурировании SQL Mail указать в качестве имени пользователя имя профиля ("profile"), а в качестве пароля - сетевой пароль владельца профиля. При этом необходимо, чтобы SQL Server регистрировался в Windows NT не под именем "Local System", а под именем владельца вышеупомянутого профиля.

Анализ сбойной ситуации

Что делать, если сервер или клиентское приложение выдает сообщение об ошибке? Прежде всего, необходимо собрать максимум точной информации - номер сообщения, поясняющий текст, какое действие производилось в момент, когда произошла ошибка. Просмотрите журнал ошибок SQL Server и системный журнал Windows NT Server. Затем нужно выяснить, какой компонент вашего клиент-серверного приложения вызывает эту ошибку. Компоненты нужно рассмотреть следующие:

• Клиентское приложение;

• Сеть;

• SQL Server

Если вы выяснили, какой запрос привел к сбойной ситуации, то изолировать клиентское приложение можно, послав этот же запрос к SQL Server через интерактивную утилиту ISQL/W. Если ошибка повторяется, значит клиентское приложение ни при чем. Послав этот же запрос, но не с рабочей станции, а непосредственно с компьютера, на котором работает SQL Server, можно выяснить, виновата ли сеть.

Анализ проблем с блокировками

Если вы предполагаете, что есть проблемы с блокировками, то удобно выяснить, так ли это, используя SQL Enterprise Manager и, конкретно, режим просмотра текущей активности ("current activity"). В этом режиме наглядно представлена информация о том, какой процесс блокирует другие процессы и из-за блокирования каких таблиц происходит конфликт. Вы имеете возможность перестроить запросы так, чтобы они не приводили к конфликтам и, в крайнем случае, "убить" нежелательный процесс.

13

Характеристики

Список файлов реферата