[MS SQL] Восстановление базы по логу транзакций
Думаю, что никак.
Представь, что в последней транзакции выполнялась такая команда
В лог транзакций не будет записано состояние БД до этой транзакции, поэтому ты его не сможешь восстановить.
Представь, что в последней транзакции выполнялась такая команда
UPDATE table1 SET column1=0;
В лог транзакций не будет записано состояние БД до этой транзакции, поэтому ты его не сможешь восстановить.
>Думаю, что никак.
Нафиг тогда вообще нужен лог транзакций, если по нему нельзя ничего восстановить?
Нафиг тогда вообще нужен лог транзакций, если по нему нельзя ничего восстановить?
Ну так необходимость регулярного резервного копирования никто не отменял. Восстанавливаешь из достаточно свежего бэкапа, потом накатываешь транзакции из лога транзакций до нужного момента.
Ага.
А вообще главная польза от журнала транзакций видна после сбоев в работе.
2Сfheny
Есть небольшая вероятность того, что удастся восстановить, если журнал (или цепочка таких журналов) транзакций ведется с самого создания БД и при этом не использовались некоторые типы операций, которые не записываются в журнал транзакций (например, операции массивного копирования, в этом случае в журнал транзакций записывается информация только о том, какие страницы были выделены, поэтому отменить такую операцию можно, а вот накатить по информации из журнала — нельзя). Да, еще нужно, чтобы была отключена опция урезания журнала для тех транзакций, которые были завершены.
В таком случае можно создать бэкап пустой БД и на него накатывать транзакции.
2
Если интересно, можешь почитать в интернете про строение журнала транзакций в MS SQL, а также про то, как там работает с кэшем диспетчер транзакций. После этого будет понятно, что можно сделать, а что нельзя.
А вообще главная польза от журнала транзакций видна после сбоев в работе.
2Сfheny
Есть небольшая вероятность того, что удастся восстановить, если журнал (или цепочка таких журналов) транзакций ведется с самого создания БД и при этом не использовались некоторые типы операций, которые не записываются в журнал транзакций (например, операции массивного копирования, в этом случае в журнал транзакций записывается информация только о том, какие страницы были выделены, поэтому отменить такую операцию можно, а вот накатить по информации из журнала — нельзя). Да, еще нужно, чтобы была отключена опция урезания журнала для тех транзакций, которые были завершены.
В таком случае можно создать бэкап пустой БД и на него накатывать транзакции.
2
Если интересно, можешь почитать в интернете про строение журнала транзакций в MS SQL, а также про то, как там работает с кэшем диспетчер транзакций. После этого будет понятно, что можно сделать, а что нельзя.
А данные для отката в лог транзакций не пишутся?
>Если интересно, можешь почитать в интернете про строение журнала транзакций в MS SQL
Да я вот и читаю собственно... Пока не вижу препятствий для существования утилиты откатывающей транзакции. (за исключением операций массового копирования, ну и если данные отката ещё не похерили)
Да я вот и читаю собственно... Пока не вижу препятствий для существования утилиты откатывающей транзакции. (за исключением операций массового копирования, ну и если данные отката ещё не похерили)
Есть небольшая вероятность того, что удастся восстановить, если журнал (или цепочка таких журналов) транзакций ведется с самого создания БД и при этом не использовались некоторые типы операций, которые не записываются в журнал транзакций (например, операции массивного копирования, в этом случае в журнал транзакций записывается информация только о том, какие страницы были выделены, поэтому отменить такую операцию можно, а вот накатить по информации из журнала — нельзя). Да, еще нужно, чтобы была отключена опция урезания журнала для тех транзакций, которые были завершены.
В таком случае можно создать бэкап пустой БД и на него накатывать транзакции.
Да, лог ведётся с самого начала, и урезание не включено. Операции, которые надо отменить - удаление. Случайно очистил не ту таблицу.
Спасибо за идею с бэкапом пустой бд, сейчас попробую.
В таком случае можно создать бэкап пустой БД и на него накатывать транзакции.серьёзно? забавная фича, в Oracle насколько знаю так не удастся
и при этом не использовались некоторые типы операций, которые не записываются в журнал транзакций (например, операции массивного копирования, в этом случае в журнал транзакций записывается информация только о том, какие страницы были выделены, поэтому отменить такую операцию можно, а вот накатить по информации из журнала — нельзя)а как в таком случае осуществляется гарантированное восстановление в случае сбоя, если какие-то операции не позволяют накатывать транзакции из журнала?
Наверное ты что-то слишком популярное читаешь. Ключевые слова тут WAL и ARIES. WAL — write-ahead logging, это такое семейство алгоритмов. ARIES относится к семейству алгоритмов WAL и используется во многих СУБД, в том числе в MS SQL Server.
Дело в том, что при таком алгоритме в лог записываются логические команды, которые изменяют данные, причем сначала все пишется в лог, а потом уже в саму БД. Таким образом мы можем делать только redo recovery, но не undo recovery. (Подробнее о различных видах протколирования можно прочитать в книжке Дж. Ульман и др. Системы баз данных. Полный курс. Там же написано, как происходит восстановлении после сбоя, когда у нас могли остаться незавершенные транзакции, на основе протоколирования "redo").
Для ознакомления с алгоритмом ARIES можно прочитать статью http://www.sigmod.org/vldb/conf/1999/P1.pdf, основное там написано на стр. 3-4.
Дело в том, что при таком алгоритме в лог записываются логические команды, которые изменяют данные, причем сначала все пишется в лог, а потом уже в саму БД. Таким образом мы можем делать только redo recovery, но не undo recovery. (Подробнее о различных видах протколирования можно прочитать в книжке Дж. Ульман и др. Системы баз данных. Полный курс. Там же написано, как происходит восстановлении после сбоя, когда у нас могли остаться незавершенные транзакции, на основе протоколирования "redo").
Для ознакомления с алгоритмом ARIES можно прочитать статью http://www.sigmod.org/vldb/conf/1999/P1.pdf, основное там написано на стр. 3-4.
Надо делать бэкап базы перед (чтобы можно было откатиться в случае неудачи) и после таких операций (чтобы было потом на что накатывать транзакции из журнала) 
На самом деле там такие операции, которые выполняются очень редко, типа ALTER DATABASE, RESTORE DATABASE и т. п.
На самом деле там такие операции, которые выполняются очень редко, типа ALTER DATABASE, RESTORE DATABASE и т. п.
Я правильно понял, что файла с данными совсем нет?
Теоретически можно сделать тул, который по журналу сгенерирует восстанавливающий скрипт. По крайней мере видел тулы, где записи определенного типа отображались в виде команд INSET, UPDATE, DELETE. Такое будет работать только, если БД использует модель восстановления FULL, иначе в журнале будут не все данные. Так в модели SIMPLE в журнале затираются записи до первой записи не зафиксированной транзакции на момент последней операции CHECKPOINT. А в модели BULK_LOGGED в журнале сохраняются изменения всяких "тяжелый операций" только при резервном копировании журнала, а то этого изменения помечаются в файле данных.
Теоретически можно сделать тул, который по журналу сгенерирует восстанавливающий скрипт. По крайней мере видел тулы, где записи определенного типа отображались в виде команд INSET, UPDATE, DELETE. Такое будет работать только, если БД использует модель восстановления FULL, иначе в журнале будут не все данные. Так в модели SIMPLE в журнале затираются записи до первой записи не зафиксированной транзакции на момент последней операции CHECKPOINT. А в модели BULK_LOGGED в журнале сохраняются изменения всяких "тяжелый операций" только при резервном копировании журнала, а то этого изменения помечаются в файле данных.
Оставить комментарий
Flack_bfsp
Задача. Есть некая база MS SQL 2000. Есть LDF-файл к ней. Надо откатить несколько последних транзакций. Бэкапа или нет, или он слишком старый. То есть восстановление из бэкапа отпадает. Каким образом обрабатывать LDF-файл?