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

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

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


Pages:     | 1 |   ...   | 14 | 15 || 17 | 18 |   ...   | 33 |

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

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

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

• Initialize and label media. Флажок доступен только при работе с лентой. Его установка предписывает записать в самом начале ленты новый заголовок MTF (Microsoft Tape Format). При этом все имеющиеся на ленте данные, включая и записанные ранее заголовки, будут потеряны. При этом не вы полняется проверка на срок хранения имеющейся на носителе информации.

Дополнительно становятся доступными два поля:

Media set name — для указания имени набора носителей, которое будет • включено в заголовок MTF;

Media set description — для ввода краткого комментария к имени набора • носителей, указанного в предыдущем поле.

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

Просмотреть с помощью Enterprise Manager список всех резервных копий, вы полненных для всех баз данных, можно & папке Backup, найти которую можно в папке Management каждого сервера.

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

Для начинающих пользователей, имеющих только общие сведения о работе подсистемы архивирования, для создания резервных копий ско рее всего подойдет мастер Create Database Backup Wizard. Для запуска этого мастера можно воспользовать ся окном Select Wizard (рис. 13.5), открыть которое можно с помощью кнопки Run a wizard, расположен ной в панели инструментов Enter prise Manager. В окне Select Wizard необходимо открыть папку Manage ment и выбрать пункт Backup Wiz ard. После этого остается только нажать кнопку ОК, что приведет к появлению первого окна мастера.

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

Второе окно мастера называется Select Database to Backup, что переводится как "выберите базу данных для архивирования". В окне имеется единственный элемент управления — раскрывающийся список Database, с помощью которого нужно определить имя одной из баз данных, имеющихся на сервере. Для выбранной базы данных и будет создаваться резервная копия.

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

Третье окно мастера имеет имя Type Name and Description for Backup (рис. 13.6), что можно перевести как "введите имя и описание архива". В соответствии с на званием окно имеет два поля:

• Name. Указывается имя, которое будет присвоено создаваемому архиву.

О Description. В этом поле пользователь может ввести небольшой комментарий к создаваемой резервной копии.

Глава 13. Резервное копирование Рис. 13.6. Окно Type Name and Description for Backup мастера Create Database Backup Wteard Указание имени архива обязательно, тогда как поле для комментария можно оставить пустым. Если даже оставить поле Name пустым, то мастер будет ис пользовать И Я ПО уМОЛЧаНИЮ, Которое генерируется В формате databasename М backup. После того, как необходимые данные будут введены, работа с третьим окном мастера заканчивается.

Четвертое окно называется Select Type of Backup (рис. 13.7) и, в соответствии с названием, предназначено для выбора тйЬа создаваемой резервной копии. В распоряжении пользователя имеется переключатель, который может быть уста новлен в одно из перечисленных положений:

• Database backup - backup the entire database — полная резервная копия базы данных;

О Differential database - backup only new and changed data — разностная резерв ная копия;

G Transactional log - backup the record of all the changes made to the database — резервная копия журнала транзакций.

с Замечание Напомним, что при архивировании системных баз данных Master и Msdb сущест вуют определенные ограничения. В частности, для базы данных Master разреша ется создание только полной резервной копии, а для базы данных Msdb — полной и разностной резервных копий.

Часть 111. Администрирование Рис. 13.7. ОКНО Select Type of Backup мастера Create Database Backup Wizard Рис. 13.8. ОКНО Select Backup Destination and Action мастера Create Database Backup Wizard После выбора типа резервной копии можно переходить к очередному окну мас тера. Оно имеет название Select Backup Destination and Action (рис. 13.8), что дословно можно перевести как "выберите место записи архива и действие". В Глава 13. Резервное копирование 5? принципе, можно не вносить никаких изменений в значения, установленные в окне по умолчанию и сразу же перейти к следующему окну мастера. Тем не ме нее, все же рассмотрим назначение имеющихся элементов управления.

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

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

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

П Backup device. При установке переключателя в данное положение будет ис пользоваться устройство резервного копирования. Это устройство может быть создано с помощью системной хранимой процедуры sp_addumpdevice либо с помощью окна Backup Device Properties - New Device. Оба этих метода создания логических устройств резервного копирования были приведены в предыдущих разделах. В частности, ранее было рассмотрено использование окна Backup Device Properties - New Device.

В группе элементов Properties, предназначенной для управления дополнительны ми параметрами создаваемого архива, содержится переключатель и два флажка:

• Append to the backup media. Новые данные будут добавляться к имеющимся.

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

• Overwrite the backup media. Новая резервная копия будет записана поверх имеющихся данных. Обычно применяется, когда резервная копия сохраняет ся в обычный файл. Таким образом, файл со старой резервной копией будет удален, а вместо него создан файл с новым архивом.

П Eject tape after backup. Этот флажок доступен только при архивировании на ленту, т. к. предписывает автоматически извлечь ленту из устройства резерв ного копирования.

П Read and verify the integrity of the backup after backup. После завершения соз дания резервной копии будет выполнена ее проверка.

Следующее окно мастера имеет название Backup Verification and Scheduling (рис. 13.9) и позволяет контролировать срок хранения резервной копии, к о н * фигурировать автоматическое выполнение архивирования, а также управлять некоторыми другими параметрами резервного копирования.

Устанавливая флажок Check media set name and backup set expiration date, вы тем самым предписываете выполнять проверку на попытку перезаписи архива, срок 19* 562 Часть III. Администрирование хранения которого еще не истек. Если такая проверка разрешена и выполняется попытка перезаписать неустаревший архив, то будет выдано сообщение об ошибке. При установке флажка также допускается проверка на сохранение ре зервной копии в конкретном наборе носителей. Имя набора носителя, в кото ром должна быть сохранена резервная копия, указывается в поле Media set name. По умолчанию это поле пусто и архив может быть сохранен в любом на боре носителей.

Рис. 13.9. Окно Backup Verification and Scheduling мастера Create Database Backup Wizard r Замечание Имя набора носителей, к которому будет принадлежать конкретный носитель, зада ется при создании или переформатировании этого носителя.

По умолчанию для создаваемой резервной копии не устанавливается какой-то конкретный срок хранения, т. е. архив может быть перезаписан сразу же после его создания. Если все же необходимо обезопасить архив от перезаписи, то сле дует отметить флажок Backup set will expire и определить срок хранения архива.

