SQL в вопросах и ответах: Узкие места и журналы транзакций. Журнал транзакций ms sql

Чтение журнала транзакций SQL Server

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

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

Если открыть файл журнала транзакций *.LDF или файл резервной копии журнала *.TRN в любом двоичном редакторе, то информация, которую вы увидите, будет мало чем информативна. Ниже представлен фрагмент LDF-файла:

Функция fn_dbblog

fn_dblog – это недокументированная функция SQL Server, которая позволяет просматривать активную часть журнала транзакций в режиме реального времени.

Давайте посмотрим, как с ней работать:

1. Выполните функцию fn_dblog
Select * FROM sys.fn_dblog(NULL,NULL)



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

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

Например, выберем только транзакции на вставку строк в таблицу:

SELECT [Current LSN], Operation, Context, [Transaction ID], [Begin time] FROM sys.fn_dblog (NULL, NULL) WHERE operation IN ('LOP_INSERT_ROWS');

Чтобы увидеть транзакции на удаление строк, выполните следующий скрипт:

SELECT [begin time], [rowlog contents 1], [Transaction Name], Operation FROM sys.fn_dblog (NULL, NULL) WHERE operation IN ('LOP_DELETE_ROWS');



3. Информация по вставленным или удалённым строкам храниться в столбцах – RowLog Contents 0, RowLog Contents 1, RowLog Contents 2, RowLog Contents 3, RowLog Contents 4, Description и Log Record

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

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

4. Далее необходимо преобразовать двоичные данные в табличный вид с учётом типа данных столбцов таблицы. Следует отметить, что механизм преобразования различный для разных типов данных.

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

Операция UPDATE при минимальном протоколировании журнала транзакций не содержит полное значение, которое было до и после изменений, а хранит только то, что изменилось (SQL Server может записать, что изменилось значение “G” на “D”, хотя в действительности изменилось слово “GLOAT” на “FLOAT”). В этом случаи вам потребуется вручную восстанавливать все промежуточные состояния записи на странице от первой её вставки до момента, который вас интересует.

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

Функция fn_dump_dblog

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

1. Ниже пример запуска функции fn_dump_dblog, обратите внимание, что необходимо указать все её 63 параметра
SELECT * FROM fn_dump_dblog (NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT);



Т.к. функция fn_dump_dblog возвращает так же, как и fn_dblog 129 столбцов, то желательно сократить этот набор полей

SELECT [Current LSN], Operation, Context, [Transaction ID], [transaction name], Description FROM fn_dump_dblog (NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, DEFAULT);

Но вам потребуется опять расшифровать шестнадцатеричные значения, чтобы найти искомые записи



И вы опять получаете те же самые ограничения, что и при работе с функцией fn_dblog.

Для восстановления БД из копии журнала транзакций до определённого момента времени или до конкретной транзакции, вам необходимо:

2. Определить LSN (Log Sequence Number) для этой транзакции
3. Преобразовать LSN в формат, который используется в конструкции WITH STOPBEFOREMARK = ‘<mark_name>’, например значение 00000070:00000011:0001 должно быть переведено в формат 112000000001700001
4. Восстановите полную резервную копию БД и всю цепочку резервных копий журнала транзакций до нужной транзакции с помощью конструкции WITH STOPBEFOREMARK = ‘<mark_name>’ , где укажите идентификатор нужной транзакции. RESTORE LOG AdventureWorks2012 FROM DISK = N'E:\ApexSQL\backups\AW2012_05232013.trn' WITH STOPBEFOREMARK = 'lsn:112000000001700001', NORECOVERY;

DBCC PAGE

Ещё одна полезная команда DBCC PAGE, но также, как и две предыдущих функции –недокументированная. Она позволяет просматривать содержимое файлов MDF и LDF. Её синтаксис:

DBCC PAGE ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])

Для просмотра содержимого первой страницы журнала транзакций БД AdventureWorks2012, необходимо выполнить:

