Ваши гаджеты

Восстановление баз данных

vita1980.80@mail.ru
10 февраля 2022
На чтение: 22 минуты 0 комментариев

Содержание

Восстановление баз данных решение, которое
Восстановление баз данных

1. Установите Recovery Toolbox for SQL Server на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;

Как восстановить базу MySQL

В данном примере показано восстановление из заранее сделанного dump-файла (с помощью mysqldump). Если нужна инструкция по созданию резервной копии, читайте Как сделать дамп базы MySQL.

Подготовка базы

Подключаемся к командной оболочке mysql:

* данной командой мы подключимся к СУБД под пользователем root. Опция -p потребует ввода пароля.

Для восстановления базы сначала необходимо ее создать:

> CREATE DATABASE db DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8 general ci;

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

> GRANT ALL PRIVILEGES ON db.* TO dbuser@localhost IDENTIFIED BY ‘password’ WITH GRANT OPTION;

Подробнее про создание баз читайте на странице Создание и удаление баз в MySQL/MariaDB.

Из файла через командную строку

Если при создании дампа использовалась gzip, сначала распаковываем архив:

Для удобства, создадим переменную с именем базы:

Команда выполняется из UNIX-shell:

* где root — учетная запись, от которой идет подключение к серверу баз данных; DNBAME — имя базы, которую необходимо восстановить (переменная, которую мы задали ранее); /tmp/recovery.sql — файл дампа, из которого восстанавливаем базу.
* можно также добавить опцию -v — она позволит показать на экране ход процесса, однако, она очень сильно снижает скорость восстановления — не рекомендуется ее использовать для больших баз.

На самом деле, если внутри дампа есть указание на переход к конкретной таблице (USE table), то восстановление будет выполняться в нее, а не ту таблицу, которую мы указали в переменной DBNAME. Как это проверить и изменить сказано ниже.

Если у нас много файлов, которые нужно импортировать, можно выполнить следующую команду:

