Автоматизация администрирования

SQL Server 2000

 

Целью автоматизации администрирования любой системы в конечном счете является снижение ее стоимости владения (ТСО, Total Cost of Ownership). В данную характеристику входит не только стоимость аппаратного и програм­много обеспечения, но и затраты на ее обслуживание. Следует за­метить, что стоимость аппаратной части составляет всего около 10–15% общей стоимости системы. Сокращение стоимости владения происходит за счет того, что часть работы администраторов перекладывается на саму систему. В итоге организация может позволить себе сократить штат персонала или использовать его работу для решения более сложных и объемных задач.

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

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

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

В настоящей главе будет рассмотрена специализированная подсистема SQL Server 2000, предназначенная для автоматического выполнения задач и контроля за работой сервера. Основы автоматического администрирования были заложе­ны еще в SQL Server 6.х, однако только начиная с SQL Server 7.0 стало воз­можным полномасштабное автоматическое управление сервером. Подсистема автоматизации может решать не только простые одношаговые задачи, но и сложные, реализующие разветвленные алгоритмы. Кроме того, если в сети име­ется несколько серверов SQL Server 2000, то подсистема администрирования может быть настроена таким образом, что одно задание будет автоматически выполняться на всех серверах сети. Фундаментом подсистемы автоматического администрирования SQL Server 2000 является служба SQLServerAgent. Она представляет собой дополнение к SQL Server 2000, и ее запуск необязателен. Если в организации не использует­ся автоматическое администрирование, то служба SQLServerAgent может быть остановлена для освобождения ресурсов операционной системы. Однако для работы подсистемы репликации необходим запуск указанной службы. Подсис­тема репликации автоматически создает набор вспомогательных задач, которые обеспечивают продолжительное функционирование серверов, освобождая не­нужные ресурсы.

Как говорилось выше, в архитектуре подсистемы автоматизации SQL Server 2000 существуют следующие объекты: Jobs – задания; Alerts – оповещения; Operators – операторы.

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

1. Wizards (мастера). Пользователи, не имеющие достаточного опыта в управле­нии подсистемой автоматизации, могут прибегнуть к помощи специальных мастеров. Мастера облегчают задачи администрирования с точки зрения требующегося объема знаний, так как они снабжены большим количеством подска­зок и работают в пошаговом режиме, что делает процесс управления интуи­тивно понятным. В SQL Server 2000 имеются следующие мастера:

- Create Alert Wizard – с помощью этого мастера можно создать оповещение;

- Create Job Wizard – этот мастер предназначен для создания заданий;

- Make Master Server Wizard – применяя данный мастер, можно создать главный сервер;

- Make Target Server Wizard – при помощи этого мастера создается сервер назначения.

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

2. Enterprise Manager. С помощью этого стандартного инструмента можно вы­полнять любые действия по управлению подсистемой автоматизации администрирования: создание, изменение или удаление задания, оповещение операторов. Enterprise Manager предоставляет удобный графический интерфейс, интуитивно понятный любому пользователю. Объекты подсистемы автоматизации можно найти в папке Management, находящемся в корневом каталоге сервера панели Enterprise Manager.

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

“Microsoft” не советует изменять или читать системные данные напрямую. Взамен на­стоятельно рекомендуется использовать специальные хранимые процедуры, в достатке имеющиеся в SQL Server 2000. “Microsoft” не гарантирует, что структура системных таблиц, типы данных колонок и их назначение останутся неизменными в последующих версиях. Хранимые процедуры обеспечивают совместимость приложений, написанных для SQL Server 2000, с последующими версиями этого продукта.

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

 

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

 

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

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

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

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

Администратор SQL Server 2000 имеет в своем распоряжении множество средств обеспечения надежности системы:

- резервное копирование данных и журнала транзакций;

- использование резервного сервера;

- создание кластеров;

- возможности технологий RAID (технология дублирования, зеркального отображения и чередования с контролем четности), предназначенные для обеспечения отказоустойчивости дисковых масси­вов.

