Шпаргалка по 70-028 | Мониторинг SQL Server 7.0 Дальше »
Задачи и цели мониторинга
Факторы производительности
Средства и способы мониторинга
Инструменты мониторинга
Microsoft Event Viewer
SQL Server Performance Monitor
Окно Current Activity, SQL Server Enterprise Manager
Мониторинг средствами Transact-SQL
Мониторинг средствами SQL Server Profiler
Информация из чёрного ящика MS SQL Server
Мониторинг средствами SQL Server Query Analyzer
Регламент администрирования SQL Server
Вопросы для повторения

Задачи и цели мониторинга

Определить оптимальность работы сервера баз данных и выявить возможные неполадки или узкие места, можно с помощью средств мониторинга, предоставляемых SQL сервером. Грамотное использование этих средств позволит Вам вовремя определить и устранить причины низкой производительности сервера, которая определяется объёмом операций ввода-вывода, необходимых для исполнения транзакции, утилизацией процессоров и временем отклика системы. Для каждой конкретной реализации, уровень доступной производительности определяется составом аппаратно-программных средств и способов их использования. Наиболее наглядным фактором оценки производительности системы является её время отклика, которое представляет собой интервал времени, в течении которого сервер возвращает первую строку результата исполнения запроса, т.е. пользователь получает визуальное подтверждение того, что его запрос исполняется. Пропускная способность обслуживаемых сервером процессов и пользователей определяет сколько запросов возможно исполнить в фиксированный интервал времени, и сколько строк и какого размера возвращается клиенту. При увеличении числа активных процессов и/или пользователей, возрастает и их конкуренция за системные ресурсы. Результатом такой чрезмерной нагрузки может стать увеличение времени отклика и снижение общей пропускной способности. Большое влияние на производительности базы данных оказывает также и состояние/согласованность самих данных. Страницы данных и индексы могут оказаться повреждёнными, что приводит потере логической и физической согласованности. Для выявления таких повреждений используют специальное средство Database Consistency Checker (DBCC).

Факторы производительности

В числе факторов, которые способны повлиять на производительности системы, можно выделить, в первую очередь, аппаратную конфигурацию сервера. Количество процессоров и их быстродействие, количество и быстродействие дисков, объём оперативной памяти; всё это оказывает очень существенное влияние на уровень производительности. Не малую роль в общую производительность вносит и операционная система (ОС). Очевидно, что параллельно с процессами сервера баз данных будут выполняться процессы ОС и других, одновременно функционирующих на этом сервере программ. Также, на производительность могут повлиять файлы страничного обмена, их количество и местоположение. Использование RAID технологии также может в ту или иную сторону сказаться на общей производительности. Разумеется, нельзя исключать из систем, участвующих в оценке общей производительности, и сетевую среду, быстродействие сетевых соединений которой, а также её утилизация или уровень коллизий влияют на полосу пропускания сети, а следовательно, и на скорость передачи данных и запросов между клиентом и сервером. Сам SQL сервер, естественно, тоже оказывает влияние на производительность системы. Его конфигурация подразумевает динамическое распределение многих ресурсов и параметров, таких, как память, дисковое пространство подключения пользователей. Если у Вас нет веских на то оснований, лучше не вмешивайтесь в это динамическое распределение. Отрицательно сказываются на производительности сервера блокировки и большие объёмы журналируемых операций. Параллельное выполнение резервирования/восстановления, запуск DBCC или переиндексация могут также существенно сказаться на времени отклика сервера. Качество проектирования баз данных тоже имеет весомое значение. Производительность запросов может зависеть от уровня нормализации данных, их логической и физической структуры. Уровень контроля выполнения транзакций, как правило, влияет на количество и длительность блокировок. Часто повторяющиеся конфликты также замедляют работу. Зато оформление запросов в виде хранимых процедур может существенно поднять их «скорострельность», относительно незапланированных запросов, реализованных в логике клиента.  От логики работы клиентского приложения также зависит очень многое. Само число одновременно обращающихся к серверу баз данных и выбранной для этого схемы сетевых соединений, оказывает существенное влияние на распределение памяти сервера. Уменьшение числа конфликтов при обслуживании транзакций в состоянии существенно повысить общую производительность. Реакция клиентского приложение на блокировки и его способность повторно выставлять запрос или операторы модификации данных, может существенно разгрузить и оптимизировать работу сети и SQL сервера. Время отклика можно значительно сократить за счёт использования правильных видов курсора, сокращения объёмов извлекаемых данных и оптимизации использования кэша.

