ГлавнаяРазноеВосстановление базы sql

Восстановление базы SQL в виде файла на тот же сервер в другое местоположение. Восстановление базы sql


Восстановление базы SQL стандартными средствами

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

Запомните,  если Вы восстанавливаете базу, используя Simple Recovery Model, Вам нужно будет восстановить только последнюю полную копию. Если же Вы используете Full или Bulk Recovery Model , Вы должны восстановить полную копию, затем последнюю дифференциальную копию и все копии журналов транзакций. Изучим подробнее процессы восстановления.

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

Независимо от модели восстановления, первым шагом всегда является восстановление последней полной резервной копии. Для восстановления БД в Enterprise Manager, следует выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, после этого откроется диалоговое окно, показанное на Рисунке A.

Рисунок А.

 

Диалоговое окно Restore Database позволяет просматривать все последние резервные копии в хронологическом порядке. Там же Вы можете выбрать базу данных, которую нужно восстановить. На вкладке Options показанной на Рисунке B, Вы можете выбрать сделующие опции:

  • Eject tapes after restoring each backup (выгружать ленту после каждого восстановления)
  • Prompt befor restoring each backup (выдавать дополнительное предупреждение перед началом восстановления каждой копии)
  • Force restore over existing database (осуществлять восстановление поверх существующей базы данных), эта опция эквивалентна Move в T-SQL.

Рисунок B.

 

В нижней части окна находятся три переключателя, которые позволяют определить состояние базы после восстановления копии:

  • Leave Database Operational. No Additional Transaction Logs Can Be Restored.
    • Если Вы выбрали это значение, то после загрузки резервной копии будет инициирован процесс восстановления, что приведет к откату всех незавершенных транзакций. Станет невозможной загрузка дополнительных копий журнала транзакций. Пользователи получат возможность нормально работать с базой данных.
  • Leave Database Nonoperational But Able To Restore Additional Transaction Logs.
    • По окончании загрузки копии база данных будет оставаться временно недоступной. Будет необходимо загрузить дополнительные копии, после чего инициировать процесс восстановления.
  • Leave Database Read-Only And Able To Restore Additional Transaction Logs.
    • База данных становится доступной только для чтения. Вы можете загрузить дополнительные резервные копии журнала транзакций. Эта опция используется для создания резервного сервера (Standby Server)

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

Восстановление базы данных с помощью T-SQL.

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

