авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 18 | 19 || 21 | 22 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 20 ] --

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

С точки зрения утилиты Performance Monitor любое приложение представляет собой набор объектов (objects), работу которых можно анализировать с количест венной стороны. Небольшие приложения могут состоять всего из одного объекта, тогда как сложные системы, например Microsoft SQL Server 2000, могут включать множество объектов. Кроме того, объекты наблюдения имеет и сама операцион ная система. С их помощью можно получить различную информацию об исполь зовании как аппаратных ресурсов сервера, таких как процессор, оперативная па мять, жесткий диск и т. д., так и о применении ресурсов самой операционной системы, таких как потоки, сетевые протоколы, файл подкачки и т. д.

( Замечание } В системе может присутствовать несколько однотипных объектов. Например, на компьютере может использоваться два процессора или несколько жестких дисков. В этом случае для идентификации конкретного объекта существует понятие экземп ляр объекта (instances).., Возможность мониторинга приложения с помощью утилиты Performance Moni tor реализуется на стадии разработки этого приложения. Разработчики должны Глава 15. Мониторинг и аудит включить в код приложения механизмы, реализующие счетчики и обеспечи вающие изменение значений этих счетчиков в зависимости от тех или иных ас пектов работы приложения. Однако реализация этих механизмов не означает, что счетчики приложения могут быть сразу же использованы утилитой Perform ance Monitor. Предварительно необходимо зарегистрировать список объектов, имеющихся в приложении, а также в имеющихся в этих объектах счетчиках. Эта операция обычно выполняется при установке приложения.

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

Все сказанное выше в полной мере относится и к SQL Server 2000. При его ус тановке можно явно указать, нужно ли регистрировать счетчики производитель ности. Рекомендуется всегда регистрировать их, т. к. информация о счетчиках занимает всего 64 Кбайта, а кто знает, когда они могут понадобиться. Для реги страции счетчиков, не зарегистрированных при установке SQL Server 2000, впо следствии понадобится дистрибутив SQL Server 2000. В табл. 15.1 приведен спи сок объектов, отражающих работу SQL Server 2000.

Таблица IS. 1. Список объектов SQL Server В табл. 15.1 перечислены объекты, позволяющие контролировать работу SQL Server 2000. Большинство из них содержит множество счетчиков, с помощью которых и контролируется тот или иной аспект работы SQL Server 2000. Мы не будем описывать все счетчики, т. к. это займет очень много места. Тем не ме нее, рассмотрим работу со счетчиками объекта SQL Server: User Settable Object.

Как уже было сказано, этот объект используется для нужд пользователя. Объект SQL Server User Settable Object имеет 10 счетчиков, именуемых с User Counter до User Counter 10. С каждым из этих счетчиков связана специальная системная хранимая процедура, с помощью которой счетчику можно присвоить опреде ленное значение. Эти хранимые процедуры нумеруются с sp_user_counteri до sp_user counter10.

Указанные хранимые процедуры всего-навсего выполняют команду dipcc с не документированным параметром s e t i n s t a n c e. В этом легко убедиться, выпол нив следующий запрос:

Глава 15. Мониторинг и аудит USE master EXEC sp_helptext 'sp_user_counter7' Будет возвращен результат:

