Презентация на тему Обеспечение доступности серверов БД

Server, синхронизируемый с основным сервером при помощи резервных копий

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

одной или нескольких БД, размещенных на основном сервере.
Для создания

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

к БД резервного сервера следует применить все последние резервные

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

транзакций можно архивировать с параметром NORECOVERY – при этом

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

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

к резервному серверу вместо основного.
На резервном сервере необходимо создать регистрационные записи пользователей:
создать на основном сервере сценарии, описывающие регистрационные записи, и затем выполнить их на резервном сервере;
воспользоваться конструктором DTS Designer и встроить в задание задачу DTS Transfer Logins, чтобы автоматизировать архивацию, копирование и восстановление системной таблицы sysxlogins с основного сервера на резервный.

создаются задания архивации, копирования и восстановления транзакций, которые SQL

Server Agent будет периодически выполнять на основном и резервном серверах.
Этот автоматизированный процесс называется распространением журнала.
Можно выделить третий сервер для наблюдения за ходом выполнения заданий распространения журнала на основном и резервном серверах.
Данные задания могут быть созданы с помощью Maintenance Plan Wizard.

на сервере наблюдателе в контейнере Management создается объект Log

Shipping Monitor. При выборе данного объекта раскроется список состояний всех серверов, участвующих в распространении журнала.
В столбце Last Backup отображается дата и время последней архивации журнала транзакций на основном сервере. В столбце Last Copy – дата и время последнего копирования архивного журнала в сетевую папку. В столбце Last Restore – дата и время последнего восстановления архивной копии журнала на резервном сервере. В столбце Status – состояние синхронизации.
Журналы архивации и восстановления можно просмотреть также на основном (View Backup History) и резервном (View Copy/Restore History) серверах.

системную хранимую процедуру sp_change_primary_role.
параметр @db_name позволяет указать нужную

БД,
параметр @backup_log – заархивировать журнал транзакций,
аргумент @terminate – откатить все незавершенные транзакции.
с помощью аргумента @fanal_state можно указать состояние восстановления БД после завершения хранимой процедуры – RECOVERY (по умолчанию), NO RECOVERY или STANDBY.
аргумент @access_level позволяет указать уровень доступа к БД после завершения хранимой процедуры – MULTI_USER (по умолчанию), RESTRICTED_USER или SINGLE_USER.

системную хранимую процедуру sp_change_secondary_role.
параметр @db_name позволяет указать нужную резервную

БД и преобразовать ее в основную;
параметр @do_load – применить к резервной БД имеющиеся архивные файлы журнала транзакций
аргумент @fanal_state можно указать состояние восстановления БД после завершения хранимой процедуры – RECOVERY (по умолчанию), NO RECOVERY или STANDBY
аргумент @access_level позволяет указать уровень доступа к БД после завершения хранимой процедуры – MULTI_USER (по умолчанию), RESTRICTED_USER или SINGLE_USER.

хранимую процедуру sp_change_monitor_role, чтобы обновить информацию о распространении журнала.
параметр

@primary_server позволяет указать заменяемый основной сервер;
параметр @secondary_server – заменяющий резервный сервер;
параметр @database – резервную БД, преобразуемую в основную;
параметр @new_source –сетевую папку, из которой новый сервер будет забирать файлы архивных копий журнала транзакций.

новом основном сервере есть все необходимые регистрационные записи.
Для этого

можно воспользоваться сценарием Transact-SQL системной хранимой процедурой sp_resolve_logins (предварительно с помощью задачи DTS Transfer Logins создается файл вывода утилиты bcp с учетными записями).
После выполнения данных процедур резервный сервер может работать в качестве основного. Старый основной сервер более не является участником пары распространения журнала.