RESTORE DATABASE { database_name | @database_name_var }[ FROM < backup_device > [ ,...n ] ][ WITH[ RESTRICTED_USER ][ [ , ] FILE = { file_number | @file_number } ][ [ , ] PASSWORD= { password | @password_variable } ][ [ , ] MEDIANAME= { media_name | @media_name_variable } ][ [ , ] MEDIAPASSWORD= { mediapassword | @mediapassword_variable } ][ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ][ ,...n ][ [ , ] KEEP_REPLICATION ][ [ , ] { NORECOVERY | RECOVERY | STANDBY =undo_file_name } ][ [ , ] { NOREWIND | REWIND } ][ [ , ] { NOUNLOAD | UNLOAD } ][ [ , ] REPLACE ][ [ , ] RESTART ][ [ , ] STATS [ =percentage ] ]

Для детального изучения каждой опции следует прочитать описание в SQL Server 2000 Books Online.

На Рисунке C показано восстановление базы данных Pubs из полной копии с устройства резервного копирования.

Рисунок С.

 

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

Если Вы используете Full или Bulk Recovery Model, Вы должны выполнить сначала восстановление полной резервной копии, затем последней дифференциальной копии и всех журналов транзакций. Для выполнения восстановления базы данных, используя дифференциальную копию, в Enterprise Manager необходимо выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, выбрать восстановления полной и дифференциальной копии базы данных, а затем нажать OK. (исунок D)

Рисунок D.

 

Синтаксис команды Restore для выполнения восстановления с использованием дифференциальных копий, показан на Рисунке Е.

Рисунок Е.

 

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

Перед началом восстановления журнала транзакций, Вы должны восстановить полную и последнюю дифференциальную копию базы. Затем Вы можете восстанавливать журналы транзакций в соответсвующем порядке. Если Вы используете Enterprise Manager, нужно выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, выбрать все нужные копии и, если есть необходимость, опцию Point in Time Restore (восстановление на определенный момент времени) (Рисунок F).

Рисунок F.

 

Синтаксис команды Restore для восстановления журнала транзакций, показан на РисункеG.

Рисунок G.

 

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

www.compline-ufa.ru

Аварийное восстановление базы данных SQL

  • 07/16/2018
  • Время чтения: 9 мин
  • Соавторы

В этой статье

База данных SQL Azure предоставляет следующие возможности восстановления после сбоя:Azure SQL Database offers the following capabilities for recovering from an outage:

Чтобы узнать о сценариях непрерывности бизнес-процессов и функциях, которые их обеспечивают, ознакомьтесь с непрерывностью бизнес-процессов.To learn about business continuity scenarios and the features supporting these scenarios, see Business continuity.

Примечание

При использовании избыточных между зонами пулов и баз данных уровня "Премиум"или "Критически важный для бизнеса" процесс восстановления автоматизирован. Поэтому описанные в этой статье действия выполнять не нужно.If you are using zone-redundant Premium or Business Critical databases or pools, the recovery process is automated and the rest of this material does not apply.

Подготовка к событию сбояPrepare for the event of an outage

Для успешного восстановления в другой регион с помощью групп отработки отказа или геоизбыточных резервных копий необходимо подготовить сервер в другом центре обработки данных, который в случае сбоя станет новым сервером-источником, если это будет необходимо. Следует также задокументировать и внедрить четко определенные инструкции, чтобы обеспечить отсутствие проблем при восстановлении.For success with recovery to another data region using either failover groups or geo-redundant backups, you need to prepare a server in another data center outage to become the new primary server should the need arise as well as have well-defined steps documented and tested to ensure a smooth recovery. Эти подготовительные действия приведены ниже.These preparation steps include:

  • Определите в другом регионе логический сервер, который станет новым сервером-источником.Identify the logical server in another region to become the new primary server. При использовании геовосстановления обычно это сервер в сопряженном регионе того региона, в котором расположена база данных.For geo-restore, this is generally a server in the paired region for the region in which your database is located. Это исключает дополнительные затраты на трафик во время операций геовосстановления.This eliminates the additional traffic cost during the geo-restoring operations.
  • Идентифицируйте и при необходимости определите правила брандмауэра уровня сервера, требуемые пользователям для доступа к новой базе данных-источнику.Identify, and optionally define, the server-level firewall rules needed on for users to access the new primary database.
  • Определите, как пользователи будут перенаправляться к новому серверу-источнику: например, изменяя строки подключения или записи DNS.Determine how you are going to redirect users to the new primary server, such as by changing connection strings or by changing DNS entries.
  • Определите и при необходимости создайте имена для входа, которые должны присутствовать в базе данных master на новом сервере-источнике, и убедитесь, что эти имена для входа имеют соответствующие разрешения в базе данных master, если таковые имеются.Identify, and optionally create, the logins that must be present in the master database on the new primary server, and ensure these logins have appropriate permissions in the master database, if any. Дополнительные сведения см. в разделе Как управлять безопасностью базы данных SQL после аварийного восстановления.For more information, see SQL Database security after disaster recovery
  • Определите правила генерации оповещений, которые потребуется обновить для сопоставления с новой базой данных-источником.Identify alert rules that need to be updated to map to the new primary database.
  • Задокументируйте конфигурацию аудита текущей базы данных-источника.Document the auditing configuration on the current primary database
  • Выполните отработку аварийного восстановления.Perform a disaster recovery drill. Чтобы сымитировать сбой для географического восстановления, можно удалить или переименовать исходную базу данных, что приведет к сбою подключения приложения.To simulate an outage for geo-restore, you can delete or rename the source database to cause application connectivity failure. Чтобы сымитировать сбой с помощью групп отработки отказа, отключите веб-приложение или виртуальную машину, подключенную к базе данных, или отработку отказа базы данных, чтобы вызвать сбой подключения приложения.To simulate an outage using failover groups, you can disable the web application or virtual machine connected to the database or failover the database to cause application connectivity failures.

Время начала восстановленияWhen to initiate recovery

Операция восстановления влияет на приложение.The recovery operation impacts the application. Для ее выполнения необходимо изменить строку подключения SQL или перенаправление с помощью DNS, что может привести к безвозвратной потере данных.It requires changing the SQL connection string or redirection using DNS and could result in permanent data loss. Поэтому восстановление следует выполнять, только если сбой будет длиться дольше, чем целевое время восстановления приложения.Therefore, it should be done only when the outage is likely to last longer than your application's recovery time objective. При развертывании приложения в рабочей среде следует выполнять регулярное отслеживание работоспособности приложений и использовать следующие точки данных для подтверждения гарантированного восстановления.When the application is deployed to production you should perform regular monitoring of the application health and use the following data points to assert that the recovery is warranted:

  1. Постоянная ошибка подключения из уровня приложения к базе данных.Permanent connectivity failure from the application tier to the database.
  2. На портале Azure отображается оповещение о происшествии с большой степенью воздействия в регионе.The Azure portal shows an alert about an incident in the region with broad impact.

Примечание

Если вы используете группы отработки отказа и настраиваете автоматический переход на другой ресурс, восстановление выполняется автоматически. Кроме того, этот процесс прозрачен для приложения.If you are using failover groups and chose automatic failover, the recovery process is automated and transparent to the application.

В зависимости от устойчивости приложения к простоям базы данных и возможных последствий для бизнеса можно рассмотреть следующие варианты восстановления.Depending on your application tolerance to downtime and possible business liability you can consider the following recovery options.

Для получения последней геореплицированной точки восстановления используйте операцию получения восстанавливаемой базы данных (LastAvailableBackupDate).Use the Get Recoverable Database (LastAvailableBackupDate) to get the latest Geo-replicated restore point.

Ожидание восстановления службWait for service recovery

Группы Azure прилагают все усилия для максимально быстрого восстановления работоспособности служб, но в зависимости от причины это может занимать часы и даже дни.The Azure teams work diligently to restore service availability as quickly as possible but depending on the root cause it can take hours or days. Если длительный простой некритичен для вашего приложения, вы можете просто дождаться завершения восстановления.If your application can tolerate significant downtime you can simply wait for the recovery to complete. В этом случае вам не нужно предпринимать какие-либо действия.In this case, no action on your part is required. Текущее состояние служб можно просмотреть на панели мониторинга работоспособности служб Azure.You can see the current service status on our Azure Service Health Dashboard. После восстановления региона ваше приложение снова станет доступным.After the recovery of the region, your application’s availability is restored.

Отработка отказа на геореплицированный сервер-получатель в группе отработки отказаFail over to geo-replicated secondary server in the failover group

Если простой может негативно влиять на организацию, в приложении следует использовать группы отработки отказа.If your application’s downtime can result in business liability, you should be using failover groups. Это позволит приложению в случае сбоя быстро восстановить доступность в другом регионе.It enables the application to quickly restore availability in a different region in case of an outage. Узнайте, как настроить группы отработки отказа.Learn how to configure failover groups.

Чтобы восстановить доступность баз данных, необходимо инициировать отработку отказа на сервер-получатель с помощью одного из поддерживаемых методов.To restore availability of the database(s) you need to initiate the failover to the secondary server using one of the supported methods.

Чтобы настроить переход на геореплицированную базу данных-получатель, используйте сведения в одном из следующих руководств:Use one of the following guides to fail over to a geo-replicated secondary database:

Восстановление с использованием геовосстановленияRecover using geo-restore

Если простой в работе приложения не скажется на вашем бизнесе, в качестве метода восстановления баз данных приложения можно использовать геовосстановление.If your application’s downtime does not result in business liability you can use geo-restore as a method to recover your application database(s). Эта функция создает копию базы данных из последней геоизбыточной резервной копии.It creates a copy of the database from its latest geo-redundant backup.

Настройка базы данных после восстановленияConfigure your database after recovery

Если вы выполняете восстановления после сбоя с помощью геовосстановления, убедитесь, что подключение к новым базам данных настроено надлежащим образом. В противном случае вы не сможете восстановить нормальную работу приложения.If you are using geo-restore to recover from an outage, you must make sure that the connectivity to the new databases is properly configured so that the normal application function can be resumed. Ниже приведен контрольный список задач для подготовки восстановленной базы данных к использованию в рабочей среде.This is a checklist of tasks to get your recovered database production ready.

Обновление строк подключенияUpdate connection strings

Так как восстановленная база данных будет находиться на другом сервере, измените строку подключения в приложении, чтобы она указывала на этот сервер.Because your recovered database resides in a different server, you need to update your application’s connection string to point to that server.

Дополнительные сведения об изменении строк подключения см. в разделе о соответствующем языке разработки для своей библиотеки подключений.For more information about changing connection strings, see the appropriate development language for your connection library.

Настройка правил брандмауэраConfigure Firewall Rules

Убедитесь, что правила брандмауэра, настроенные на сервере и в базе данных, соответствуют правилам, настроенным на основном сервере и в базе данных-источнике.You need to make sure that the firewall rules configured on server and on the database match those that were configured on the primary server and primary database. Дополнительные сведения см. в статье Практическое руководство. Настройка параметров брандмауэра для Базы данных SQL.For more information, see How to: Configure Firewall Settings (Azure SQL Database).

Настройка учетных данных и пользователей базы данныхConfigure logins and database users

Убедитесь, что все учетные данные, используемые приложением, существуют на сервере с восстановленной базой данных.You need to make sure that all the logins used by your application exist on the server which is hosting your recovered database. Дополнительные сведения см. в статье Настройка безопасности Базы данных SQL Azure и управление ею для геовосстановления или отработки отказа.For more information, see Security Configuration for geo-replication.

Примечание

Необходимо настроить и протестировать правила брандмауэра и имена для входа (и их разрешения) на сервере во время отработки аварийного восстановления.You should configure and test your server firewall rules and logins (and their permissions) during a disaster recovery drill. Эти объекты уровня сервера и их конфигурации могут быть недоступны во время сбоя.These server-level objects and their configuration may not be available during the outage.

Настройка оповещений телеметрииSetup telemetry alerts

Убедитесь, что существующие настройки правил оповещения обновлены. Они должны соответствовать восстановленной базе данных и другому серверу.You need to make sure your existing alert rule settings are updated to map to the recovered database and the different server.

Подробнее о правилах генерации оповещений базы данных см. в разделах Получение уведомлений об оповещениях и Получение информации о работоспособности службы.For more information about database alert rules, see Receive Alert Notifications and Track Service Health.

Включение аудитаEnable auditing

Если для доступа к базе данных требуется аудит, то после восстановления базы данных необходимо включить аудит.If auditing is required to access your database, you need to enable Auditing after the database recovery. Дополнительные сведения см. в статье Аудит базы данных.For more information, see Database auditing.

Дополнительная информацияNext steps

docs.microsoft.com

Как восстановить поврежденную или подвешенную базу данных Microsoft SQL Server?

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

  1. Свойство FILE SIZE неверно. (Microsoft SQL Server, Error:5172)
  2. SQL Server обнаружил ошибку логической несогласованности операций ввода/вывода: Неверная контрольная сумма. (Microsoft SQL Server, Error:824)
  3. Страница индекса карты размещения (IAM) указывает на следующий указатель страницы IAM.
  4. Ошибка ввода/вывода обнаружена (некорректный ID страницы) при чтении со смещением 0x###### в файле FileName.mdf.
  5. Представленный файл обрезан Операционной системой.
  6. В течении переделывания логической операции в базе данных DatabaseName, выявлена ошибка в ID лога.

Возможности утилиты восстановления баз данных MS SQL Server

  1. Восстановление баз данных SQL Server и *.MDF файлов всех версий Microsoft SQL Servers: 7/2000/2005/2008/2008 R2/2012/2014/2016
  2. Восстановление всех объектов поврежденного .mdf файла: типы данных, данные таблиц, просмотры, сохраненные процедуры, пользовательские функции, триггеры, индексы, главные и внешние ключи, ограничения и прочее
  3. Восстановление баз данных SQL сохраненных в нескольких файлах (*.mdf + *.ndf файлы)
  4. Экспорт восстановленных данных напрямую в базу данных Microsoft SQL Server
  5. Сохранение исправленных данных как SQL скрипты
  6. Предварительный просмотр восстановленных данных и структур
  7. Утилита восстановления SQL успешно протестирована под Windows 98/Me/2000/XP/Vista/7/8/10 или Windows Server 2003/2008/2012/2016 и выше
  8. Многоязычный интерфейс для исправления MDF файлов

sql.recoverytoolbox.com

Восстановление базы SQL в виде файла на тот же сервер в другое местоположение

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

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

Восстановление базы SQL выполнено средствами программного продукта Arcserve Backup

Шаги по восстановлению базы данных SQL в другое местоположение на тот же сервер, но под другим именем

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

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

Основное требование – не производить никакие деструктивные действия с текущей версией этой базы данных, работающей на сервере Microsoft SQL.

Однако эта задача имеет скрытые особенности.

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

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

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

Путь решения восстановления базы SQL

Открыть менеджер восстановления Quick Start-> Restore и выбрать базу данных MS SQL, которую необходимо восстановить в виде файла. 

Нажать на выбранной базе данных правую кнопку мыши и выбрать 'Agent Option...' 

 

  • Перейти на закладку 'Database File Options' 
  • Выделить мышью название базы данных и выбрать опцию 'Restore to Original Location, Except:' 
  • Выбрать опцию 'Move to Directory' и ввести название директории, в которую необходимо произвести восстановление базы данных как файла. (Если необходимо произвести восстановление на другой диск, необходимо выбрать опцию 'Move to Drive') 
  • Выбрать опцию 'Filename Pattern Change' – Ввести маску существующего имени базы данных и маску нового имени базы данных. 

 

В нашем примере, мы меняем маску названия базы данных с 'User1*' на 'Restored_User1*' 

  • Нажать кнопку 'Apply', затем нажать кнопку OK

 

На закладке Destination в ARCserve Restore Manager, снять «галочку» с опции 'Restore files to their Original location(s)' 

Раскрыть сервер MS SQL через агент Arcserve SQL и выделить мышью пиктограмку 'Microsoft SQL Server'. На картинке ниже показан пример. 

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

\\Server-Name\MSSQLSERVER\Restored_User1_DB

При формировании задания на восстановление проверьте, введены ли логины и пароли в обеих закладках окна «Session User Name and Password»

По завершении восстановления базы SQL, через консоль управления сервером Microsoft SQL вы увидите восстановленную базу SQL на своем сервере SQL:

 

Работа Arcserve с виртуальными системами

 

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

Подробную информацию о том, как Arcserve работает с виртуальными системами можно найти в подборке статей "Работа Arcserve с виртуальными системами"

 

Лучший способ проверить превосходство Arcserve - испытать его

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

Просто найдите в меню "Пробные версии" и оформите получение бесплатной пробной версии Arcserve

На все время тестирования Arcserve вы будете подключены к бесплатной технической поддержке.

Начните строить современную систему резервного копирования прямо сейчас.

 

Где купить Arcserve Backup

 

Получить дополнительную информацию о продукте Arcserve Backup и приобрести его можно в фирменном он-лайн магазине:

 

 Фирменный он-лайн магазин Arcserve Shop.Arcserve.RU

 

К вашим услугам предлагаются следующие бесплатные сервисы:

  • Бесплатный расчет спецификации Arcserve
  • Бесплатная пробная версия Arcserve

Разработчик - Arcserve LLC, Операционные системы: Windows, Linux, UNIX, MacOS, FreeBSD

Тип: Программа для резервного копирования

Официальный дистрибьютор: УЦ Компьютер-Пресс Технологии

 

 

www.arcserve.ru

Как восстановить базу данных Microsoft SQL Server 2008 из архива | Info-Comp.ru

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

Как создать архив базы данных на Microsoft SQL Server 2008 мы научились, теперь давайте научимся восстанавливать базу из этих архивов.

Примечание! Восстанавливать базу будем также на локальном сервере (MS SQL Server 2008) под управлением операционной системой Windows 7. База с названием test. Если Вы не знаете как вообще создается база то рекомендую ознакомиться с материалом Как создать базу данных в Microsoft SQL Server 2008.

Восстанавливаем базу данных SQL сервера через графический интерфейс

Открываем Management Studio, раскрываем «Базы данных», выбираем необходимую для восстановления базу, щелкаем правой кнопкой мыши Задачи->Восстановить->База данных

Затем открывается окно «Восстановление базы данных», где Вы выбираете нужный архив (в прошлом уроке мы создали архив на диске C в папке temp с названием test_arh.bak), и в нашем случае там будет всего один набор данных, выбираем его

Далее перейдем на пункт «Параметры» и поставим галочку напротив «Перезаписать существующую базу данных (WITH REPLACE)».

Это мы сделаем, для того чтобы перезаписать журнал транзакций, в противном случае база не восстановится, если Вам необходимо сохранить прежний журнал транзакций, то его можно предварительно сохранить, через пункт Задачи->Создать резервную копию->Тип резервной копии «Журнал транзакций»

Все жмем «ОК». Если Вы увидите следующее сообщение, то все хорошо

Если появится сообщение следующего содержимого

То это означает, что в данной базе кто-то работает, если Вы уверены, что в ней никто не работает, то в этом случае в ней работаете ВЫ, скорей всего у Вас просто открыто окно запросов, к этой базе данных, закройте его и все.

Восстанавливаем базу данных с помощью сценария

Для того чтобы создать сценарий мы также открываем Задачи->Восстановить->База данных вводим все необходимые параметры и жмем не «ОК» как в прошлом случае, а «Сценарий»

Затем у Вас откроется окно запросов и в нем будет следующий сценарий

RESTORE DATABASE [test] FROM DISK = N'C:\temp\test_arh.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10 GO

Если Вы его запустите, то получится, то же самое что и при нажатии кнопки «ОК» в окне «Восстановление базы данных».

Рассматривать написание бат файла не будем так как восстанавливать базу приходиться не так часто как ее архивировать, тем более что процесс практически одинаковый, если все же Вам интересно то можете это посмотреть в прошлой нашей статье Как создать архив базы данных на MS SQL 2008 там мы рассматривали возможность архивирования базы с помощью батника, Вам необходимо переделать только файл со сценарием, т.е. вставить тот который мы получили сегодня. Также если Вам интересно, то ранее мы рассматривали возможность восстановления базы данных на СУБД PostgreSQL в статье Как восстановить базу данных PostgreSQL из архива.

На этом предлагаю закончить. Удачи!

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

info-comp.ru

Восстановление и предотвращение утери файлов Microsoft SQL Server

Читайте, как восстановить удалённую базу MSSQL используя встроенные в приложение инструменты или сторонние программы. Рассмотрим причины, по которым база может быть утеряна, а также способы восстановления для каждого из них. SQL Server – это система управления реляционными базами данных (СУБД) от Microsoft, которая изначально разрабатывалась компанией как конкурент набиравшим популярность Oracle Database и MySQL.

Основным инструментом интерфейса SQL Server является Microsoft SQL Server Management Studio (SSMS).

Как и большинство СУБД Microsoft SQL Server поддерживает стандарт ANSI SQL. Но, СУБД от Microsoft также использует собственную реализацию стандарта – T-SQL.

Содержание:
  1. Файлы системы Microsoft SQL Server.
  2. Причины утери данных MSSQL.
  3. Способы восстановления базы данных.
  4. Восстановление удалённой базы с Hetman Partition Recovery.
  5. Как создать копию базы SQL Server для дальнейшего восстановления, импорта или переноса.

Файлы системы Microsoft SQL Server

Файлы базы SQL Server по умолчанию сохраняются на диске С компьютера:

C:\Program Files\Microsoft SQL Server

Причём под каждую базу создаётся отдельная папка с её названием. Например, в нашем случае создано две базы данных Microsoft SQL Server: MSSQL13.SQLEXPRESS, MSSQL13.MSSQLHETMAN.

Данные любой из баз данных MSSQL хранятся в рабочих системных файлах, которых есть три типа:

  • *.mdf – это первичный файл данных базы. В таком файле содержатся сведения, которые необходимы для запуска базы, ссылки на другие файлы базы, данные и объекты пользователя. В .mdf файле физически хранятся данные базы.
  • *.ndf – вторичные файлы данных базы, которые также используются системой для хранения данных базы.
  • *.ldf – файлы журнала транзакций (лог файлы).

Каждый из указанных файлов имеет название базы данных и хранится в папке \DATA:

C:\Program Files\Microsoft SQL Server\Название_Базы_Данных\MSSQL\DATA

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

Причины утери данных MSSQL

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

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

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

Человеческий фактор. Утеря данных в результате неумышленных действий пользователя или администратора системы.

Способы восстановления базы данных

Есть несколько способов резервирования и восстановления данных базы SQL Server. Использование каждого из них зависит от преследуемой цели: плановое создание бэкапа базы данных или восстановление из него при переносе базы данных на другую машину, или необходимость восстановления данных базы MSSQL в результате её утери или удаления.

Создать копию базы данных для дальнейшего восстановления можно как с помощью встроенных в Microsoft SQL Server Management Studio инструментов, так и вручную. Создание и восстановление базы данных из созданной вручную копии, это более быстрый процесс чем создание и разворачивание резервной копии, но не такой надёжный.

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

Для этого:

  • Запустите Диспетчер конфигурации SQL Server (Sql Server Configuration Manager)

  • Выберите Службы SQL Server

  • В правом окне диспетчера кликните правой кнопкой мыши на базе данных которую необходимо остановить и выберите «Остановить».

  • Запустить базу данных можно аналогичным образом, выбрав пункт меню «Запустить».

Также базу данных можно остановить и запустить с помощью команд:

  • В Transact-SQL: SHUTDOWN;
  • Из окна командной строки: Net stop MSSQLHETMANNet start MSSQLHETMANГде, MSSQLHETMAN – название базы данных

Восстановление удалённой базы с Hetman Partition Recovery

В случае утери или удаления базы данных SQL Server из компьютера, её можно восстановить при условии, что его диск сохранил свою работоспособность. Это можно сделать с помощью программы для восстановления данных жесткого диска Hetman Partition Recovery.

Чтобы восстановить утерянные файлы данных базы MS SQL Server:

  • Запустите Hetman Partition Recovery и просканируйте с её помощью диск на котором были сохранены файлы данных SQL Server

  • Перейдите с помощью проводника программы в папку с файлами данных базы

  • Восстановите необходимые *.mdf, *.ndf, *.ldf файлы данных

  • Присоедините восстановленные файлы данных к базе SQL Server используя функцию «Присоединить…»

    Для этого, войдите в базу данных и кликните правой кнопкой мыши на папке «Базы данных». Выберите меню «Присоединить…» / кнопка «Добавить», после укажите *.mdf файл данных восстановленной базы и нажмите OK.

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

Как создать копию базы SQL Server для дальнейшего восстановления, импорта или переноса

Чтобы избежать утери данных базы MSSQL в случае возникновения непредвиденных обстоятельств, в случае необходимости импорта базы или её переноса из одной машины на другую, в Microsoft SQL Server Management Studio (SSMS) предусмотрен целый ряд инструментов на разные случаи, часть из которых мы уже упоминали в данной статье.

Создать резервную копию… / Восстановить

Чтобы создать резервную копию базы данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи / Создать резервную копию…

В результате, в папке \Backup

C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLHETMAN\MSSQL\Backup

будет создан *.bak файл с резервной копией базы данных.

Чтобы восстановить резервную копию базы данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи / Восстановить, и укажите путь к файлу резервной копии.

Импорт данных… / Экспортировать данные…

C помощью функции Импорта / Экспорта данных Microsoft SQL Server можно скопировать данные из источника в файл назначения или сервер. Данная функция поддерживает такие источники данных:

  • SQL Server
  • Microsoft Access
  • Microsoft Excel
  • Неструктурированные файлы

Другими словами, из SQL Server базы данные можно экспортировать на другой SQL Server или в файл Access, Excel, неструктурированный файл. Из этих же источников можно импортировать данные в SQL Server.

Чтобы экспортировать данные базы, кликните на папке с её названием правой кнопкой мыши и выберите Задачи / «Экспортировать данные…».

После чего укажите с помощью открывшегося Мастера импорта и экспорта SQL Server, Источник и Куда копировать данные.

Импортировать данные в базу можно аналогичным образом, с помощью меню Задачи / «Импорт данных…».

Отсоединить… / Присоединить…

Самым подходящим способом создания копии базы данных для переноса её на другую машину, есть функция Отсоединить… / Присоединить…

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

Такие файлы данных можно перенести в другое удобное пользователю место без риска утери данных из соответствующей базы и подсоединить их к SQL Server другого компьютера (с версией не ниже отсоединённой).

Чтобы отсоединить базу данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи / «Отсоединить…» / Ok.

Чтобы присоединить базу данных, кликните на папке «Базы данных» правой кнопкой мыши и выберите «Присоединить…» / Добавить, после чего укажите путь к *.mdf файлу базы данных которую необходимо присоединить.

Примечание. В случае необходимости, с помощью Hetman Partition Recovery можно восстановить файл резервной копии базы данных (*.bak), Иморта/Экспорта базы данных или файлы отсоединённой базы (*.mdf, *.ndf ,*.ldf) с дальнейшим их присоединением или восстановлением в Microsoft SQL Server.

hetmanrecovery.com

Загадки SQL Server. Долго висит восстановление базы данных на 100%

Меня недавно спросили:

«Я использую восстановление базы данных с опцией WITH STATS, которая показывает процент восстановления базы данных, но когда процент восстановления доходит до 100%, то процесс может ещё долго висеть на 100%, что происходит в этот момент?»

Я не смог сразу ответить на этот вопрос, поэтому решил провести исследование. Первым делом я настроил extendev events (XEvent) и запустил восстановление БД WideWorldImporters sample database. После восстановления я получил следующий вывод в SSMS:

10 percent processed. 20 percent processed. 30 percent processed. Processed 1464 pages for database ‘wideworldimporters’, file ‘WWI_Primary’ on file 1. Processed 53096 pages for database ‘wideworldimporters’, file ‘WWI_UserData’ on file 1. Processed 33 pages for database ‘wideworldimporters’, file ‘WWI_Log’ on file 1. Processed 3862 pages for database ‘wideworldimporters’, file ‘WWI_InMemory_Data_1’ on file 1. 100 percent processed. RESTORE DATABASE successfully processed 58455 pages in 8.250 seconds (55.354 MB/sec).

10 percent processed.

20 percent processed.

30 percent processed.

Processed 1464 pages for database ‘wideworldimporters’, file ‘WWI_Primary’ on file 1.

Processed 53096 pages for database ‘wideworldimporters’, file ‘WWI_UserData’ on file 1.

Processed 33 pages for database ‘wideworldimporters’, file ‘WWI_Log’ on file 1.

Processed 3862 pages for database ‘wideworldimporters’, file ‘WWI_InMemory_Data_1’ on file 1.

100 percent processed.

RESTORE DATABASE successfully processed 58455 pages in 8.250 seconds (55.354 MB/sec).

Когда я посмотрел на события в XEvent, то увидел следующее:

После восстановления БД до 100% есть ещё несколько событий. Давайте рассмотрим этапы восстановления БД и их влияние на время восстановления.

Эта восстановления БД

  1. Создание файла БД
  2. Копирование всех страниц данных из backup
  3. Создание файла логов
  4. Копирование блоков данных в файл лога из backup
  5. Запуск Recovery БД

Сделаю предположение, что большинство людей использует Instant File Initialization, поэтому не будем останавливаться на 1 шаге, так как с этой возможностью создание файла на файловой системе происходит быстро.

Пункт 3 выглядит наиболее подходящим для наших исследований, так как к нему не может быть применено Instant File Initialization и файл лога должен быть заполнен нулями полностью, так же нам может помешать большое количество виртуальных файлов логов.

Я решил проверить моё предположение с помощью доработки XEvent и увеличения размера БД до 10 Гб файла данных и 5 Гб файл лога (реальных данных всего 13 Мб). После запуска нового восстановления я получил следующий результат:

Обратите внимание, что процент восстановление указывает количество байт, которое было восстановлено и когда восстановление дошло до 100% мы получили наши 13 Мб (реальный размер данных).  Но самое важно для нас — это шаги «Waiting for Log zeroing» и “Log Zeroing is complete”. Если посмотреть внимательно, то мы обнаружим, что эти шаги заняли значительно больше времени (около 2-х минут), чем процесс восстановления, выраженный в процентах (секунды).

Из данного эксперимента можно сделать несколько выводов:

  1. Заполнение файла лога нулями и есть та причина, по которой восстановление так долго висит на 100%
  2. Проценты восстановления показывают только восстановленный объём файла данных.

Надеюсь раскрытие этой загадки SQL Server было вам интересно.

Вырезка из статьи — SQL Server Mysteries: The Case of the Not 100% RESTORE

Facebook

Twitter

Вконтакте

Google+

sqlcom.ru