SELECT FILE_ID ('AdventureWorks2012_Log') AS 'File ID' DBCC PAGE (AdventureWorks2012, 2, 0, 2)

В качестве результата вы получите сообщение:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

По умолчанию результат команды DBCC PAGE не выводится в SQL Server Management Studio и для её отображения первым шагом необходимо включить флаг трассировки 3604:

И теперь повторно выполните команду:

DBCC PAGE (AdventureWorks2012, 2, 0, 2)

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

Полученный результат ничем не отличается от того, который вы можете получить в любом hex-редакторе, а может быть даже и в менее наглядном виде. Главное отличие – это возможность просматривать файл в режиме реального времени, без отключения БД, но дружелюбным такой формат никак нельзя назвать.

Use ApexSQL Log

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

1. Запустите ApexSQL Log

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

   

3. На шаге Select SQL logs to analyze, выберите записи, которые нужно прочитать. Убедитесь, что они образуют полную цепочку

   

4. Чтобы добавить резервные копии журнала транзакций и отдельные файлы LDF, используйте кнопку Add

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

   

6. Нажмите Open

   Полный результат можно будет увидеть в табличном виде

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

   

Чтобы избежать нечитаемых шестнадцатеричных значений, недокументированных функций, непонятного содержимого колонок, запросов со сложной конструкцией, сложных сценариев получения данных, неполных данных операций UPDATE, а также проблем с получением BLOB значений из журнала транзакций SQL Server, используйте программу ApexSQL Log. Она за вас выполнит все сложные операции и предоставит результат в читабельном виде. Кроме того, она позволит вам с помощью одного нажатия отменить или повторно выполнить нужную транзакцию.

Переводчик: Алексей Князев

November 20, 2015

solutioncenter.apexsql.com

SQL в вопросах и ответах: Узкие места и журналы транзакций

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

Пол С. Рэндал

Дисковая подсистема как узкое место

Вопрос: Я пытаюсь определить причину узкого места в своей системе. Я убежден, что оно находится на уровне системы хранения, так как видел, что длина дисковой очереди превышает значение 2. Я читал, что это хороший способ, доказывающий, что SQL Server перегружает дисковую систему. Правда ли это? Если так, то что мне делать с этим?

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

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

Но нас интересует вопрос, на что же все-таки смотреть, чтобы узнать, является ли подсистема ввода/вывода узким местом? В объекте производительности «Физический диск» (Physical Disk) есть два счетчика, на которые надо обратить внимание.

• Среднее время чтения с диска (с) (Avg. Disk sec/Read)
• Среднее время записи на диск (с) (Avg. Disk sec/Write)

Они предоставляют информацию в миллисекундах о времени выполнения операций ввода/вывода. Если показания постоянно выше (или часто превышают) нормы (то есть 5-12 мс), то физический диск является узким местом ввода/вывода. Конечно, физическим диском может быть LUN-массив SAN, но наши возможности ограничены возможностями Windows.

Если на физическом диске расположены данные и журналы SQL Server, возможно потребуется выяснить, какие файлы создают нагрузку на систему ввода/вывода. Используйте динамическое представление sys.dm_io_virtual_file_stats и выполните некоторое простое исследование времени на основе результатов.

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

Если речь идет просто о файлах SQL Server в этой подсистеме и можно определить, которые из них создают чрезмерное число операций ввода/вывода, проблему можно решить одним из следующих способов:

• Проанализируйте рабочую нагрузку запросов базы данных и выясните, не выполняют ли они излишние просмотры таблицы из-за неправильной стратегии индексации или неудачных планов выполнения, созданных с использованием устаревшей статистики.
• Перенесите некоторые файлы в другую часть подсистемы ввода/вывода.
• Увеличьте размер памяти на сервере, чтобы серверу SQL Server был доступен пул буферов большего размера (кеш страниц файлов данных в памяти) и снизить число операций ввода/вывода.