Средства и способы мониторинга

Задача исследования производительности SQL сервера и выявления узких мест решается намного проще, если Вы будете использовать системный подход. Столкнувшись с тем, что Ваша СУБД работает не так производительно, как Вы ожидали или производительности неожиданно снизилась, без видимых на то причин, необходимо последовательно локализовать проблему, которая стала этому виной.
Стандартное руководство Микрософт предлагает начать поиск проблемы или узкого места на системном уровне, а уже после этого на уровне клиентского приложения и отдельного запроса. Это можно объяснить тем, что низкая производительность приложения баз данных может быть не следствием проблем SQL сервера, а вызвана перегрузкой дисковой подсистемы, высокой утилизацией процессора или памяти. Причиной перегрузки дисковой подсистемы может быть, к примеру, высокое число запросов на подкачку страниц. Для того, что бы судить о том, высока ли утилизация одного из используемых системой ресурсов, необходимо представлять, какие значения его утилизации являются допустимыми, а какие низкими или высокими. Выяснить допустимые диапазоны производительности логично до начала промышленной эксплуатации системы (используя модель рабочей нагрузки), и периодически их корректировать по мере роста или модификации составных компонентов системы. Ясное и точное представление о допустимых диапазонах значений имеющихся в Вашем распоряжении счётчиков производительности поможет Вам быстро локализовать неисправности или находить узкие места, даже в тех случаях, когда причиной возникновения проблемы в одной области могут быть проблемы   из другой области, или они их маскируют. Например, один из используемых компонентов может мешать передаче рабочей нагрузки на другой компонент. Или проблемы в сети могут не давать клиентам подключиться к серверу или очень сильно увеличивать время отклика. Также, на производительность сервера могут оказывать негативное влияние узкие места клиентских программ. После перевода системы в промышленную эксплуатацию, стандартное руководство рекомендует составить базовый профиль производительности, в который включаются основные параметры реальной работы системы, а также часы максимальной загрузки пользователями базы данных, реальное время отклика запросов или пакетных файлов, время резервирования/восстановления баз данных и т.п. Базовый профиль можно сравнить с допустимыми диапазонами, что бы выяснить, производительность каких систем или компонент оказалась не достаточно высока.

Инструменты мониторинга

На всех этапах мониторинга производительности системы в Вашем распоряжении будут шесть инструментальных средств, входящих в базовый комплект поставки Microsoft SQL Server. Для мониторинга на уровне системы используют Microsoft Event Viewer и SQL Server Performance Monitor. Для мониторинга операций Microsoft SQL Server и работы его компонент (блокировки, коллизии, подключения, утилизация tempdb, согласованность данных) используют такие средства, как: SQL Server Profiler, окно Enterprise Manager - Current Activity, системные хранимые процедуры, специальные операторы T-SQL, операторы DBCC. Для исследования производительности отдельных запросов (использование индексов, утилизация запросом процессора, объём I/O) применяют SQL Server Query Analyzer и Index Tuning Wizard.

Microsoft Event Viewer

Журналы операционной системы Microsoft Windows NT, доступ к которым легко осуществляется с помощью программы Microsoft Event Viewer, дают много полезной информации о событиях, зафиксированных ОС. Анализируя эти события можно составить представления о характере возможных «узких» мест в Вашей системе. Программа Event Viewer предоставляет возможность анализа трёх журналов событий операционной системы: Windows NT Application Log, Windows NT System Log и Windows NT Security Log.
Windows NT Application Log – это журнал регистрации событий запущенных на сервере Windows NT приложений, включая сервисы MS SQL Server. Windows NT System Log – журнал регистрации системных событий, порождённых компонентами Windows NT (например, драйверами устройств). Windows NT Security Log – журнал безопасности, в котором регистрируются все события связанные с авторизацией и аутентификацией доступа к ресурсам системы (например, попытки регистрации в системе).
Этими журналами собираются, в частности, события, которые отражают причины прерывания работы системы или её компонент, а также сведения о событиях, влияющих на производительность работы. Записи в журналах, регистрирующие уведомления о переполнении журналов, повреждениях файлов, ошибках приложений или предупреждения о не штатных ситуациях должны стать предметом постоянного контроля со стороны DBA. В число событий, генерирующихся приложениями, могут входить и события, порождаемые в ходе исполнения хранимых процедур на сервере баз данных. Кроме того, в этом журнале отображаются многие события, которые фиксируются также в журнале ошибок SQL Server, включая запуск и останов его сервисов, выполнение регенерации, оповещениях и т.п. Удобство использования программы Event Viewer состоит в том, что она обладает удобными средствами просмотра, фильтрации и поиска по содержащимся в журнале событиям.

