Как восстановить удаленную таблицу на сервере sql после полной резервной копии

Мне нужно восстановить удаленную таблицу из базы данных SQL Server, которая работает на SQL Server 2016 Standard edition. База данных находится в режиме полного восстановления.

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

Я пробовал это ссылка и ошибка в последней команде.

Результат запроса STOPBEFOREMARK:

Обработано 2104752 страницы для базы данных «databasecopy», файл «databasefilename» в файле 1. Обработано 6 страниц для базы данных «datebasecopy», файл «database_log» в файле 1. RESTORE DATABASE успешно обработала 2104758 страниц за 123,259 секунд (133,405 МБ/с). Сообщение 4335, уровень 16, состояние 2, строка 15 Указанное время STOPAT слишком раннее. Для всей базы данных или ее части уже выполнен повтор транзакций после этой точки. Сообщение 3013, уровень 16, состояние 1, строка 15 RESTORE LOG аварийно завершается. RESTORE DATABASE успешно обработала 0 страниц за 0,544 секунды (0,000 МБ/с).

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

введите здесь описание изображения

Таблица времени удаления из fun_dblog:

введите здесь описание изображения


person Ivan Lewis    schedule 15.01.2019    source источник
comment
Вам придется восстановить резервную копию, которую вы сделали ДО того, как вы уронили таблицу. Вы также забыли указать, какую ошибку вы получили и какую команду вы использовали, которая ее вызвала.   -  person scsimon    schedule 15.01.2019
comment
Если у вас также есть журналы транзакций, восстановите полную резервную копию (сохраненную до удаления) и используйте журналы транзакций для восстановления на момент времени до удаления таблицы. Возможно, вы захотите выполнить несколько тестовых восстановлений на вашем Sandbox Server, если таблица сильно загружена, чтобы попытаться максимально приблизиться к тому времени, когда она была удалена. Очевидно, что если вы восстанавливаете до момента времени, когда таблица не существует, вы зашли слишком далеко, но если вы находитесь на своем сервере-песочнице, вы можете восстанавливать столько раз, сколько хотите, в разное время, не нарушая ничего (далее).   -  person Larnu    schedule 15.01.2019
comment
Обратите внимание, что полное резервное копирование из после DROP здесь бесполезно. Вам нужна копия базы данных до. Если у вас есть только копия полной резервной копии базы данных после того, как вы сделали DROP, таблица исчезла, и вы практически ничего не можете с этим поделать, кроме повторного создания таблицы с помощью определения в системе управления версиями. Любые данные, которые были в этой таблице, скорее всего, будут потеряны, если только кто-то лично не помнит ее содержимое.   -  person Larnu    schedule 15.01.2019
comment
Я не сделал полный бэкап перед сбросом. И после дропа у меня 2 бэкапа лога. Также есть ли какой-либо сторонний инструмент, который может помочь в этом случае?   -  person Ivan Lewis    schedule 15.01.2019
comment
Итак, чтобы внести ясность, резервная копия, которую вы сделали ПОСЛЕ того, как вы удалили таблицу, была вашей первой полной резервной копией? Я прошу только для того, чтобы мы могли получить отправную точку, чтобы помочь вам, а не быть критичными. Если это так, то я бы спросил, как эта таблица была построена изначально и можете ли вы повторить эти шаги.   -  person JMabee    schedule 15.01.2019
comment
Вы не могли бы делать резервные копии журналов после сброса без предварительного создания полной резервной копии в какой-то момент времени.   -  person scsimon    schedule 15.01.2019
comment
1. У меня есть полная резервная копия 4-месячной давности. 2. INSERT, UPDATE, DELETE произошло в таблице из производственного приложения. 3. Я уронил стол. 4. Сделал полный бекап. 5. Я выполнил шаги, указанные здесь: sqlskills.com/blogs/paul/ 6. Автоматическое резервное копирование журнала транзакций по расписанию произошло на сервере с помощью задания агента sql. Теперь есть ли шансы восстановить падение, произошедшее на шаге 3, либо с помощью запросов sql, либо с помощью любого стороннего инструмента?   -  person Ivan Lewis    schedule 15.01.2019
comment
Есть ли у вас резервная копия всех журналов транзакций, сделанных с момента полного резервного копирования 4 месяца назад? Если это с регулярным интервалом (скажем, каждые 15 минут), вам понадобятся все (примерно) 11500 файлов журнала транзакций (4 (месяца) * 30 (дней) * 24 * (часа) * 4 (15-минутные интервалы)) если вам не хватает хотя бы одного файла, то (к сожалению) эти резервные копии журнала транзакций бесполезны, как только вы доберетесь до первого отсутствующего файла.   -  person Larnu    schedule 15.01.2019
comment
У меня есть полная резервная копия 4-месячной давности, и до падения таблицы никакая другая резервная копия не делалась.   -  person Ivan Lewis    schedule 15.01.2019
comment
Аааа, значит, когда вы запустили fn_dump_dblog при первой резервной копии журнала, нашли ли вы запись, показывающую, куда вы перетащили таблицу?   -  person JMabee    schedule 15.01.2019
comment
Да, это показало мне, и у меня есть этот номер. Но после этого запроса на восстановление STOPBEFOREMARK я не нахожу этот lsn в файле fun_db.   -  person Ivan Lewis    schedule 15.01.2019
comment
Итак, на отдельной машине вы восстановили базу данных 4-месячной давности и запустили восстановление журнала до STOPBEFOREMARK и получили эту ошибку?   -  person JMabee    schedule 15.01.2019
comment
Нет. Я не восстанавливал базу данных четырехмесячной давности. Я восстановил последнюю резервную копию после перехода в другую базу данных, как указано в этой ссылке. Появилась еще одна новая база данных, и в ней возникла вышеуказанная ошибка, которую я указал в своем вопросе.   -  person Ivan Lewis    schedule 15.01.2019
comment
Неа. Восстановите старый и запустите восстановление журнала до этого LSN. Ошибка, которую вы получаете, связана с тем, что база данных в полной резервной копии находится за пределами этого момента времени... если это имеет смысл.   -  person JMabee    schedule 15.01.2019
comment
Я обновил свой вопрос, указав, что именно я сделал.   -  person Ivan Lewis    schedule 15.01.2019


