Предназначенные для решения практических задач базы данных на платформе SQL Server становятся все объемнее; во многих корпоративных сетях такие базы вмещают по нескольку терабайтов информации. Одновременно отмечается тенденция консолидации сред SQL Server с целью сокращения затрат и предотвращения непроизводительного расходования ресурсов. Консолидированные среды состоят из нескольких баз данных на единственном экземпляре, из нескольких экземпляров на одном сервере или на виртуализованных серверах. В процессе эксплуатации этих особо крупных баз данных very large databases (VLDB) и консолидированных сред возникают специфические проблемы, касающиеся производительности и управления. Одна из них связана с необходимостью обеспечения эффективного восстановления данных после сбоев в соответствии с положениями соглашений об уровне обслуживания service level agreements (SLA) и с учетом заданных периодов обслуживания. Стремясь помочь потребителям в решении некоторых из упомянутых задач, корпорация Microsoft реализовала (сначала в пакете SQL Server 2008, Enterprise Edition, а затем и в SQL Server 2008 R2, Standard Edition) средства сжатия резервных копий. Эти средства позволяют существенно уменьшать размеры резервных копий и сокращать время восстановления данных в большинстве сетей.
При использовании средств сжатия сокращается объем дискового пространства, необходимого для хранения резервных копий, а следовательно, возрастает объем зарезервированных данных, которые можно поместить в локальные хранилища, снижаются требования к пропускной способности сети в процессе перемещения резервных копий из одного места в другое, сокращается объем ленточных носителей, используемых для хранения архивов вне компании, наконец, процедуры резервного копирования выполняются быстрее, что обеспечивает администраторам, осуществляющим резервное копирование в жестких рамках окон обслуживания, больше свободы для маневра. И что особенно важно, при использовании сжатых резервных копий быстрее завершается восстановление данных, которое часто приходится выполнять в нерабочее время в стрессовых ситуациях восстановления данных. Однако, если база данных содержит предварительно сжатые данные (например, файлы в формате BLOB, такие, как. pdf и. jpg), описанные выше достоинства нередко значительно уменьшаются и даже практически сходят на нет. Кроме того, при получении сжатых резервных копий возникает дополнительная нагрузка на процессор, что может, к примеру, обернуться серьезной проблемой в среде SharePoint.
. В прошлом администраторы баз данных неохотно брались за выполнение разностного резервного копирования, однако сейчас, когда базы данных становятся все объемнее, а выполнение условий соглашений об уровне обслуживания все более затрудняется, администраторам необходимо изучить данный метод копирования и применять его в своей работе. Чтобы помочь вам в этом деле, мы расскажем об идеях, лежащих в основе резервного копирования, а также остановимся на том, как снимать и восстанавливать разностные резервные копии и в каких ситуациях их использовать.
Что такое разностное резервное копирование?
Ключевым фактором при формировании эффективной стратегии разностного резервного копирования является способность уверенно оперировать базой разностного резервирования, или базовой копией для разностного копирования. Базовая копия для разностного копирования — это полная, состоящая из одного файла или из группы файлов резервная копия базы данных. Она необходима для получения разностных резервных копий. Для обеспечения уверенности в надежности базовой копии для разностного резервирования можно использовать такие параметры резервного копирования, как Checksum и Restore with Verify.
Существует два четко определенных типа разностных резервных копий: однобазовая копия (single-base) — разностная резервная копия на базе одной полной резервной копии — и многобазовая копия (multibase) — разностная резервная копия на базе резервных копий в виде файлов или групп файлов. Чаще всего используются однобазовые разностные резервные копии. Такие копии необходимо получать в базах данных, реализующих простую модель восстановления. Если вы попытаетесь создать многобазовую разностную копию, то получите сообщение об ошибке, и разностное резервное копирование завершится сбоем.
В базах данных, реализующих модель полного восстановления, можно выполнять как однобазовое, так и многобазовое разностное резервирование. Многобазовое разностное копирование можно выполнять и в базах данных, реализующих модель восстановления с неполным протоколированием и соответствующих определенным критериям. Однако многобазовые разностные копии характеризуются большой сложностью администрирования и обслуживания. По этой причине Microsoft при прочих равных условиях рекомендует воздерживаться от их использования (см. статью «Working with Multibase Differential Backups» по адресу http://msdn.microsoft.com/en-us/library/ms178046.aspx).
Разностные резервные копии не зависят от копий журналов транзакций и не влияют ни на порядок регистрационных номеров транзакций в журнале, ни на доставку журналов. Реализация разностных резервных копий может способствовать резкому сокращению числа необходимых восстановлений, поскольку объемы резервных копий журналов транзакций могут достигать внушительных размеров на протяжении одной недели. Восстановив разностную резервную копию, вы сможете быстрее привести базу данных в актуальное состояние.
Резервные копии copy-only никак не сказываются на снятии разностных резервных копий, поэтому мы можем смело использовать параметр WITH COPY_ONLY для получения полной резервной копии — управление обычными процедурами разностного резервного копирования при этом не будет нарушено. Полную резервную копию copy-only нельзя применять в качестве базовой копии для разностного копирования с целью восстановления.
В системе SQL Server дисковое пространство распределяется по непрерывным областям памяти на диске, экстентам (extent). Экстент — это восемь физически смежных страниц памяти по 8 Кбайт. В SQL Server на каждые 64 000 экстентов приходится одна разностная побитовая страница, именуемая интервалом глобальной таблицы распределения Global Allocation Map (GAM). В этой разностной побитовой странице на каждый экстент каждого GAM-интервала приходится один бит. В случае добавления или изменения данных в базе данных распределение экстентов изменяется. Изменение каждого экстента по сравнению с его состоянием на момент получения последней полной резервной копии влечет за собой присвоение соответствующему биту в разностной побитовой странице значения 1. И только после выполнения полной резервной копии все значения битов будут обнулены. При получении разностной резервной копии разностные побитовые страницы опрашиваются для выяснения, какие экстенты необходимо зарезервировать. Даже если изменения коснулись всего лишь одной страницы того или иного экстента, в разностной резервной копии будет зарезервирован весь экстент, содержащий эту страницу.
Выполнение разностного резервного копирования допускается в базах данных, реализующих модель полного восстановления, модель восстановления с неполным протоколированием либо простую модель восстановления, с правом доступа только для чтения, а также для чтения и записи. Разностное копирование выполняется на файлах данных FILESTREAM и в полнотекстовых каталогах (исключение составляют файлы системы FAT32), поэтому разностные копии могут эффективно применяться в самых разнообразных ситуациях, предусматривающих резервирование данных. Использование разностных резервных копий в главных базах данных не допускается.
Применение разностных копий может принести организации поистине неоценимые преимущества. Дело в том, что изменения, вносимые в базу данных в течение дня, редко касаются более чем 3–5% ее содержимого, поэтому файл разностной резервной копии (как в сжатом, так и в несжатом состоянии) намного меньше, чем полная резервная копия, причем размеры такого файла увеличиваются медленно.
Информация о разностных резервных копиях хранится в представлениях каталогов sys.database_files и sys.master_files. Если база данных предназначена только для чтения, обновлению подлежит лишь представление каталога sys.master_files.
Код в листинге 1 показывает время получения новейшей разностной базы для каждой базы данных, а также регистрационный номер транзакции в журнале, присвоенный такой базе. Этот код можно использовать для установления факта существования разностной базы, а также даты, когда она была получена, и для оценки того, подходит ли упомянутая разностная база для начала выполнения разностных резервных копий.
Данный код извлекает информацию из следующих столбцов sys.master_files:
- differential_base_lsn. Этот столбец содержит последний регистрационный номер LSN текущей резервной копии базы. Экстенты с данными, измененными после этого LSN, будут включены в следующую разностную резервную копию;
- differential_base_guid. Этот столбец содержит уникальный идентификатор текущей резервной копии базы, на котором будет основана следующая разностная резервная копия;
- differential_base_time. Этот столбец содержит дату и время создания текущей базовой резервной копии.
Если полная резервная копия соответствующей базы данных еще не была получена, упомянутым переменным будет присвоено значение NULL.
Как реализовать стратегию разностных резервных копий
В целях демонстрации процесса разностного резервного копирования мы решили создать однобазовую резервную копию базы данных, реализующей модель полного восстановления. На рисунке 1 представлена типичная стратегия резервного копирования, в соответствии с которой выполняется полная резервная копия, а также резервная копия журнала регистрации транзакций. Полная резервная копия формируется в автоматическом режиме раз в сутки в 18:00, а последующие копии журнала регистрации создаются раз в три часа. Таким образом, в течение 24-часового цикла создается один файл с полной резервной копией и семь файлов с копиями журнала регистрации транзакций.
.jpg) |
| Рисунок 1. Типичная стратегия резервного копирования |
.jpg) |
| Рисунок 2. Стратегия разностного резервного копирования |
Допустим, мы хотим изменить эту стратегию: вместо ежесуточных (кроме воскресенья) полных резервных копий создавать разностные копии, как показано на рисунке 2. Первый этап в реализации этой стратегии разностного резервного копирования состоит в создании базовой копии для разностного копирования с помощью команды BACKUP DATABASE:
BACKUP DATABASE Orders TO DISK='d: \backups\Orders.bak' WITH INIT
Далее необходимо выполнить инкрементные резервные копии журнала регистрации транзакций с помощью команды BACKUP DATABASE:
BACKUP LOG Orders TO DISK='d: \backups\Orders (x).trn' WITH INIT
В этой команде (x) обозначает уникальный постоянно растущий номер набора резервных копий журнала. Мы рекомендуем использовать уникальное, постоянно увеличивающееся число, так как при добавлении резервных копий в конец одного файла может возникнуть путаница, что увеличивает вероятность случайной записи данных поверх присоединенных резервных копий журналов.
И последний шаг — получение разностных резервных копий. Команду BACKUP DATABASE необходимо выполнять с параметром WITH DIFFERENTIAL:
BACKUP DATABASE Orders TO DISK='d: \backups\Orders_Diff.bak' WITH DIFFERENTIAL, INIT
Как восстанавливать разностные резервные копии
Чтобы продемонстрировать, как выполняется восстановление разностных резервных копий, предположим, что системный сбой произошел в 14:30 во вторник. Первое, что нужно делать в подобных случаях, — создать резервную копию заключительного фрагмента журнала; речь идет о резервной копии журнала регистрации, включающей ту часть журнала, которая не была зарезервирована ранее (эта часть известна как хвостовой фрагмент активной части журнала). В резервной копии заключительного фрагмента журнала усечение журнала не допускается; такие копии применяются, когда возникает необходимость вернуть базу данных в состояние на тот момент, когда произошел сбой.
Чтобы инициировать процедуру формирования резервной копии заключительного фрагмента журнала, выполните следующую команду:
BACKUP LOG Orders TO DISK='d: \backups\Orders_Tail.trn' WITH NO_TRUNCATE
Отметим, что получение резервной копии заключительного фрагмента журнала невозможно в случаях, когда база данных функционирует в соответствии с моделью восстановления с неполным протоколированием (BULK_LOGGED recovery model) и когда со времени предыдущего резервирования журнала регистрации была выполнена операция с минимальным протоколированием.
Далее, нужно восстановить полную резервную копию, для чего применяется команда RESTORE DATABASE с параметром NORECOVERY:
RESTORE DATABASE Orders FROM DISK='d:\backups\Orders.bak' WITH REPLACE, NORECOVERY
Параметр NORECOVERY открывает возможность для применения других резервных копий. Оптимальный метод состоит в следующем: параметр NORECOVERY используется в ходе каждого восстановления, а затем для перевода базы данных в оперативный режим применяется инструкция RESTORE с параметром RECOVERY.
При использовании этой команды с целью восстановления полной резервной копии применяется параметр REPLACE, который предписывает перезаписать новые сведения поверх существующей базы данных, но надо сказать, что применение указанного параметра в корпоративной среде может быть чревато самыми серьезными последствиями. В производственной среде мы рекомендуем восстанавливать резервную копию на новой базе данных; таким образом вы исключите возможность утраты базы данных в случае, если записываемая поверх нее резервная копия окажется поврежденной.
Теперь нам нужно восстановить последнюю разностную резервную копию (ту, что была создана в 18:00 в понедельник). Для этого используется команда RESTORE DATABASE с параметром NORECOVERY:
RESTORE DATABASE Orders FROM DISK='d: \backups\Orders_Diff.bak' WITH NORECOVERY
Выполнив эту задачу, мы можем восстановить резервные копии журнала регистрации транзакций, которые были созданы после разностной резервной копии. По условиям нашего примера, восстановлению подлежат резервные копии журнала, созданные в понедельник в 21:00, а также во вторник — в полночь, в 03:00, в 06:00, в 09:00 и в полдень. Резервные копии журнала регистрации транзакций можно восстановить с большей скоростью в среде SQL Server Management Studio (SSMS); дело в том, что она позволяет восстанавливать все резервные копии журналов за один проход. Код для запуска SSMS представлен в листинге 2. Как видите, для этого необходимо использовать команду RESTORE LOG с параметром NORECOVERY.
Теперь нам нужно восстановить резервную копию заключительного фрагмента журнала. Запустив команду RESTORE LOG с параметром NORECOVERY, мы возвращаем базу данных в состояние, в котором она находилась до момента сбоя (то есть во вторник в 14:30).
RESTORE LOG Orders FROM DISK='d:\backups\Orders_Tail.trn' WITH NORECOVERY GO
Наконец, мы можем перевести базу данных в оперативный режим с помощью инструкции RESTORE с параметром RECOVERY:
RESTORE DATABASE Orders WITH RECOVERY GO
В каких случаях используются разностные резервные копии
Многие администраторы баз данных неохотно применяют разностные резервные копии, поскольку не знают, в каких ситуациях лучше всего ими пользоваться. Представляем краткое руководство на первый случай; надеемся, оно поможет вам в принятии решений.
- Если ваши базы данных компактны или сжаты настолько эффективно, что размеры полных резервных копий, а также резервных копий журналов регистрации транзакций вполне вписываются в характеристики системы хранения данных и в ограничения, указанные в соглашении по уровню обслуживания, то разностные резервные копии вам не нужны.
- Если в промежутках между созданием очередных резервных копий в содержимое ваших баз данных вносится большое число изменений, вам стоит создавать полные резервные копии.
- Если изменений, вносимых в вашу базу данных, немного, а на восстановление резервных копий журналов транзакций уходит больше времени, чем на восстановление разностных резервных копий, использование разностных копий может иметь смысл, и такую возможность стоит рассмотреть.
Если у вас нет точных сведений о том, какая часть информации в ваших базах данных подвергается изменениям, вы можете получить такие сведения с помощью незадокументированной команды и сценария. Позднее вы сможете использовать полученные сведения для оценки размеров разностной резервной копии. Более подробная информация о незадокументированной команде и сценарии приведена во врезке «Определяем объем измененных данных».
Еще одна причина, побуждающая некоторых администраторов баз данных отказываться от использования разностных резервных копий, состоит в том, что последние могут осложнить процесс управления резервными копиями. Когда объем данных, подвергающихся изменению (а, следовательно, и объем разностных резервных копий), невозможно предсказать, труднее сделать заключение о том, что эффективнее — создавать полные резервные копии и резервные копии журналов регистрации транзакций или включать разностные копии.
Сравнительные достоинства разностных резервных копий
Чтобы определить эффективность процесса разностного резервного копирования, мы протестировали три сценария резервного копирования, обращая внимание на следующие факторы:
- объем дискового пространства, еженедельно необходимый для реализации соответствующей стратегии резервирования;
- максимальное число процедур восстановления, необходимых для приведения базы данных в состояние на момент сбоя.
Размер пользовательской базы данных, которую мы взяли для тестирования, составил 156 Гбайт. Ее содержимое резервировалось базовыми средствами SQL Server без сжатия. Отметим, что для каждого сценария ежедневная резервная копия журнала транзакций состояла из промежуточных резервных копий журнала транзакций, которые формировались с интервалом в три часа. Промежуточные резервные копии журнала транзакций сохранялись для восстановления на определенный момент времени. В каждом сценарии в процессе восстановления создавалась также резервная копия заключительного фрагмента журнала. В максимальное число необходимых процедур восстановления входит процесс восстановления резервной копии заключительного фрагмента журнала.
Ниже приводится информация по трем сценариям резервного копирования и по их результатам.
Сценарий резервного копирования 1. В этом сценарии мы включали в расписание ежедневное создание полных резервных копий, а также ежедневное создание резервных копий журнала транзакций каждые три часа; период хранения составлял семь дней. Как явствует из таблицы 1, текущая потребность в дисковом пространстве для данного сценария составляет 1336,5 Гбайт; по мере роста базы данных этот показатель будет увеличиваться. Однако максимальное число процедур восстановления остается неизменным.
| Таблица 1. Результаты выполнения сценария резервного копирования 1 |
.jpg) |
Сценарий резервного копирования 2. В этом сценарии мы включали в расписание еженедельное создание полных резервных копий, а также ежедневное создание резервных копий журнала транзакций каждые три часа; период хранения составлял семь дней. Как показано в таблице 2, потребность в дисковом пространстве невысока, его объем составляет 380 Гбайт. Поскольку полная резервная копия создается лишь один раз в воскресенье и сохраняется до следующего воскресенья, когда поверх нее будет записана новая копия, данный механизм не предполагает ежедневного увеличения объема используемого дискового пространства на 156 Гбайт. Однако время, необходимое для применения максимального числа процедур восстановления, обесценит выигрыш от сокращения объема дискового пространства.
| Таблица 2. Результаты выполнения сценария резервного копирования 2 |
.jpg) |
Сценарий резервного копирования 3. В этом сценарии мы включали в расписание еженедельное создание полных резервных копий, а также ежедневное создание разностных резервных копий и резервных копий журнала транзакций каждые три часа; период хранения составлял семь дней. Созданная в предыдущий день разностная резервная копия удаляется после успешного завершения формирования разностной резервной копии за текущий день и ее проверки. Как показано в таблице 3, использование разностных резервных копий обеспечивает сокращение процессов восстановления по сравнению со сценарием 2 и сокращение выделяемого для резервных копий дискового пространства по сравнению с ежедневными полными резервными копиями в сценарии 1.
| Таблица 3. Результаты выполнения сценария резервного копирования 3 |
.jpg) |
Ниже приводятся результаты сопоставления упомянутых сценариев.
- Сценарий 1 против сценария 2: хотя по сценарию 1 предусмотрено применение меньшего числа процедур восстановления, он предполагает использование значительно больших объемов дискового пространства для хранения резервных копий.
- Сценарий 1 против сценария 3: хотя по сценарию 3 предусмотрено применение примерно такого же числа процедур восстановления, для хранения резервных копий в нем используется на 60% меньше дискового пространства.
- Сценарий 2 против сценария 3: хотя по сценарию 2 предусмотрено использование меньших объемов дискового пространства, число процедур восстановления с каждым следующим днем недели становится все больше и достигает недопустимо высоких значений.
Средства сжатия резервных копий могут обеспечить дополнительную экономию дискового пространства при работе с полными резервными копиями, резервными копиями журналов транзакций и с разностными резервными копиями, так что показатели, приведенные в таблице 3, могут быть лучше во всех отношениях. Однако, как уже отмечалось ранее, средства сжатия не включены во все версии и редакции SQL Server (именно по этой причине мы не рассматривали их использование в предложенных сценариях), к тому же эффективность этих средств может быть ограниченной при работе с базами данных, которые содержат предварительно сжатые данные.
Когда создавать следующую полную резервную копию
Следующий вопрос, с которым придется столкнуться администратору баз данных, состоит в том, когда же необходимо создавать очередную полную резервную копию; ведь если не управлять процессом, дополняющие друг друга разностные резервные копии быстро превзойдут по размерам базовую копию для разностного копирования. Важно помнить о причинах, побуждающих нас применять разностные резервные копии: эти копии нужны для сокращения дискового пространства, необходимого для хранения резервных копий, а также для повышения скорости восстановления. Возьмем для примера сценарий 3. В нем размер разностной резервной копии составляет более половины размера полной резервной копии, а это значит, что экономия дискового пространства от использования разностных резервных копий уже не компенсирует увеличение времени на восстановление. Иначе говоря, на следующей неделе можно начинать разностное копирование с новой базовой копии.
В некоторых обстоятельствах за столь короткое время администратор не может удостовериться в том, что разностные резервные копии остаются достаточно компактными и что ими все еще можно управлять эффективно. Если на протяжении одной недели база данных претерпит значительных изменений по причине поступления больших объемов данных, из-за осуществления масштабной операции по дефрагментации индексов, повсеместного обновления данных или вследствие иных событий, тогда потребуется создать незапланированную полную резервную копию. Эта необходимость уделять пристальное внимание мониторингу и управлению представляет собой один из недостатков, из-за которых многие администраторы баз данных воздерживаются от развертывания решений для создания разностных резервных копий. С целью устранения этого недостатка некоторые сторонние поставщики средств резервного копирования для SQL Server уже реализовали в своих продуктах динамические функции управления.
Ценная возможность
Средства для создания разностных резервных копий имелись в распоряжении администраторов баз данных с первых дней существования SQL Server, но сейчас, похоже, многие о них забыли. Между тем разностные резервные копии — инструмент очень мощный. Они могут стать исключительно важным компонентом реализуемой администраторами баз данных стратегии управления хранением данных. Эти копии с легкостью интегрируются в любой сценарий резервного копирования, и администраторы баз данных могут быстро получить экономию как дискового пространства, используемого для хранения резервных копий, так и средств, затрачиваемых на хранение каждого гигабайта этих данных. Разностные резервные копии может применять любой администратор баз данных, поскольку соответствующие функции реализованы во всех версиях продуктов. В сочетании с собственными средствами сжатия изделий SQL Server 2008 R2 Standard Edition и SQL Server 2008 Enterprise Edition разностные резервные копии могут обеспечить еще более существенную экономию средств, затрачиваемых на хранение каждого гигабайта данных.
Определяем объем изменения данных
Если вы не имеете четкого представления о том, насколько значительно — или незначительно — изменяется содержимое вашей базы данных, можете воспользоваться недокументированной (и потому неподдерживаемой) командой DBCC PAGE. Эта команда позволяет считывать информацию с разностной побитовой страницы и отображать ее в удобной для чтения форме. Синтаксис команды следующий:
DBCC PAGE ({'dbname' | dbid}, filenum,
pagenum [, printopt={0|1|2|3}])
Прежде всего, необходимо идентифицировать страницы, содержащие разностную побитовую страницу. Чтобы возвратить информацию о заголовке страницы и о каждой индивидуальной строке, запустите команду DBCC PAGE, установив для аргумента filenum значение 1, для аргумента pagenum — значение 0, а для аргумента printopt — значение 3:
DBCC PAGE (AdventureWorks,1,0,3) WITH TABLERESULTS, NO_INFOMSGS
Результаты представлены на экране A. Как видите, первой разностной побитовой страницей является страница 6 первого файла базы данных, так что ее страничный идентификатор имеет вид (1:6). Столбец VALUE на экране А показывает, что за период после создания последней базовой копии для разностного копирования его содержимое изменилось, а значит, команду DBCC PAGE можно выполнять с аргументом filenum, равным 1, аргументом pagenum, равным 6, и аргументом printopt, равным 3:
DBCC PAGE (AdventureWorks,1,6,3) WITH TABLERESULTS, NO_INFOMSGS
.jpg) |
| Экран А. Результаты выполнения первоначального запроса DBCC PAGE |
Результаты представлены на экране Б. Столбец ParentObjects отображает значение DIFF_MAP для всех экстентов, входящих в данную глобальную таблицу распределения. Столбец Field отображает страницы, сгруппированные по экстентам, а столбец VALUE показывает, изменились ли упомянутые экстенты. На данном этапе вы можете рассчитать объем данных, подвергшихся изменениям, и оценить размер разностной резервной копии.
.jpg) |
| Экран Б. Результаты выполнения запроса DBCC PAGE на странице PageID (1:6) |
В своем блоге New script: How much of the database has changed since the last full backup? (http://www.sqlskills.com/BLOGS/PAUL/post/New-script-How-much-of-the-database-has-changed-since-the-last-full-backup.aspx) Пол Рэндал приводит сценарий, в котором рассчитывается процент подвергшихся изменению данных (по всей базе данных) за период после создания последней полной резервной копии. Эти сведения помогут вам определить, есть ли необходимость создания полной или разностной резервной копии.
Иейн Кик (iain.kick@computacenter.com) — старший технический консультант по SQL Server в компании Computacenter
Крис Бернс (chris.burns @ datatech.ltd.uk) — технический директор компании Data Technology Consultants в Великобритании. Имеет 15-летний опыт работы с SQL
Иейн Кик (iain.kick@computacenter.com) — старший технический консультант по SQL Server в компании Computacenter
SELECT d.name as DatabaseName,
mf.name as DatabaseFileName,
mf.differential_base_lsn,
mf.differential_base_guid,
mf.differential_base_time
FROM sys.master_files mf
JOIN sys.databases d on mf.database_id = d.database_id
-- Исключение главной базы данных и базы данных tempdb.
WHERE mf.database_id not in ('1','2')
-- Исключение файлов журналов.
AND mf.file_id <> ‘2’
RESTORE LOG Orders FROM DISK='d:\backups\Orders1.trn' WITH NORECOVERY GO RESTORE LOG Orders FROM DISK='d:\backups\Orders2.trn' WITH NORECOVERY GO RESTORE LOG Orders FROM DISK='d:\backups\Orders3.trn' WITH NORECOVERY GO RESTORE LOG Orders FROM DISK='d:\backups\Orders4.trn' WITH NORECOVERY GO RESTORE LOG Orders FROM DISK='d:\backups\Orders5.trn' WITH NORECOVERY GO RESTORE LOG Orders FROM DISK='d:\backups\Orders6.trn' WITH NORECOVERY GO