Если ни один из этих способов не поможет, и это действительно тот случай, когда подсистема ввода/вывода не справляется с рабочей нагрузкой, нужно переходить на более производительную подсистему ввода/вывода. Можно также подумать о переходе на флэш-память класса предприятия, например на решения компании Fusion-io.

Размер имеет значение

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

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

Первый — базовый уровень RAID. Различные уровни RAID имеют различные плюсы и минусы относительно производительности и избыточности. Например, самая доступная конфигурация RAID, предоставляющая некоторую избыточность, это RAID-5, однако эта конфигурация рассчитана на сбой только одного диска (если не используется RAID-6, или не настроены резервные диски), и иногда может вызывать снижение производительности для рабочих нагрузок с множеством операций записи в зависимости от числа дисков в массиве.

Журнал транзакций должен всегда иметь возможность увеличиваться автоматически. Это особенно верно в критических ситуациях, когда отказывает или бесполезен мониторинг размера журнала. Представьте себе, к примеру, что у вас есть уведомление агента SQL Server, срабатывающее при показаниях счетчика производительности «Процент использования журнала» (Percent Log Used), превышающих 90 %, и сотрудник, ответственный за разрешение ситуации, уведомлен по электронной почте или через пейджер, но он отсутствует из-за болезни. Если у журнала нет возможности увеличиваться, все текущие транзакции, изменяющие базу данных, останавливаются и откатываются. Это приводит к простою и прекращению выполнения бизнес-операций.

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

• Самую объемную транзакцию вставки, обновления или удаления в рабочей нагрузке (независимо от того, неявная ли это транзакция, состоящая из одного оператора и затрагивающая миллионы строк таблицы, или явная транзакция, выполняющая много операций).
• Самую объемную массовую операцию в рабочей нагрузке, например BULK INSERT. Если на вашем сервере используется модель полного восстановления, можно сократить объем данных, поступающих в журнал транзакций, используя модель восстановления с неполным протоколированием. Но имейте в виду, что в такой модели страдает способность восстановления после аварии. Подробнее см. сообщение в моем блоге: A SQL Server DBA myth a day: BULK_LOGGED recovery model.”
• Перестроение наибольшего кластеризованного индекса. Здесь также может помочь использование модели восстановления с неполным протоколированием.

При анализе этих операций надо учитывать не только количество создаваемых записей в журнале транзакций, но пространство, которое система управления журналом транзакций «резервирует» для надлежащего отката транзакций. Если транзакция создает 100 МБ записей в журнале транзакций, система зарезервирует примерно столько же пустого пространства в журнале транзакций, чтобы гарантировать возможность в случае прерывания транзакцию правильно откатить ее. Это защитный механизм, предотвращающий возникновение несогласованности данных в базе. Скорее всего, именно поэтому вы наблюдали увеличение журнала транзакций, хотя и считали, что предусмотрели в нем достаточно пространства для самой крупной транзакции.

Нужно учесть еще одну вещь — есть ли причины продолжительного хранения записей в журнале транзакций. Это может вести к «распуханию» журнала. Вот некоторые из возможных причин:

• В базе используется полная модель восстановления или модель с неполным протоколированием, а резервные копии журнала транзакций не создаются (или создаются нечасто). Чтобы записи удалялись из журнала, должно выполняться их резервное копирование.
• Слишком долго выполняющаяся транзакция. Она не позволяет удалять какие-либо записи журнала транзакций, созданные с момента начала «долгоиграющей» транзакции.
• В базе данных действует зеркальное отображение, и некоторые записи журнала транзакций не переправлены с основного на зеркальный сервер. Подлежащие пересылке на зеркальный сервер записи удалить нельзя.
• В базе данных действует репликация транзакций (или одноранговая репликация), и в журнале транзакций есть записи, не обработанные агентом чтения журнала.

