Как исправить файл mdf

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

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

Специалисты пользуются несколькими способами восстановления баз данных (БД). Наиболее простой и удобный ­– воспользоваться программой (SSMS) SQL Server Management Studio.

Как восстановить

Узнать, где находится SQL Server Management Studio, довольно легко. Microsoft Windows Server 2012 R2 располагается в стандартном перечне программных продуктов. В Microsoft Windows Server 2008 R2 следует зайти в меню Пуск и отыскать Microsoft Windows Server 2012. Там смотреть Microsoft SQL Server Management Studio.

Далее следует ввести тип сервера с именем, а чтобы подтвердить подлинность – информацию, требуемую для прохождения авторизации. Нажать Соединить (Connect).

В левом углу из обозревателя (Object Explorer) раскрыть Базы данных (Server Objects). Из представленного перечня отобрать базу, подлежащую восстановлению либо ту, данные которой будут восстанавливаться. На выбранном файле кликнуть мышкой и в выпавшем перечне выбрать Задачи (Tasks), затем Восстановить (Restore), потом База данных… (Databases …).

Проделанные шаги дадут старт процессу Restore Database, а значит требуемая база данных начнет восстанавливаться. Следует сделать выбор источника для Restore Database.

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

1. Переключить соответствующую кнопку на Устройство (From device).
2. Прописать, откуда восстановится БД.
3. Выбрать инфобазу, в которую произведется загрузка данных (Destination for restore). Ею может выступать любая БД, которая регистрировалась на SQL Server (в том числе и база, с которой создавалась резервная копия).

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

Если требуется провести копирование БД, то во вкладке Файлы (Files) нужно будет прописать путь к файлам выбранной инфобазы.

Настройка дополнительных параметров

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

• Которая опубликована не на сервере, где она создавалась, сохранились настройки репликации, поможет отметка «Сохранить параметры репликации). Он важен, если при резервном копировании была реплицирована БД;
• была проведена перезапись файлов БД с именем, которое указывалось в качестве базы назначения – нужно поставить отметку «Перезаписать существующую базу данных»;
• сузить доступность к базе всем, кто не sysadmin, db_owner, dbcreator – нужно поставить флажок «Ограничение доступа к восстановленной базе данных»;
• старту должен предшествовать перевод БД в режим одного пользователя, а по его завершению вернуть в пользование для множества пользователей – поставить отметку «Закрыть существующие соединения»;
• чтобы провести требуемое резервное копирование завершающего фрагмента журнала транзакций, следует поставить отметку «Создание резервной копии заключительного фрагмента журнала перед восстановлением». Если в окошке Временная шкала резервного копирования (Backup Timeline) для временной точки требуется эта резервная копия, то отметка будет поставлена системой, без возможности снятия;
• чтобы после завершения восстановления каждой резервной копии уточнялась необходимость продолжения процесса – следует поставить отметку «Выдавать приглашение перед восстановлением каждой резервной копии» (Prompt before restoring each backup). Достаточно полезен, т.к. после того, как восстановлено определенное количество резервных копий можно остановить дальнейшую цепочку восстановительных процессов.

Настроив все важные параметры следует нажать ОК. Тем самым запустится процесс. Соответствующее уведомление сообщит об его окончании.

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

Чтобы перенести базу данных MSSQL Server по другому пути каталога либо сделать ее копию, следует знать, как восстановить БД в новую папку. Полезно знать как ее переименовывать. Для этого можно воспользоваться вышеупомянутой программой SSMS и T-SQL.

Подготовка к восстановлению базы данных

Перед стартом процесса восстановления нужно соблюдать ряд требований:

1. Когда осуществляется процесс восстановления базы, доступ к ней может быть только у системного администратора. Для остальных пользователей доступ должен быть ограничен.
2. Перед восстановлением нужно сделать резервную копию активного журнала транзакций.
3. Чтобы восстановить зашифрованную базу необходим доступ к сертификату либо ассиметричному ключу, который применялся в качестве ее шифратора. Не имея доступа к ним, восстановление зашифрованной БД становится невозможным. Потому, такой сертификат следует хранить, пока может понадобиться резервное копирование.

После того, как база данных версии SQL Server 2005 (9.x) либо более поздней, восстановится, произойдет автоматическое обновление, и она станет доступной.