Каждое из приведенных средств имеет свои недостатки и преимущества. Например, технологии RAID (Redundant Array of Independent Disks) обеспечивают работоспособность системы в случае небольших сбоев в функционировании дисковой системы, но при выходе из строя всего компьютера на помощь прихо­дит резервный сервер или кластер. Когда же все серверы повреждены и нет возможности восстановить данные ни с одного из них, то остается лишь обра­титься к резервной копии.

Упомянутые средства обеспечения надежности системы не исключают друг друга. Наоборот, желательно применять их совместно. Например, информационная система предприятия может работать на главном сервере со­вместно с резервным, и на каждом из них может использоваться чередование дисков с контролем четности. Кроме того, необходимо периодически создавать резервную копию данных, чтобы иметь возможность восстановить информацию при выходе из строя обоих серверов баз данных (например, в случае пожара или природного катаклизма).

Резервное копирование (back up) является одним из самых надежных способов защиты данных от потери. Технологии RAID обеспечивают функционирование системы при выходе из строя одного из жестких дисков или даже дискового контроллера. Но они бессильны в случае выхода из строя оперативной памяти центрального процессора или сетевой карты. В этом случае пользователи не смогут получить с сервера данные. Решением проблемы будет использование резервного сервера или кластера. Но предположим, что информация на всех серверах была уничтожена. Чтобы иметь возможность восстановить данные, не­обходимо иметь полную их копию. Такая копия данных называется резервной (backup), и ни пользователи, ни система не имеют к ней доступа. Не­обходимо отметить, что резервная копия имеет значительно меньший размер по сравнению с исходной базой данных. Процесс создания резервной копии также называют архивированием.

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

Часто архивирование используется для переноса баз данных между серверами SQL Server 2000. База данных архивируется на исходном сервере на какой-нибудь носитель, который затем рассылается на другие серверы. На удаленном сервере администратор восстанавливает базу данных и может успешно с ней работать.

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

SQL Server 2000 поддерживает различные типы резервного копирования, позволяя администратору очень гибко управлять данным процессом. Существует полная копия; разностная копия; копия журнала транзакций; резервное копирование файлов и групп файлов.

 

Полная копия

Полная копия базы данных (database backup) является стандартным типом резервного копирования. Этот тип резервирования предполагает полное копирование всей информации, имеющейся в базе данных. В качестве приемника данных может выступать либо обычный файл, либо специальное устройство резервного копирования, такое, как стример, магнитооптический или zip-диск.

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

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

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

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

Существует ряд операций, которые не могут выполняться одновременно с про­цессом создания резервной копии. Список этих операций следующий:

- создание и удаление файлов базы данных;

- создание индексов;

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

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

 

Разностная копия

Разностное, или дифференциальное, резервное копирование (differential database backup) было разработано с целью уменьшения времени, необходимого для по­лучения копии базы данных. В основе дифференциальной копии лежит отсле­живание изменений, вносимых пользователями в базу данных. Создание диф­ференциальной копии состоит из двух этапов: создание полной копии данных; создание собственно дифференциальной копии.

Полная копия базы данных является отправной точкой, начиная с которой сис­тема может отслеживать изменения. Изменения отслеживаются на уровне стра­ниц. Каждая страница имеет флаг архивирования, который сбрасывается при создании полной копии и устанавливается, если данные на странице были из­менены. Это можно сравнить с атрибутом архивирования для файлов. При соз­дании резервной копии атрибут снимается, но если файл изменяется, то систе­ма автоматически устанавливает его. Программа резервного копирования ищет все файлы с установленным атрибутом архивирования и копирует их. Аналогично ведет себя и подсистема резервного копирования SQL Server 2000. Однако необходимо отметить, что флаг архивирования для страниц данных снимается только при создании полной копии данных. Это означает, что при создании последовательно нескольких дифференциальных копий каждая следующая будет полностью включать страницы, которые были включены в предыдущую копию, плюс все страницы, измененные со времени создания предыдущей копии. По­этому актуальна только самая последняя дифференциальная копия. Достаточно применить ее после восстановления полной резервной копии, чтобы целиком восстановить систему.

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

 

Копия журнала транзакций

 

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

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