Обнаружив непонятное увеличение размера журнала транзакций, лучше «спросить» о причинах сам сервер SQL Server:

technet.microsoft.com

Применение резервных копий журналов транзакций (SQL Server)

 

Опубликовано: Ноябрь 2016

Этот раздел относится только к модели полного восстановления и модели восстановления с неполным протоколированием.

В этом разделе описано применение резервных копий журнала транзакции в процессе восстановления базы данных SQL Server .

В этом разделе.

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

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

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

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

   Совет

  Лучше всего восстановить все резервные журналы (RESTORE LOG имябазыданных WITH NORECOVERY). После восстановления последней резервной копии журнала восстановите базу данных отдельной операцией (RESTORE DATABASE имябазыданных WITH RECOVERY).

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

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

 Примечание

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

Предполагается такая последовательность событий.

TimeСобытие

8:00	Создание резервной копии базы данных для создания полной резервной копии базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Создание резервной копии базы данных для создания полной резервной копии базы данных.
20:00	Резервное копирование журнала транзакций.
21:45	Произошел сбой.

Чтобы восстановить базу данных до ее состояния в 21:45 (точка сбоя), может быть использована любая из следующих альтернативных процедур.

Альтернативный способ 1. Восстановление базы данных с помощью последней полной резервной копии базы данных

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

2. Не восстанавливайте полную резервную копию базы данных, резервной копии базы данных от 18:00. Вместо этого восстановите последнюю полную резервную копию, созданную в 18:00:00 а затем примените резервную копию журнала и резервную копию заключительного фрагмента журнала, созданные в 20:00:00.

Альтернативный способ 2. Восстановление базы данных с использованием более ранней полной резервной копии базы данных

 Примечание

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

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

2. Восстановите полную резервную копию базы данных от 8:00, а затем последовательно восстановите все четыре резервные копии журнала транзакций. Это позволяет произвести накат всех завершенных транзакций вплоть до 21:45.

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

Использование резервной копии журнала транзакций

Восстановление до нужной точки восстановления

Восстановление базы данных после восстановления резервных копий с параметром WITH NORECOVERY

Журнал транзакций (SQL Server)

msdn.microsoft.com

Резервные копии журналов транзакций (SQL Server)

• 06/25/2013
• Время чтения: 2 мин

В этой статье

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

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

В этом разделе:

Работа последовательности резервных копий журнала

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

Время

Событие

8:00	Резервное копирование базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Резервное копирование базы данных.
20:00	Резервное копирование журнала транзакций.

Резервная копия журнала транзакций создана в 20:00, содержит записи журнала транзакций начиная с 16:00 до 20:00, включая время создания полной резервной копии базы данных в 18:00. Последовательность резервных копий журнала транзакций непрерывна, начиная с первого полного резервного копирования базы данных в 8:00 и до последнего резервного копирования журнала в 20:00. Сведения о применении этих резервных копий журналов приводятся в примере в разделе Применение резервных копий журналов транзакций (SQL Server).

[В начало]

Рекомендации

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

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

• По умолчанию каждая успешная операция резервного копирования добавляет запись в журнал ошибок служб SQL Server и в журнал системных событий. Если создание резервной копии журналов производится очень часто, это приводит к быстрому накоплению сообщений об успешном завершении. Это приводит к увеличению журналов ошибок, затрудняя поиск других сообщений. Если работа существующих скриптов не зависит от этих записей, то их можно отключить с помощью флага трассировки 3226. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).

Связанные задачи

Создание резервной копии журнала транзакций

Описание планирования заданий резервного копирования см. в разделе Использование мастера планов обслуживания.

[В начало]

См. также

Отсутствует.

[В начало]

См. также

Основные понятия

Журнал транзакций (SQL Server)

Резервное копирование и восстановление баз данных SQL Server

Резервные копии заключительного фрагмента журнала (SQL Server)

Применение резервных копий журналов транзакций (SQL Server)