Если присутствуют полнотекстовые индексы

В том случае, когда в БД SQL Server 2005 (9.x) присутствуют полнотекстовые индексы, в момент ее обновления произойдет импорт, сброс либо перестроение. Результат зависит от того, какое значение проставлено в свойствах сервера upgrade_option.

При обновлении такие индексы станут недоступны, если upgrade_option имеет значения:

• 2 в режиме импорта;
• 0 в режиме перестроения.

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

В том случае, когда выбран процесс Импорт, а доступ к полнотекстовому каталогу отсутствует, то произойдет перестроение одноименных индексов, которые связаны с ним. Для изменения свойств upgrade_option необходимо воспользоваться процедурой sp_fulltext_service.

Соблюдение правил безопасности

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

• запускать выполнение инструкций T-SQL, не предусмотренных системой;
• вызывать ошибки в результате изменения схемы либо самой структуры БД

Если БД получена из источников, не внушающих доверия, то перед началом ее использования необходимо:

• протестировать по инструкции DBCC CHECKDB;
• исследовать исходный и иные коды БД, изучить процедуры.

Инструкции RESTORE

На ход реализации этих инструкций влияет факт существования восстанавливаемой базы. Если база:

• присутствует, то разрешения получают пользователи sysadmin, dbcreator, dbo (владелец БД) по умолчанию;
• отсутствует, то пользователям потребуются разрешения CREATE DATABASE.

Разрешения на реализацию таких инструкций выдаются в соответствии с ролями. В соответствии с ними сервер всегда имеет доступ к данным о членстве. Разрешение RESTORE отсутствует у пользователей с ролями db_owner. Причина в том, что членство может быть проверено лишь в тех случаях, когда к базе данных всегда есть доступ и она не повреждена. А это иногда не соблюдается в процессе выполнения инструкций RESTORES.

Пошаговая инструкция восстановления БД в новую папку в SSMS

1. Открыть SSMS и произвести подключение к SQL Server Database Engine.
2. Щелкнуть мышкой по имени сервера, чтобы развернулось его дерево.
3. Кликнуть мышкой на Базы данных, потом – по Восстановить базу данных.
4. В разделе Источник выбрать Общие, чтобы определить соответственное расположение и источник копий, подлежащих восстановлению. Пользователю предлагается выбрать нужный вариант (Базы данных либо Устройства). Особенности:
5. При выборе Базы данных открывается перечень БД, где можно выбрать нужную. В нем представлены лишь те базы, у которых резервные копии создавались по журналу msdb. Стоит отметить, что для БД на целевом сервере, резервные копии которых поступили с иных серверов, подобный журнал будет отсутствовать. В таких ситуациях следует выбирать вариант Устройство. Это позволит руками прописать файл, а в случае необходимости – обозначить устройство для выполнения восстановления.
6. Устройство можно выбрать, воспользовавшись кнопкой обзора (…). В результате появится окошко Выбор устройств резервного копирования. Перейти в окошко Тип носителя резервной копии, в котором из списка выбрать необходимый тип устройства. Если требуется добавить ряд устройств, это можно сделать с помощью кнопки Добавить в окошке Носитель резервной копии. Когда все необходимые устройства добавлены, необходимо вновь перейти на страницу Общие. Для этого следует нажать ОК в списке Носитель резервной копии. Обратившись к списку Источник: Устройство: База данных обозначить название БД, куда будет производиться восстановление. Пользователь может воспользоваться данным списком только при выборе Устройства. Можно выбирать лишь те БД, у которых на отобранном устройстве имеются резервные копии.
7. Название новой базы для проведения восстановления автоматом сформируется в поле База данных в разделе Назначение. При желании оно может быть изменено. Для этого желаемое название вводится в окошке База данных.
8. Далее перейти к Восстановить до. Пользователь может оставить значение До последней выбранной резервной копии (по умолчанию) либо кликнуть по Временной шкале. При выбре второго варианта всплывет соответствующее окошко Временная шкала …. В нем нужно указывать точное время.
9. Необходимые резервные копии для восстановления можно выбрать в соответствующей сетке. В ней отражены все наборы, доступные в выбранном месте. Система сама предложит план восстановления отобранных копий, который будет использован по умолчанию. Он может быть переопределен, если в сетке изменить отобранные элементы.
10. Для указания другого места расположения файлов базы, необходимо выбрать страницу Файлы после чего нажать на Переместить все файлы в папку. Следует указать вновь выбранное место расположения папок файлов данных и журнала.
11. Если возникла необходимость – провести настройку параметров, как было рассказано выше.