Это осуществляется с помощбю переключателя, устанавливаемого либо в поло жение After (Определенное количество дней), либо в положение On (Конкрет ная дата).

Наконец, в окне имеется флажок Schedule, устанавливая который вы тем самым предписываете разрешить автоматическое создание резервных копий. Для полу чения более подробной информации об автоматическом архивировании следует обратиться к предыдущему разделу. Напомним, что резервное копирования мо Глава 13. Резервное копирование жет выполняться и как часть плана сопровождения баз данных, что было рас смотрено в разд. "Мастер Database Maintenance Plan Wizard" главы 12.

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

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

П при помощи утилиты Enterprise Manager;

• используя возможности языка Transact-SQL.

Замечание Мы не рассматриваем восстановление файлов базы данных, которые были архиви рованы не средствами SQL Server 2000, а как файлы операционной системы с по мощью утилиты Windows NT Backup или ей подобных. Этот способ архивирования рекомендуется использовать только опытным пользователям.

Восстановление любого типа резервной копии выполняется с помощью единст венной команды Transact-SQL — RESTORE. В следующих разделах будет рассмот рено использование этой команды для восстановления архивов различных типов.

Восстановление полной и разностной копий Для восстановления полной или разностной резервной копий необходимо ис пользовать команду RESTORE со следующим синтаксисом:

RESTORE DATABASE {database_name I @database_name_var} [FROM backup_device [,... n ] ] [WITH [DBO_ONLY] [ [, ] FILE = file_number] [ [, ] MEDIANAME = {media_name I @media_name_variable}] [ [, ] M V ' l o g i c a l _ f i l e _ n a m e ' TO l o p e r a t i n g _ s y s t e m _ f i l e _ n a m e 1 ] OE [,...n] [ [, ] {NORECOVERY I RECOVERY I STANDBY = undo_file_narae}] [ [, ] {NOUNLOAD I UNLOAD}] [ [, ] REPLACE] • [ [, ] RESTART] [ [, ] STATS [= p e r c e n t a g e ] ] ] Рассмотрим назначение каждого из аргументов команды.

Часть III. Администрирование • DATABASE {database_name | @database_name_var} Ключевое слово DATABASE указывает, что восстанавливается база данных, а точнее — ее полная или разностная резервная копия. За ключевым словом DATABASE следует имя восстанавливаемой базы данных. Имя может указы ваться как строковая константа (database name) или с помощью переменной СИМВОЛЬНОГО т и п а ( @ d a t a b a s e _ n a m e _ v a r ).

• FROM backup_device [,...n] С помощью ключевого слова FROM задается имя устройства резервного копи рования, с которого необходимо восстановить базу данных. Имя устройства задается в конструкции backupdevice, синтаксис которой был приведен в разд. "Создание полной и разностной копий" ранее в этой главе. Можно ис пользовать множество устройств. Если раздел FROM не указывается, то вы полняется операция реконструкции (recovery) базы данных. В этом случае не обходимо использовать опции NORECOVERY, RECOVERY ИЛИ STANDBY.

DBO_ONLY О При вводе этого ключевого слова доступ к восстановленной базе данных бу дет иметь только владелец базы данных (DBO, database owner). Впоследствии база данных может быть переведена в обычный режим с помощью вызова хранимой процедуры sp_dboption с параметром dbo use only.

П FILE = file_number Задает номер набора резервной копии (backup set) на носителе. Наборы распо лагаются на носителе последовательно.

О MEDIANAME = tmedia_name i @medianame_variable) Имя носителя, с которого должна быть восстановлена резервная копия.

d M V 'logical_file_name' ТО 'operating_system_filename' OE Этот параметр используется для присвоения логическим файлам базы дан ных физических имен, отличных от тех, которые они имени при архивиро вании. По умолчанию все восстанавливаемые файлы базы данных будут иметь то же имя и находиться в том же каталоге, что и исходные файлы.

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

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

Глава 13. Резервное копирование.

;

О STANDBY = u n d o _ f i l e _ n a m e С помощью этой опции указывается файл отката (undo file), с помощью ко торого можно отменить действия, выполненные в ходе восстановления базы данных. Если указан ключ STANDBY, пользователи могут работать с базой данных в режиме только для чтения между операциями восстановления жур нала транзакций. Ключ STANDBY задается при восстановлении базы данных на резервном сервере (standby server), который доступен только в режиме чте ния и отображает все изменения, сделанные на основном сервере с помо щью применения транзакций. Если указанный файл отката не существует, SQL Server 2000 автоматически создает его. Если файл отката является теку щим файлом отката базы данных, то новая информация будет добавлена в него. В противном случае файл будет переписан.