Решением подобных проблем является применение резервного копирования жур­нала транзакций (transaction log backup). Этот тип резервного копирования позволяет сохранять информацию обо всех транзакциях, выполненных в базе дан­ных. В итоге резервная копия содержит непрерывную цепочку изменений, которые претерпели данные со времени последнего архивирования. Такая цепочка позволяет восстановить систему в состоянии, в котором она была в любой мо­мент времени и этот момент отображен в резервной копии. При восстановле­нии резервной копии журнала транзакций SQL Server 2000 последовательно вы­полняет все изменения, выполненные пользователями в базе данных.

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

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

 

Резервное копирование файлов и групп файлов

 

Это последний из типов резервного копирование SQL Server 2000. Как известно, база данных состоит из одного или более файлов данных и одного или более файлов журнала транзакций. Иными словами, любая база данных состоит минимум из двух файлов. Ни полное, ни резервное копирование не позволяют архивиро­вать только часть данных, например, только данные без индексов или только столбцы типа image, text и ntext. Резервная копия журнала транзакции ото­бражает лишь операции изменения данных.

SQL Server 2000 позволяет выполнять частичное архивирование данных. Для этого администратор должен использовать копирование файлов или групп файлов. Такой подход позволяет контролировать диапазон архивируемых данных вплоть до конкретного столбца таблицы. В основе этого подхода лежит возмож­ность привязывания таблицы или даже отдельного столбца к конкретному фай­лу или группе файлов. Все данные, принадлежащие столбцу, будут размешаться только в указанном файле или группе файлов. Обычно к файлу или группе фай­лов привязываются либо таблицы целиком, либо столбцы с типом данных im­age, text и ntext, требующие значительных ресурсов для их обработки.

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

Для восстановления целостности данных будет достаточно восстановить отдель­ный файл или группу файлов. Однако чтобы такое восстановление не сопрово­ждалось проблемами, администратор обязан следить за тем, чтобы связанные данные оставались согласованными после восстановления архива. Рассмотрим следующую ситуацию. Имеются две связанные таблицы, прикрепленные к раз­ным файлам и архивируемые отдельно. В первой, основной, таблице хранится описание сотрудников фирмы, а во второй – проекты, над которыми они рабо­тают. Проекты связаны с людьми по личным идентификаторам сотрудников, которые определяются в первой таблице. Предположим, что файл с основной таблицей был поврежден и администратор восстановил архив недельной давно­сти. За время, прошедшее с момента создания этого архива, в первую таблицу было добавлено несколько строк, описывающих новых сотрудников. Эти со­трудники были закреплены за определенными проектами, что было отображено во второй таблице. После восстановления файла с первой таблицей данные о новых сотрудниках окажутся потерянными. Однако во второй таблице останется информация о связи новых сотрудников с проектами. Налицо нарушение цело­стности данных. Во избежание подобных проблем рекомендуется хранить все связанные данные в одной группе файлов и выполнять ее архивирование за од­ну операцию.

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

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

Выбор носителя

 

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

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

Магнитная лента. Это наиболее часто используемый тип носителей для хра­нения резервных копий. Аппаратно реализуется в виде устройств, называе­мых стримерами. В стример вставляется кассета с лентой, с которой пользо­ватель хочет работать. По завершении работы можно вставить другую ленту. Преимуществом использования стримера является большой объем данных, который можно записать на ленту. Однако существенный недостаток заключается в относи­тельно медленной скорости записи и чтения данных.

Диск. В качестве носителя информации этого типа может выступать любой диск, с которым операционная система способна работать напрямую, т.е. без дополнительных утилит. Таким диском может являться и обычный жест­кий диск, и гибкий диск, и zip-диск, и даже магнитооптический диск. В по­следнее время получают распространение диски DVD. Накопители этого ти­па также могут выступать в качестве носителя резервной копии. Архив SQL Server 2000 представляет собой обычный файл операционной системы, с ко­торым могут выполняться те же операции, что и при работе с другими фай­лами: копирование, переименование, удаление, перемещение и т.д.

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