SQL Server Performance Monitor

Стандартное средство диагностики работы операционной системы Windows NT Performance Monitor может иметь вариант настройки, позволяющий отслеживать операции, статистику производительности в течении заданного временного интервала или наблюдать операции сервера по мере их выполнения, и т.п., касающееся MS SQL Server, и всё это будет уже называться SQL Server Performance Monitor. К стандартному набору счётчиков сервера и операционной системы добавляются специфические счётчики сервера баз данных, которые совместно со счётчиками NT сохраняются в файле с расширением .pmc. Создание объектов измерения производительности MS SQL Server происходит на стадии инсталляции сервера БД, и эти, предварительно определённые счётчики, сохраняются в файле Sqlctrs.pmc. Разумеется, работа Performance Monitor не проходит незаметно для общей производительности системы, поскольку отнимает ресурсы на свои нужды. Если Вы используете NT аутентификацию, то счётчики сервера баз данных будут доступны только для пользователей, входящих роль sysadmin.
Автоматически, при запуске SQL Server Performance Monitor вам будут предложены для анализа данные следующих, предварительно определённых счётчиков:

- SQL Server: Buffer Manager\Buffer Cache Hit Ratio - определяющий долю страниц в процентах, которые были обнаружены в буферном кэше, что позволило обойтись без дисковых операций;
- SQL Server: General Statistics\User Connections - показывающий количество подключённых к системе пользователей;
- SQL Server: Memory Manager\Total Server Memory (KB) - показывает общий объём динамической памяти, используемой сервером в текущий момент.
- SQL Server: SQL Statistics\SQL Compilations/sec - показывает количество исполненных компиляций SQL запросов в секунду;
- SQL Server: Buffer Manager\Page Reads/sec - показывает число операций чтения физических страниц базы в секунду;
- SQL Server: Buffer Manager\Page Writes/sec - показывает число операций записи физических страниц базы в секунду.

Следующие счётчики не являются предварительно определёнными, но очень часто бывают полезны:

- SQL Server: Databases\Active Transactions - показывает количество активных транзакций для БД;
- SQL Server: Databases\Percent Log Used\database - показывает процент заполнения журнала регистрации транзакций для выбранной БД;
- SQL Server: Access Methods\Full Scans/sec - показывает количество исполненных полных сканирований (без ограничений) таблиц или индексов, в секунду;
- SQL Server: Access Methods\Index Searches/sec - показывает количество исполненных операций поиска по индексу, в секунду. Такие сканирования могут применятся для начала процедуры просмотра диапазона, выборки отдельных записей индекса и переустановки узлов в индексе;
- SQL Server: Locks\Number of Deadlocks/sec - показывает количество запросов на блокировку, которые закончились тупиковой блокировкой.

Часто, весьма полезными оказываются и счётчики Windows NT Performance Monitor, вот некоторые из них:

- Memory/Pages per second - показывает количество считанных или записанных на диск страниц из-за отсутствия нужных страниц в памяти;
- Memory/Pages faults per second - показывает количество ошибок процессора в секунду, вызванных отсутствием страниц в памяти;
- Memory/Pages input per second - показывает количество считанных с диска страниц, в секунду, из-за отсутствия страниц в памяти;
- Process/Pages faults per second/SQL Server - показывает количество ошибок SQL Server в секунду, вызванных отсутствием страниц в памяти;
- Processor/% processor time - показывает долю процессорного времени в процентах (утилизацию процессора), затраченную на обслуживание текущего операционного потока;
- Process/% processor time/ SQL Server - показывает утилизацию процессора со стороны SQL Server.