msdn.microsoft.com

Управление размером файла журнала транзакций

 

Опубликовано: Декабрь 2016

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

В этом разделе:

Контролировать используемое пространство журнала можно с помощью процедуры DBCC SQLPERF (LOGSPACE). Она возвращает сведения об объеме пространства, используемого журналом в данный момент, и указывает, если необходимо провести усечение журнала транзакций. Дополнительные сведения см. в статье DBCC SQLPERF (Transact-SQL). Для получения сведений о текущем размере файла журнала, его максимальном размере и параметре автоматического увеличения файла вы можете также использовать столбцы size, max_size и growth для данного файла журнала в представлении sys.database_files. Дополнительные сведения см. в статье sys.database_files (Transact-SQL).

 Важно

Рекомендуется избегать переполнения диска, содержащего журналы.

[В начало]

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

 Примечание

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

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

Сжатие файла журнала (без сжатия файлов базы данных)

Мониторинг событий сжатия файла журнала

To monitor log space

 Примечание

Можно задать автоматическое выполнение сжатия файлов базы данных и журнала. Однако автоматическое сжатие не рекомендуется, поэтому свойство autoshrink базы данных по умолчанию имеет значение FALSE. Если свойство autoshrink имеет значение TRUE, то автоматическое сжатие уменьшит размер файла только в том случае, если неиспользуемое пространство занимает более 25 % от общего объема. Файл будет сжат либо до размера, в котором 25 % пространства не используется, либо до исходного размера, каким бы большим он ни был. Дополнительные сведения об установке свойства autoshrink см. в разделе Просмотр или изменение свойств базы данных при использовании свойства Auto Shrink на странице Параметры или в разделе Параметры ALTER DATABASE SET (Transact-SQL) при использовании параметра AUTO_SHRINK.

[В начало]

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

• Файл журнала добавляется в базу данных с помощью предложения ADD LOG FILE инструкции ALTER DATABASE. Это позволяет увеличить размер файла.

• Файл журнала можно увеличить с помощью предложения MODIFY FILE инструкции ALTER DATABASE. При этом следует указать синтаксис SIZE и MAXSIZE. Дополнительные сведения см. в статье ALTER DATABASE (Transact-SQL).

[В начало]

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

[В начало]

Для управления размером файла журнала транзакций вы можете использовать инструкцию ALTER DATABASE (Transact-SQL). Следует отметить следующее.

• Чтобы изменить текущий размер файла в КБ, МБ, ГБ и ТБ, используйте параметр «SIZE».

• Чтобы изменить шаг приращения размера, используйте параметр FILEGROWTH. Значение 0 указывает, что автоматическое приращение выключено и дополнительное пространство для файла не разрешено. Небольшое значение параметра автоувеличения прироста размера файла журнала может снизить производительность системы. Во избежание слишком частых увеличений размера файла журнала следует задать достаточно большое значение шагу роста файла журнала. Как правило, достаточно установить значение увеличения шага роста равным 10 %.

  Сведения об изменении параметра прироста для файлов журнала см. в разделе ALTER DATABASE (Transact-SQL).

• Чтобы установить максимальный размер файла журнала в КБ, МБ, ГБ и ТБ или задать неограниченный размер, используйте параметр MAXSIZE.

[В начало]

BACKUP (Transact-SQL)Устранение неполадок при переполнении журнала транзакций (ошибка SLQ Server 9002)

msdn.microsoft.com

Восстановление резервной копии журнала транзакций (SQL Server)

 

Опубликовано: Декабрь 2016

В этом разделе описывается восстановление журнала транзакций из резервной копии в SQL Server 2014 с помощью среды SQL Server Management Studio или Transact-SQL.

В этом разделе

Предварительные требования

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

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

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

    Дополнительные сведения о резервных копиях журналов транзакций см. в статье Резервные копии журналов транзакций (SQL Server) и Применение резервных копий журналов транзакций (SQL Server).