Чтобы начать процесс, в котором будет восстанавливаться БД в новую папку с возможностью переименовывать ее, можно воспользоваться инструкциями Transact-SQL.

Как просмотреть отчет

Стандартный отчет «События резервного копирования и восстановления» позволяет получить сведения о том, когда проводилось:

• Резервное копирование определенной БД;
• операции восстановления базы MS SQL из них.

Данный отчет включает данные, касающиеся создания резервных копий:

• время, затраченное на это в среднем (Average Time Taken For Backup Operations);
• операции, которые прошли успешно (Successful Backup Operations);
• ошибки, которые были допущены (Backup Operation Errors);
• удачно прошедших восстановлений баз (Successful Restore Operations).

Чтобы он начал формироваться, следует в Обозревателе объектов выбрать нужную БД и щелкнуть по ней мышкой. Выбрать в меню Отчеты, а затем – Стандартный отчет. После этого кликнуть на События резервного копирования и восстановления.

Чтобы просмотреть информацию из сформированного отчета следует выбрать нужную группировку и раскрыть данные по ней.

Для восстановления поврежденной БД можно воспользоваться еще одним инструментом.

Как исправить ошибки в MS SQL с помощью Recovery Toolbox for SQL Server

Для восстановления поврежденной базы данных можно обратиться к помощи Recovery Toolbox for SQL Server. Для исправления ошибки (Error), следует воспользоваться пошаговой инструкцией восстановления данных из файла *.mdf, который был поврежден. Для этого необходимо:

1. Скачать Recovery Toolbox for SQL Server.
2. Установить программу следуя инструкциям и запустить ее.
3. Из списка файлов выбрать файл *.mdf, который был поврежден.
4. Осуществить предварительный просмотр тех данных, которые в процессе выполнения программы могут быть подвергнуты извлечению из базы MS SQL сервер, которая подверглась повреждению.
5. Выбрать наиболее приемлемый способ, которым будут экспортироваться данные:
6. сохранением на диск в качестве SQL-скрипта;
7. выполнением SQL-скрипта в самой БД.
8. Произвести выборку информации, требующей восстановления и сохранения.
9. Начать восстановление нажатием Start recovery.

Данная программа создавалась, чтобы облегчить процесс восстановления поврежденных БД. Специально разработанная, оптимизированная для восстановления SQL Server, утилита поможет устранить ошибки и внести правки в разные типы повреждений *.mdf файлов и базы данных MS SQL Server.

Как становится понятно, для исправления ошибок и восстановления БД необходимо уметь пользоваться различными инструментами. Читайте, изучайте материалы по данной теме. Если возникнут вопросы – обязательно задавайте.

Также приглашаем на специальный курс по MS SQL в Otus.

Applies To: MS SQL Server 2016, 2014, 2012, 2008/2008 R2 and older versions

As one of the best database management tools, Microsoft SQL Server is frequently used among database administrators, and the versions, SQL Server 2008 and 2008 R2, still gain widespread popularity. However, similar to using any other software, it is not without any problem while using SQL Server. One of the common issues encountered by SQL Server users is the corruption of the database, which will need you to restore the database from the MDF and LDF files in the SQL Server. Fortunately, the way to repair your database with the MDF and LDF files are quite straightforward and there are two different methods to achieve it. Apply your preferable solution and restore your SQL Server database without delay.

How to Restore Database from MDF File in SQL Server 2008/2008 R2

There are two options for you to restore MDF and LDF files to your SQL database. 

Method 1. Restore Database from MDF Using SQL Server

You can choose to repair your SQL database with the help of SQL Server Management Studio or T-SQL.

Preparation:

• Detach the database you want to restore
• Put the MDF file and the LDF file in the same location and a specific folder

Tip 1. Use SQL Server Management Studio

Step 1. Open Microsoft SQL Server Management Studio and go to “Object Explore”.

Step 2. Right-click on “Database” and choose “Attach”.