Кроме стандартных счётчиков, у Вас есть возможность определить до десяти пользовательских счётчиков. Специальный объект SQL Server User-Settable Counters может содержать до 10-ти определяемых пользователем счётчиков - SQL User Counter. Такие счётчики Вы можете создавать с помощью хранимой процедуры sp_usercounter, параметром которой служит номер счётчика от 1 до 10. Вы можете сами определять значения для этих счётчиков, которые могут отображать данные, возвращаемые операторами SQL, а также любыми операциями SQL сервера, например, системными хранимыми процедурами.

Окно Current Activity, SQL Server Enterprise Manager

Одной из составных частей Enterprise Manager является окно Current Activity (текущие операции), с помощью которого можно получить данные о процессах, блокировках и текущих подключениях SQL сервера. Эта информация представляется в графическом виде и позволяет DBA получить информацию о текущих соединениях пользователей с сервером, состоянии и блокировках процессов и операторов и др. объектов, а также позволяет управлять процессами и блокировками.
Одним из самых важных применений окна Current Activity является возможность контроля и управления процессами и блокировками. Просмотреть существующие в текущее время соединения с сервером, определить, какие пользователи эти соединения создали и какие последние операторы этими пользователями выполнялись, можно с помощью опции PROCESS INFO в папке Management в Enterprise Manager. В целях контроля параллелизма, SQL сервер выставляет блокировки на используемые пользователями или процессами таблицы или страницы данных. Вид такой блокировки выбирается в зависимости от логики вносимых изменений, что позволяет организовать такую работу пользователей, при которой они не будут мешать друг другу при обращении к одним и тем же данным. Например, для таких операции, как UPDATE, DELETE и INSERT применяется монопольная блокировка, которая остаётся активной до конца исполнения транзакции, и не позволяет другим пользователям получать доступ к изменяемым данным. Если же пользователю необходимо только чтение данных, применяется разделяемая блокировка, действие которой до конца транзакции можно продлить с помощью ключевого слова HOLDLOCK. Не всегда процесс блокирования объектов проходит гладко. Если в двух транзакциях устанавливается блокировка на отдельные объекты, и каждая из этих транзакций пытается обратиться к объекту другой транзакции, то возникает так называемая взаимная блокировка. В таких случаях сервер баз данных просто уничтожает одну из транзакций, пользователю (её инициировавшему) выдаётся сообщение об ошибке, а предпринятые в рамках его транзакции изменения откатываются назад. У Вас есть возможность просматривать в окне Current Activity информацию видах используемых в каждом из текущих процессов блокировок, о запросах на блокировку, которые блокируются сами или блокируют другие процессы, а также обо всех случаях взаимоблокировок и тупиковых блокировках. Вы можете сортировать просматриваемую информацию по идентификаторам процессов или по объектам. Кроме этого, есть возможность просмотреть дополнительные сведения о процессе, послать сообщение пользователю, которому процесс принадлежит или принудительно завершить текущий процесс.

Мониторинг средствами Transact-SQL

Много полезной информации о работе сервера и состоянии его объектом можно получить включив в запрос специализированные хранимые процедуры, операторы, переменные или за счёт использования флагов трассировки.
Для начала, рассмотрим несколько системных хранимых процедур, с помощью которых можно изучать текущее состояние:
Sp_who – показывает текущих пользователей и процессы;
Sp_lock – показывает активные блокировки, заблокированные процессы и взаимоблокировки;
Sp_spaceused – показывает объём используемого дискового пространства таблицей или базой данных;
Sp_helpdb – показывает информацию о базах данных и их объектах;
Sp_monitor – показывает статистическую информацию о работе сервера, общее время обработки, число чтений и записи, количество подключений и т.п.;
Sp_helpindex – показывает информацию об индексах;
Sp_statistics – показывает информацию обо всех индексах выбранной таблицы.