Безопасность

Разрешения

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

 Предупреждение

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

Восстановление резервной копии журнала транзакций

1. После соединения с соответствующим экземпляром компонента Microsoft Компонент SQL Server Database Engineв обозревателе объектов разверните дерево сервера, щелкнув его имя.

2. Раскройте узел Базы данныхи в зависимости от типа восстанавливаемой базы данных выберите пользовательскую базу данных или раскройте узел Системные базы данных и выберите системную базу данных.

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

    Примечание

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

4. На странице Общие в списке База данных выберите имя базы данных. Перечислены только базы данных, которые находятся в состоянии восстановления.

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

   • Из предыдущих резервных копий базы данных

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

   • Из файла или с ленты

     Нажмите кнопку обзора (...), после чего откроется диалоговое окно Выбор устройства резервного копирования . В окне Тип носителя резервной копии выберите один из перечисленных типов устройств. Чтобы выбрать одно или несколько устройств в окне Носитель резервной копии , нажмите кнопку Добавить.

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

6. В сетке Выберите резервные копии журнала транзакций для восстановления выберите нужные резервные наборы. В этой сетке перечислены резервные копии журналов транзакций, доступные для выбранной базы данных. Резервная копия журналов доступна только в том случае, если ее первый номер LSN больше, чем последний номер LSN базы данных. Резервные копии журналов перечислены в порядке содержащихся в них номеров LSN и должны быть восстановлены в этом порядке.

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

   ЗаголовокЗначение

   Восстановить	Установленные флажки показывают резервные наборы данных для восстановления.
   Название	Имя резервного набора.
   Компонент	Компонент, сохраненный в резервной копии: База данных, Файл или <пусто> (для журналов транзакций).
   База данных	Имя базы данных, участвовавшей в операции резервного копирования.
   Дата начала	Дата и время начала резервного копирования, представленные в соответствии с региональными стандартами клиента.
   Дата завершения	Дата и время окончания резервного копирования, представленные в соответствии с региональными настройками клиента.
   первый номер LSN	Регистрационный номер транзакции в журнале для первой транзакции резервного набора данных Пустой для резервных копий файлов.
   последний номер LSN	Регистрационный номер в журнале для первой транзакции резервного набора данных Пустой для резервных копий файлов.
   Номер LSN для контрольной точки	Регистрационный номер транзакции в журнале для последней контрольной точки на момент создания резервной копии.
   Полный номер LSN	Регистрационный номер транзакции в журнале для последней полной резервной копии базы данных.
   Server	Имя экземпляра ядра СУБД, выполнившего операцию резервного копирования.
   Имя пользователя	Имя пользователя, выполнившего операцию резервного копирования.
   Размер	Размер резервного набора данных в байтах.
   Положение	Позиция резервного набора данных в томе.
   Истечение срока	Дата и время окончания срока действия для резервного набора.

7. Выберите один из следующих вариантов:

   • На момент времени

     Либо сохраните значение по умолчанию (Самый последний), либо выберите конкретную дату и время, нажав кнопку обзора и открыв диалоговое окно Восстановление на момент времени .

   • До помеченной транзакции

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

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

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

     ЗаголовокЗначение

     <пустое>	Отображает флажок для выбора маркера.
     Отметка транзакции	Имя помеченной транзакции, заданное пользователем при фиксации транзакции.
     Дата	Дата и время фиксации транзакции. Дата и время транзакции отображаются, в соответствии с данными в таблице msdbgmarkhistory , а не с датой и временем на клиентском компьютере.
     Описание	Описание помеченной транзакции, заданное пользователем при ее фиксации (при его наличии).
     Номер LSN	Регистрационный номер помеченной транзакции в журнале.
     База данных	Имя базы данных, в которой была зафиксирована помеченная транзакция.
     Имя пользователя	Имя пользователя базы данных, зафиксировавшего помеченную транзакцию.