( Замечание Если не указано ни одно из ключевых слов RECOVERY, NORECOVERY ИЛИ STANDBY, TO по умолчанию используется параметр RECOVERY.

UNLOAD П При указании этого ключевого слова после восстановления архива будет вы полнена автоматическая выгрузка ленты из стримера.

О NOUNLOAD В отличие от предыдущего параметра, по завершении восстановления вы грузка ленты из стримера не выполняется.

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

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

О STATS [= percentage] Этот аргумент позволяет (в процентах) задать дискретность шкалы индикато ра процесса архивирования. По умолчанию пользователь получает сообще ние по завершении каждых 10% процесса.

Восстановление файлов или групп файлов Для восстановления архива файлов или групп файлов используется команда RESTORE со следующим синтаксисом:

566 Часть III. Администрирование RESTORE DATABASE {database_name I Gdatabase_name_var} file_or_filegroup [,...n] [FROM backup_device [,... n ] ] [WITH [DBO_ONLY] [ [, ] FILE = f i l e _ n u m b e r ] [ [, ] MEDIANAME = {media_name I @media_name_variable)] [ [, ] NORECOVERY] [ [, ] {NOUNLOAD I UNLOAD}] [ [, ] REPLACE] [ [, ] RESTART] [ [, ] STATS [= p e r c e n t a g e ] ] ] Как видно, в этом варианте команды RESTORE используется только один параметр, не описанный в предыдущем разделе — конструкция file_or_filegroup [,... п ]. С помощью этой конструкции указываются файлы или группы файлов, которые должны быть восстановлены. Подробно синтаксис и использование указанной конструкции были представлены в разд. "Создание копий файлов и групп файлов"ранее в этой главе.

Восстановление журнала транзакций Для восстановления резервной копии журнала транзакций служит команда RESTORE со следующим синтаксисом:

RESTORE LOG (database_name I @database_name_var) [FROM backup_device [,... n ] ] [WITH [DBO_ONLY] [ [, ] FILE = f i l e _ n u m b e r ] [ [, ] MEDIANAME = {media_name I @media_name_variable}] [ [, ] {NORECOVERY I RECOVERY | STANDBY = undo_file_name} ] [ [, ] {NOUNLOAD | UNLOAD}] [ [, ] RESTART] [[,] STATS [= percentage]] [[,] STOPAT = {date_time I @date_time_var}] ] Отличие синтаксиса команды RESTORE при восстановлении журнала транзакций от восстановления полной или разностной копии сводится к двум параметрам.

Рассмотрим их.

Вместо ключевого слова DATABASE используется ключевое слово LOG, говорящее о том, что восстанавливается резервная копия журнала транзакций.

С помощью аргумента STOPAT = ( d a t e t i m e | S d a t e t i m e v a r } можно указать конкретное время, до которого следует восстановить журнал транзакций. Время указывается в формате, используемом при работе с типом данных datetime. До пускается применение облегченного варианта — типа данных smaiidatetime.

Время можно задать в виде символьной константы или с помощью переменной, имеющей ТИП данных datetime ИЛИ smaiidatetime.

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

Восстановление архива средствами Enterprise Manager Как уже говорилось, использование команд Transact-SQL требует соответст вующей профессиональной подготовки и навыков. Поэтому не каждый пользо ватель решится для восстановления резервной копии воспользоваться непосред ственно командой RESTORE. Более того, для администратора знание синтаксиса и использования команд Transact-SQL вовсе не обязательно. Этого можно тре бовать от разработчика, но не от пользователя, пусть даже и весьма продвину того, каковым является администратор.

Для пользователей, не обремененных знанием команд Transact-SQL, лучшим вари антом выполнения восстановления резервной копии будет использование средств Enterprise Manager. Этот инструмент также может оказаться весьма удобным и для продвинутых разработчиков, уставших от стучания по клавиатуре и постоянного отслеживания имен архивов, файлов, версий и другой подобной информации.

Восстановление резервной копии при работе с Enterprise Manager выполняется с помощью окна Restore database (рис. 13.10). Открыть это окно можно либо вы брав в меню Tools команду Restore Database, либо указав в контекстном меню какой-нибудь базы данных команду All Tasks, а затем команду Restore Database.

Как видно, окно Restore database имеет две вкладки. Первая из них называется General и используется для управления общими свойствами восстанавливаемой базы данных. Вторая же вкладка — Options — предназначена для конфигуриро вания дополнительных параметров. Сначала рассмотрим элементы управления, имеющиеся на вкладке General (рис. 13.10):

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

( Замечание ^ Таким образом, архив одной и той же базы данных может быть восстановлен под разными именами, что бывает довольно полезно, когда базу данных необходимо Часть III. Администрирование лишь частично восстановить в первоначальное состояние. Например, если пользо ватели в течение недели активно изменяли данные в двух десятках таблиц и вдруг оказалось, что в одной из них были выполнены неверные модификации, то можно восстановить резервную копию базы данных под другим именем и перенести в ра бочую базу данных лишь поврежденную информацию. Из чего следует, что данные, внесенные в девять других таблиц, удастся сохранить.

Рис. 13.10. Окно Restore database • Restore. С помощью данного переключателя производится выбор типа уст ройства или архива. В зависимости от того, в какое положение установлен переключатель, меняется состав элементов управления в группе Parameters.

Рассматриваемый набор элементов управления (см. рис. 13.10) соответствует положению переключателя Database. Вообще же переключатель может быть установлен в следующие положения:

Database— полная или разностная резервная копия, а также резервная • копия журнала транзакций;

Filegroups or files — резервная копия одного или более файлов или групп • файлов;

• From device — будет восстанавливаться архив, сохраненный на устройстве резервного копирования.

• Show backups of database. С помощью этого раскрывающегося списка пользо ватель может выбрать имя одной из имеющихся на сервере баз данных.

Глава 13. Резервное копирование Другие элементы управления, размещенные в группе Parameters, зависят от рассматриваемого раскрывающегося списка. Например, в таблице, располо женной в нижней части вкладки, будут отображаться архивы, созданные ра нее на сервере для указанной базы данных.

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

• Point in time restore. Флажок доступен только в том случае, когда восстанав ливается резервная копия журнала транзакций. Устанавливая флажок, можно восстановить базу данных в состояние, в котором она была в конкретный момент времени. Это время указывается в поле, расположенном справа от флажка.

В нижней части вкладки находится таблица, в которой отображается список всех архивов, сделанных для базы данных, выбранной в списке Show backups of database, а также созданных начиная с момента, выбранного в списке First backup to restore. В таблице содержатся перечисленные ниже колонки:

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

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

П Backup Set Date. В колонке отображается дата создания соответствующей резервной копии.

П Size. Отображается размер, который имеет резервная копия.

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

О Backup Set Name. Выводится имя набора носителей, к которому принадлежит носитель, содержащий соответствующую резервную копию.

С помощью кнопки Properties отрывается окно свойств, с помощью которого можно выбрать иной носитель, чем тот, что указан в колонке Restore From. Это 570 Часть III. Администрирование бывает необходимо, например, когда файл с резервной копией был перемещен в иное место, чем в то, куда он был сохранен при создании резервной копии.

Мы рассмотрели элементы управления, которые имеются на вкладке General окна Restore database, когда переключатель Restore установлен в положение Database. Как уже было сказано, при установке указанного переключателя в иное положение в группе Parameters будет существовать другой набор элементов управления.

Теперь же перейдем к рассмотрению вкладки Options (рис. 13.11), которая слу жит для тонкой настройки процесса восстановления резервной копии. На вкладке имеются следующие элементы управления:

• Eject tapes (if any) after restoring each backup. После завершения восстановле ния будет автоматически извлечена лента из устройства резервного копиро вания.

• Prompt before restoring each backup. Пользователю будет выдаваться диалого вое окно с вопросом о необходимости восстановления резервной копии.

• Force restore over existing database. Восстановление резервной копии будет осуществляться поверх существующей базы данных.

• Restore database files as. С помощью данной таблицы можно изменять имена и положение файлов базы данных. Таблица имеет следующие колонки:

• Original File Name — имя файла, которое он имел в оригинале;

• Restore As — имя и местоположение на диске, которые будет иметь соот ветствующий файл. По умолчанию предлагаются те же значения, что бы ли в первоначальном варианте. Однако пользователь может указать любые другие допустимые значения.

• Recovery completion state. С помощью этого переключателя можно опреде лить, в каком состоянии должна находиться база данных после восстановле ния. Возможны следующие варианты:

• Leave database operational. No additional transaction logs can be restored — после завершения восстановления база данных будет приведена в рабочее состояние. При этом дополнительное восстановление резервной копии журнала транзакций будет невозможно;

• Leave database nonoperational but able to restore additional transactional logs — в этом случае база данных не приводится в рабочее состояние, а остается в промежуточном состоянии. Это позволяет выполнять восста новление резервной копии журнала транзакций;

• Leave database read-only and able to restore additional transactional logs — как и в предыдущем случае, установка переключателя в данное положе ние дает возможность восстанавливать резервную копию журнала тран закций. Однако при этом также разрешается чтение данных пользовате лями, что невозможно в предыдущем случае. Возможность чтения обеспе чивается за счет того, что база данных устанавливается в состояние "толь ко для чтения". Дополнительно в поле Undo file можно указать имя и путь Глава 13. Резервное копирование к файлу отката. С помощью этого файла можно будет отменить измене ния, выполненные при последующем восстановлении журнала транзак ций.

На этом рассмотрение вкладки Options, а также и восстановления резервных копий с помощью Enterprise Manager, можно считать оконченным.

Рис. 1 3. 1 1. Окно Restore database, вкладка Options Глава Репликация данных Обмен данными — одна из важнейших составляющих работы с информацией на любом предприятии. Данные, накопленные в одном подразделении, обрабаты ваются и агрегируются, после чего передаются в другое подразделение в качест ве входных данных. Во втором подразделении данные снова обрабатываются и передаются в третий отдел. Эта цепочка может продолжаться довольно долго.

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

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

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

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

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

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

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

О Без постоянного физического соединения. В этом случае компоненты инфор мационной системы организации не имеют постоянной связи друг с другом.

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

Администраторы региональных филиалов должны вручную синхронизиро вать изменения.

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

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

В SQL Server 2000 имеется мощное средство обмена данными — репликация (replication). Механизмы репликации данных предоставляют серверам SQL Server 2000 мощный фундамент для создания распределенных систем хранения информации с использованием ODBC или OLE DB. Автоматическая синхрони зация изменений (при постоянном физическом соединении или без него), сде ланных на одном сервере, со всеми другими серверами делает возможным соз дание на основе SQL Server 2000 больших распределенных систем хранения информации, удовлетворяющих самым высоким современным требованиям.

Система репликации SQL Server 2000 основывается на технологии Replication Dis tribution Interface. Эта технология позволяет включать в репликацию данных не только серверы SQL Server 2000, SQL Server 7.0 или SQL Server 6.x, но и другие системы хранения и обработки данных, например Microsoft Access, Oracle, dBase, Paradox и даже MS Excel. С помощью подсистемы репликации администратор может создавать распределенные гетерогенные системы хранения информации масштаба предприятия.

574 Часть III. Администрирование J Г Замечание В принципе, достаточно просто организовать обмен данными и с использованием механизмов DTS. Однако подсистема репликации предлагает гораздо большие воз можности, чем просто закачка данных в удаленные системы. Эта глава полностью посвящена рассмотрению работы с подсистемой репликации SQL Server 2000.

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

Существенные изменения в подсистеме репликации были сделаны еще в SQL Server 7.0. Была реализована автоматическая синхронизация изменений, сделан ных на всех участвующих в репликации серверах. Это достигается применением репликации сведением, для тонкой настройки которой применяется система приоритетов серверов.

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

В SQL Server 2000 также были внесены некоторые изменения в подсистему реп ликации. Самым важным из них является появление нового механизма, обеспечи вающего изменение данных подписчиками — отложенное обновление (queue up dating). Достоинством этой технологии по сравнению с технологией подписчиков незамедлительного обновления является возможность выполнения изменений на подписчике при отсутствии соединения между издателем и подписчиком.

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

Начало активного применения репликации данных было положено появлением SQL Server версии 6.0. Модель репликации бази^ется на метафоре "опубликуй и подпишись"— Publish and Subscribe, введенных в том же SQL Server 6.0. Терми нология репликации использует понятия издатель — Publisher, дистрибьютор — Distributor и подписчик — Subscription.

Глава 14. Репликация данных (~ Замечание } Не следует понимать, что издатель, подписчик и дистрибьютор— это специально сконфигурированный SQL Server 2000. Они являются лишь программными компонен тами. Хотя обычно под издателем, подписчиком и дистрибьютором понимается от дельный сервер, наделенный некоторыми специальными функциями.

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

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

С Замечание ^ Хотя система репликации предназначена для обмена данными между множеством SQL Server 2000 (или других источников данных), в принципе можно организовать про цесс репликации между базами данных одного и того же сервера. В этом случае изда тель, дистрибьютор и подписчик запускаются на одном сервере SQL Server 2000.

Помимо уже упомянутых терминов, при обсуждении репликации используются еще несколько:

• Публикация (Publication). Публикация представляет собой набор статей.

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

П Статья (Article). Статьей называется минимальный набор данных, рассматривае мый системой репликации как одно целое. Статья представляет собой таблицу или какую-то ее часть. Если необходимо выполнить тиражирование не всей таб лицы, а только ее фрагмента, то необходимо использовать фильтрацию:

• Using a vertical filter (использование вертикального разделения), при кото рой в статью не включается одна или более колонок исходной таблицы;

• Using a horizontal filter (использование горизонтального разделения), когда на строки, включаемые в статью, накладывается одно или более условий с ПОМОЩЬЮ КОНСТРУКЦИИ WHERE.

( Замечание ) Следует отметить, что в SQL Server 6.x существовала возможность подписки на от дельную статью публикации. Хотя в документации по SQL Server 2000 и указано, что подписка на отдельную статью не поддерживается, все же при обновлении SQL 576 Часть III. Администрирование Server 6.x до SQL Server 2000 настройки системы репликации сохраняются, и под писчик может копировать отдельную статью. Тем не менее, уже в SQL Server 7.0, а тем более в SQL Server 2000 средствами пользовательского интерфейса подпи саться на отдельную статью публикации невозможно. Выходом является создание новой публикации, включающей только нужную статью. Microsoft не гарантирует, что поддержка репликации единственной статьи будет сохранена и рекомендует пере писать приложения в соответствии с новыми требованиями.

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

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

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

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

Подписчик Подписчиком (subscriber) называется сервер, который принимает данные от изда теля. Этот сервер подписывается на одну или более публикаций и единожды или периодически копирует опубликованные данные. Один подписчик может получать данные от множества издателей. Если учесть, что подписчик может Глава 14. Репликация данных выступать и в качестве издателя, то такой подход позволяет создавать сложные разветвленные системы распространения информации.

С Замечание ^ Система репликации SQL Server 2000 построена таким образом, что в качестве под писчиков могут выступать любые источники данных Microsoft Jet Database, ODBC и OLE DB.

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

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

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

• Репликация сведением (Merge Replication). Это самый сложный тип реплика ции. В этом случае допускается нахождение одних и тех же данных в не скольких различных состояниях. То есть каждый из серверов — участников репликации может иметь свое собственное значение для одной и той же строки. Для решения этой проблемы используется система приоритетов, в соответствии с которой решается, данные какого из серверов должны быть тиражированы на все другие серверы.

D Подписчики незамедлительного обновления (Immediate Updating Subscribers).

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

• Отложенное обновление (Queue Updating). Эта технология, как и репликация сведением, допускает наличие на различных серверах нескольких состояний одних и тех же данных. Однако, в конце концов все изменения объединяют ся и из них остается только одно. Выбор этого изменения осуществляется в соответствии с правилами, установленными при создании соответствующей публикации.

578 Часть III. Администрирование ( Замечание ^ Более подробно каждая из технологий, реализующих изменение данных на подпис чиках, будет рассмотрена в следующих разделах этой главы.

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

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

• Репликация по запросу (Pull subscription). Этот метод обновления предполага ет, что вся работа по обновлению данных ложится на сервер-подписчик, ко торый через определенные интервалы подключается к дистрибьютору и ко пирует с него новую порцию данных. Дистрибьютор подготавливает для каждого подписчика набор данных, отображающий все изменения, сделан ные на издателе со времени последнего подключения этого подписчика. Ре пликация по запросу активно применяется мобильными пользователями и на серверах, не имеющих постоянного соединения с дистрибьютором. Такой метод репликации позволяет выполнять синхронизацию данных не только через определенные интервалы, но и в удобное для пользователей время.

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

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

Глава 14. Репликация данных Дистрибьютор Дистрибьютором (distributor) называется сервер, являющийся промежуточным звеном между издателем и подписчиком. Роль дистрибьютора сводится к сбору всей информации, которая должна быть скопирована подписчикам от издателя.

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

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

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

Это база данных D i s t r i b u t i o n. Для каждого издателя в ней хранится информа ция о сконфигурированных на нем публикациях, их типе и параметрах статей в каждой публикации. Для подписчиков хранится список статей, на которые он подписан, информация о расписании обновления, времени последней синхро низации, и другие сведения. Кроме того, в базу данных распределения при реп ликации сведением стекается информация обо всех производимых на подпис чиках и издателе изменениях. Специальный агент затем анализирует эту информацию и выполняет сведение множества данных в один блок.


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

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

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

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

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

( Замечание V Функции дистрибьютора может выполнять как выделенный сервер, так и сервер, сконфигурированный в качестве издателя или подписчика. В зависимости от метода репликации, функции дистрибьютора могут существенно меняться.

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

Приведем список агентов подсистемы репликации SQL Server 2000:

• Snapshot Agent П Log Reader Agent • Queue Reader Agent О Distribution Agent • Merge Agent Каждый из указанных агентов реализован как утилита командной строки. В пре делах одного компьютера для всех инсталляций SQL Server 2000 предназначен общий набор агентов. Таким образом, при выполнении обновления агентов для одной инсталляции будет выполнено и обновление агентов для всех других ин сталляций. Все агенты располагаются в каталоге \Program Files\Microsoft SQL Server\80\COM. В следующих разделах будет рассмотрено назначение агентов реп ликации, утилиты, представляющие каждый из агентов, и синтаксис этих утилит.

Глава 14. Репликация данных 56?

Помимо указанных агентов, при конфигурировании механизмов репликации автоматически создаются несколько вспомогательных задач, которые выполня ют "черновую" работу. Можно сказать, что перечисленные задачи убирают за агентами репликации. Например, эти задачи удаляют ненужные строки из базы данных D i s t r i b u t i o n, не позволяя ей разрастаться до необъятных размеров.

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

П Agent History Clean Up: Distribution запускается каждые 10 минут и выполня ет удаление из базы данных распределения информацию о ходе работы аген тов репликации. Удаляется вся информация, которая храниться более 48 часов.

• Distribution Clean Up: Distribution запускается каждые 10 минут и удаляет из базы данных распределения информацию о всех транзакциях, которые были скопированы подписчиками.

• Expired Subscription Clean Up запускается каждый день в час ночи и деакти вирует все подписки, которые не были синхронизированы в течение указан ного при создании публикации максимального периода ожидания.

• Reinitialize Subscriptions Having Data Validation Failures — это задание не име ет расписания для автоматического запуска, однако активно и может быть с успехом запущено вручную. Рассматриваемое задание предназначено для по вторной инициализации подписчиков, на которых обнаружено нарушение целостности данных.

О Replication Agents Checkup осуществляет поиск агентов репликации, которые не запускались длительное время. Задание стартует каждые 10 минут и по могает администратору своевременно обнаружить сбои в работе агентов реп ликации.

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

) ( Замечание Механизмы репликации должны быть установлены отдельно после инсталляции SQL Server 2000. Репликация не является часто применяемым инструментом, по этому программа установки SQL Server 2000 не включает ее в систему. Чтобы ини циализировать механизмы репликации, достаточно вызвать один из мастеров реп ликации. SQL Server 2000 обнаружит, что система репликации не установлена и автоматически выполнит все необходимые действия. После этого на сервере доба вится база данных D i s t r i b u t i o n, а в консоли Enterprise Manager— папка Replication Monitor.

Рассмотрим подробно назначение и работу каждого из агентов.

582 Часть III. Администрирование Агент Snapshot Agent Основное предназначение агента Snapshot Agent заключается в создании файлов моментальных снимков (snapshot file). Моментальные снимки представляют со бой полную копию данных, выбранных для публикации, в конкретный момент времени. Моментальные снимки используются в каждом типе репликации.

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

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

( Замечание ^ Для каждой публикации SQL Server 2000 применяет индивидуальный Snapshot Agent.

Агент Snapshot Agent реализован в виде утилиты snapshot.exe, которая имеет следующий синтаксис:

snapshot -Publisher..

-PublisherDB..

-Publication..

[-ReplicationType 1|2] [-Distributor..] [-DistributorSecurityMode 0|l] [-DistributorLogin..] [-DistributorPassword..] [-PublisherSecurityMode 0|l] [-PublisherLogin..] [-PublisherPassword..] [-MaxBcpThreads..] [-BcpBatchSize..] [-HistoryVerboseLevel 0|l|2|3] [-RowDelimiter..] [-FieldDelimiter..] [-70Subscribers] [-ProfileName] [-DynamicFilterLogin..] [-DynamicFilterHostName..] [-DynamicSnapshotLocation..] [-Continuous] Глава 14. Репликация данных [-Output..] [-OutputVerboseLevel 0|l|2], [-LoginTimeout..] [-QueryTimeout..] [-DefinitionFile..] Мы не будем рассматривать назначение каждого из параметров утилиты snapshot.exe, т. к. это займет слишком много места. В разд. "Запуск агентов" да лее в этой главе будет подробно рассмотрен принцип запуска агентов реплика ции. Сейчас же скажем, что агент Snapshot Agent по умолчанию запускается раз в неделю и обновляет файлы моментальных снимков. В принципе, владея син таксисом утилиты snapshot.exe, можно инициировать процесс создания момен тальных снимков из командной строки. Однако, более удачным способом будет принудительный запуск задания службы SQLServerAgent, реализующего запуск данного агента. Также можно сконфигурировать его запуск как реакции на ге нерирование сообщения об ошибке SQL Server, что позволит инициировать об новление файлов моментальных снимков из хранимых процедур, триггеров, функций и т. д. Для реализации этой возможности следует всего-навсего в свойствах соответствующего задания на вкладке Schedules определить оповеще ние, реагирующее на нужное сообщение об ошибке.


Агент Log Reader Agent Агент Log Reader Agent является основой репликации транзакций (Transactional Replication), запускается на дистрибьюторе и подключается к издателю. Затем он сканирует публикуемые таблицы и отслеживает строки, которые были изме нены со времени последнего подключения. Эти строки отмечаются как обрабо танные И КОПИРУЮТСЯ В базу данных распределения Distribution. Из базы Dis t r i b u t i o n информация затем распространяется всем подписчикам.

( Замечание ^ Как и в случае со Snapshot Agent, для каждой публикации используется индивиду альный Log Reader Agent.

Агент Log Reader Agent реализован в виде утилиты logread.exe, которая имеет следующий синтаксис:

logread - P u b l i s h e r..

-PublisherDB..

[-KeepAliveMessagelnterval..] [-PublisherSecurityMode 0 | l ] [-PublisherLogin..] [-PublisherPassword..] [ - D i s t r i b u t o r..] [-DistributorSecurityMode 0 | l ] [-DistributorLogin..] [-DistributorPassword..] [-Buffers..] [-SyncLogging] Часть III. Администрирование [-HistoryVerboseLevel 0|l|2] [-PacketSize..] [-ReadBatchSize..] [-ReadBatchThreshold..] [-Pollinglnterval ••] [-Messagelnterval.-] [-Continuous] [-Output..] [-OutputVerboseLevel 0|l|2] [-LoginTimeout.. ] [-QueryTimeout.. ] [-DefinitionFile..] Агент Queue Reader Agent В одном из предыдущих разделов этой главы было сказано, что в SQL Server 2000 появилась новая технология, позволяющая выполнять изменение данных на подписчиках — отложенное изменение (Queue Updating). Работа этой технологии базируется на помещении выполненных на подписчике изменений в специальную очередь (queue). Информация в эту очередь отправляется всеми серверами-подписчиками каждый раз, когда работающие на них пользователи вносят изменения в опубликованные данные.

Сделанные на подписчиках изменения должны быть отображены на издателе и других подписчиках. То есть необходимо забрать у каждого подписчика инфор мацию об изменениях, обработать ее и сделать доступной всем другим участни кам репликации. Эти функции и выполняет агент Queue Reader Agent.

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

Агент Queue Reader Agent реализован в виде утилиты qrdrsvc.exe, имеющей сле дующий синтаксис:

Qrdrsvc [-Distributor local-machine-name] [-DistributionDB distribution_database] [-DistributorLogin distributor_login] [-DistributorPassword distributor_password] [-DistributorSecurityMode 0-l] [-ResolverState l-3] [-HistoryVerboseLevel 0-3] [-Pollinglnterval 0-240 seconds] [-Continuous] [-Output..] [-OutputVerboseLevel 0|l|2] Глава 14. Репликация данных [-LoginTimeout..] [-QueryTimeout..] [-DefinitionFile..] Агент Distribution Agent Назначение агента Distribution Agent состоит в распространении изменений, собранных агентами Snapshot Agent и Log Reader Agent. Агент Distribution Agent подключается к подписчику и копирует ему данные из моментальных снимков И И базы данных D i s t r i b u t i o n.

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

Место запуска Distribution Agent зависит от метода обновления подписчика. При репликации по запросу (pull replication) агент запускается на подписчике. Когда же используется принудительная репликация (push replication), то старт агента выполняется на дистрибьюторе.

Агент Distribution Agent реализован в виде утилиты distrib.exe, имеющей сле дующий синтаксис:

distrib -Publisher.. -PublisherDB.. -Subscriber..

[-Publication..] [-SubscriptionType 0-2] [-SubscriberDB -..] [-SubscnberSecurityMode 0 I 1] [-SubscriberLogin..} [-SubscriberPassword -.] [-SubscriberType 0-2l [-SubscriberDatabasePath.. j [-Distributor.. ] [-DistributorSecurityMode 0I 1] [-DistributorLogin..] [-DistributorPassword..] [-DistributorNetwork..] [-DistributorAddress..) [-FileTransferType 0|l] [-FtpAddress..J [-FtpPort..] [-FtpOserName..] [-FtpPassword..] [-TransactionsPerHistory..] [-CommitBatchSize..] [-CommitBatchThreshold...] [-MaxDeliveredTransactions..] [-BcpBatchSize..] [-SubscriptionTableName..] [-ErrorFile..] [-MaxBcpThreads..] Часть III. Администрирование [-UselnprocLoader] [-NoTextInitOnSync] [-Buffers] [-Quotedldentifier..] [-HistoryVerboseLevel O|1|2I3] [-ProfileName..] [-KeepAliveMessagelnterval..] Г-AltSnapshotFolder..] -SkipErrors] L [-Hostname] [-OseDTS] [-PacketSize..] [-Pollinglnterval..] [-Messagelnterval..] [-Continuous] [-Output..] [-OutputVerboseLevel 0ll|2] [-LoginTimeout..] [-QueryTimeout..] [-DefinitionFile..] Агент Merge Agent Агент Merge Agent применяется исключительно при работе с репликацией сведе нием (merge replication). Это самый сложный тип репликации, появившийся в SQL Server 7.0. В более ранних версиях ничего подобного не было. Репликация сведением позволяет изменять данные не только издателю, но и подписчикам.

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

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

Кроме того, агент Merge Agent решает конфликты изменения, неизбежные при таком способе внесения исправлений в данные. Агент собирает модифициро ванные строки с подписчиков и издателя и помещает их в базу D i s t r i b u t i o n.

Если в один момент времени имеется более одного состояния для одной и той же строки (строка была изменена на нескольких серверах), то возникает кон фликт изменения. Агент должен решить, какое изменение имеет право "на жизнь", а какое должно быть потеряно. Это заключение дается на основе шкалы Глава 14. Репликация данных приоритетов. Изменения, сделанные сервером с более высоким приоритетом, остаются, остальные теряются.

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

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

Агент Merge Agent подключается как к издателю, так и ко всем подписчикам.

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

Агент Merge Agent реализован в виде утилиты replmerg.exe, имеющей синтаксис:

replmerg -PublisherDB.. -Subscriber..

-SubscriberDB.. -Publication..

[-Hostname..] [-Pollinglnterval in seconds] [-Validatelnterval in minutes] [-SubscriptionType 0|l|2] [-SubscriberConflictClean 0|l] [-PublisherSecurityMode 0|l] [-PublisherLogin..] [-PublisherPassword..] [-SubscriberSecurityMode 0|l] [-SubscriberLogin..] [(-SubscriberPassword I -SubscriberEncryptedPassword)..] [-SubscriberType 01112 I 31 4 I 5 I 61718] [-Validate 0|l|2|3] [-FastRowCount 0|l] [-HistoryVerboseLevel 0|l|2|3] [-ProfileName..] [-MaxBcpThreads..] [-UselnprocLoader] [-interactiveResolution 0|l] [-KeepAliveMessagelnterval..] [-SrcThreads..] [-DestThreads..] [-ForceConvergenceLevel 0|l] [-InputMessageFile..J [-InputMessageFromPublisher 0|1] [-OutputMessageFile..] [(-Distributor..) I (-DistributorNetwork.. -DistributorAddress..]) [-DistributorSecurityMode 0|l] [-DistributorLogin..] 588 ^ Часть III. Администрирование [(-DistributorPassword I -DistributorEncryptedPassword)..] [-MaxDownloadChanges..] [-MaxUploadChanges..] [-UploadGenerationsPerBatch..] [-DownloadGenerationsPerBatch..] [-UploadReadChangesPerBatch..] [-DownloadReadChangesPerBatch..] [-UploadWriteChangesPerBatch..] [-DownloadWriteChangesPerBatch..] [-SubscriberDBAddOption 0|l1213] [-SubscriberDatabasePath..] [-FileTransferType 0|l] [-FtpAddress..] [-FtpPort..] [-FtpUserName..] [-FtpPassword..] [-ExchangeType 1|2|3] [-AltSnapshotFolder..] [-SyncToAlternate 0|l] [-DynamicSnapshotLocation..] [-Continuous] [-Output..] [-OutputVerboseLevel 0|l|2] [-LoginTimeout..] [-QueryTimeout..] [-DefinitionFile..] Запуск агентов Агенты репликации запускаются с помощью заданий службы SQLServerAgent.

Следовательно, они будут иметь те же права доступа к данным, что и учетная запись, под которой стартует SQLServerAgent. Чтобы избежать проблем с раз граничением доступа, можно запускать службу SQLServerAgent под той же учет ной записью, что и службу MSSQLServer. Перед началом процесса репликации следует убедиться, что служба SQLServerAgent запущена. Рекомендуется устано вить автоматический запуск этой службы при каждом запуске операционной системы. Однако указанные проблемы возникают, если агенты репликации ис пользуют аутентификацию Windows NT. Однако агенты также могут устанавли вать соединение и с помощью аутентификации SQL Server, что позволяет пре доставлять им права, отличные от прав службы SQLServerAgent.

Если посмотреть содержимое папки Management\SQL Server Agent\Jobs (рис. 14.1) на сервере, участвующем в репликации данных, то можно будет уви деть, что на нем имеется ряд заданий, относящихся к одной из категорий REPL.

Эти задания как раз и реализуют работу агентов репликации.

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

На рис. 14.2 приведено окно свойств задания STORAGE-pubs-1, обеспечиваю щего работу агента Log Reader Agent.

Глава 14. Репликация данных уг*А*ГЛ^**Х**ГЛГЧуу^Я-Л*?

Рис. 1 4. 1. Папка Management's SQL Server AgentXJobs при использовании репликации Рис. 14.2. Вкладка General окна свойств задания Интерес на вкладке Genera] представляет только категория, к которой относится задание — REPL-LogReader. В принципе, сам по себе выбор категории не играет Глава 14. Репликация данных Agent. Впоследствии по подобным записям можно восстановить ход работы агентов репликации. В принципе, если вы не хотите оставлять следов, можно удалить первый шаг задания.

Рис. 14.4. Окно свойств первого шага, вкладка General Перейдя на вкладку Advanced (рис. 14.5), можно посмотреть, какое действие бу дет выполнено после завершения выполнения шага. Как видно, независимо от результата выполнения первого шага будет запущен второй шаг.

Рис. 14.5. Окно свойств первого шага, вкладка Advanced 592 Часть III. Администрирование Рассмотрим же теперь свойства второго шага задания (рис. 14.6). Этот шаг име ет тип Replication Transaction-Log Reader. Особенностью шагов этого типа явля ется то, что они запускают утилиту командной строки logread.exe, реализующую агента Log Reader Agent. Текст, приведенный в поле Command, является ничем иным как ключами запуска этой утилиты, с помощью который указывается конкретный набор действий и их параметры, подлежащие выполнению агентом.

Полный синтаксис вызова утилиты logread.exe будет дан ниже при описании агента Log Reader Agent.

Р и с. 1 4. 6. Окно с в о й с т в в т о р о г о ш а г а, вкладка G e n e r a l Перейдя на вкладку Advanced (рис. 14.7) можно увидеть, что в случае успешного завершения работы утилиты logread.exe (поле On success action) работа всего за дания завершится и будет возвращен код успешного завершения задания (значение Quit the job reporting success). В случае неудачного завершения шага (поле On failure action) будет выполнен следующий шаг (значение Goto the next step). Однако перед этим будет предпринято 10 попыток (поле Retry attempts) выполнения утилиты с интервалом в одну минуту (поле Retry interval (minutes)).

В завершение рассмотрим свойства третьего шага задания (рис. 14.8), который, как уже стало ясно, выполняется лишь в случае неудачного выполнения всех 10;

попыток запуска утилиты logread.exe. Как видно из рисунка, шаг имеет тип Transact-SQL Script (TSQL) и представляет собой выполнение недокументиро ванной системной хранимой процедуры sp_MSdetect_nonlogged_shutdown, ко торая вносит соответствующую запись в базу данных распределения о неудач ном завершении запуска агента Log Reader Agent.

На вкладке Advanced (рис. 14.9) можно увидеть, что независимо от результата выполнения указанной хранимой процедуры работа всего задания будет завер шена с выдачей кода неудачного выполнения.

Глава 14. Репликация данных Рис. 14.7. Окно свойств второго шага, вкладка Advanced Рис. 14.8. Окно свойств третьего шага, вкладка General На этом рассмотрение шагов задания, реализующего работу агента Log Reader Agent, можно считать оконченным. Как видно, для запуска собственно агента достаточно одного шага. Два же других шага являются вспомогательными для отображения в журнале репликации хода работы ее агентов. На основе этой ин формации впоследствии можно будет увидеть, как часто запускались агенты, в какой последовательности и с каким результатом.

20* 594 Часть III. Администрирование Рис. 14.9. Окно свойств третьего шага, вкладка Advanced Рис. 1 4. 1 0. Вкладка S c h e d u l e s окна свойств задания Интерес также представляет и время запуска агента Log Reader Agent. Для полу чения этой информации необходимо в окне свойств задания перейти на вкладку Schedules (рис. 14.10). Как видно, для задания определено всего одно расписа ние запуска. В столбце Description можно просмотреть расписание запуска зада ния. Как видно, задание запускается каждый раз при старте службы SQLServerAgent (Start automatically when SQL Server Agent Starts). Запушенное однажды, оно загружает утилиту logread.exe, которая в дальнейшем функциони рует как самостоятельный процесс операционной системы. Таким образом, нет Глава 14. Репликация данных нужды запускать агента каждый раз, когда необходимо обновить данные. От крыв менеджер задач (Task Manager) и перейдя на вкладку Processes (рис. 14.11), можно заметить, что утилита logread.exe находится в оперативной памяти. Там же можно увидеть, какой ее объем используется этой утилитой.

Рис. 14.11. Вкладка Processes менеджера задач с Замечание Открыть менеджер задач можно с помощью комбинации клавиш Ctrl+Shift+ +Esc, или нажав в свободной части панели задач правую кнопку мыши и в от крывшемся контекстном меню выбрать пункт Task Manager. Можно также нажать комбинацию клавиш Ctrl+Alt+Del и воспользоваться кнопкой Task Manager.

Отметим, что указанные действия относятся только к операционным системам Win dows NT 4.0 и Windows 2000.

Замечание На рис. 14.11 отлично видно, что в памяти также постоянно находятся и другие аген ты — Distributor Agent (distrib.exe) и Queue Reader Agent (qrdrsvc.exe). Агент Merge Agent (replmerg.exe) не присутствует в памяти, т. к. не сконфигурирована реплика ция сведением. Агент Snapshot Agent выгружается из памяти сразу же после того, как выполнит создание моментальных снимков. По умолчанию он запускается каж дую субботу в 23:33.

На этом рассмотрение задачи, выполняющей запуск агента Log Reader Agent, можно считать оконченным. Вкладка Notifications при автоматическом создании 596 Часть III, Администрирование задания средствами мастеров поддержки репликации не конфигурируется. Од нако, если вы хотите извещать какого-то оператора о неудачном запуска агента, то ничто не мешает сделать этого.

Мы на примере агента Log Reader Agent объяснили общие принципы запуска агентов репликации. Конфигурирование других агентов не имеет особых отли чий, поэтому мы не будем их рассматривать.

Типы репликации В предыдущих разделах мы уже упоминали типы репликации. В этом разделе будет дана исчерпывающая информация о принципах их работы. Система реп ликации SQL Server 2000 предоставляет пользователям и администраторам по^ трясающие возможности распространения и объединения данных среди множе ства систем хранения и обработки данных.

В SQL Server 2000 применяются три следующих базовых типа репликации:

О Snapshot Replication — репликация моментальных снимков;

О Transactional Replication — репликация транзакций;

• Merge Replication — репликация сведением.

Между перечисленными типами существует довольно значительная разница.

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

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

• Immediately-Update Subscribers — подписчики незамедлительного обновления;

• Queue Updating — отложенное обновление.

Замечание Напомним, что технология отложенного обновления является нововведением SQL Server 2000 и недоступна в SQL Server 7.0.

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

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

Глава 14. Репликация данных Репликация моментальных снимков Начнем знакомство с типами репликации с самого простого — репликации момен тальных снимков (Snapshot Replication). Свое название этот тип репликации полу чил за метод, которым данные распространяются подписчикам. Для тиражирова ния данных используются так называемые моментальные снимки (snapshot).

Моментальный снимок представляет собой полную копию данных издателя.

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



Pages:     | 1 |   ...   | 14 | 15 || 17 | 18 |   ...   | 33 |
 





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

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