Далее, рассмотрим некоторые глобальные переменные, позволяющие получить, как конкретные данные, так и статистику по запросам.
@@connections – счётчик подключений после последнего запуска сервера;
@@error – номер последней ошибки оператора T-SQL;
@@spid – идентификатор текущего пользовательского процесса (используется в Sp_who);
@@procid – идентификатор текущей хранимой процедуры.

Теперь, рассмотрим полезные для мониторинга операторы T-SQL.
SET STATISTICS IO – отображает информацию о величине дисковых операций, причиной которых стало исполнение оператора T-SQL;
SET STATISTICS TIME – время компиляции и выполнения операторов в миллисекундах;
SET SHOWPLAN_TEXT ON/OFF – выдаёт информацию об исполнении операторов и запрещает/разрешает серверу обрабатывать запрос.

Также, много полезного можно почерпнуть с помощью разнообразных операторов команды DBCC.
MEMUSAGE – показывает сколько в данный момент используется объектами к кэше данных и процедур;
SQLPERF – статистика сервера с момента запуска, LOGSPACE утилизация базами журналов транзакций, IOSTATS дисковые операции ввода-вывода, LRUSTATS утилизация памяти и кэшей, NETSTATS сетевые операции;
OPENTRAN – информация о самой старой активной транзакции (в т.ч. распределённые и не распределённые реплицированные транзакции) для указанной базы, если таковые существуют;
SHOW_STATISTICS – статистика использования индексов позволяющая определить необходимость их использования оптимизатором запросов;
CHECKDB – распределение и структурная целостность объектов базы данных;
CHECKFILEGROUP – распределение и структурная целостность таблиц в файлгруппе;
CHECKALLOC – распределение страниц данных и индексов для каждой таблицы, входящей в структуру экстентов базы данных;
CHECKTABLE – информация о целостности страниц данных и индексов выбранной таблицы, а также страниц типа TEXT, NTEXT и IMAGE.

И в завершение, с помощью представленных ниже флагов трассировки, можно устанавливать характеристики сервера, выявлять проблемы в его работе, отлаживать запросы и процедуры. Установить/снять флаги можно с помощью DBCC TRACEON/TRACEOFF.
302 – позволяет получить информацию об использовании страниц статистики, избирательности (если есть такая статистика), оценке возможного объёма физических и логических операций IO для индексов. Для удобочитаемости, можно использовать предложение SET SHOWPLAN ON. Для детализации фактического порядка объединения, используйте также флаг 310;
310 – позволяет получить порядок объединения;
325 – позволяет получить информацию о стоимости различных вариантов исполнения предложения ORDER BY (с не кластерным индексом или путём сортировки);
326 – позволяет получить информацию об оценочной и фактической стоимости операций сортировки;
330 – при использовании параметра SET SHOWPLAN (указывающего выдавать подробную информацию по операциям объединения), позволяет получать всю доступную информацию;
1204 – позволяет получить информацию о типе блокировки, которая стала причиной взаимоблокировки, а также текущий оператор, на исполнение которого это повлияло;
1205 – позволяет получить более подробную информацию об операторе, исполнявшемся во время возникновения взаимоблокировки;
1704 – позволяет получить информацию о создании и удалении временной таблицы;
3604 – при установке флагов только с помощью DBCC TRACEON/TRACEOFF, позволяет отправить вывод трассировки клиенту;
3605 – отправляет результаты трассировки в журнал ошибок. При запуске сервера из командной строки, вывод результатов трассировки будет осуществляется также и на экран;
8501 – записывает в журнал подробную информацию об изменениях контекста и состояния, связанных с DTC.

Мониторинг средствами SQL Server Profiler

Profiler является чрезвычайно мощным инструментом мониторинга и позволяет следить (трассировать) за операциями сервера и БД, подключениями и действиями пользователей и приложений. Для удобства анализа больших потоков информации, есть возможность использования гибких фильтров и сохранения результатов трассировки в файл или таблицу.
До определения новой трассы, необходимо чётко определиться, что конкретно Вы хотите отслеживать и в соответствии с этим настроить фильтрацию трассировки, разграничив информацию трассы по смыслу её содержимого. Иначе, Вы просто "утоните" в потоке информации Profiler. Кроме того, можно заранее определить, будут ли доступны результаты трассировки всем пользователям сервера или только владельцу трассировки. Таким образом, у Вас есть возможность отслеживать такие события, как: длительные запросы, сканирования таблиц, активность пользователей и приложений, тупиковые и обычные блокировки, удачные и неудачные входы и выходы из БД, логические чтения/запись диска, режимы использования операторами процессора, ошибки допустимых уровней, время ожидания для всех событий окончания обработки. Всю эту информацию можно получать, как в режиме реального времени, так и после предварительного сохранения в файл. С помощью сохранённых трасс, можно будет воспроизводить действия сервера, более строго отбирать нужные данные, создавать файл нагрузки для Index Tuning Wizard, пошагово проходить SQL пакеты, хранимые процедуры и вызовы Remote Procedure Call (RPC) для отладки пользовательских приложений.