8. Чтобы просмотреть или выбрать дополнительные параметры, нажмите кнопку Параметры на панели Выбор страницы .

9. В разделе Восстановление параметров предусмотрены следующие варианты выбора:

   • Сохранить параметры репликации (WITH KEEP_REPLICATION)

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

     Этот параметр доступен только вместе с параметром Оставить базу данных готовой к использованию, выполнив откат незафиксированных транзакций... (описанным ниже), который эквивалентен восстановлению резервной копии с параметром RECOVERY.

     Выбор этого параметра равнозначен использованию параметра KEEP_REPLICATION в инструкции Transact-SQLRESTORE****.

   • Выдавать приглашение перед восстановлением каждой резервной копии

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

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

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

   • Ограничить доступ к восстановленной базе данных (WITH RESTRICTED_USER)

     Доступ к восстановленной базе данных будет только у пользователей db_owner, dbcreator или sysadmin.

     Выбор этого параметра равнозначен использованию параметра RESTRICTED_USER в инструкции Transact-SQLRESTORE****.

10. В качестве значения параметра Состояние восстановления укажите состояние базы данных после операции восстановления.

    • Оставить базу данных готовой к использованию, выполнив откат незафиксированных транзакций. Невозможно восстановить дополнительные журналы транзакций. (RESTORE WITH RECOVERY)

      Восстанавливает базу данных. Этот параметр равнозначен параметру RECOVERY в инструкции Transact-SQLRESTORE .

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

    • Оставить базу данных в нерабочем состоянии и не производить откат незафиксированных транзакций. Можно восстановить дополнительные журналы транзакций. (RESTORE WITH NORECOVERY)

      Оставить базу данных в состоянии RESTORING (невосстановленном). Этот параметр равнозначен использованию параметра NORECOVERY в инструкции Transact-SQLRESTORE .

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

       Важно

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

    • Оставить базу данных в режиме только для чтения. Отменить незафиксированные транзакции, но сохранить отмененные действия в файле, чтобы результаты восстановления могли быть отменены. (RESTORE WITH STANDBY)

      Оставляет базу данных в резервном состоянии. Этот параметр равнозначен использованию параметра STANDBY в инструкции Transact-SQLRESTORE .

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

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

 Важно

Во избежание неоднозначности в каждой инструкции WITH RECOVERY рекомендуется явное задание параметра WITH NORECOVERY или WITH RECOVERY. Это особенно важно учитывать при написании скриптов.

Восстановление резервной копии журнала транзакций

1. Чтобы применить резервную копию журналов транзакций, выполните инструкцию RESTORE LOG, указав при этом:

   • Имя базы данных, к которой будет применен журнал транзакций.

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

   • Предложение NORECOVERY.

   В этой инструкции применяется следующая основная синтаксическая конструкция:

   RESTORE LOG имябазыданных FROM <устройстворезервногокопирования> WITH NORECOVERY.

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

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

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

   • Восстановить базу данных в составе последней инструкции RESTORE LOG:

     RESTORE LOG <database_name> FROM <backup_device> WITH RECOVERY; GO

   • Подождать, а затем восстановить базу данных отдельной инструкцией RESTORE DATABASE:

     RESTORE LOG <database_name> FROM <backup_device> WITH NORECOVERY; RESTORE DATABASE <database_name> WITH RECOVERY; GO

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

    Важно

   При создании зеркальной базы данных этап восстановления можно пропустить. Зеркальная база данных должна остаться в состоянии RESTORING.

Примеры (Transact-SQL)

По умолчанию для базы данных AdventureWorks2012 используется простая модель восстановления. В следующем примере для перехода на модель полного восстановления требуется изменить базу данных следующим образом:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

A. Применение одной резервной копии журнала транзакций

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