Step 3. In the new window, click the “Add” button. Then search for and choose the .mdf file of the database you want to restore. Click “OK” > “OK”.

Tip 2. Use T-SQL

Execute the following command in the management studio:

Create database dbname 

On 
(   
Filename= ‘path where you store the MDF file’, 
Filename =’path where you store the LDF file’
)

For attach; 

If the two options above fail to restore your database from the MDF file in SQL Server, don’t be upset, you still have another choice.

Method 2. Restore Database from MDF in SQL Server with SQL Recovery Software

Professional SQL repair tool – EaseUS MS SQL Recovery, will easily fulfill your needs of restoring the database from MDF file in SQL Server. It is especially good at restoring the corrupt database by repairing its MDF file. Besides, it also performs well in:

• Restoring corrupted SQL server database objects – tables, triggers, indexes, keys, rules & stored procedures
• Repairing database log files that may result in database errors
• Recover deleted/dropped SQL database records

Now, restore your database from MDF file in SQL Server with EaseUS MS SQL Recovery:

Step 1. Stop MS SQL Server service via services.msc or Management Studio.

Step 2. Run EaseUS SQL Recovery. In the main interface, choose the MDF/NDF file of the database you want to restore. Then click “Repair” to start repairing your MDF/NDF file. 

If you know the exact location of the file, click “Browse” to locate the database.

If you don’t know the file location, click “Search” to search for the .mdf or .ndf file in.

Step 3. When it has done, you will see the recovered database objects listed in the left pane of the window.

Step 4. Click “Export” in the bottom right corner of the screen to save your database objects. Choose a preferred format, MDF, or SQL scripts.

On the “Export to database” window, choose “Create new database” or “Export to existing database” to save the repaired data. If you want “Create new database”, enter the database name and choose an SQL location. If you select “Exporting to existing database”, you need to select the existing database.

Step 5. Now restart the SQL Server.

Утилита для восстановления Microsoft SQL Server

Как восстановить неисправный MDF файл Microsoft SQL Server?

Recovery Toolbox for SQL Server

Recovery Toolbox for SQL Server поможет исправить поврежденные MDF файлы MS SQL Server всех версий

Как восстановить базу данных Microsoft SQL Server

Как восстановить поврежденную или нерабочую базу данных Microsoft SQL Server. Как восстановить данные из поврежденного файла *.mdf — пошаговая инструкция:

1. Загрузите Recovery Toolbox for SQL Server здесь: https://recoverytoolbox.com/download/RecoveryToolboxForSQLServerInstall.exe
2. Установите Recovery Toolbox for SQL Server
3. Запустите Recovery Toolbox for SQL Server
4. Выберите поврежденный файл *.mdf
5. Сделайте предпросмотр данных, которые могут быть извлечены из поврежденной базы данных Microsoft SQL Server
6. Выберите способ экспорта данных
   • Сохранить как SQL-скрипты на диск
   • Выполнять SQL скрипт непосредственно в базе данных
7. Выберите информацию, которая должна быть восстановлена и сохранена
8. Нажмите Начать восстановление (Start recovery)

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

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

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

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

Recovery Toolbox for SQL Server является решением все в одном для исправления поврежденных MDF/NDF файлов. Recovery Toolbox for SQL Server поможет вернуть данные из mdf файлов подвешенных баз данных.

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

Процесс восстановления базы данных SQL Server Microsoft это сложная задача, состоящая из нескольких этапов. Процесс исправления повреждений БД SQL подразумевает восстановление MDF файла, в котором хранятся все объекты базы данных:

• Таблицы (Tables)
• процедуры (Stored Procedures)
• функции (Functions)
• триггеры (Triggers)
• индексы (Indexes)
• Просмотры (Viewers)

Программа Recovery Toolbox for SQL Server работает по очень сложному алгоритму восстановления баз данных SQL от Microsoft. На начальном этапе восстановления базы SQL Server требуется определить и выявить страницы блоков данных внутри файла. Страница — это всего лишь универсальный блок хранения данных в MDF/NDF файле. Размер блока может задаваться Администратором базы данных. По умолчанию размер страницы составляет около 8К байт. Каждая страница восстанавливаемого MDF файла имеет уникальный индекс и номер. На основании этой уникальной информации можно отсеять неактуальные и неиспользуемые номера страниц при восстановлении SQL базы данных. Избыточные страницы обычно появляются при модифицировании или удалении пользовательских данных в MDF файле. Эти лишние избыточные страницы не должны использоваться при восстановлении базы MSSQL. Recovery Toolbox for SQL Server исключает избыточные страницы при восстановлении баз данных SQL, чтобы данные не дублировались и для того, чтобы в восстановленных данных присутствовали только актуальные данные. После завершения восстановления БД MS