Информация из чёрного ящика MS SQL Server

Как в самолёте, у SQL сервера есть "чёрный ящик" (BlackBox.trc). В этом BlackBox динамически хранится и обновляется информация о ста последних событиях сервера баз данных, которые записываются и хранятся в т.н. буфере истории запросов. Если ваш сервер сбойнёт (произойдёт исключительная ситуаций не ниже 17-го уровня), будет предпринята попытка записи содержимого буфера запросов в специальный файл трассировки BlackBox.trc, который, как и все аналогичные файлы, можно будет просмотреть в Profiler, даже если сервер на запущен или когда работоспособность сервера будет восстановлена. Хотя сбор данных для истории запросов практически не вносит дополнительной нагрузки в работу сервера, эта опция, по умолчанию, отключена. Включение/отключение её можно осуществить с помощью расширенной хранимой процедуры xp_trace_setqueryhistory, которая имеет следующий синтаксис:

EXECUTE xp_trace_setqueryhistory (0|1)

Другая расширенная процедура поможет Вам вручную записать последние 100 запросов в указанный файл. Вот её синтаксис:

EXECUTE xp_trace_flushqueryhistory ИМЯ_ФАЙЛА

Есть ещё одна специальная программа sqldiag, запуск которой при включённой истории запросов записывает буфер в файл \MSSQL7\LOG\Sqldiag.trc
Чёрный ящик будет содержать имя сервера, события (включая их классы) и сообщения об ошибках ими вызванных, текст запросов T-SQL или приложений, пользователей, SQL:BatchStarting, RPC:Starting, Exception и все поля данных программы SQL Server Profiler.
Воспользовавшись содержимым чёрного ящика, можно последовательно отследить всё, что непосредственно предшествовало сбою.

Мониторинг средствами SQL Server Query Analyzer

Query Analyzer часто используется для детального, поэтапного анализа исполнения запроса, что позволяет составить представление об эффективности его построения. Для этого, существует опция Show Estimated Execution Plan, которая позволяет без реального исполнения запроса показать подробный план его исполнения сервером. В этом плане становятся доступны для анализа эффективности такие его делали, как использование индексов, типы методов доступа (сканирование таблиц), объём работы средств ввода/вывода, временные затраты на выполнение каждого этапа запроса, а также условная стоимость каждого этапа. Кроме того, с помощью Perform Index Analysis можно сгенерировать скрипт T-SQL, который достроит необходимые для оптимальной работы Вашего запроса индексы.

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