RESTORE DATABASE AdventureWorks2012 FROM AdventureWorks2012_1 WITH NORECOVERY; GO RESTORE LOG AdventureWorks2012 FROM AdventureWorks2012_log WITH FILE = 1, WITH NORECOVERY; GO RESTORE DATABASE AdventureWorks2012 WITH RECOVERY; GO

Б. Применение нескольких резервных копий журналов транзакций

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

RESTORE DATABASE AdventureWorks2012 FROM AdventureWorks2012_1 WITH NORECOVERY; GO RESTORE LOG AdventureWorks2012 FROM AdventureWorks2012_log WITH FILE = 1, NORECOVERY; GO RESTORE LOG AdventureWorks2012 FROM AdventureWorks2012_log WITH FILE = 2, WITH NORECOVERY; GO RESTORE LOG AdventureWorks2012 FROM AdventureWorks2012_log WITH FILE = 3, WITH NORECOVERY; GO RESTORE DATABASE AdventureWorks2012 WITH RECOVERY; GO

msdn.microsoft.com

Применение резервных копий журналов транзакций (SQL Server)

• 06/25/2013
• Время чтения: 3 мин

В этой статье

Этот раздел относится только к модели полного восстановления и модели восстановления с неполным протоколированием.

В этом разделе описано применение резервных копий журнала транзакции в процессе восстановления базы данных SQL Server.

В этом разделе:

• Требования к восстановлению резервных копий журналов транзакций

• Журналы восстановления и транзакций

• Использование резервных копий журнала для восстановления до точки сбоя

• Связанные задачи

Требования к восстановлению резервных копий журналов транзакций

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

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

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

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

  Совет

  Лучше всего восстановить все резервные журналы (RESTORE LOG database_name WITH NORECOVERY). После восстановления последней резервной копии журнала восстановите базу данных отдельной операцией: (RESTORE DATABASE database_name WITH RECOVERY).

Журналы восстановления и транзакций

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

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

Примечание

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

[В начало]

Использование резервных копий журнала для восстановления до точки сбоя

Предполагается такая последовательность событий.

Время

Событие

8:00	Создание резервной копии базы данных для создания полной резервной копии базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Создание резервной копии базы данных для создания полной резервной копии базы данных.
20:00	Резервное копирование журнала транзакций.
21:45	Произошел сбой.

Чтобы восстановить базу данных до ее состояния в 21:45 (точка сбоя), может быть использована любая из следующих альтернативных процедур.

Вариант 1. Восстановление базы данных с помощью последней полной резервной копии базы данных

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

2. Не восстанавливайте полную резервную копию базы данных, созданную в 08:00:00. Вместо этого восстановите последнюю полную резервную копию, созданную в 18:00:00 а затем примените резервную копию журнала и резервную копию заключительного фрагмента журнала, созданные в 20:00:00.

Вариант 2. Восстановление базы данных с использованием более ранней полной резервной копии базы данных

Примечание

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

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

2. Восстановите полную резервную копию базы данных от 8:00, а затем последовательно восстановите все четыре резервные копии журнала транзакций. Это позволяет произвести накат всех завершенных транзакций вплоть до 21:45.

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

[В начало]

Связанные задачи

Использование резервной копии журнала транзакций

Восстановление до нужной точки восстановления

Восстановление базы данных после восстановления резервных копий с параметром WITH NORECOVERY

[В начало]

См. также

Основные понятия

Журнал транзакций (SQL Server)

msdn.microsoft.com

---

Смотрите также

• 
  Публикация статьи ринц журналы
• 
  Ясновидящая анастасия из журнала
• 
  Журнал играем с мамой
• 
  Подписка на журнал библиотека
• 
  Общественные науки научный журнал
• 
  Актуальные проблемы экономики журнал
• 
  Журнал башкортостан укытыусыхы башкортостан
• 
  Форма журнала под 11
• Журнал начальная школа 2015
• 
  Пример заполнения оперативный журнал
• 
  Электронный журнал школа 187