Как восстановить MDF файл

Простое восстановление MDF файла путем исправления или модификации содержимого поврежденного MDF файла невозможно. MDF файл имеет сложную структуру со множеством связей между объектами. Соответственно малейшие правки внутри поврежденного MDF файла приведут к нарушению целостности данных и еще большему усложнению восстановления MDF файла. Это, в свою очередь, может привести к увеличению затрат времени на восстановление всей базы данных MS SQL, или даже утере возможности восстановления в целом. Таким образом, ответ на вопрос о том, как восстановить MDF файл, требует полного понимания процесса.

Процесс восстановления MDF файлов осуществляется в несколько этапов:

1. Анализ структуры MDF файла
2. Выделение страниц, хранящих данные
3. Структурирование страниц данных в MDF файле
4. Удаление избыточных страниц для исключения дублирования контента
5. Выделение системных данных, описывающих структуру хранимых данных
6. Сборка разрозненных данных в общие структуры таблиц, индексов и других объектов
7. Сохранение данных в виде отдельных файлов как SQL скрипты (*.sql файлы)
8. Создание новой базы данных в MSSQL Server
9. Последовательный импорт данных из SQL скриптов (*.sql файлы) в новую базу данных
10. Замена поврежденной базы данных новым MDF файлом (новой базой данных)

В результате восстановления БД SQL, после импорта всех данных, извлеченных из поврежденного MDF файла, в новую базу мы можем считать эту новую БД восстановленной базой данных MS SQL Server. А MDF файл новой исправленной базы MS SQL Server это и есть восстановленный MDF файл. Таким образом, данный алгоритм позволяет Recovery Toolbox for SQL Server получить рабочую версию базы данных MS SQL, являющуюся полной копией исходного файла до повреждения. При восстановлении MDF файла сначала требуется восстановить данные (таблицы), далее восстанавливаются все остальные пользовательские объекты (Процедуры (Stored Procedures), функции (Functions), триггеры (Triggers), индексы (Indexes) и Просмотры (Viewers)). Иными словами, восстановление MDF файла проходит через промежуточный шаг: сохранение данных в .sql файлы. Таким образом, сами поврежденные MDF файлы поврежденной базы данных MSSQL Server не редактируются и не модифицируются в процессе восстановления БД.

Требования:

• Windows 98/Me/2000/XP/Vista/7/8/10/11 or Windows Server 2003/2008/2012/2016 и выше
• Microsoft SQL Server: 7/2000/2005/2008/2008 R2/2012/2014/2016/2019

Copyright © 2003 — 2022 Recovery Toolbox. Все права зарегистрированы. Microsoft®, Windows® и Outlook® являются зарегистрированными торговыми марками Microsoft® Corporation.

Источник

Мои 5 копеек. Вставить.

Впечатления от жизни

19 октября 2013 г.

Что делать, если не удается импортировать базу данных Microsoft SQL Server (ошибка 3154)?

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

Вы, наверняка, в курсе, что простой экспорт и импорт баз данных можно выполнять с помощью функций резервного копирования и восстановления, где команда Back up будет служить экспортом, а команда Restore — импортом. (По умолчанию в подпапке Backups папки, где установлен Microsoft SQL Server, появится файл c расширением *.bak. Его-то и можно использовать для импорта на другом сервере.)

Я не особо тесно работал с Microsoft SQL Server. Просто знал, как можно импортировать и какую опцию включить при импорте, чтобы он состоялся. Но почему-то в этот раз мне никак не удавалось импортировать базу данных на свой сервер. Все попытки заканчивались ошибкой, примерно такой:

The backup set holds a backup of a database other than the existing ‘MyDatabase’ database. RESTORE DATABASE is terminating abnormally. (Microsoft SQL Server, Error: 3154)