cat /tmp/*.sql | mysql -u root -p db

* в данном случае мы прочитаем из каталога /tmp все файлы, заканчивающиеся на .sql и импортируем их содержимое в базу.

С помощью phpMyAdmin

Выбираем базу, которую нужно восстановить. Переходим на вкладку Импорт — кликаем по кнопке Выберите файл:

Восстановление баз данных

Выбираем файл с резервной копией.

Нажимаем по OK и ждем восстановления данных.

Пропускать ошибки

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

Суть сводится к простому добавлению ключа —force или -f:

mysql -v -u root -p -f db < /tmp/dump.sql

Восстановление в другую базу

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

* где database name — имя конкретной базы.

Для смены базы просто редактируем это значение на любое другое, например, строка:

. приведет к тому, что восстановление будет выполняться в базу new database name.

Если файл дампа большой, открывать его на редактирование может оказаться непростой задачей. Поменять название базы можно с помощью sed:

sed ‘s/USE `database name`;/USE `new database name`;/’ -i /tmp/dump.sql

* в данном примере мы заменим имя базы database name на new database name в файле /tmp/dump.sql.

Восстановление в другую таблицу

Команда mysql не предусматривает возможности восстановить дамп только для одной таблицы. Есть два варианта это обыграть.

1. Восстановление с применением временной базы.

Чтобы выполнить развертывание конкретной таблицы, нам нужно сначала сделать восстановление в отдельную базу, после чего скопировать таблицу в нужную базу командой на подобие этой (должна выполняться в среде SQL):

> INSERT INTO database name.table name SELECT * FROM new database name.table name;

* в данном примере выполняется копирование содержимого таблицы table name из базы данных new database name в базу database name.

2. Резервирование только одной таблицы.

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

mysqldump -uroot -p database name table name > /tmp/dump base table.sql

После чего уже выполняем восстановление из дампа.

Возможные ошибки

В процессе восстановления мы можем столкнуться с разными ошибками. Рассмотрим их примеры.

MySQL server has gone away

Во время восстановления базы может выскочить ошибка:

ERROR 2006 (HY000) at line xxx: MySQL server has gone away.

Как правило, ее причина в низком значении параметра max allowed packet, который отвечает за ограничение выполнения команд из файла. Посмотреть текущее значение можно командой в mysql:

> SHOW VARIABLES LIKE ‘max allowed packet’;

Чтобы увеличить значение параметра, открываем конфигурационный файл my.cnf:

* в некоторых версиях СУБД конфиг может находится по пути /etc/my.cnf.d/server.cnf.

В разделе [mysqldump] редактируем или добавляем:

[mysqldump]
.
max allowed packet = 512M

* значение для данного параметра не обязательно должно быть таким большим.

Перезапускаем mysql одной из команд:

systemctl restart mariadb

systemctl restart mysqld

systemctl restart mysql

Восстановление баз данных

Row size too large

Ошибка выскакивает после небольшого времени работы восстановления. Более полный текст выглядит, примерно, так:

ERROR 1118 (42000) at line 608: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

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

Решение:

Для решения проблемы мы можем добавить опцию innodb strict mode со значением 0. Данная опция регламентирует более строгий режим работы СУБД. Это грубое решение, которое позволит нам добиться результата, но мы можем выполнить настройку тонко — об этом можно прочитать на соответствующей странице блога mithrandir.ru.

Мы же сделаем все по-быстрому. Открываем конфигурационный файл СУБД — его местоположение зависит от версии и реализации, например:

* это пример расположения для базы MariaDB 10. Более точное расположение можно найти в файле /etc/my.cnf.

Приводим опцию innodb strict mode к виду:

[mysqld]
.
innodb strict mode = 0

systemctl restart mariadb

* в данном примере мы перезапустили сервис для mariadb.

Восстанавливаем базу данных SQL Server из режима “suspect”

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

Автор: Waqas, журналист в сфере информационной безопасности В случае выхода базы данных из строя может быть потеряна важная информация. Последствия потери данных могут быть катастрофическими как для пользователя, так и для бизнеса. Если крупные организации понесут огромные убытки, малые предприятия могут поплатиться своим существованием. По словам разработчиков, ошибка присутствует в каждой программе. Даже самое лучшее программное обеспечение может иногда давать сбой. Восстановление баз данных
Иногда работа и жизнь людей зависят от функциональности программного обеспечения. Корректная работа ПО влияет на финансовое благополучие или здоровье людей. Поэтому особенно важно, чтобы при сбоях программного обеспечения, имелась возможность быстро его вернуть в нормальное рабочее состояние. Программы работают с базами данных. В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса. Большинство баз данных работают на сервере Microsoft SQL. В случае проблем с сервером для восстановления базы потребуется много времени и сил. Восстановление баз данных
Существует несколько способов восстановить базу данных после инцидента. Во-первых, следует разобраться с таблицей подозрительных(suspect) страниц. Информация в таблице подозрительных страниц доступна любому пользователю, имеющему доступ к базе данных MSDB. Обновлять базу также может любой пользователь, имеющий разрешение на обновление. Владельцы базы, исправив роль базы данных в MSDB, или сисадмин, исправив роль сервера, могут вставлять, обновлять и удалять записи. Способы восстановления базы данных из подозрительного режима: Сброс статуса базы данных + DBCC CHECKDB DBCC CHECKDB Используйте программное обеспечение Recovery Toolbox for SQL Server Таблица подозрительных страниц содержит информацию о потенциально поврежденных страницах и используется при принятии решения о восстановлении страниц. Подозрительная страница из таблицы находится в базе данных MSDB. Страница считается «подозрительной», если при попытке ее чтения ядром СУБД SQL Server обнаруживается одна из следующих ошибок.

  • Ошибка 823: возникает во время проверки циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (возникает при некоторых аппаратных ошибках)
  • Ошибка 824: например, разрыв страницы (или любая другая логическая ошибка)

Идентификатор каждой «подозрительной» страницы записывается в таблицу подозрительных страниц. В данную таблицу компонент Database Engine записывает все подозрительные страницы, с которыми сталкивается во время обработки, в частности:

  • Когда при обработке запроса необходимо прочитать страницу.
  • При выполнении DBCC CHECKDB.
  • Во время операции резервного копирования.

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

Ниже приведены несколько способов восстановления базы данных, если она перешла в режим “suspected”.

Во время своей работы я однажды столкнулся с ситуацией, когда рабочая база данных в конце дня перешла в режим “suspected”. Причем в последний раз база была заархивирована много часов назад. К сожалению, вернуться в штатный режим не получилось. DBCC checkdb также отказался запускаться.

Я очень расстроился, пока не нашел решение. Рассмотрим первый способ восстановления базы данных.

Как восстановить сайт из резервной копии или бэкапа — восстановление из backup базы данных и файлов

Сначала необходимо перевести базу данных в АВАРИЙНЫЙ режим, выполнив следующие действия:

  • EXEC sp resetstatus ‘yourDBname’;
  • ALTER DATABASE yourDBname SET EMERGENCY

Затем требуется протестировать базу данных:

6.4 Модели восстановления баз данных

  • DBCC checkdb (‘yourDBname’)
  • ALTER DATABASE yourDBname SET SINGLE USER WITH ROLLBACK IMMEDIATE
  • DBCC CheckDB (‘yourDBname’, REPAIR ALLOW DATA LOSS)
  • ALTER DATABASE yourDBname SET MULTI USER

Если не получилось восстановить базу первым способом

У вас имеется поврежденная база данных сервера (MS SQL 2005) и она неисправна. Такую базу невозможно восстановить путем тестирования-исправления (возникает ошибка контрольной суммы). В таком случае база данных не выгружается в файл – выдается та же ошибка. Вы попробовали несколько раз, и это не помогло. Попробуйте восстановить базу данных, протестировав сам SQL.

Команды для тестирования SQL приведены ниже:

  • DBCC CHECKDB (‘database’, REPAIR FAST)
  • DBCC CHECKDB (‘database’, REPAIR REBUILD)

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

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

DBCC CHECKDB (‘database’, REPAIR ALLOW DATA LOSS)

Если команда не выполняется из-за не однопользовательского режима, используйте команду:

Alter database db-name set SINGLE USER

! Перед тестированием обязательно сделайте бэкап!

Используйте программу Recovery Toolbox for SQL Server — важный инструмент в работе любого системного администратора. Программа позволяет работать с файлами MS SQL Server любой версии.

Восстановление баз данных

Программа позволяет комплексно восстанавливать файлы базы данных. Особенности программы Recovery Toolbox for SQL Server приведены ниже:

1. Данные из нечитаемых баз данных можно восстановить в приостановленном состоянии (suspended state);

2. Программа работает со всеми версиями Microsoft SQL Server;

3. Программа позволяет восстановить самое важное и ценное в базе данных;

4. В базе данных несколько элементов — тоже не проблема;

5. Восстановливает таблицы при работе с MDF файлами;

6. SQL MDF Recovery экспортирует данные непосредственно в Microsoft SQL Server;

7. Информация сохраняется в том числе в виде скриптов;

8. Извлеченные данные напрямую экспортируются в новую базу данных;

9. Программа работает с любой версией Windows;

10. Мультиязычный интерфейс;

11. Возможен просмотр данных перед восстановлением;

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

Восстановление баз данных

Для восстановления данных после сбоя обычно используется резервная копия. Однако, если по какой-то причине копия не была сделана, попробуйте использовать Recovery Toolbox for SQL Server. Скорее всего, вам удастся восстановить рабочее состояние базы данных.

Для этого необходимо выполнить следующие действия:

1. Установите Recovery Toolbox for SQL Server на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;

2. Выберите файл;

6.7 Создание резервной копии и восстановление базы данных в MS SQL Server

3. После выполнения действий начнется анализ базы данных;

4. Изучите список всех восстановленных таблиц;

5. Просматривайте данные в таблицах;

6. Изучайте восстановленные объекты;

7. Настройте параметры сохранения;

8. Выберите необходимые данные;

9. Сохраните их (для этого потребуется полная версия)

Восстановление баз данных

Восстановление базы данных

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

Восстановление баз данных

Как это работает?

1. Выбираем поврежденную базу данных.

2. Смотрим, какие данные можно восстановить.

3. Определяемся с вариантом экспорта.

4. Выбираем данные для восстановления.

5. Просматриваем отчет после сохранения.

Программа условно-бесплатная, стоит 99 долларов. Скачать программу можно здесь.

Цифровой мир не прощает ошибок — подписывайтесь на наш канал и узнавайте, как избежать неприятностей и защитить свои данные!

SQL-Ex blog

Задачей номер 1, которую каждый администратор баз данных должен выполнять идеально, является восстановление базы данных, если она по какой-то причине окажется поврежденной. Модель восстановления (recovery model) базы данных определяет варианты, которые имеются у администратора при восстановлении базы данных. Если администратор не может восстановить базу данных в случае аварии, ему лучше стряхнуть пыль со своего резюме и начать искать новое направление работы.

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

Понимание моделей восстановления SQL Server

Каждая база данных на SQL Server имеет установку модели восстановления. SQL Server имеет три различных модели восстановления: простая (Simple), полная (Full) и с неполным протоколированием (Bulk-Logged). Установка модели восстановления определяет, какие варианты создания резервных копий и восстановления доступны для базы данных, а также то, каким образом ядро базы данных обрабатывает сохранение записей в журнале транзакций.

Журнал транзакций представляет собой подробный файл, который используется для записи обновлений, выполняемых в каждой транзакции. Ядро SQL Server использует этот журнал для поддержания целостности базы данных. В случае, если транзакция требует отката, или база данных повреждается по какой-то причине, журнал транзакций используется для восстановления базы данных в согласованное состояние. Модель восстановления для базы данных определяет, как много данных требуется записать SQL Server в журнал транзакций, и может ли быть выполнено восстановление к некоторой точке во времени. Начальная установка модели восстановления для новой базы данных определяется моделью восстановления системной базы данных model. Настройка модели восстановления базы данных может быть легко изменена либо с помощью SSMS, либо кодом T-SQL. Чтобы лучше понять детали каждой модели восстановления и то, как они влияют на доступные варианты резервирования и восстановления, позвольте мне сделать обзор каждой из имеющихся моделей восстановления.

Простая модель восстановления

Simple recovery model является самой простой из моделей восстановления. Когда используется эта модель, каждая транзакция по-прежнему записывается в журнал транзакций. Записи журналов транзакций будут автоматически удаляться , если используется простая модель восстановления. Этот процесс удаления происходит для всех завершенных транзакций, когда устанавливается контрольная точка. Поскольку записи журнала удаляются при возникновении контрольной точки, резервирование журналов транзакций не поддерживается при использовании простой модели восстановления. Это означает, что восстановление к заданному моменту времени не может быть выполнено, если для базы данных модель восстановления установлена в SIMPLE. Поскольку в данном режиме журнал транзакций автоматически очищается, это позволяет сохранять его малый размер и избежать контроля над его ростом.

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

Полная модель восстановления

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

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

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

Модель восстановления с неполным протоколированием

Модель восстановления с неполным протоколированием минимизирует использование пространства журнала транзакций при операциях с неполным протоколированием, подобных BULK INSERT, SELECT INTO или CREATE INDEX. Функцилнальность этой модели подобна полной модели восстановления за исключением того, что записи в журнал транзакции минимально протоколируются при выполнении указанных операций. Минимальное протоколирование помогает поддерживать журнал меньших размеров, но при этом журнализируется не так много информации.

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

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

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

Какая модель восстановления используется?

Существует много способов для определения того, какая модель восстановления для базы данных используется. Одним вариантом определения модели восстановления является SQL Server Management Studio. Для этого сначала щелкните правой кнопкой на базе данных и выберите пункт "Properties" (свойства) из меню. В окне свойств выберите пункт "Options" (опции) в левом контекстном меню. Выполнив эти действия, вы увидите нижеприведенное окно.

Рис.1: Опция Recovery Model

Рисунок 1 показывает, что для базы данных AdventureWorks2017 модель восстановления установлена в значение Simple.

Другим способом отображения свойств восстановления базы данных является выполнение кода T-SQL, показанного в листинге 1.

Листинг 1: Код для отображения модели восстановления 

SELECT name, recovery model desc 
FROM sys.databases 
WHERE name = 'AdventureWorks2017' ;

Изменение модели восстановления

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

Листинг 2: Изменение модели восстановления с помощью кода T-SQL 

USE master; 
GO 
ALTER DATABASE AdventureWorks2017 SET RECOVERY FULL; 
GO

В листинге 2 модель восстановления для базы данных AdventureWorks2017 была изменена на FULL. Кроме того, вы можете изменить модель восстановления базы данных с помощью страницы свойств SSMS, показанного на рисунке 1. Для этого просто выберите требуемый вариант в поле Recovery Model, а затем щелкните OK.

Восстановление баз данных для каждой модели восстановления

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

Простая модель восстановления

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

Полная модель восстановления

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

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

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

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

Модель восстановления в неполным протоколированием

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

Модели восстановления

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

Обратные ссылки

SQL-Ex blog on Суббота, 1 января. 2022 : Архитектура журнала транзакций SQL Server

Show preview

Пересказ статьи Greg Larsen. SQL Server transaction log architecture Журнал транзакций — это файл, который имеет каждая база данных SQL Server. Его можно представить как журнал активности обновлений, которые происходят в базе данных. Журнал транзакций ис

Комментарии

Показывать комментарии Как список | Древовидной структурой

Автор не разрешил комментировать эту запись

Похожие статьи

  • Восстановление данных с помощью r studio

    Содержание Программа для восстановления файлов R-Studio: как пользоваться ↑ Программа для восстановления файлов R-Studio: как пользоваться ↑ Полный поиск…

  • Восстановление базы данных access

    Содержание Как сжать и восстановить базу данных Access Как сжать и восстановить базу данных Access 1]Как сжать и восстановить базу данных в Access…

  • Восстановление поврежденных архивов

    Содержание Восстановление повреждённых файлов на основе CRC32 Не открывается фото? Как восстановить поврежденное фото Восстановление архива Easy RAR…

Нравится: 0
Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Что будем искать? Например,Человек

Мы в социальных сетях