Text c r e a t e proc sp_user_counter7 @newvalue i n t as dbcc s e t i n s t a n c e ('SQLServer:User S e t t a b l e ', 'Query, 'User counter 7 ', gnewvalue) Таким образом, можно довольно просто присвоить значение нужному счетчику напрямую:

dbcc setinstance ('SQLServer:User Settable', 'Query', 'User counter T, 10) Замечание v, Отметим, что команда dbcc setinstance может быть применена для установки значений счетчиков объекта SQL Server: User Settable Object. Хотя при использова нии указанной команды для установки значений других объектов и появится сооб щение об успешном выполнении, на практике ничего изменено не будет.

Теперь же перейдем от теории к практике и рассмотрим работу непосредствен но с утилитой Performance Monitor. Эту утилиту можно запустить, выбрав в главном меню операционной системы Programs (Программы) группу Administra tive Tools, а затем соответствующую пиктограмму. Другой метод запуска предпо лагает запуск утилиты с помощью командной строки. Для этого необходимо ВЫПОЛНИТЬ команду perfmon.exe.

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

Окно утилиты Performance (рис. 15.1) разделено на две области. В левой части окна представлен список режимов, в которых работает утилита. Выбирая тот или иной элемент в левой части окна, можно переключиться на конфигуриро вание соответствующего режима работы. Конфигурирование осуществляется в правой части окна, содержимое которого зависит от элемента, выбранного в левой части.

По умолчанию работа ведется в режиме System Monitor, который позволяет контролировать показания счетчиков, добавлять новые счетчики, просматривать их в различных режимах, а также экспортировать данные. Вид окна утилиты при работе в этом режиме и приведен на рис. 15.1.

Часть III. Администрирование Рис. 1 5. 1. Утилита Performance, режим System Monitor Помимо режима System Monitor, пользователи могут использовать перечислен ные далее режимы:

• Counter Logs. Этот режим работы позволяет собирать показания определен ных счетчиков в специальный журнальный файл. При этом набор счетчиков, информация о которых сохраняется в файле, не зависит от счетчиков, ис пользуемых для режима System Monitor. Пользователь может сконфигуриро вать более одного журнального файлы. Утилита Performance будет записывать информацию в каждый из них параллельно, но друг от друга. Впоследствии сохраненная в журнальном файле информация может быть просмотрена в графическом режиме. Сохранение информации в журнальном файле являет ся незаменимым при длительном наблюдении за системой. При работе в ре жиме System Monitor представленная в окне информация охватывает сравни тельно небольшой участок времени, т. к. устаревшие сведения затирются новыми. Когда же необходимо собрать информацию о счетчиках, например, за неделю, то при использовании режима System Monitor оператор должен будет просидеть все это время у компьютера для обнаружения узких мест.

Для применения режима Counter Logs достаточно запустить утилиту Perform ance и через неделю проанализировать собранную информацию.

Глава 15. Мониторинг и аудит П Trace Logs. Данный режим напоминает предыдущий тем, что также создается журнальный файл. Но в нем сохраняется информация не о значениях счетчи ков, а данные, предоставляемые программами или операционной системой.

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

Мы не будем рассматривать использование утилиты Performance в трех послед них режимах, а ограничимся обсуждением режима System Monitor. Как видно из рис. 15.1, центральную часть правой области окна занимает поле, в котором и отображаются значения счетчиков. Непосредственно после запуска утилиты для наблюдения не определено ни одного счетчика. Поэтому никакой информации в окне отображаться не будет. Для добавления нового счетчика следует нажать в панели инструментов утилиты кнопку Add (кнопка с плюсом). В ответ откроется окно Add Counters (рис. 15.2), с помощью которого и осуществляется выбор счетчика для добавления.

Рис. 15.2. Окно Add Counters В верхней части окна расположен переключатель, с помощью которого указыва ется, будет ли осуществляться наблюдение за локальным компьютером (положе ние Use local computer counters) или за удаленным (положение Select counters from computer). В последнем случае необходимо будет в раскрывающемся спи ске, расположенном непосредственно ниже рассмотренного переключателя, вы брать имя интересующего компьютера.

В раскрывающемся списке Performance object необходимо указать объект, за счетчиками которого предполагается наблюдать. Именно в этом списке будет приведен перечень объектов, представленных в табл. 15.1. В зависимости от то го, какой объект выбран в списке, будет меняться содержимое списка в левом Часть III. Администрирование нижнем углу, где перечисляется список созданных для объекта счетчиков.

Можно добавить либо единственный счетчик (положение переключателя Select counters from list), либо сразу все доступные для объекта счетчики (положение переключателя All counters).

Помимо выбора объекта и счетчика, необходимо также задать и экземпляр объ екта, за которым будет вестись наблюдение. Выбор экземпляра осуществляется с помощью списка, расположенного в правой нижней части окна. Можно доба вить либо счетчики сразу для всех экземпляров объекта, установив переключа тель в положение All instances, либо лишь для конкретного экземпляра (положение переключателя Select instances from list).

На рис. 15.2 приведен вид окна Add Counters при выбранном объекте SQL Server:Databases. Если указать сразу все счетчики (All counters) для всех экземп ляров объекта (All instances), то будет добавлено несколько сотен счетчиков. На рис. 15.3 приведен вид окна утилиты Performance после осуществления указан ной операции.

Рис. 15.3. Объект SQL Server:Databases — все счетчики для всех экземпляров объектов Контроль за таким набором счетчиков весьма затруднен. Поэтому рекомендует ся наблюдать за количеством счетчиков, не превышающим одного-двух десят ков. Список счетчиков приводится в нижней части окна. Как видно, для каж Глава 15. Мониторинг и аудит дого указывается цвет, масштаб отображения, название счетчика, имя экземпля ра объекта, имя самого объекта и т. д. Можно просмотреть свойства любого счетчика, выбрав в его контекстном меню команду Properties.

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

Каждому счетчику соответствует отдельная кривая. При таком количестве счет чиков, какое мы добавили, трудно будет понять, что же происходит. Поэтому удалим все добавленные счетчики и добавим такое их количество, которое мож но без труда контролировать. Для удаления одного счетчика достаточно выбрать его в списке и нажать клавишу Delete. Для удаления же всех счетчиков доста точно нажать на панели инструментов кнопку New Counter Set.

После этого добавим счетчик Percent Log Used объекта SQL Server: Databases для всех экземпляров объекта. На рис. 15.4 приведен вид окна утилиты Performance при контроле значений этих счетчиков.

Рис. 15.4. Объект SQL Server:Databases — счетчик Percent Log Used для всех экземпляров объектов До сих пор мы рассматривали вывод значений счетчиков в виде кривой. Подоб ный подход позволяет анализировать изменения счетчиков с течением времени.

Однако помимо указанного режима отображения данные также можно просмат ривать в виде гистограмм. Для просмотра значений счетчиков в этом режиме Часть III. Администрирование необходимо нажать кнопку View Histogram. После этого окно утилиты примет вид, подобный приведенному на рис. 15.5.

Рис. 15.5. Объект SQL Server:Databases — режим гистограмм Рис. 15.6. Объект SQL Server-Databases — режим отчетов Глава 15. Мониторинг и аудит Помимо двух описанных режимов просмотра, также имеется возможность ото бразить значения счетчиков в текстовом виде. Для этого достаточно нажать кнопку View Report. Окно утилиты после этого будет иметь вид, подобный при веденному на рис. 15.6.

Помимо указанных возможностей просмотра, можно сохранить текущее состоя ние утилиты в качестве HTML-страницы. Для этого необходимо в центральной части окна щелкнуть правой кнопкой мыши и в контекстном меню выбрать ко манду Save As, а затем в открывшемся диалоговом окне указать каталог и имя, под которым следует сохранить файл.

Впоследствии файл может быть открыт в любое время. Более того, файл можно вы ложить на Web-сервер и просматривать его с любой точки земного шара. Откроем созданный-файл в браузере Internet Explorer. Результат приведен на рис. 15.7.

Mm* Рис. 15.7. Просмотр содержимого сгенерированной HTML-страницы Самое интересное, что при открытии страницы имеется возможность переклю чаться между режимами просмотра. Все кнопки, доступные в отображаемой на странице панели инструментов утилиты Performance, приводят к тому же ре зультату, что и при непосредственной работе с утилитой Performance. Например, на рис. 15.8 приведен вид страницы после нажатия кнопки View Histogram.

Часть III. Администрирование Рис. 15.8. Просмотр содержимого сгенерированной HTML-страницы — режим гистограмм Утилита Task Manager Рассмотренная в предыдущем разделе утилита Performance хотя и предназначена для сбора общей информации о работе SQL Server 2000, все же она в некоторых случаях является довольно избыточной. Иногда необходимо просто определить количество оперативной памяти, занимаемой SQL Server 2000. Для этого можно использовать утилиту Task Manager, которая всегда под рукой. Для ее вызова достаточно нажать комбинацию клавиш Ctrl+Shift+Esc. Сразу же после этого откроется окно утилиты, подобное приведенному на рис. 15.9.

Как видно из рисунка, окно утилиты представлено тремя вкладками. На первой из них, имеющей название Applications, приведен список приложений, запущен ных в настоящее время в операционной системе. В этот список включены не только те приложения, что отображены на панели задач (taskbar), но и которые запущены в фоновом режиме. Для каждого приложения отображается его ста тус. При нормальной работе приложение имеет статус Running. Если же прило жение "повисло" и не отвечает на запросы операционной системы, то для такого приложения указывается статус Not Responding. С помощью утилиты можно "снять" такое приложение, т. е. завершить его работу, принудительно выгрузив из памяти. Для этого достаточно нажать кнопку End Task.

Глава 15. Мониторинг и аудит Рис. 15.9. Окно утилиты Task Manager, вкладка Applications Рис. 15.10. Окно утилиты Task Manager, вкладка Processes Часть III. Администрирование Как видно, на вкладке Applications нет никакогц намека на SQL Server 2000. Это связано с тем, что SQL Server 2000 выполняете^ как часть операционной систе мы в виде службы. Тем не менее, информация о SQL Server 2000 может быть получена как о процессе операционной системы. Для этого необходимо перейти на вкладку Processes (рис. 15.10), где перечислены все процессы, запущенные в операционной системе. Список объектов на этой вкладке заметно больше, чем на вкладке Applications. Для каждого процесса указывается количество исполь зуемого процессорного времени, объем используемой оперативной памяти, идентификатор процесса и другая информация. Именно с помощью этой вклад ки можно судить о том, сколько памяти расходует SQL Server 2000, точнее службы MSSQLServer и SQLServerAgent в отдельности.

Г Замечание Служба MSSQLServer представлена процессом sqlservr.exe, а служба SQLServerAgent — sqlagent.exe. Как видно, в окне указаны два процесса sqlservr.exe. Это связано с тем, что на компьютере установлено две инсталляции.

Рис. 1 5. 1 1. Окно утилиты Task Manager, вкладка Performance Информацию об общей загрузке системы и использовании ресурсов можно по лучить с помощью вкладки Performance (рис. 15.11). На этой вкладке отобража ется информация о загрузке процессора и оперативной памяти, а также выво дится статистическая информация о созданных в операционной системе про цессах, нитях, описателях, использовании ядра и т. д.

Глава 15. Мониторинг и аудит Утилита Event Viewer Описанная в предыдущем разделе утилита Task Manager позволяет контролиро вать текущее состояние системы, точнее загрузку операционной системы. Более детальную информацию предоставляет утилита Performance, которая также по зволяет длительное время наблюдать за показаниями счетчиков, сохраняя их в файл для последующего анализа.

Однако помимо рассмотренных методов наблюдения за системой нельзя не учи тывать, что в SQL Server 2000 также могут возникать и нештатные ситуации, опре делить которые по показаниям счетчиков вряд ли удастся. Для получения инфор мации о нештатных ситуациях как в SQL Server 2000, так и в операционной системе, используется утилита Event Viewer. Она предоставляет доступ к журналам (logs) операционной системы, в которых и хранится информация о тех или иных событиях. В операционной системе имеется несколько типов журналов:

• Security Log. Используется для хранения информации, связанной с системой безопасности — регистрации пользователей в системе, выполнении ими тех или иных операций, доступу к файлам и т. д.

• System Log. В этом журнале записывается информация о работе операцион ной системы и различных ее подсистем.

• Application Log. Данный журнал используется для записи в него информации, генерируемой различными дополнительными приложениями — SQL Ser ver 2000, Exchange Server, BizTalk Server и другими.

Рис. 15.12. Окно утилиты Event Viewer Таким образом, информацию о работе SQL Server 2000 следует искать в журнале Application Log. Запуск утилиты Event Viewer можно выполнить из меню Pro Часть III. Администрирование grams (Программы) с помощью категории Administrative Tools или набрать ко манду eventvwr.exe. Окно утилиты Event Viewer в режиме просмотра журнала Application Log приведено на рис. 15.12.

В левой части окна приведен список доступных журналов, тогда как в правой части отображается перечень событий, содержащийся в выбранном журнале.

Каждое событие описывается набором атрибутов. Для получения более подроб ной информации следует дважды щелкнуть на событии. В ответ откроется окно Event Properties (рис. 15.13), в котором и будет приведена подробная информа ция о событии. Не выходя из этого окна, можно переходить к следующему или предыдущему событию.

Р и с. 1 5. 1 3. Окно свойств события Event Properties В поле Description указывается краткое описание события, по которому и можно определить источник проблемы. Помимо этого, в верхней части окна приводит ся информация о номере события, дате, компьютере, типе и т. д.

Утилита SQL Server Profiler Представленные ранее инструменты позволяют в основном контролировать лишь количественные характеристики работы SQL Server 2000 и предупреждать администратора, если система находится в критическом состоянии. Однако для детального мониторинга работы SQL Server 2000 и поиска конкретной причины неудовлетворительной работы сервера этих инструментов явно недостаточно.

Глава 15. Мониторинг и аудит С помощью утилиты Performance вы можете лишь определить подсистему, не эффективная работа которой тормозит работу всей системы. Предположим, вы выяснили, что причина периодических зависаний сервера кроется в одной из хранимых процедур. Однако с помощью рассмотренных ранее средств вы не сможете определить, какая именно процедура написана некорректно. Для про ведения качественного анализа работы запросов и хранимых процедур необхо димо использовать инструменты мониторинга, предоставляемые самим SQL Server 2000. Один из них — утилита SQL Server Profiler.

Утилита SQL Server Profiler — это графический инструмент, с помощью кото рого администратор может наблюдать за теми или иными аспектами работы SQL Server 2000. В основе работы этой утилиты лежит тот же принцип, что и в основе работы утилиты Performance. При выполнении пользовательских запро сов, хранимых процедур, команд Transact-SQL, подключении к серверу и от ключении от него, а также множестве других операций ядро SQL Server сохраняет в системных таблицах массу различной информации о ходе выполне ния операций. Эта информация может быть получена с помощью специальных хранимых процедур. Утилита SQL Server Profiler использует эти хранимые про цедуры для получения необходимой информации. Полученные данные затем представляются в удобном виде с помощью графического интерфейса. Однако пользователи способны получать информацию о процессах SQL Server 2000, об ращаясь напрямую к хранимым процедурам. В принципе, на основе этих хра нимых процедур можно даже написать свое собственное приложение, которое будет отображать информацию о работе SQL Server 2000 в нужной форме.

Основы мониторинга Мониторинг работы SQL Server 2000 основывается на наблюдении за событиями (events). Событие генерируется ядром SQL Server 2000 и является минимальным объемом работы, который можно контролировать. Каждое событие принадлежит к какому-то классу событий (event classes), который описывает его параметры и смысл той или иной информации. Для лучшего понимания разницы между со бытием и классами событий SQL Server Profiler проведем аналогию с объектами и экземплярами объектов Performance Monitor. Класс событий SQL Server Pro filer, как и объект Performance Monitor, представляет собой абстрактное описа ние. Тогда как само событие (экземпляр объекта) — информацию о работе того или иного объекта.

Количество классов событий SQL Server довольно велико. Для облегчения рабо ты с ними они были разбиты на двенадцать категорий (category). В табл. 15. приведен список категорий и их краткое описание.

Таблица 15.2. Список категорий классов событий SQL Server Имя категории Описание Sessions События, связанные с установлением и закрытием соединения клиента с сервером 738 Часть III. Администрирование Таблица 1S.2 (окончание) Описание Имя категории События, генерируемые в случае создания, открытия, закрытия и Objects удаления объектов базы данных События, связанные с просмотром объектов базы данных, таких Scans как таблицы и индексы События, связанные с выполнением команд Transact-SQL TSQL События, связанные с использованием курсоров Cursors Stored Procedures События, связанные с выполнением хранимых процедур Error and Warning События, связанные с ошибками и сообщениями SQL Server Transactions События, связанные с транзакциями, выполненными SQL Server или MSDTC, а также связанные с работой журнала транзакций Locks События, связанные с установкой блокировок в базах данных Databases События, происходящие при увеличении или уменьшении разме ра файлов данных или журнала транзакций Performance События, связанные с работой команд манипуляции данными — подготовка и компиляция плана исполнения запроса, использова ние статистики и т. д.

Server События, описывающие использование сервером оперативной памяти и запуск, останов и приостанов службы MSSQLServer Security Audit События, связанные с отслеживанием различных аспектов дейст вий пользователей User Configurable События, определенные пользователями Как было сказано ранее, информация о событиях хранится в специальных таб лицах системной базы данных Master. Каждое событие описывается отдельной строкой. Для описания событий предназначен фиксированный набор колонок данных (Data Column). Однако конкретное назначение колонок зависит от того, к какому классу принадлежит событие. Кроме того, при описании некоторых классов событий могут применяться не все колонки. В этом случае в незадейст вованной колонке хранится пустое значение (Null). Для простоты в дальнейшем будем называть колонки данных свойствами событий. В табл. 15.3 приведен полный список свойств, используемых для описания всех событий SQL Server.

Часть этих свойств используется для всех событий. Эти свойства отмечены сим волом * во второй колонке таблицы.

с Замечание По сравнению с SQL Server 7.0 количество колонок данных, имеющихся в распоря жении пользователя, заметно расширилось. Если в SQL Server 7.0 их было всего 25, то в SQL Server 2000 количество колонок возросло до 43. При этом стало гораздо удобнее анализировать информацию, т. к. теперь указываются не только идентифи Глава 15. Мониторинг и аудит кационные номера объектов, но и их имя, а также владелец и права доступа пользо вателя к этим объектам.

Таблица 15.3. Колонки данных, используемые для описания событий SQL Server Описание Свойство * Имя приложения, установившего соединение с SQL Server.

Application Указывается имя, предоставленное самим приложением, а не Nm ae физическое имя файла программы Двоичные данные. Конкретное назначение данных зависит от BinaryData класса события * Идентификационный номер процесса на клиентском компью ClientProcessID тере, в контексте которого установлено соединение Свидетельствует, были ли установлены права доступа к объек Column ту на уровне столбцов Permission * Количество процессорного времени (в миллисекундах), выде CPU ленное контролируемому событию * Идентификационный номер базы данных, с которой работал Database ID* процесс, вызвавший наступление события * Имя базы данных, с которой работал процесс, вызвавший на Database Name* ступление события * Длительность события в миллисекундах Duration* * Время, в которое было завершено событие End Time* Номер ошибки, с которой был завершен запрос Error * Класс события Event Class* Подкласс события EventSubClass Имя файла базы данных, к которому имеет отношение ото FileName бражаемая информация Специальный дескриптор, представляющий собой целое чис Handle ло. Этот описатель используется технологиями ODBC, OLE DB и DB-Library для координации действий с сервером Имя компьютера, являющегося инициатором соединения, в Host N m ae контексте которого произошло событие Идентификационный номер индекса объекта, на который по Index ID влиял процесс, вызвавший событие Целочисленные данные. Конкретное назначение данных зави Integer Data сит от класса события * Имя учетной записи, с правами которой был выполнен запрос.

LoginName Указывается либо учетная запись SQL Server, либо учетная запись Windows NT 740 Часть III. Администрирование Таблица 1S.3 (продолжение) Свойство Описание LoginSID * Имя учетной записи, с правами которой был выполнен запрос.

Указывается либо учетная запись SQL Server, либо учетная запись Windows NT Mode Целочисленное значение, описывающее свойства события NestLevel Уровень вложенности на момент выдачи информации. Соот ветствует значению, возвращаемому функцией @@NESTLEVEL NT Domain Name * Имя домена Windows NT. к которому принадлежит пользова тель, вызвавший генерацию события NT Domain Name * Имя домена Windows NT, содержащего сведения о зарегист рированном пользователе, с правами которого установлено соединение NT User Name * Имя учетной записи Windows NT пользователя, деятельность которого вызвала генерирование события Object ID Идентификационный номер объекта, присвоенный ему системой Object Name Имя объекта, о котором предоставляется информация Object Type Тип объекта, о котором предоставляется информация OwnerName Имя владельца объекта, о котором предоставляется информация Permissions Целочисленное значение, описывающее права доступа поль зователя к объекту:

1 — выборка всех столбцов (SELECT A L L ) 2 — обновление всех столбцов (UPDATE A L L ) 4 — ссылаться на любой столбец (REFERENCES A L L ) 8 —добавлять новые строки ( I N S E R T ) 16 — удалять строки (DELETE) 32 — выполнять хранимую процедуру (EXECUTE) 4096 — выбирать хотя бы из одного столбца (SELECT ANY) 8192 — изменять хотя бы один столбец (UPDATE ANY) 16384 — ссылаться хотя бы на один столбец (REFERENCES ANY) Reads Количество операций логического чтения, осуществленных за время выполнения события RoleName Имя роли активного приложения, в контексте которого выпол нялся запрос Server Name * Имя сервера SQL Server, который подвергается мониторингу Severity. Уровень серьезности ошибки Глава 15. Мониторинг и аудит Таблица 15.3 (окончание) Описание Свойство * Идентификационный номер процесса сервера (SPID), ассо SPID циированный сервером с клиентским соединением, вызвав шим возникновение события * Имя пользователя базы данных, под которым работает клиент SQL User Name ское соединение * Время, в которое зафиксировано наступление события Start Time Код состояния ошибки State Значение 1 свидетельствует об успешности выполнения опе Success рации, тогда как значение 0 — о неудаче Имя учетной записи, над которой была произведена какая TargetLoginName либо операция (например, создание) Идентификатор безопасности учетной записи, над которой TargetLoginsID была произведена какая-либо операция (например, создание) Имя пользователя базы данных, над которым была произведе TargetUserName на какая-либо операция (например, создание) Символьные данные. Конкретное назначение данных зависит TextData от класса события Идентификационный номер транзакции, присвоенный ей сис Transaction ID темой Количество физических операций записи на диск, произве Writes денных за время выполнения события Некоторые типы событий могут генерировать огромное количество информа ции. Кроме того, при активной работе пользователей с сервером объем инфор мации увеличивается прямо пропорционально росту запросов пользователей.

Анализ большого объема информации, в свою очередь, требует значительных системных ресурсов. Это ведет к тому, что анализ становится весьма затрудни тельным. Выходом из подобной ситуации является применение фильтров (filters). С помощью фильтров на события можно наложить условия, лишь при соблюдении которых информация о событии будет использована для анализа.

Если же условие не выполняется, то информация теряется и не анализируется.

Для объектов SQL Server 2000 поддерживается несколько типов фильтров:

• Фильтр Like. Выполняет сравнение значения по указанному шаблону. Если значение колонки совпадает с указанным шаблоном, то соответствующая информация включается в отчет Profiler.

С? Фильтр Not Like. Этот фильтр также выполняет сравнение значения по ука занному шаблону, однако информация включается в отчет только в случае несовпадения значения колонки с указанным шаблоном.

П Фильтр Equals. Информация включается только в случае полного совпадения.

742 Часть III. Администрирование ^ D Фильтр Not Equal to. Информация включается только в случае несовпадения.

• Фильтр Greater that or equal. Если значение колонки выше или равно ука занному значению, то информация будет включена в отчет.

П Фильтр Less that or equal. Если значение колонки меньше или равно указан ному значению, то информация будет включена в отчет.

( Замечание ^ Наглядным примером использования фильтров Like/Not Like является ограничение списка контролируемых приложений при выполнении мониторинга с помощью ути литы SQL Server Profiler. Если не применять фильтрацию, то утилита SQL Server Profiler будет отображать информацию об использовании ресурсов сервера, кото рые необходимы ей для проведения мониторинга. Однако эта информация только мешала бы осуществлять анализ. По умолчанию события, генерируемые утилитой SQL Server Profiler, в мониторинг не включаются.

При использовании фильтра во время работы с утилитой SQL Server Profiler тип фильтра, устанавливаемый для того или иного свойства, контролируется автома тически. Более подробно работа с утилитой SQL Server Profiler, в том числе и ус тановка фильтров, будет рассмотрена в одном из следующих разделов этой главы.

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

В каждом из разделов будет приведена таблица, в которой перечислены все классы событий, принадлежащие категории. В первой колонке указывается имя события, а во второй — его описание. В третьей же колонке представлены свой ства, назначение которых зависит от конкретного класса события. К таким СВОЙСТВам, В Первую Очередь, ОТНОСЯТСЯ СВОЙСТВа BinaryData, I n t e g e r Data И Text Data, а также некоторые другие.

Категория Sessions Категория Sessions позволяет контролировать установление и разрыв соедине ний клиентов с сервером. С помощью событий этой категории администратор может получить информацию о том, кто, когда и с какого компьютера подклю чался к серверу, а также о том, сколько времени он проработал и когда отклю чился от сервера. Данная информация может быть использована как дополне ние к системе безопасности SQL Server 2000. В случае повреждения данных или их несанкционированного копирования вы можете определить, какой именно пользователь выполнил операцию. В табл. 15.4 приведен список классов собы тий категории Sessions.

Таблица 1S.4. Классы событий категории Sessions Имя класса Описание Свойства Connect Подключение, еде- BinaryData — значения свойств соединения, ланное после начала устанавливаемые командой SET. Каждый бит мониторинга соответствует определенной опции Замечание Помимо свойств, приведенных в третьей колонке, для объектов категории Sessions поддерживаются все общие свойства, которые могут использоваться для контроля различных аспектов работы пользователей.

Категория Objects События этой категории позволяют контролировать различные операции, произ водимые в базе данных и над ее объектами. Администратор может контролировать создание, открытие, закрытие и удаление любых объектов базы данных, таких как таблицы, индексы, хранимые процедуры и т. д., а также добавление, удаление и выборку данных с помощью команд Transact-SQL SELECT, INSERT И DELETE.

Подобный контроль может быть применен для получения статистической инфор мации об активности использования тех или иных объектов базы данных. Кроме того, события категории Objects могут служить для выполнения аудита деятельно сти Пользователей. С П М Щ Ю С О С В NT User Name, SQL User Name И Host Name ОО Ь ВЙТ можно весьма успешно контролировать действия пользователей.

В табл. 15.5 приведен список событий категории Objects с их кратким описани ем и указанием свойств, специфичных для конкретного события.

Таблица 15.5. Классы событий категории Objects Категория Scans При выполнении запросов ядро SQL Server выполняет сканирование таблиц и индексов с целью выборки данных, которые соответствуют критериям запроса.

Сам по себе процесс сканирования не влечет изменения или чтения данных.

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

Сканирование таблиц и индексов может осуществляться различными способа ми, т. е. в разных режимах. Режим сканирования указывается в свойстве EventSubClass. В табл-. 15.6 приведены различные режимы сканирования с их кратким описанием:.

Таблица 15.6. Режимы сканирования для объектов категории Scans Значение Описание Значение Описание Нормальное (Normal) Зарезервировано (Reserved) 1 Быстрое (First) Блокирующее (Exlatch) 2 Обратное (Back) Для поддержки индексов 4 (Index supplied) Неупорядоченное (Unordered) 8 Нет данных (No data) Маркирующее (Marker) 16 с Замечание Номера режимов сканирования, приведенные в табл. 15.6, представляют собой би товые маски. Номер каждого из режимов соответствует одному биту байта. Режим сканирования может определяться единственным битом или их комбинацией. В по следнем случае необходимо сложить номера режимов, которые используются при Глава 15. Мониторинг и аудит сканировании. Например, если сканирование выполняется с помощью быстрого, не упорядоченного и маркирующего режимов, то итоговый режим будет равен (2+8+256).

В табл. 15.7 приведен список классов событий категории Scans с их кратким описанием и указанием назначения специфичных свойств.

Таблица 15.7. Классы событий категории Scans Категория TSQL В эту категорию включены события, используемые для мониторинга вызова удаленных процедур (RPC), пакетов и команд Transact-SQL. События категории TSQL часто служат для анализа производительности выполнения запросов. С П М Щ Ю СВОЙСТВ S t a r t Time, End Time И D u r a t i o n М Ж О определить, Как ООЬ ОН долго выполняется запрос. Внося коррективы в код запроса, можно найти наи лучшее решение. С П М Щ Ю С О С В NT User Name и SQL User Name М Ж О ООЬ ВЙТ ОН контролировать пользователей, которые осуществляют запросы. Список классов событий, включенных в категорию TSQL, приведен в табл. 15.8.

Таблица 15.8. Классы событий категории TSQL 746 Часть ///, Администрирование Таблица 15.8 (окончание) Имя класса Описание Свойства Завершение команды I n t e g e r Data — количество строк, SQLStmtCompleted Transact-SQL обработанных командой TextData — текст команды, кото рая была выполнена Категория Cursors События этой категории позволяют наблюдать за операциями, выполняемыми над курсорами: создание, открытие, закрытие, удаление, преобразование и т. д.

В SQL Server 2000 поддерживается несколько типов курсоров. Их перечень с кратким описанием приведен в табл. 15. Таблица 1S.9. Типы курсоров SQL Server Значение Описание Название 1 Keyset (ключевой) Строки, включенные в курсор, отмечаются с по мощью ключей (индекса) 2 Dynamic Каждый раз при выборке строк курсор обращается к исходным данным и перечитывает их. Это позво (динамический) ляет отображать в курсоре все изменения, сделан ные в таблице после открытия курсора 4 Forward only При работе с этим типом курсоров разрешается только последовательная выборка. Нельзя выбрать (однонаправленный) предыдущие строки 8 Static (статический) Курсор этого типа представляет собой копию дан ных таблицы. В отличие от динамического курсора, статический курсор не отображает изменения, сделанные в таблице после открытия курсора 16 Fast Forward Курсор, оптимизированный для быстрого последо (быстрый вательного просмотра. Обладает той же функцио однонаправленный) нальностью, что и обычный однонаправленный курсор (Forward-only), но отличается более высо кой производительностью работы Список классов событий, включенных в категорию Cursors, приведен в табл. 15.10.

Таблица 15.10. Классы событий категории Cursors Описание Имя класса Свойства CursorPrepare Подготовка курсора к ис- EventSubClass —дескриптор пользованию (создание) подготавливаемого курсора Глава 15. Мониторинг и аудит Таблица 15.10 (окончание) Категория Stored Procedures События категории Stored Procedures позволяют контролировать различные аспекты выполнения хранимых процедур. С помощью событий SP.CacheHit и SP:CacheMiss можно получить информацию, как часто хранимая процедура выполняется из кэша.

Если событие SP:CacheMiss происходит слишком часто, то необходимо увеличить объем оперативной памяти, доступной SQL Server 2000. Это позволит увеличить объем кэш-памяти, доступной для хранимых процедур SQL Server 2000.

Выполняя мониторинг события SP:CacheHit с указанием идентификатора хра нимой процедуры (фильтр для свойства object I D ) МОЖНО определить, как час то конкретная хранимая процедура выполняется из кэша.

В табл. 15.11 приведен список событий категории Stored Procedures с кратким описанием и списком специфичных свойств.

Таблица 15.11. Классы событий категории Stored Procedures Категория Error and Warning Категория Error and Warning содержит классы событий, с помощью которых мож но контролировать возникновение ошибок и предупреждений, генерируемых ядром SQL Server 2000 и его компонентами (например, OLE DB). Кроме того, события этой категории могут быть использованы для анализа хода выполнения запросов с целью их оптимизации. Например, событие Missing Column Statistics возникает в том случае, если колонка, участвующая в запросе, имеет поврежден ную статистику. Использование статистики позволяет построить более эффектив Глава 15. Мониторинг и аудит ный план выполнения запроса и, как следствие, добиться более высокой произво дительности. Если статистика отсутствует или повреждена^ то оптимизатор запро сов построит неоптимальный план выполнения запроса, что отрицательно скажет ся на производительности выполнения этого запроса.

С помощью событий Execution Warning можно получить информацию о том, как долго система ожидала освобождения ресурсов, прежде чем начать выпол нение запроса. Слишком долгое ожидание ресурсов свидетельствует о том, что обрабатываются неоптимизированные запросы. Для более детального анализа блокировок следует использовать события категории Locks.

В табл. 15.12 приведен список событий категории Error and Warnings с кратким описанием и списком специфичных свойств.

Таблица 15.12. Классы событий категории Error and Warning Категория Transactions Как следует из названия, события этой категории используются для наблюдения за ходом выполнения транзакций. Можно контролировать как обычные, ло кальные, так и распределенные транзакции, выполняемые координатором рас пределенных транзакций (MSDTC, Microsoft Distributed Transactional Coordinator).

События категории Transactions позволяют контролировать начало, откат, фик сирование и создание точки сохранения (Save point) транзакции.

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

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

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

В табл. 15.13 приведен список событий категории Transactions с описанием спе цифичных свойств.

Таблица 15.13. Классы событий категории Transactions Глава 15. Мониторинг и аудит Категория Locks С помощью событий категории Locks можно контролировать работу системы бло кирования SQL Server 2000. То есть можно получить информацию обо всех бло кировках, выполняемых на сервере. Например, с помощью событий Lock:Acquired и Lock: Released можно определить, как долго выполнялась блокировка, и какой тип она имела. Слишком долго удерживаемые блокировки должны быть изучены более детально, т. к. они могут существенно снизить производительность системы и даже привести к возникновению мертвых блокировок (deadlock).

с Замечание В SQL Server 2000 существуют специальные механизмы решения конфликтов мерт вых блокировок. Сервер периодически проверяет, какие блокировки установлены в системе. Если какая-то блокировка удерживается слишком долго, то сервер запус кает процесс отслеживания мертвых блокировок. Если обнаруживается, что дли тельное удержание блокировки вызвано образованием мертвой блокировки, то сер вер автоматически решает конфликт. При этом одна из блокировок, образующих мертвую, принудительно снимается, и установившая ее транзакция откатывается.

После этого соединение, инициировавшее отмененную блокировку, получает сооб щение об ошибке 1205.

Для наблюдения за мертвыми блокировками можно применять события Lock:Deadlock, Lock:Deadlock Chain и Lock:Timeout. С их помощью можно по лучить информацию о том, когда произошла мертвая блокировка, как долго она удерживалась, и какие объекты были блокированы. Эта информация может быть использована для поиска причин возникновения подобных блокировок и поиска объектов, на которые налагается мертвая блокировка. Проанализировав полученную информацию можно переписать некоторые участки приложения с целью уменьшения вероятности возникновения мертвых блокировок.

В табл. 15.14 приведен список событий категории Locks с кратким описанием и указанием специфичных свойств.

Таблица 15.14. Классы событий категории Locks 25 Л Категория Databases В категорию Databases включены события, связанные с увеличением и умень шением размера файлов базы данных. При этом отдельно рассматриваются файлы данных и файлы журнала транзакций. В табл. 15.15 приведен список со бытий категории Databases.

Таблица 15.15. Классы событий категории Databases Глава 15. Мониторинг и аудит Таблица 15.15 (окончание) Категория Performance События этой категории позволяют наблюдать за выполнением команд языка ма нипуляции данных (DML, Data Manipulation Language). К этим командам отно сятся КОМаНДЫ INSERT, UPDATE, SELECT И DELETE, С ПОМОЩЬЮ КОТОРЫХ, СООТВеТСТ венно, выполняется добавление, обновление, выбор и удаление данных. В частности, события рассматриваемой категории (табл. 15.16) позволяют просмот реть план исполнения запроса после обработки его оптимизатором запросов.

Таблица 15.16. Классы событий категории Performance 25* Категория Server В этой категории содержится всего два события, которые позволяют наблюдать за использованием сервером оперативной памяти и основными моментами ра боты службы MSSQLServer. В табл. 15.17 приведены названия событий с указа нием специфичных свойств.

Таблица 15.17. Классы событий категории Server Категория Security Audit Это самая большая категория событий. В предыдущих версиях SQL Server ничего подобного не было. События категории Security Audit позволяют отслеживать дей ствия пользователей, которые они выполняют в системе. При работе с SQL Server 7.0 администратор мог отслеживать только попытки регистрации пользова телей. В SQL Server 2000 возможности наблюдения за пользователями существен но расширены. Подробное описание всех свойств событий категории Security Audit займет довольно много места. Поэтому мы не будем приводить при описа нии событий свойства, значения которых и без того понятны. Например, многие Глава 15. Мониторинг и аудит события имеют свойства LoginsiD и LoginName, которые отображают идентифи катор безопасности и имя учетной записи, в контексте которых произошло заре гистрированное событие. Назначение указанных и других подобных свойств (Database Name, Database ID, RoleName, SQL User Name, Permissions, OwnerName, Object Name, Object ID, Column Permissions И Т. Д.) были приведены В табл. 15.3.

Специфичные же для событий категории свойства (такие как Event c l a s s, Eventsubciass и т. д.) будут рассмотрены в табл. 15.18, где и приведен список событий. Отметим, что свойство Event c l a s s определяет код события. Это свойство имеет одинаковое назначение для всех событий категории. Поэтому для каждого из них мы будем только указывать значение свойства, идентифици рующее данное свойство. Если аудит сохраняется в таблице, то по свойству Event c l a s s впоследствии можно будет легко идентифицировать события.

Таблица 15.18. Классы событий категории Security Audit 756 Часть III. Администрирование Таблица 15.18 (продолжение) Имя класса Описание Свойства Event Class = Audit Object Регистрирует выполнение команд GDR управления GDR Event EventSubClass — класс события:

правами доступа пользова телей к объектам 1 — разрешение (GRANT) 2 — отклонение (REVOKE) 3 — запрещение (DENY) P e r m i s s i o n s — права доступа:

1 — SELECT ALL 2 — UPDATE ALL 4 —REFERENCES ALL 8— INSERT 1 6 - DELETE 32 —EXECUTE 4096 — SELECT ANY 8192-UPDATE ANY 16384 —REFERENCES ANY, а также L o g i n s ID, LoginName, Database ID, Database Name,SQL User Name, OwnerName, Object Name, Column Permission и TextData Audit Addlogin Регистрирует добавление и Event Class = Event удаление учетных записей E v e n t S u b C l a s s — класс события:

SQL Server (процедуры sp addlogin и 1 — добавление (Add) sp droplogin) 2 — удаление (Drop), а также LoginSID, LoginName, TargetLoginSID,TargetLoginName и TextData Audit Login Регистрирует выполнение Event Class = GDR Event команд GDR для предостав EventSubClass — класс события:

ления, отклонения и запре щения доступа к серверу 1 — разрешение (GRANT) учетных записей Windows NT (процедуры 2 — отклонение (REVOKE) sp grantlogin, 3 — запрещение (DENY), sp revokelogin и sp denylogin) а также LoginSID, LoginName, TargetLoginSID, TargetLoginName И TextData Глава 15. Мониторинг и аудит Таблица 15.18 (продолжение) Таблица 15.18 (продолжение Описание Свойства Имя класса а также LoginSID, LoginName, Database ID, Database Name, SQL User Name, Target User Name и RoleName Event Class = Регистрирует создание и Audit Add Role удаление в базе данных Event Event Sub Class — класс события:

пользовательских ролей (процедуры sp add r o l e и 1 — добавление (Add) sp droprole) 2 — удаление (Drop), а также LoginSID, LoginName, Database ID,Database Name, SQL User Name и RoleName Фиксирует факт изменения Event Class = Audit App Role пароля для роли приложения Change Pass Event Sub Class всегда равно 1, word Event а также LoginSID, LoginName, Database ID,Database Name, SQL User Name И RoleName Регистрирует выполнение Event Class = Audit State команд с учетом предостав ment Permis EventSubClass всегда равно ленных прав sion Event Permissions — права доступа:

1 — CREATE DATABASE 2 — CREATE TABLE 4 —CREATE PROCEDURE 8 — CREATE VIEW 16 —CREATE RULE 32 — CREATE DE FAULT 6 4 - B A C K U P DATABASE 128 —BACKUP LOG 512 —CREATE FUNCTION, а также L o g i n S I D, LoginName, D a t a b a s e I D, D a t a b a s e Name, SQL User Ыате и TextData Фиксирует доступ к объекту Audit Object Event Class = с учетом предоставленных Permission EventSubClass всегда равно прав Event Permissions — права доступа:


1 — SELECT ALL Глава 15. Мониторинг и аудит Таблица 15.18 (продолжение) Свойства Имя класса Описание 2 — UPDATE ALL 4-REFERENCES ALL 8 — INSERT 16 — DELETE 32 — EXECUTE, а также LoginSID, LoginNarae, D a t a b a s e ID, Database Name, SQL User Name, OwnerName, Object Name, Column P e r m i s s i o n и TextData Audit Фиксирует выполнение ко- Event C l a s s = Backup/Restore манд работы с резервными Event Sub C l a s s — класс события:

Event копиями (BACKUP И RESTORE) 1 — архивирование (Backup) 2 — восстановление (Restore), а также LoginSID, LoginName, Database ID, Database Name, SQL User Name и TextData Audit DBCC Фиксирует факт выполнения Event Class = Event команд проверки целостно EventSubClass всегда равно 1, сти базы данных DBCC а также LoginSID, LoginName, Database ID, Database Name, SQL User Name и RoleName Audit Change Фиксирует изменения пара- Event C l a s s = 1 1 Audit Event метров аудита E v e n t S u b C l a s s — класс события:

1 — начат новый аудит 2 — останов аудита, а также LoginSID, LoginName и TextData Audit Фиксирует факты останова, Event Class = Server/Stop/Pa запуска и приостанова Event Sub C l a s s — класс события:

use Event служб 1 — останов (Shutdown) 2 — запуск (Start) 3 — приостанов (Pause) 4 — продолжение (Continue), а также LoginSID и LoginName 760 Часть III. Администрирование Категория User Configurable В этой категории отображаются события, определяемые пользователями. Такие события предназначены для генерации событий на уровне приложений и при меняются для мониторинга работы приложений. Категория содержит 10 собы тий, нумерующихся с UserConfigurable:0 и до UserConfigurable:9. Пользователь ские события должны генерироваться принудительно путем выполнения специальной хранимой процедуры.

Этой процедурой является специальная системная хранимая процедура sp_trace_generateevent, имеющая следующий синтаксис:

sp_trace_generateevent [ @eventid = ] event_id [, [ @userinfo = ] 'user_info' ] [, [ Ouserdata = ] user_data ] При работе с предыдущими версиями вместо хранимой процедуры sp_trace_generateevent использовалась системная хранимая процедура xp_trace_generate_event, которая имела более сложный синтаксис.

Рассмотрим назначение параметров этой хранимой процедуры:

О [ Oeventid = ] event_id Параметр имеет тип данных i n t и представляет идентификационный номер события, которое предполагается сгенерировать. Пользовательским событиям соответствуют номера 82—91, которые соответственно связаны с событиями UserConfigurable:0—UserConfigurable:9. Попытка указать иной идентификаци онный номер приведет к ошибке.

d I Ouserinfo = ] 'user_info' Данный параметр, имеющий тип данных nvarchar (128), используется для указания символьной строки, которая в обычном случае представляет текст сообщения. Значение, указанное с помощью этого параметра, отображается в колонке трассировки TextData. Если параметр опускается, то колонка TextData будет иметь значение NULL.

( Замечание } Необходимо отметить, что параметр g u s e r i n f o требует указания строки в стан дарте Unicode. Поэтому перед строкой следует указать символ N. Например, Suserinfo = N'No more data for t r a n s l a t e '.

П t Suserdata = ] user_data Параметр предназначен для отображения в трассировке любых данных и имеет тип данных varbinary(8000), т. е. данные должны сохраняться в дво ичном виде. Указанное посредством рассматриваемого параметра значение отображается в колонке трассировки BinaryData.

Глава 15. Мониторинг и аудит Замечание Двоичные данные должны указываться в шестнадцатеричном виде. Запись числа в этой форме требует указания символов Ох непосредственно перед самим числом.

Например, чтобы отобразить в колонке BinaryData шестнадцатеричное значение 17FA, необходимо указать Suserdata = 0xl7FA.

В качестве примера рассмотрим генерирование пользовательского события Us erConfigUrable:5. В КОЛОНКе TextData укажем значение 'Фатальный катак лизм! ! ! ', тогда как В столбце BinaryData — значение 0x28305FC3B:

E E sp_trace_generateevent XC Seventid = 87, @userinfo = Ы'Фатальный катаклизм! ! ! ', Suserdata = 0x28305FC3B Помимо колонок TextData и BinaryData для пользовательских событий предна значены следующие колонки, значения которым присваиваются автоматически:

П Application Name;

О LoginSID;

• Database ID;

O NT Domain Name;

О Host Name;

О NT User Name;

П LoginName;

О Server Name.

Осуществление мониторинга В предыдущих разделах были подробно рассмотрены события и объекты SQL Server 2000, которые можно подвергнуть мониторингу с помощью утилиты SQL Server Profiler. В этом разделе будут рассмотрены практические стороны мони торинга — выбор объектов мониторинга, установка фильтров, сохранение и анализ полученных данных и т. д.

( Замечание ^ Для запуска SQL Profiler можно использовать различные пути, например, выбрав со ответствующий значок в меню Programs (Программы) в категории Microsoft SQL Server или выбрав команду SQL Server Profiler в меню Tools утилиты Enterprise Manager. Кроме того, утилиту Profiler можно запустить из командной строки, набрав команду s q l t r a c e. e x e.

Первое, что необходимо сделать при мониторинге — это выбрать события для анализа. Список событий, подвергающийся мониторингу в одно и то же время, называется профилем трассировки (trace profile). Утилита SQL Server Profiler ра ботает с профилями трассировки, а не с определенными событиями. Кроме то го, профиль трассировки можно сохранить как файл и затем использовать сно ва. В профиле трассировки указываются не только сами события, подвер гающиеся мониторингу, но также и фильтры, примененные к этим событиям, и свойства событий, которые необходимо отображать.

Часть III. Администрирование с Замечание Утилита SQL Server Profiler позволяет использовать созданный ранее профиль. Од нако не стоит путать описание параметров мониторинга — профиля (Trace Definition) с данными, полученными в результате мониторинга — файлом (Trace File) или таб лицей (Trace Table).

Прежде чем приступить к созданию мониторинга, необходимо сначала запус тить утилиту SQL Server Profiler. Непосредственно после запуска окно утилиты пусто (рис. 15.14). До тех пор, пока не будет определен хотя бы один профиль трассировки, утилита не станет отслеживать никаких событий. Надо заметить, что утилита Profiler может одновременно работать с множеством профилей, от слеживая события параллельно.

Рис. 15.14. Пустое окно утилиты SQL Server Profiler Для создания нового профиля необходимо в меню File выбрать команду New, a затем команду Trace или нажать комбинацию клавиш Ctrl+N. В ответ от кроется диалоговое окно Connect to SQL Server (рис. 15.15), где следует выбрать подлежащий трассировке сервер и учетную запись, с правами которой будет установлено соединение с выбранным сервером.

Рис. 15.15. Окно Connect to SQL Server Глава 15. Мониторинг и аудит После того, как работа с окном Connect to SQL Server будет завершена, откро ется окно Trace Properties (рис. 15.16), с помощью которого и определяется профиль. Как видно из рисунка, это окно имеет четыре вкладки.

Рис. 15.16. Окно Trace Properties, вкладка General На вкладке General имеется ряд элементов управления, с помощью которых за даются общие свойства профиля:

О Trace name — имя профиля трассировки.

О Trace SQL Server — имя сервера, события которого будут отслеживаться.

• Template name. В этом раскрывающемся списке можно указать один из имеющихся шаблонов. Шаблон представляет собой описание событий и их свойств, которые будут включены в профиль, а также фильтры. Выбор шаб лона изменяет значения, заданные на трех остальных вкладках окна Trace Properties. Однако после выбора шаблона можно внести любые изменения в создаваемый профиль трассировки. Использование шаблонов призвано облег чить создание профиля, ориентированного на отслеживание специфических событий — выполнение хранимых процедур, команд Transact-SQL и т. д.

Пользователь может организовывать свои собственные шаблоны.

764 Часть III. Администрирование О Template file name. Данное текстовое поле содержит путь и имя файла, в ко тором сохранен шаблон, выбранный в раскрывающемся списке Template name. Утилита SQL Server Profiler поставляется с набором стандартных шаб лонов, которые располагаются в каталоге \Program Files\Microsoft SQL Server\80\Tools\Templates\SQL Profiler. Можно располагать свои собственные шаблоны либо в этом же каталоге, либо в любом другом. Однако в послед нем случае необходимо будет явно указать каталог и имя файла, из которого следует получить шаблон. Это можно сделать с помощью кнопки, располо женной справа от рассматриваемого поля. Все имеющиеся в выбранном ка талоге шаблоны будут перечислены в списке Template name.

• Save to file. Установка этого флажка предписывает сохранять собранную ин формацию в файл. Впоследствии можно будет в любой момент просмотреть все события, произошедшие за все время сбора данных. Нажав кнопку в пра вой части окна, необходимо будет указать имя файла, в котором станет со храняться информация. При установке рассматриваемого флажка также ста новятся доступными несколько дополнительных флажков:

• Set maximum file size (MB) — если необходимо ограничить объем инфор мации, сохраняемой в файле, то следует установить данный флажок. При этом в поле нужно будет указать максимальный размер файла в мегабай тах;

• Enable file rollover — этот флажок используется совместно с предыдущим, и его установка предписывает создать новый файл, как только размер те кущего файла достигнет указанного ограничения. Новому файлу присваи вается то же имя, что было указано в поле слева от флажка Save to file, но к нему добавляется порядковый номер файла. Например, если для сохра нения информации был указан файл SampleTrace.trc, то при достижении указанного размера будет создан новый файл SampleTrace_l.trc, затем SampleTrace_2.trc и т. д.


Server processes SQL Server trace data — когда этот флажок установлен, »

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

(U Save to table. При установке этого флажка данные о трассировке будут со храняться в специальной таблице. Для выбора таблицы достаточно нажать кнопку в правой части окна. Можно сохранять информацию как в таблице локального сервера, так и удаленного. Можно указать имя таблицы, которой еще не существует. В этом случае она будет автоматически создана после на жатия кнопки Run. Ее структура будет полностью соответствовать парамет рам созданной трассировки. При установке флажка Save to table становится доступным1 флажок Set maximum rows (in thousands), выбирая который, мож Глава 15. Мониторинг и аудит но ограничить количество строк, записывающихся в указанной таблице. УсГ таревшие строки будут удаляться, и вместо них будет записываться новая информация. Максимальное количество строк в тысячах устанавливается в поле, расположенном в правой части окна.

• Enable trace stop time. Устанавливая этот флажок, можно указать момент вре мени, до которого будет осуществляться трассировка. Эта возможность быва ет полезна, когда необходимо завершить сбор информации, например, через несколько часов, а возможности находиться за сервером в это время нет.

На этом работа с вкладкой General заканчивается. Следующая вкладка Events (рис. 15.17) используется для выбора классов событий, которые необходимо контролировать.

Рис. 15.17. Окно Trace Properties, вкладка Events Окно разделено на два списка. В левом из них (Available event classes) приведен список категорий со всеми входящими в них классами событий. В правом спи ске (Selected event classes) приведены события, выбранные для мониторинга.

События в правом списке также группируются по категориям. Для включения или исключение события из мониторинга служат кнопки Add и Remove. В ниж Часть III. Администрирование ней части окна отображается краткая информация о назначении выбранного события.

После того, как все события, которые предполагается контролировать, перене сены в список Selected event classes, можно переходить к следующей вкладке.

Вкладка Data Columns (рис. 15.18) предназначена для управления списком свойств, которые будут отображаться при мониторинге.

Рис. 15.18. Окно Trace Properties, вкладка Data Columns Работа с вкладкой Data Columns аналогична работе с вкладкой Events. Список Unselected data содержит перечень всех доступных свойств. Набор свойств, кото рые будут отображаться пользователю, приводится в списке Selected data. С по мощью кнопок Up и Down можно контролировать порядок отображения колонок.

Последнее, что остается после выбора колонок, которые станут отображаться при мониторинге — это установка фильтров на контролируемые события. Одна ко эта операция не обязательна и с успехом может быть пропущена. К тому же, если требуется установка фильтра, то необходимо воспользоваться вкладкой Filters (рис. 15.19).

На вкладке Fitters приведен список свойств событий, выбранных для мониторин га. В зависимости от того, какой тип свойства задан, надо использовать один из Глава 15. Мониторинг и аудит трех типов доступных фильтров. Типы фильтров и их использование были под робно рассмотрены в разд. "Утилита SQL Server Profiler" этой главы.

Рис. 15.19. Окно Trace Properties, вкладка Filters На этом процесс создания профиля трассировки заканчивается. После нажатия кнопки ОК профиль будет сохранен, и утилита SQL Server Profiler сразу же при ступит к контролю событий.

Анализ полученной информации После того, как профиль будет создан, утилита SQL Server Profiler приступает к мониторингу сервера. Как уже было сказано, с помощью данной утилиты мож но одновременно работать более чем с одним профилем трассировки и собирать различные данные. Рабочее окно утилиты разделено на две части (рис. 15.20).

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

Каждое событие отображается в виде отдельной строки. Слева у строки имеется знак j j j, который позволяет раскрыть строку для вывода детальной информа ции. Кроме того, детальная информация может быть отображена в нижней час Часть III. Администрирование ти окна при установке указателя в верхней части на нужную строку. Это при мерно та же информация, что выводится после раскрытия строки с помощью знака Д. Однако ее просмотр в нижней области позволяет вывести в верхней части большее количество событий. По мере того, как происходят новые собы тия, они добавляются в верхний список утилиты SQL Server Profiler.

Рис. 15.20. Утилита SQL Server Profiler Помимо описанного режима просмотра событий, утилита SQL Server Profiler может отображать информацию, сохраненную в файл или в таблицу. Это позво ляет анализировать работу сервера, не имитируя каждый раз одну и ту же ситуа цию. Достаточно один раз привести систему в нужное состояние и сохранить все события в файл или таблицу. После этого можно многократно анализиро вать сведения. Кроме того, если вы не сильны в анализе работы сервера, полу ченный файл может быть отправлен эксперту.

Кроме того, что вы можете просматривать полученную из файла или таблицы информацию о ходе возникновения различных событий, вы также можете вы полнить операции, которые вызвали генерацию событий. Для воспроизведения (replay) событий служит меню Replay. Однако элементы в этом меню доступны только в том случае, если информация о событиях загружена из файла или таб лицы. Если список событий получен из профиля трассировки, то воспроизведе ние событий будет невозможно. Однако последовательность событий может Глава 15. Мониторинг и аудит быть сохранена в файл или таблицу и уже оттуда воспроизведена. Для сохране ния информации из профиля в файл или таблицу необходимо воспользоваться в меню file командой Save as.

Для начала воспроизведения событий следует выбрать в меню Replay либо пункт Start, либо пункт Step. В ответ откроется окно Connect to SQL Server (см.

рис. 15.15), где нужно будет выбрать сервер, который должен аутентифициро вать пользователя. Это может быть не тот сервер, чья трассировка выполнялась.

После завершения работы с окном Connect to SQL Server будет открыто окно Replay SQL Server (рис. 15.21), с помощью которого требуется сконфигуриро вать свойства воспроизведения событий.

Рис. 1 5. 2 1. Диалоговое окно Replay SQL Server В поле Replay SQL Server указывается сервер, в контексте которого будут вос производиться события. По умолчанию предлагается использовать тот же сер вер, который выполнял аутентификацию. Однако можно выбрать любой другой, нажав для этого кнопку в правой части окна. В поле Output file name можно указать имя файла, в который будет сохраняться информация, возвращаемая сервером в результате воспроизведения собранных событий.

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

О Replay events in the order they were traced. This option enables debugging. Собы тия начнут воспроизводиться в том же порядке, в каком они происходили в реальности. То есть будет осуществляться полная синхронизация событий.

Все события станут выполняться в той же последовательности, в которой они происходили в оригинале. Каждое следующее событие будет выполнено только после того, как завершится работа предыдущего.

• Replay events using multiple threads. This option optimizes performance and dias bles debugging. В этом случае осуществляется частичная синхронизация собы тий. События, выполняемые внутри одного соединения, происходят в той же последовательности, в какой они выполнялись при мониторинге. Однако ее 770 Часть III. Администрирование ли воспроизводятся события, выполненные в нескольких соединениях, то синхронизация между соединениями не осуществлется. То есть событие, ко торое по времени было выполнено позже других событий, может при вос произведении быть выполнено раньше этих событий, если оно принадлежит другому соединению. Для обработки событий разных соединений могут ис пользоваться свои собственные потоки.

На этом настройка параметров воспроизведения заканчивается. Для запуска воспроизведения остается только выбрать команду Start в меню Replay. После этого SQL Server Profiler начнет выполнение событий.

Использование Transact-SQL Как уже говорилось ранее, управление мониторингом работы SQL Server можно осуществлять с помощью хранимых процедур. В SQL Server 7.0 для осу ществления мониторинга и управления им пользователям предлагалось более полусотни специальных расширенных хранимых процедур — SQL Server Profiler Extended Procedures. Использование такого большого количества процедур, ко нечно же, вызывало немалые затруднения. Поэтому в SQL Server 2000 это множе ство процедур было заменено несколькими системными процедурами и функ циями, с помощью которых теперь и осуществляется мониторинг.

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

Преимуществом использования для мониторинга хранимых процедур являются меньшие требования к системным ресурсам по сравнению с утилитой SQL Server Profiler. Кроме того, с помощью хранимых процедур можно организовать более надежный мониторинг работы сервера. В SQL Server 2000 имеется возможность автоматического выполнения хранимых процедур каждый раз при запуске службы MSSQLServer. Это позволит вести непрерывный мониторинг работы сервера.

С~ Замечание ^ Помимо хранимых процедур, в SQL Server 2000 имеется ряд команд DBCC, С ПОМО ЩЬЮ которых можно контролировать различные аспекты работы внутренних меха низмов сервера.

Мы не будем рассматривать мониторинг средствами хранимых процедур, т. к.

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

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

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

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

Помимо использования для создания копии данных такого специализирован ного механизма, как резервное копирование, можно также применять и другие средства, предоставляемые SQL Server 2000. Например, с помощью подсистемы репликации, рассмотренной в главе 14, можно в режиме реального времени ко пировать важные данные на удаленный сервер. В случае выхода из строя основ ного сервера останется возможность работы с данными, расположенными на одном из серверов сети.

Также можно применять и возможности служб трансформации данных (DTS, Data Transformation Services), рассмотренных в главе 11. Варианты использова ния технологии DTS весьма разнообразны. Можно периодически сохранять оп ределенные данные в сетевом каталоге в обычном текстовом файле или отправ лять их по электронной почте на другой конец планеты. Можно также и закачивать данные на соседний сервер SQL Server 2000, который может быть использован в случае выхода из строя исходного сервера.

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

772 Часть III. Администрирование Многие организации работают по схеме 24x7. Это означает, что сервер баз дан ных должен быть доступен 24 часа в сутки 7 дней в неделю, т. е. пользователи должны иметь возможность работы с данными в любое время суток в любой день недели. Простои в работе должны быть исключены с максимальной веро ятностью. Для достижения этой цели возможностей одного только резервного копирования явно маловато.

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

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

П Кластер. С помощью данной технологии создается виртуальный сервер SQL Server 2000, к которому обращаются пользователи. На самом деле этот вирту альный сервер состоит из нескольких компьютеров (от 2 до 4). При выходе из строя одного компьютера остальные смогут принимать пользовательские запросы и обрабатывать их.

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

В следующих разделах будет подробно рассмотрена каждая из указанных техно логий.

Резервный сервер Резервный сервер (standby server), или как его еще называют горячая резервная копия (warm backup), представляет собой специальный выделенный сервер, который дублирует функци основного сервера. В случае выхода из строя основного сервера резервный переключается в нормальный режим, и пользователи могут работать с ним, как с обычным сервером. Резервный сервер работает отдельно от основного сервера, имеет свое собственное сетевое имя и сетевой адрес.

( Замечание ) Если основной сервер выходит из строя, то пользователи должны вручную пере ключиться на использование резервного. При этом должны быть заново запущены все задачи, которые выполнялись на основном KOMnbratepe. Автоматический пере нос задач между основным и резервным сервером не выполняется.

Резервный сервер содержит те же базы данных, что и основной. При нормально работающем основном сервере резервный сервер поддерживает свои базы дан ных в том же состоянии, что и основной.Для этого с основного сервера перио дически копируются все изменения, которые пользователи сделали на нем. Эти изменения в виде транзакций применяются на резервном сервере. В итоге ре зервный сервер Находится в том же состояний, что и основной. Пользователи Глава 16. Создание отказоустойчивой системы могут работать как с основным, так и с резервным сервером. Однако данные на резервном сервере доступны в режиме только для чтения (read only mode).

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

Работу с резервным сервером можно разделить на три фазы:

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

) С Замечание При синхронизации системных баз данных следует учесть, что для базы данных Master невозможно выполнить синхронизацию серверов с помощью резервной ко пии журнала транзакций. Взамен администратор должен использовать полную ре зервную копию.

• Установка и синхронизация резервного сервера. После того как администра тор создаст резервные копии баз данных, они должны быть восстановлены на резервном сервере в резервном режиме (standby mode). Для восстановления базы данных в этом режиме необходимо выполнить восстановление резерв ной копии с помощью команды RESTORE С указанием опции STANDBY. Восста новленная база данных будет доступна пользователям в режиме только для чтения (read only mode). Естественно, необходимо гарантировать, что база данных находится в целостном состоянии. Для этого должны быть откачены все незавершенные транзакции и восстановлены все изменения, сделанные данными незавершенными транзакциями. При этом необходимо сохранить все изменения, которые были выполнены незавершенными транзакциями, для последующего применения восстановленной копии журнала транзакций, полученной с основного сервера. Для достижения этой цели все страницы, которые были изменены незавершенными транзакциями, сохраняются в спе циальном файле отката (undo file). Имя этого файла указывается вместе с опцией STANDBY при восстановлении архива. Для каждой базы данных ре зервного сервера создается единственный файл отката. Размер этого файла не ограничивается. Периодически администратор должен выполнять на ос новном сервере создание резервных копий журнала транзакций и применять 774 Часть III. Администрирование его на резервном сервере. Частота выполнения этой операции зависит от объема изменений, которые пользователи выполняют на основном сервере.

Чем больше изменений осуществляется на основном сервере, тем чаще дол жен создаваться архив журнала транзакций. Так можно минимизировать по тери в случае выхода из строя основного сервера. Восстановление журнала транзакций должно выполняться с указанием опции STANDBY И тем же фай лом отката, что был использован ранее.

• Установка резервного сервера в нормальный режим. В ходе этой операции базы данных резервного сервера переводятся в нормальный режим. После этого пользователи могут подключаться к резервному серверу и работать с ним так же, как они работали с основным сервером. Для перевода базы дан ных в нормальный режим необходимо выполнить команду RESTORE С опцией RECOVERY BMeCTO ОПЦИИ STANDBY.



Pages:     | 1 |   ...   | 18 | 19 || 21 | 22 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.