Почему же она возникает и как ее преодолеть?

Интернет дал мне две подсказки.

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

Этот фокус я знал и без интернета. И я как раз эту опцию включал. И мне это никак в этот раз не помогало.

Во-вторых, импортировать базу данных можно не с помощью пункта меню, а с помощью скрипта.

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

Скрипт примерно такой:

RESTORE DATABASE NEW
FROM DISK = ‘C:Program FilesMicrosoft SQL ServerMSSQLBackupTEST.bak’
WITH REPLACE

При запуске скрипта в журнале я увидел в чем именно была проблема. Был указан путь по которому процесс восстановления базы данных пытался найти файлы база данных (*.mdf и *.ldf).

Путь этот резко отличался от путей, которые давал ему мой сервер. Дело в том, что на сервере, откуда была взята база данных, файлы *.mdf и *.ldf находились не в папке по умолчанию для Microsoft SQL Server, а в соврешенно другом месте. И путь этот был жестко пописан в файле импорта (резервной копии).

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

Что ж, это решаемая проблема.

Неправильный, но рабочий вариант (мой)

Поэтому я (плохо разбираясь в Microsoft SQL Server):

1. Создал базу данных с точно таким же названием, что и на сервере-источнике.
2. Остановил службу SQL Server для следующего шага.
3. Скопировал новосозданные файлы из папки по умолчанию, где мой сервер их создал, в папку, в которой ожидает ее бэкап, который я пытался импортировать на свой сервер.
4. Запустил службу SQL Server.

Все. Теперь должно было заработать как нужно.

Правильный путь

Отступление. Умные же люди говорят, что правильно нужно в этом случае использовать еще пару опций MOVE, чтобы дать правильный новый путь к базе данных. Что-то вроде:

RESTORE DATABASE NEW
FROM DISK = ‘C:Program FilesMicrosoft SQL ServerMSSQLBackupTEST.bak’
WITH REPLACE,
MOVE ‘TEST’ TO ‘C:Program FilesMicrosoft SQL ServerMSSQLDATANEW.mdf’,
MOVE ‘TEST_Log’ TO ‘C:Program FilesMicrosoft SQL ServerMSSQLDATANEW_log.ldf’

Либо в окне импорта (восстановления), указать новый путь в колонке Restore As.

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

Опять неправильный, но рабочий вариант (мой)

Но я сделал, не как в этом скрипте, а как написал выше — копированием файлов. И да, указанная проблема решилась, но теперь импорт не получался из-за другой проблемы.

Скопированные в другое место файлы не открывались при восстановлении БД — доступ был запрещен.

Тут я же растерялся. Успех маячил перед глазами — и на тебе. Очередная ошибка.

Но воспользовался помощью зала. Человек, сведущий в этих вопросах подсказал: просто на скопированные в другое место файлы не были выставлены права доступа.

И ларчик просто открывался. Нужно было всего лишь дать доступ к этим файлам. Чтобы долго не возится — так как это одноразовое действие, я просто временно — для импорта- дал все права учетной записи Everyone.

И в этот раз импорт прошел и копия базы с другого сервера теперь обосновалась на моем сервере.

Но повторю. Я делал этот фокус с копированием файлов и выставлением прав на них от не знания правильного способа с опцией MOVE.

Итоги

Повторю главные моменты, которые можно или нужно сделать, если возникают ошибки при импорте (восстановлении) одной БД в другую :

1. включить перезапись своей базы данных, в которую восстанавливается чужая база данных — либо из из окна восстановления, либо с помощью опции REPLACE в скрипте восстановления
2. проверить путь к базе данных, прописанный в файле резервной копии базы данных (запустив скрипт, приведенный выше, можно отчетливо увидеть ожидаемый путь при ошибке)

Путь можно исправить с помощью другой опции MOVE указав логическое имя базы данных-источника, и нового пути к файлам (*.mdf, *.ldf) к файлу получателей.

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

Но лучше воспользоваться MOVE и не морочить себе голову, как я.)

Источник

Help, my database is corrupt. Now what?

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

Как обнаружить, что база данных повреждена

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file ‘D:DevelopDatabasesBroken1.mdf’.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