Именованные каналы. Это последний из типов носителей, применяемых системой резервного копирования. В принципе, при работе с любым из перечисленных выше типов носителей SQL Server 2000 также использует именованные каналы. Работа с именованными каналами (named pipes) в чистом виде необходима, если вы хотите использовать свое собственное приложение для обработки архивов SQL Server 2000. Именованные каналы предоставляют механизм обмена информацией между приложениями. SQL Server “закачивает” данные в канал, а ваше приложение получает из него данные. Дальнейшие операции, выполняемые с полученными данными, зависят от вашей фантазии.

Когда мы говорили о резервном копировании, речь прежде всего шла о пользовательских базах данных. Но не стоит забывать и о системной информации, без которой работа SQL Server 2000 будет невозможной. Наиболее критическим местом являются системные базы данных Master и Msdb. Повреждение этих баз данных приведет как минимум к неправильной работе сервера, а как мак­симум – к невозможности запуска.

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

Мы не рассмотрели еще две системных базы данных – Model и Tempdb. Первая из них используется как шаблон при создании новой базы данных. Особой необхо­димости в ее архивировании нет. Вторая же предназначена для хранения всех временных объектов, создаваемых пользователями. Архивирование этой базы дан­ных бессмысленно, так как база данных Tempdb создается заново каждый раз, когда стартует SQL Server 2000. При останове сервера происходит автоматическое унич­тожение всех временных объектов и удаление самой базы данных Tempdb.

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

 

Репликация данных

 

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

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

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

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

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

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

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

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

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

SQL Server 2000 предлагает пользователям и администраторам множество различных средств обмена данными между самыми разнообразными системами с постоянным физическим соединением друг с другом или без него. Это службы трансформации данных DTS и механизмов массивного копирования. Как ни широки возможности, предлагаемые этими инструментами, все же есть один существенный недоста­ток: эти механизмы являются надстройкой над базой данных, что влечет за собой некоторые неудобства. В SQL Server 2000 имеется мощное средство обмена данными – репликиции (replication). Механизмы репликации данных предоставляют серверам SQL Server 2000 мощный фундамент для создания распределенных систем хранения информации. Автоматическая синхронизация изменений (при постоянном физическом соединении или без него), сде­ланных на одном сервере, со всеми другими серверами делает возможным создание на основе SQL Server 2000 больших распределенных систем хранения информации, удовлетворяющих самым высоким современным требованиям. Система репликации SQL Server 2000 основывается на технологии Replication Distribution Interface. Эта технология позволяет включать в репликацию данных только серверы SQL Server 2000, SQL Server 7.0 или SQL Server 6.х, но и другие системы хранения и обработки данных, например Microsoft Access, Oracle, dBase, Paradox и даже MS Excel. С помощью подсистемы репликации администратор может создавать распределенные гетерогенные системы хранения информации масштаба предприятия.

Репликация данных – это совокупность механизмов SQL Server 2000, обеспечивающих отображение изменений данных, сделанных на одном сервере, на другие серве­ры. Подсистема репликации реализована в виде специализированных агентов, выполняемых на сервере как самостоятельный процесс. Эти агенты подключаются к серверам-участникам репликации и выполняют создание копий данных и тиражирование их между другими серверами. В зависимости от используемого типа репликации и функции сервера набор агентов на конкретном SQL Server 2000 может сильно различаться. В состав SQL Server 2000 включены несколько мастеров, охватывающих все во­просы настройки репликации. Удобный графический интерфейс и наличие под­сказок значительно облегчают процесс создания, удаления и конфигурирования издателя, дистрибьютора и подписчика. Репликация может быть реализована между базами данных одного и того же сервера или между различными серве­рами, которые объединены сетями LAN, WAN или Интернетом.

В список агентов подсистемы репликации SQL Server 2000 входят: Snapshot Agent, Log Reader Agent, Queue Reader Agent, Distribution Agent, Merge Agent.

Каждый из указанных агентов реализован как утилита командной строки. Все агенты располагаются в каталоге \ Program Files\Microsoft SQL Server\80\COM.

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

Список этих задач следующий:

- Agent History Clean Up: Distribution;

- Distribution Clean Up: Distribution;

- Reinitialize Subscriptions Having Data Validation Failures;

- Replication Agents Checkup.

 

Мониторинг и аудит

 

