Так как проект находится в стадии разработки и опытной эксплуатации, он не успел выполнить резервную обработку, поэтому восстановление из резервной копии не удалось. Даже если есть резервная копия, данные на узле времени резервного копирования восстанавливаются, а это значит, что данные, сделанные с помощью платформы, нужно переделывать из времени резервного копирования, и могут быть пропуски.
Мой друг спросил меня, что делать.Во-первых, нет резервной копии, поэтому я могу только искать из журнала базы данных, а затем посмотреть, могу ли я получить предыдущие данные через журнал, а затем восстановить данные до состояния обновления . Затем я нашел инструмент ApexSQLLog. Далее я расскажу об использовании этого инструмента и о том, как восстанавливать данные. Существует несколько версий ApexSQLLog.Я использую ApexSQLLog2014 для поддержки более высокой версии SqlServer, а база данных использует SqlServer2014.
Сначала создайте тестовую библиотеку и тестовую таблицу.
Тестовая библиотека ApexSQLLogTest и тестовая таблица TestUser, а затем я вручную отредактировал в ней три куска данных, и сохранил отредактированные данные.
Используйте ApexSQLLog, чтобы открыть журнал тестовой библиотеки.
Выберите базу данных для подключения или откройте ее из последнего сеанса и откройте отфильтрованные записи, чтобы сохранить выход из сеанса.
Затем выберите файл журнала для фильтрации, и если есть резервный файл базы данных, он будет автоматически найден и указан здесь, и вы можете выбрать его в зависимости от ситуации.
Условная фильтрация
После того, как мы выберем файл журнала, мы войдем в выбор условий фильтрации, которые можно свободно комбинировать в условиях фильтрации.
Вы можете выбрать временной диапазон (Time range), операции (операции), таблицу (таблицы).
В дополнительных параметрах также можно выбрать пользователей, полевые условия и т. д.
Просмотр данных журнала
После того, как мы объединили условия фильтрации, мы входим в интерфейс анализа журнала и видим, что три фрагмента данных, которые мы вручную вставили ранее, фактически находятся в журнале, разделенном на три оператора вставки. Когда выбран один из журналов, вы можете увидеть изменение каждого значения поля, выполненное ниже.
Вы можете щелкнуть историю строк ниже, чтобы просмотреть записи, сценарий повтора может генерировать выполненные операции, а сценарий отмены может восстановить предыдущие данные. Восстанавливаем данные с помощью скрипта Undo.
Тест восстановления данных.
Мы используем оператор обновления, чтобы сбросить статус статуса на все 3.
обновите TestUser, установите Status = 3,
а затем обновите журнал, вы увидите, что есть еще три записи журнала обновлений, нажмите на первую, чтобы увидеть, что поле «Статус» ниже изменилось с 0 на 3.
Мы выбираем эти три записи, щелкая правой кнопкой мыши или используя функцию строки меню выше, и используем сценарий отмены создания для создания SQL восстановления.
-- Этот сценарий ОТМЕНЫ был создан с помощью журнала ApexSQL 2014.04.1133 от 10 июня 2020 г. 11:18:47.601
-- ПРИМЕЧАНИЕ. Операции в сценариях ОТМЕНЫ всегда выводятся в порядке убывания.
-- СЕРВЕР VIP-966\SQLEXPRESS
-- БАЗА ДАННЫХ ApexSQLLogTest
-- ОБНОВЛЕНИЕ (00000024:000000A0:0004), выполненное 10.06.2020 11:09:36.293 администратором VIP-966\Администратор в транзакции 0000:0000034B (зафиксировано) НАЧАТЬ
ТРАНЗАКЦИЮ
UPDATE [dbo].[TestUser] SET [Status] = 2 WHERE [Id] = 3
IF @@ROWCOUNT <= 1 COMMIT TRANSACTION ELSE BEGIN ROLLBACK TRANSACTION; PRINT 'ОШИБКА: ЗАЯВЛЕНИЕ ЗАТРАГИВАЕТ БОЛЕЕ ОДНОЙ СТРОКИ. ВСЕ ИЗМЕНЕНИЯ БЫЛИ ОТМЕНЕНЫ. КОНЕЦ
-- ОБНОВЛЕНИЕ (00000024:000000A0:0003) выполнено 10.06.2020 11:09:36.293 пользователем VIP-966\Администратор в транзакции 0000:0000034B (зафиксировано)
BEGIN TRANSACTION
UPDATE [dbo].[TestUser] SET [Status] = 1 WHERE [Id] = 2
IF @@ROWCOUNT <= 1 COMMIT TRANSACTION ELSE BEGIN ROLLBACK TRANSACTION; PRINT 'ОШИБКА: ЗАЯВЛЕНИЕ ЗАТРАГИВАЕТ БОЛЕЕ ОДНОЙ СТРОКИ. ВСЕ ИЗМЕНЕНИЯ БЫЛИ ОТМЕНЕНЫ. КОНЕЦ
-- ОБНОВЛЕНИЕ (00000024:000000A0:0002), выполненное 10 июня 2020 г. 11:09:36.293 пользователем VIP-966\Администратор в транзакции 0000:0000034B (зафиксировано) НАЧАТЬ ОБНОВЛЕНИЕ ТРАНЗАКЦИИ [dbo].[TestUser] SET
[
Status ] = 0 WHERE [Id] = 1
IF @@ROWCOUNT <= 1 COMMIT TRANSACTION ELSE BEGIN ROLLBACK TRANSACTION; PRINT 'ОШИБКА: ЗАЯВЛЕНИЕ ЗАТРАГИВАЕТ БОЛЕЕ ОДНОЙ СТРОКИ. ВСЕ ИЗМЕНЕНИЯ БЫЛИ ОТМЕНЕНЫ. END
GO
-- ЗАВЕРШЕНО 10.06.2020 11:18:47.697
-- ВСЕГО ОБРАБОТАННЫХ ОПЕРАЦИЙ 3
-- КОНЕЦ ФАЙЛАНаконец, мы можем использовать этот скрипт для восстановления данных.
Примечание.
Когда мы используем восстановление журнала, если в таблице есть первичный ключ, SQL будет сгенерирован в соответствии с первичным ключом, как показано в условии после где в приведенном выше SQL. Если в таблице нет первичного ключа, условие where после сгенерированного SQL выведет все поля. Когда я помог своему другу восстановить данные, я обнаружил, что его таблица не задавала первичный ключ, а полей было больше 20. SQL, сгенерированный из более чем 30 000 фрагментов данных, составлял более 100 МБ, и его нужно было расколот и казнен.
Например, если я удалю первичный ключ Id, а затем обновлю статус до 4, сгенерированный sql будет выглядеть следующим образом, и он подскажет, что первичного ключа нет.