Основная проблема заключается в том, что если проверки целостности базы данных не производятся на постоянной основе, то повреждение может быть обнаружено спустя часы, дни и даже месяцы, после того, как оно образовалось, в тот момент, когда уже сложно будет что-то исправить.
Я не буду описывать ситуацию когда база данных перешла в состояние «suspect» («подозрительная» в русской редакции SQL Server — прим. переводчика). Описание всевозможных причин почему база данных может перейти в «suspect» и множества вариантов исправления этого — тема отдельной статьи, если не книги.

Что делать если база данных все-таки повреждена

1. Не паниковать
2. Не отсоединять (detach) ее
3. Не перезапускать SQL Server
4. Не начинать восстановление сразу
5. Запустить проверку целостности
6. Найти причину

Не паниковать

Самое важное, при обнаружении повреждения БД — это не паниковать. Любые принимаемые решения должны быть тщательно взвешаны, во внимание должны быть приняты все возможные факторы. Чертовски просто ухудшить ситуацию приняв не до конца обдуманное решение.

Не отсоединять базу данных

В большинстве случаев, когда SQL Server обнарживает повреждение базы данных, это означает, что в БД на самом деле есть поврежденные страницы. Попытка убедить SQL Server что это не так, путем отсоединения (detach) и повторного присоединения (attach) БД, бэкапа и последующего восстановления, перезапуска службы SQL Server, либо перезагрузки сервера, не приведет к тому, что ошибка исчезнет.
Если база данных повреждена и SQL Server обнаружит это при присоединении, он не сможет присоединить ее. Есть несколько способов заставить его увидеть эту БД, но намного лучше просто не отсоединять ее.

Не перезапускать SQL Server

Точно так же, как при отсоединении-присоединении, перезапуск службы SQL Server не сможет исправить обнаруженные ошибки (если они есть).
Перезапуск службы может сделать ситуацию хуже. Если SQL Server обнаружит ошибки во время выполнения фазы восстановления (recovery) БД после перезапуска, он пометит ее как «suspect», что сильно усложнит процесс восстановления БД.

Не начинать восстановление сразу

У вас может возникнуть соблазн просто запустить DBCC CHECKDB с одним из «восстановительных» параметров (обычно допускающими потерю данных) и надеяться, что все станет лучше (по моему опыту — первое что рекомендуют на «непрофильных» форумах по SQL Server — запустить DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS — прим. переводчика). Во многих случаях запуск такого восстановления не рекомендуется. Он не гарантирует исправления всех ошибок и может привести к недопустимой потере данных.
Такое восстановление — это последний шаг при исправлении ошибок. Оно должно быть запущено только если у вас уже нет другого выбора, но никак не в первую очередь.

Запустить проверку целостности

Для того чтобы решить как исправить базу данных, мы точно должны знать что именно повреждено. Единственный способ, которым мы можем это выяснить — запустить DBCC CHECKDB с параметром All_ErrorMsgs (в SQL Server 2005 SP3, SQL Server 2008 SP1 и в более старших версиях, этот параметр включен по умолчанию, указывать его не обязательно). Помните, что если вы запустите DBCC CHECKDB без параметра No_InfoMsgs, в выводе этой процедуры будет информация о количестве строк и страниц в каждой таблице, что вряд ли будет вас интересовать при анализе ошибок.
DBCC CHECKDB может долго выполняться на больших БД, но необходимо дождаться пока эта процедура не закончит работу. Грамотная стратегия восстановления может быть построена только при наличии информации обо всех проблемах в БД.

Найти причину

После того как ошибки исправлены, работу нельзя считать законченной. Если причина этих ошибок не установлена, они могут возникнуть снова. Обычно, основной причиной ошибок являются проблемы с подсистемой ввода-вывода, но они также могут быть вызваны неправильной работой «низкоуровнего ПО» (вроде антивируса), действиями человека, либо багами самого SQL Server.

Что дальше

Дальнейшие действия по исправлению ошибок целиком и полностью зависят от результатов выполнения CheckDB. Чуть дальше я покажу несколько наиболее часто возникающих ошибок (учтите, что эта статья не претендует на звание полного описания всевозможных ошибок).
Описанные ошибки располагаются по возрастанию уровня серьезности — от наименее серьезных к наиболее серьезным. В общем-то, для наиболее серьезных ошибок, находимых CheckDB, есть описание доступных методов их резрешения.
Если у вас вдруг обнаружится ошибка не описанная в статье, обратите внимание на последний раздел — «Поиск помощи».