Сопровождение баз данных и непосредственно SQL сервера требует системного подхода, который должен учитывать все особенности конкретной реализации информационной системы и её эволюцию во времени. Большинство баз данных не являются статичными, и, как это присуще OLTP системам, могут претерпевать значительные изменения в процессе их эксплуатации. Рост объёмов данных в таблицах приводит к увеличению отвлекаемых на поддержание индексов ресурсов и к существенной фрагментации данных. Это требует периодического обновления сведений об оптимизации данных и регулярной реорганизации размещения самих страниц данных. Также, возможно потребуется изменять коэффициент заполнения - fillfactor, если автоматический выбор оптимального его значения не приносит желаемого результата, или первоначальная установка требует корректировки. Кроме того, существенные размеры базы данных могут затруднить автоматическое обновление статистики распределения значения ключа индексов таблиц, используемое оптимизатором запросов, что, в свою очередь может потребовать дополнительного использования оператора UPDATE STATISTIC. Если логика работы системы требует массового удаления данных или данные удаляются достаточно часто, а также, при переносе больших кусков базы (например, относящихся к прошлым временным периодам) в другие местоположения (например, долговременный, юридический архив), в базе может образоваться не заполненное место, которое возможно усечь с помощью оператора DBCC SHRINKDATABASE. Это бывает необходимо, если не задействована опция автоматического усечения базы - autoshrink. Не мало важную роль играет также отслеживание целостности данных, в процессе которого выявляется несогласованность содержимого базы, появление которой возможно в результате аппаратных или программных сбоев, а также в следствии сетевых проблем. Для внутренней проверки целостности данных исследуют распределение страниц индексов и данных каждой таблицы, образующих целостную структуру экстентов, используя при этом оператор DBCC CHACKALLOC. Целостность объектов базы проверяют с помощью DBCC CHECKDB, а проверку целостности страниц данных (включая тип text), индексов или страниц индексов заданной таблицы, выполняют с помощью DBCC CHECKTABLE. Возможно задать автоматическое исправление обнаруженных нарушений целостности. Святой обязанностью каждого DBA является создание и поддержание в актуальном состоянии резервных копий, иначе, случаев потери данных не избежать. Резервирование журналов транзакций позволяет, сохранять внесённые в базу данных между полными копиями изменения. Стандартное руководство рекомендует также вести подробную историю администрирования СУБД, включающую информацию о всех выполненных на сервере операциях и результаты мониторинга.
Перечисленные выше задачи и направления администрирования сервера баз данных будут неукоснительно выполняться, если этот процесс автоматизировать. Для этого SQL Server имеет целый ряд удобных в применении средств. Основным таким средством является специализированный визард Database Maintenance Plan Wizard, с помощью которого можно воплотить в реальность, действующую в соответствии с заданными условиями и расписанием, автоматизированную систему администрирования/сопровождений сервера баз данных. Для работы этого визарда необходимо задать базу данных или набор баз данных, которые подлежат автоматическому сопровождению в соответствии с установленным планом. Этот план может включать элементы оптимизации данных, путём обновления статистики, реорганизации индексов, оптимизации fillfactor, сжатия данных и т.п. Кроме того, в план можно включить все виды проверки целостности данных, а также задать частоту и место создания резервных копий баз и журналов. Результаты исполнения элементов плана можно сохранять в текстовом или HTML файле, записывать в таблицу или отправлять оператору в виде сообщений электронной почты. Ещё одним средством автоматизации задач администрирования является утилита sqlmaint, которая, будучи вызванной из командной строки, позволяет выполнять операторы DBCC, сохраняет на диске данные из базы и журналы транзакций, обновлять статистику и перестраивает индексы.

Вопросы для повторения.

ВОПРОС
Пользователи жалуются, что каждый день в 14:00 производительность сервера заметно падает. Как найти причину этих неполадок?
ОТВЕТ
Сначала определите, вызваны неполадки чрезмерной нагрузкой системы в целом или только перегрузками на сервере SQL Server. Для этого с помощью программы SQL Server Performance Monitor сравните показатели использования ресурсов системы Windows NT с показателями сервера SQL Server.
Если неполадки связаны с работой сервера SQL Server, задайте трассировку в программе SQL Server Profiler и соберите сведения обо всех действиях, происходящих ежедневно около 14:00. Эта трассировка должна регистрировать события, которые могут увеличить нагрузку на сервер, например, подключения пользователей, выполнение операторов Transact-SQL и хранимых процедур, использование базы данных tempdb. Целесообразно сгруппировать эти данные по продолжительности, а также по приложениям или пользователям. Имея такие сведения, можно определить, какие события вызывают наиболее ощутимое увеличение нагрузки в системе.
ВОПРОС
Вам нужно знать, какие блокировки установлены для данной таблицы сервера SQL Server. Какими средствами следует воспользоваться?
ОТВЕТ
На уровне таблицы можно использовать программу SQL Server Profiler, системные хранимые процедуры sp_lock и sp_who, а также окно Current Activity программы SQL Server Enterprise Manager.

Шпаргалка по 70-028 | Мониторинг SQL Server 7.0 Дальше »
Скачать электронную карту Ангарска бесплатно
Сайт управляется системой uCoz