Ответы (1)


Хорошо, чтобы избежать долгих разговоров об этом, вот что я предлагаю:

  1. Восстановите полную резервную копию, которую вы сделали 4 месяца назад, а НЕ ту, которую вы сделали сегодня:

    ВОССТАНОВИТЬ БАЗУ ДАННЫХ [databasecopy] С ДИСКА = N'OLD_BACKUP.bak' С ПЕРЕМЕЩЕНИЕМ N'database' В N'C:\SQLskills\database2.mdf', ПЕРЕМЕСТИТЬ N'database_log' В N'C:\SQLskills\database2_log.ldf' , ЗАМЕНА, БЕЗ ВОССТАНОВЛЕНИЯ; ИДТИ

  2. Затем запустите RESTORE до этого LSN:

    ЖУРНАЛ ВОССТАНОВЛЕНИЯ [копия базы данных] С ДИСКА = N'D:\SQLskills\database_Log2.bak' WITH STOPBEFOREMARK = 'lsn:3420000002597000001', NORECOVERY; ВОССТАНОВИТЬ БАЗУ ДАННЫХ [databasecopy] С ВОССТАНОВЛЕНИЕМ; ИДТИ

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

person JMabee    schedule 15.01.2019
comment
Пожалуйста, проверьте, я обновил вопрос со скриншотами. Подтвердите, поможет ли мне ваш ответ. - person Ivan Lewis; 15.01.2019
comment
Поправьте меня, если я ошибаюсь, вы пытаетесь использовать свою текущую резервную копию, а я говорю вам использовать старую. - person JMabee; 15.01.2019
comment
Да. Я пытаюсь использовать текущую резервную копию. Также возможно ли отменить резервные копии (полные резервные копии и резервные копии журналов), которые были сделаны после сброса? Проверьте мое восстановление на скриншоте выше. Можно ли вернуться к состоянию базы данных на 15:00? - person Ivan Lewis; 15.01.2019
comment
Ответ, который я вам даю, заключается в том, чтобы использовать вашу старую резервную копию. Вы можете попробовать или нет. Единственный способ отменить что-либо - восстановить более старую копию, я думаю, в этом и есть смысл всего этого вопроса. - person JMabee; 15.01.2019
comment
Делая то, что вы сказали в своем ответе, могу ли я вернуть все данные таблицы? с 4 месяцев до вчерашнего дня. - person Ivan Lewis; 15.01.2019
comment
Ну я верю, что будет. - person JMabee; 16.01.2019
comment
Очевидно, восстановите его на другое имя базы данных, чтобы вы не перезаписывали свои производственные данные. - person JMabee; 16.01.2019