Неверная информация о свободном месте на странице

Msg 2508, Level 16, State 3, Line 1
The In-row data RSVD page count for object «Broken1», index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.

Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:26839) in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 76911687695381 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.

Эта ошибка появляется, когда PFS-страница (Page Free Space), которая учитывает насколько заполнены страницы в БД, содержит некорректные значения. Эта ошибка, как и упомянутая ранее, не является серьезной. Алгоритм, по которому определялось насколько заполнены страницы, в SQL Server 2000 не всегда отрабатывал правильно. Для решения этой проблемы нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS и, если это единственная ошибка в БД, никакие данные, на самом деле, не пострадают.

Повреждение только некластерных индексов

Msg 8941, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted [i].offset >= PAGEHEADSIZE) failed. Slot 159, offset 0x1 is invalid.

Msg 8942, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted[i].offset >= max) failed. Slot 0, offset 0x9f overlaps with the prior row.

В этом случае, повреждение может быть полностью исправлено удалением поврежденных некластерных индексов и повторным их созданием. Перестроение индекса (ALTER INDEX REBUILD) в режиме on-line (и иногда в off-line) читает страницы старого индекса для создания нового и, следовательно, завершится с ошибкой. Поэтому, необходимо удалить старые индексы и создать их заново.
Именно это сделает DBCC CHECKDB с параметром REPAIR_REBUILD, но база данных при этом должна быть в однопользовательском режиме. Вот почему обычно лучше вручную выполнить эти операции, чтобы с базой данных можно было продолжать работать, пока индексы будут пересоздаваться.
Если у вас недостаточно времени на то, чтобы пересоздать нужные индексы и в наличии есть «чистый» (не содержащий в себе ошибок) полный бэкап и бэкапы журнала транзакций с неразорванной цепочкой журналов, вы можете восстановить поврежденные страницы из них.

Повреждение LOB-страниц

Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 1, partition ID 72057594145669120, alloc unit ID 72057594087800832 (type LOB data). The off-row data node at page (1:2444050), slot 0, text ID 901891555328 is not referenced.

Ошибка говорит о том, что существуют LOB-страницы (Large OBject), на которые не ссылается ни одна страница с данными. Такое может произойти, если ранее был поврежден кластерный индекс (или куча) и его поврежденные страницы были удалены.
Если CheckDB говорит только о таких ошибках, то можно запускать DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS — эти страницы будут уничтожены. Поскольку у вас все равно нет страниц с данными, которые ссылаются на эти страницы, бОльшей потери данных уже не будет.

Ошибки, связанные с выходом за пределы допустимого диапазона

Msg 2570, Sev 16, State 3, Line 17
Page (1:1103587), slot 24 in object ID 34, index ID 1, partition ID 281474978938880, alloc unit ID 281474978938880 (type «In-row data»). Column «modified» value is out of range for data type «datetime». Update column to a legal value.

Эти ошибки показывают, что в столбце есть значения выходящие за пределы допустимого диапазона. Это может быть значение типа datetime, предполагающее, что с полуночи прошло больше 1440 минут, строка-Unicode, в которой количество байт не делится на 2, или float/real с неверным значением точности.
Проверка на эти ошибки не выполняется по умолчанию, для баз данных обновленных с версии SQL Server 2000 или более ранних, если перед этим ни разу не выполнялась команда DBCC CHECKDB со включенным параметром DATA_PURITY.
CheckDB не сможет исправить эти ошибки, поскольку неизвестно какие значения поставить взамен неправильных. Исправление таких ошибок не требует особых усилий, но выполняется вручную. Неправильные значения должны быть заменены на что-нибудь приемлимое. Основная проблема — это поиск неверных значений. В этой статье базы знаний есть пошаговая инструкция.

Повреждение кластерного индекса или кучи

Server: Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 181575685, index ID 1, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data). Page (1:22417) was not seen in the scan although its parent (1:479) and previous (1:715544) refer to it.

Server: Msg 8939, Level 16, State 1, Line 2
Table error: Object ID 181575685, index ID 0, page (1:168576). Test (m_freeData >= PAGEHEADSIZE && m_freeData

Источник