ship transaction log что это
Километры логов и восстановление баз данных на MS SQL
Или как без труда восстанавливать базы данных из длинной цепочки бэкапов
Введение
Если вы используете SQL Server, то, вероятно, слышали про Полную и Простую модель восстановления баз данных. Вы, возможно, знаете, что Простая модель позволяет восстановить данные только на момент создания резервной копии, в то время как Полная — на любой момент времени, надо лишь регулярно делать резервные копии журнала транзакций. Однако, для восстановления данных при Полной модели потребуется «накатить» резервные копии журналов транзакций в определенной последовательности. Это можно без проблем сделать с помощью SSMS, но только на том SQL Server, где создавались резервные копии. Для восстановления на другом сервере потребуется вручную написать T-SQL скрипт. И чем длиннее будет цепочка резервных копий, тем больше будет сам скрипт и тем больше времени уйдет на его создание. По этой же причине администраторы редко используют уже созданные резервные копии, когда требуется развернуть копию базы на другом SQL Server, и предпочитают создавать свежий полный бэкап. Но такая процедура может быть настоящей проблемой для больших баз данных из-за высокой нагрузки на сервер. Кроме этого, если сервер «упал», то, как правило, нет времени писать длинный T-SQL скрипт для восстановления. В такие моменты нужно делать все максимально быстро и без лишней нервотрепки.
В интернете, в том числе и на Хабре (например, тут), можно найти различные способы, решающие задачу автоматизированного построения T-SQL скрипта восстановления. В основном это различные скрипты, базирующиеся на названиях файлов резервных копий или запросы на сервер-источник к истории резервных копий (к базе msdb). В этой статье я хотел бы сделать обзор возможностей XML-планов восстановления, которые появились в Quick Maintenance & Backup for MS SQL начиная с версии 1.6.
Обзор самой утилиты можно почитать в статье по этой ссылке или на официальном сайте. Наличие XML-плана восстановления в сетевой папке вместе с резервными копиями позволит не тратить время на подготовку T-SQL скрипта. Какая бы длинная ни была цепочка резервных копий, вы в несколько кликов восстановите базу данных на другом SQL Server. Также это можно делать по расписанию, на тестовом или рабочем сервере, например, для проверки всей цепочки резервных копий или актуализации копий баз данных.
Что такое XML-план восстановления
XML-план восстановления — это XML-файл, в котором перечислены имена файлов резервных копий в последовательности, необходимой для восстановления одной или нескольких баз данных. Пример содержимого XML-файла:
XML-файл всегда размещается в корневой папке с резервными копиями и содержит относительные пути до файлов резервных копий. Такая организация позволяет не терять актуальность после копирования файлов в другое место, например, в сетевую папку.
Создание XML-плана
Программа позволяет создавать XML-план двумя способами:
Перед созданием XML-файла программа определит последовательность резервных копий по информации, хранимой в системной базе mdsb, аналогично тому, как это делает SQL Server Management Studio. Для первого и второго способов XML-план будет содержать последовательность резервных копий, необходимых для восстановления базы данных на последнее возможное состояние.
Важной особенностью является то, что при создании XML-плана программа всегда выполняет проверку наличия файлов резервных копий. Если хотя бы один из файлов не будет найден, то программа выдаст ошибку. Таким образом дополнительно контролируется целостность всей цепочки. Если XML-план создается при помощи задачи, то можно автоматически скопировать недостающие резервные копии с сервера источника. Для этого в задаче нужно установить соответствующий признак.
Восстановление по XML-плану
Восстановление баз данных по XML-плану может выполняться двумя способами:
1. Вручную. Для этого в программе имеется специальное окно, которое вызывается командой «Восстановить по XML-плану» из контекстного меню в древовидном списке серверов.
На форме нужно выбрать XML-файл и базы данных, резервные копии которых будут восстановлены. Обратите внимание, восстанавливать можно в одноименные базы данных, во временную, либо в указанную базу данных. Режим восстановления во временную базу данных удобен для проверки цепочки резервных копий. Режим в Указанную базу данных может быть полезен, если требуется восстановить в определенную базу данных, например, с нестандартным размещением её файлов на дисках. По кнопке «Показать Т-SQL» можно просмотреть сформированный T-SQL скрипт, который будет запущен для восстановления.
2. Автоматически по заданному расписанию. Например, если требуется регулярная проверка цепочки резервных копий на тестовом SQL Server, или актуализация баз данных. Для этих целей в программе предусмотрена специальная задача. Параметры, указываемые в задаче, практически аналогичны тем, что задаются на форме восстановления в ручном режиме.
Для того чтобы задача выполнялась по расписанию, её необходимо включить в сценарий. Например, в ночной. Подробный лог восстановления можно просматривать в журнале обслуживания.
Заключение
Механизм XML-планов восстановления в QMB — это отличная возможность, позволяющая значительно облегчить жизнь администраторам при восстановлении данных с километровыми логами, переносе баз на другой SQL Server и проверке бэкапов. Механизм можно задействовать даже в тех случаях, когда для резервного копирования используется стандартный План обслуживания. В дальнейшем мы планируем подготовить статью, о том как это сделать с помощью программы.
Ship transaction log что это
Доставка журналов (log shiiping) в SQL Server 2005: настройка, режим доставки журналов без восстановления работоспособности (NoRecovery mode), режим доставки журналов в режиме горячей готовности (standby mode)
В предыдущей версии SQL Server для настройки доставки журналов использовался Database Maintenance Plan Wizard — мастер настройки планов обслуживания баз данных. В SQL Server 2005 планы обслуживания баз данных не имеют к доставке журналов никакого отношения. Настройка доставки журналов производится из вкладки Transaction Log Shipping (Доставка журналов транзакций) свойств базы данных (рис. 7.1). Эту вкладку можно открыть также из контекстного меню базы данных при помощи команды Tasks | Ship Transaction Logs (Задачи | Доставлять журналы транзакций).
Рис. 7.1. Экран настройки доставки журналов
Остановимся на возможностях настройки доставки журналов:
q нажатие на кнопку Backup Settings (Настройки резервного копирования) приведет к открытию еще одного диалогового окна Transaction Log Backup Settings (Настройки резервного копирования журнала транзакций), в котором вы сможете настроить параметры резервного копирования журнала транзакций основной базы данных. Следующие параметры настраиваются именно из этого окна;
q Network path to backup folder (Сетевой путь к каталогу резервного копирования) и Local path to the folder (Локальный путь к каталогу) — соответственно, сетевой и локальный пути к каталогу, в который будут помещаться резервные копии журналов транзакций. Служба SQL Server Agent вторичного сервера будет забирать файлы резервных копий из этого каталога. Если вы решили помещать резервные копии сразу на сетевой сервер, то поле с локальным путем можно оставить пустым.
Обратите внимание, что если основной сервер работает от имени локальной учетной записи, он не сможет обращаться к сетевым каталогам на другом компьютере. В этом случае вам обязательно потребуется указать локальный путь для резервных копий журналов транзакций;
q Delete files older than (Удалять файлы, старше чем) — этот параметр позволяет указать срок (дату), по истечении которого файлы журналов транзакций будут удалены (по умолчанию 3 дня). Даже успешно скопированные и восстановленные файлы журналов транзакций все равно будут оставаться в исходном каталоге в течение указанного времени. То, что они не удаляются сразу, связано с тем, что для одного первичного сервера можно настроить доставку журналов на несколько вторичных;
После того, как вы закончите настройку параметров резервного копирования журналов транзакций и нажмете кнопку OK на вкладке Transaction Log Shipping окна свойств базы данных, вам потребуется настроить параметры восстановления резервных копий на сервере-получателе. Для этого надо нажать кнопку Add (Добавить) под списком Secondary server instances and databases (Вторичные экземпляры серверов и базы данных) на той же вкладке. В открывшемся окне Secondary database settings (Параметры вторичных баз данных) вам потребуется определить следующие параметры:
q Secondary server instance (Вторичный экземпляр сервера) — тот сервер, на котором будут восстанавливаться резервные копии журнала транзакций;
q Secondary database (Вторичная база данных) — та база данных, для которой будет производиться восстановление копий журналов транзакций. Можно не только выбрать имя существующей базы данных, но и вписать новое имя. В этом случае базу данных можно будет создать автоматически.
В том же окне при помощи вкладки Initialize Secondary Database (Инициализировать вторичную базу данных) вам придется определиться, как именно будет создана вторичная база данных. В вашем распоряжении три варианта:
Самый простой и надежный вариант — первый, когда копия основной базы данных создается автоматически. Второй и третий варианты имеет смысл выбирать только в специальных ситуациях, например, когда основная база данных очень большая или когда падение производительности, вызванное резервным копированием, недопустимо.
На вкладке Copy Files (Копирование файлов) вы определяете параметры копирования файлов резервных копий журналов транзакций:
q Destination folder to copied files (Каталог назначения для скопированных файлов) — удобнее всего здесь указать просто локальный каталог на вторичном сервере. Но если это противоречит каким-то правилам безопасности, можно указать и сетевой каталог на файл-сервере;
q Delete copied files after (Удалять скопированные файлы после) — скопированные файлы будут удалены только через указанное здесь количество часов (даже если восстановление этих резервных копий прошло успешно). По умолчанию задано также 3 суток (72 часа);
На вкладке Restore Transaction Log (Восстановление журналов транзакций) вы можете настроить параметры восстановления резервных копий журналов транзакций:
q Database state when restoring databases (Состояние базы данных при восстановлении) — это очень важный параметр, который определяет, будет ли база данных открываться для пользователей. В вашем распоряжении два варианта:
· No recovery mode (Режим без восстановления работоспособности) — база данных открываться для пользователей не будет;
· Standby mode (Режим «горячей готовности») — база данных будет открыта в режиме «только чтение». Однако понятно, что если к базе данных подключены пользователи, восстановление журналов транзакций производиться не будет. Поэтому вы можете или смириться с задержками при восстановлении, или принудительно отключать пользователей при восстановлении, установив флажок Disconnect users in the database when restoring backups (Отсоединять пользователей от базы данных при восстановлении резервных копий).
q Delay restoring backups at least (Отложить восстановление базы данных по крайней мере на) — этот параметр дает возможность определить задержку перед восстановлением резервной копии. По умолчанию задано без задержки;
q Restore Job (Задание восстановления) — можно выбрать имя и расписание для задания, которое будет заниматься восстановлением резервных копий журналов транзакций.
После того, как настройка вторичного сервера будет завершена, вам останется только вернуться в окно свойств основной базы данных и настроить параметры сервера мониторинга. В принципе, можно обойтись и без сервера мониторинга, но производить диагностику поставок журналов без информации, которая накапливается в таблицах этого сервера, намного сложнее. Включить такой сервер можно при помощи флажка Use a monitor server instance (Использовать экземпляр сервера мониторинга). Затем при помощи кнопки Settings (Параметры) вам потребуется настроить дополнительные параметры сервера мониторинга:
q Monitor server instance (Экземпляр сервера мониторинга) — этот параметр позволяет выбрать сервер, который будет отслеживать доставку журналов;
q Monitor connections (Отслеживать соединения) — определяет, как именно задания, которые выполняют резервное копирование, копирование по сети и восстановление, будут «отчитываться» перед сервером мониторинга (т. е. заносить информацию в его таблицы):
Если переключатель Monitor connections установлен в это положение, то этой учетной записи нужно предоставить права на запись информации в таблицы на сервере мониторинга;
q Delete history after (Удалять историю после) — через сколько дней будут удаляться старые записи из таблиц мониторинга. По умолчанию определено, что через четыре дня;
q Alert job (Задание для оповещения) — этот параметр позволяет настроить задание, которое будет выполняться на сервере мониторинга и опрашивать основной и резервный сервера на предмет появления каких-либо проблем с доставкой журналов. Обратите внимание, что опрос по умолчанию производится каждые две минуты, что может повлиять на производительность работы сервера мониторинга.
About Log Shipping (SQL Server)
SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a primary server instance to one or more secondary databases on separate secondary server instances. The transaction log backups are applied to each of the secondary databases individually. An optional third server instance, known as the monitor server, records the history and status of backup and restore operations and, optionally, raises alerts if these operations fail to occur as scheduled.
In this Topic:
Benefits
Provides a disaster-recovery solution for a single primary database and one or more secondary databases, each on a separate instance of SQL Server.
Supports limited read-only access to secondary databases (during the interval between restore jobs).
Allows a user-specified delay between when the primary server backs up the log of the primary database and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly, a delay can let you retrieve still unchanged data from a secondary database before the change is reflected there.
Terms and Definitions
primary server
The instance of SQL Server that is your production server.
primary database
The database on the primary server that you want to back up to another server. All administration of the log shipping configuration through SQL Server Management Studio is performed from the primary database.
secondary server
The instance of SQL Server where you want to keep a warm standby copy of your primary database.
secondary database
The warm standby copy of the primary database. The secondary database may be in either the RECOVERING state or the STANDBY state, which leaves the database available for limited read-only access.
monitor server
An optional instance of SQL Server that tracks all of the details of log shipping, including:
When the transaction log on the primary database was last backed up.
When the secondary servers last copied and restored the backup files.
Information about any backup failure alerts.
Once the monitor server has been configured, it cannot be changed without removing log shipping first.
backup job
A SQL Server Agent job that performs the backup operation, logs history to the local server and the monitor server, and deletes old backup files and history information. When log shipping is enabled, the job category «Log Shipping Backup» is created on the primary server instance.
copy job
A SQL Server Agent job that copies the backup files from the primary server to a configurable destination on the secondary server and logs history on the secondary server and the monitor server. When log shipping is enabled on a database, the job category «Log Shipping Copy» is created on each secondary server in a log shipping configuration.
restore job
A SQL Server Agent job that restores the copied backup files to the secondary databases. It logs history on the local server and the monitor server, and deletes old files and old history information. When log shipping is enabled on a database, the job category «Log Shipping Restore» is created on the secondary server instance.
alert job
A SQL Server Agent job that raises alerts for primary and secondary databases when a backup or restore operation does not complete successfully within a specified threshold. When log shipping is enabled on a database, job category «Log Shipping Alert» is created on the monitor server instance.
For each alert, you need to specify an alert number. Also, be sure to configure the alert to notify an operator when an alert is raised.
Log Shipping Overview
Log shipping consists of three operations:
Back up the transaction log at the primary server instance.
Copy the transaction log file to the secondary server instance.
Restore the log backup on the secondary server instance.
The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are duplicated for each secondary server instance.
A log shipping configuration does not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, any of the secondary databases can be brought online manually.
You can use a secondary database for reporting purposes.
In addition, you can configure alerts for your log shipping configuration.
A Typical Log Shipping Configuration
The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restorejobs, as follows:
The primary server instance runs the backup job to back up the transaction log on the primary database. This server instance then places the log backup into a primary log-backup file, which it sends to the backup folder. In this figure, the backup folder is on a shared directory-the backup share.
Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its own local destination folder.
Each secondary server instance runs its own restore job to restore the log backup from the local destination folder onto the local secondary database.
The primary and secondary server instances send their own history and status to the monitor server instance.
Interoperability
Log shipping can be used with the following features or components of SQL Server:
Always On availability groups and database mirroring are mutually exclusive. A database that is configured for one of these features cannot be configured for the other.