Как бы хорошо ни была настроена система при установке, рано или поздно в ее работе появятся проблемы. Это связано не с ошибками при администрирова­нии, а в большей степени с последствиями добавления в базы данных новой информации, создания новых объектов, написания неоптимизированных запро­сов, использования новых приложений и т. д. Со временем эти проблемы могут привести к серьезным неприятностям в работе сервера и даже к его краху. По­следнее случается достаточно редко, но все же вероятность этого остается. Чем боль­ше сеть предприятия и чем больше объем обрабатываемой информации, тем выше вероятность возникновения проблем.

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

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

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

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

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

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

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

1. Мониторинг операционной системы и аппаратной части компьютера. В этом случае администратор получит количественную информацию о работе систе­мы. Этот тип мониторинга операционной системы предполагает применение следующих инструментов: утилиты Performance Monitor; утилиты Task Manager; утилиты Event Viewer; протокола Simple Network Management Protocol, SNMP.

2. Мониторинг работы SQL Server 2000 и его подсистем. Этот тип мониторинга позволяет проанализировать работу отдельных запросов и хранимых процедур. Для получения качественной информации о работе SQL Server 2000 могут применяться следующие инструменты: утилита SQL Server Profiler; утилита Enterprise Manager; средства Transact-SQL.

Каждый из упомянутых инструментов мониторинга отличается своей спецификой. Выбор конкретного инструмента прежде всего зависит от типа анализи­руемых объектов. Например, если пользователи жалуются, что выполнение их запросов прерывается и сервер часто выдает сообщение об ошибке 1205, то это говорит о том, что на сервере часто возникают мертвые блокировки (deadlocks). Мертвые блокировки – это взаимное блокирование ресурсов разными процессами таким образом, что каждый из них ждет, пока другой процесс освободит ресурсы, необходимые для завершения транзакции. Так как ресурсы, требуемые каждому из процессов, заблокированы, то завершение операций невозможно. Процессы могут бесконечно ожидать разблокирования ресурсов. Мертвая блокировка может состоять более чем из двух процессов. Нетрудно догадаться, что увеличение производительности аппаратной части сервера не приведет к решению этой проблемы. Необходимо определить, какие запросы образуют мертвые блокировки и переписать их таким образом, чтобы этого больше не возникало.

 

Мониторинг работы SQL Server 2000

 

Мониторинг работы SQL Server 2000 основывается на наблюдении за событиями (events). Событие генерируется ядром SQL Server 2000 и является минимальным объемом работы, который можно контролировать. Каждое событие принадлежит к какому-то классу событий (event classes), который описывает его параметры и смысл той или иной информации. Количество классов событий SQL Server довольно велико. Для облегчения рабо­ты с ними они разбиты на категории (category):

1. Sessions. События, связанные с установлением и закрытием соединения клиента с сервером.

2. Objects. События, генерируемые в случае создания, открытия, закрытия удаления объектов базы данных.

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

4. TSQL. События, связанные с выполнением команд Transact-SQL.

5. Cursors. События, связанные с использованием курсоров.

6. Stored Procedures. События, связанные с выполнением хранимых процедур.

7. Error and Warning. События, связанные с ошибками и сообщениями SQL Server 200C.

8. Transactions. События, связанные с транзакциями, выполненными SQL Serve или MSDTC, а также связанные с работой журнала транзакций.

9. Locks. События, связанные с установкой блокировок в базах данных.

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

11. Performance. События, связанные с работой команд манипуляции данными, – подготовка и компиляция плана исполнения запроса, использование статистики и т. д.

12. Server. События, описывающие использование сервером оперативной памяти и запуск, останов и приостанов службы MSSQLServer.

13. Security Audit. События, связанные с отслеживанием различных аспектов дейст­вий пользователей.

14. User Configurable. События, определенные пользователями.

Информация о событиях хранится в специальных таб­лицах системной базы данных Master. Каждое событие описывается отдельной строкой. Для описания событий предназначен фиксированный набор колонок данных. Однако конкретное назначение колонок зависит от того, к какому классу принадлежит событие. Кроме того, при описании некоторых классов событий могут применяться не все колонки. В этом случае в незадейст­вованной колонке хранится пустое значение (Null).