restore of database failed что делать
Ошибка восстановления резервной копии базы данных
Я получаю сообщение об ошибке с помощью SQL Server 2012 при восстановлении резервной копии, сделанной с предыдущей версией (SQL Server 2008). На самом деле у меня есть несколько файлов резервных копий одной и той же базы данных (взятых в разное время в прошлом). Новейшие восстанавливаются без проблем; однако одна из них дает следующую ошибку:
System.Data.SqlClient.SqlError: поиск в каталоге для файла “C:\PROGRAM FILES\MICROSOFT SQL SERVER\MSSQL.1\MSSQL\DATA\MYDB_ABC.MDF” не удалось выполнить системная ошибка 3 (система не может найти указанный путь). (Microsoft.SqlServer.SmoExtended)
Мне удалось сделать это из кода. Этого было недостаточно
Свойство RelocateFiles должно быть заполнено именами и путями файлов, подлежащих перемещению. Для каждого файла вы должны указать имя файла и новый физический путь. Итак, я сделал поиск PrimaryFilePath базы данных, которую я восстанавливал, и использовал это как физическое местоположение. Что-то вроде этого:
То же самое для файла журнала.
Похоже, что резервная копия была сделана на машине, чьи пути не совпадают с вашими. Попробуйте выполнить резервное копирование с использованием T-SQL вместо пользовательского интерфейса. Также убедитесь, что пути, которые вы указываете, действительно существуют и что в них нет копии этих файлов mdf/ldf.
Резервное копирование сохраняет исходное местоположение файлов базы данных и по умолчанию пытается восстановить его в том же месте. Поскольку ваша новая установка сервера находится в новых каталогах, и, по-видимому, старые каталоги больше не существуют, вам нужно изменить каталоги по умолчанию, чтобы они соответствовали местоположению, которое вы хотите использовать.
В зависимости от того, как вы восстанавливаете базу данных, способ сделать это будет отличаться. Если вы используете SSMS, просмотрите вкладки и списки до тех пор, пока не найдете список файлов и связанных с ними мест на диске – вы можете затем отредактировать эти места перед восстановлением.
У меня была та же проблема, и это исправлено без кода С#:
При восстановлении в разделе “Файлы” установите флажок “Переместить все файлы в папку”
Попробуйте снять флажок “Резервное копирование журнала” на странице “Параметры” диалогового окна “Восстановить базу данных”
В этом есть проблема с версией. Вы можете перенести свою базу данных на 2012 еще двумя способами: –
2) Создайте script всей базы данных со схемой и данными и запустите ее на целевом сервере (очень медленный процесс требует времени). см. это: –
Создать script в SQL Server Management Studio
Попробуйте перезапустить службу SQL. Работал для меня.
На всякий случай это полезно для тех, кто работает непосредственно с Powershell (используя библиотеку SMO), в этом конкретном случае были вторичные файлы данных. Я немного улучшил script, убив любые открытые процессы, а затем выполнив восстановление.
Вы должны удалить эти строки из вашего скрипта.
Обычно это происходит, когда вы используете одну MSSQL Studio для резервного копирования (подключена к старому серверу) и восстановления (подключена к новому). Просто убедитесь, что вы выполняете восстановление на правильном сервере. Либо проверьте имя сервера и IP в левой панели в пользовательском интерфейсе или доу
Мои 5 копеек. Вставить.
Впечатления от жизни
19 октября 2013 г.
Что делать, если не удается импортировать базу данных Microsoft SQL Server (ошибка 3154)?
Недавно мне нужно было импортировать базу данных Microsoft SQL Server, созданной на одном сервере на другой сервер. Обычно я это делаю с помощью SQL Server Management Studio.
Я не особо тесно работал с 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 Files\Microsoft SQL Server\MSSQL\Backup\TEST.bak’ WITH REPLACE |
При запуске скрипта в журнале я увидел в чем именно была проблема. Был указан путь по которому процесс восстановления базы данных пытался найти файлы база данных (*.mdf и *.ldf).
Путь этот резко отличался от путей, которые давал ему мой сервер. Дело в том, что на сервере, откуда была взята база данных, файлы *.mdf и *.ldf находились не в папке по умолчанию для Microsoft SQL Server, а в соврешенно другом месте. И путь этот был жестко пописан в файле импорта (резервной копии).
Поэтому при попытке восстановления, последнее захлебывалось, потому что ожидаемых файлов на «привычном» месте не окзалалось.
Что ж, это решаемая проблема.
Неправильный, но рабочий вариант (мой)
Правильный путь
Отступление. Умные же люди говорят, что правильно нужно в этом случае использовать еще пару опций MOVE, чтобы дать правильный новый путь к базе данных. Что-то вроде:
| RESTORE DATABASE NEW FROM DISK = ‘C:\Program Files\Microsoft SQL Server\MSSQL\Backup\TEST.bak’ WITH REPLACE, MOVE ‘TEST’ TO ‘C:\Program Files\Microsoft SQL Server\MSSQL\DATA\NEW.mdf’, MOVE ‘TEST_Log’ TO ‘C:\Program Files\Microsoft SQL Server\MSSQL\DATA\NEW_log.ldf’ |
Либо в окне импорта (восстановления), указать новый путь в колонке Restore As.
И правда, ваши мучения должны здесь закончится.
Опять неправильный, но рабочий вариант (мой)
Но воспользовался помощью зала. Человек, сведущий в этих вопросах подсказал: просто на скопированные в другое место файлы не были выставлены права доступа.
И в этот раз импорт прошел и копия базы с другого сервера теперь обосновалась на моем сервере.
Но повторю. Я делал этот фокус с копированием файлов и выставлением прав на них от не знания правильного способа с опцией MOVE.
Итоги
(Можно конечно сделать как я: скопировать файлы базы данных получателя в то место, где резервная копия базы данных-источника ожидает их, но при этом не забыть дать права процессу, осуществляющему импорт, на эти скопированные файлы базы данных.
Но лучше воспользоваться MOVE и не морочить себе голову, как я.)
Ошибка 3266 или 3013 при выполнении резервного копирования базы данных на диск или ленту или восстановление базы данных с диска или ленты
В этой статье предоставляется помощь в решении ошибок 3266 или 3013, которые возникают при выполнении резервного копирования базы данных на диск или ленту или восстановление базы данных с диска или ленты.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 290787
Симптомы
При выполнении резервного копирования базы данных на диск или ленту или восстановления с диска или ленты может возникнуть следующее сообщение об ошибке:
SQL Server 7.0 Server:
Msg 3266, Level 16, State 1, Line 1
База данных мягких файлов microsoft Tape Format (MTF) в имени устройства резервного копирования не может быть прочитана, что препятствует случайному доступу.
Сервер: Msg 3013, уровень 16, состояние 1, строка 1
Операция резервного копирования или восстановления завершается ненормально.
SQL Server 2000 Server:
Msg 3266, Level 16, State 1, Line 1
Данные резервного копирования в «имени устройства» неправильно отформатированы. Резервное копирование не может быть примеся, но существующие наборы резервного копирования по-прежнему можно использовать.
Сервер: Msg 3013, уровень 16, состояние 1, строка 1
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ завершается ненормально.
SQL Server 2005 Сервер:
Msg 3013, Level 16, State 1, Line 1
Данные резервного копирования в конце «имени устройства» неправильно отформатированы. Наборы резервного копирования на носителю могут быть повреждены и недоступны. Чтобы определить наборы резервного копирования на носителю, используйте RESTORE HEADERONLY. Чтобы определить возможности использования наборов резервного копирования, запустите RESTORE VERIFYONLY. Если все наборы резервного копирования неполны, переформатирование носителек с помощью BACKUP WITH FORMAT, который уничтожает все наборы резервного копирования.
Сервер: Msg 3013, уровень 16, состояние 1, строка 1
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ завершается ненормально.
Причина
Файл в устройстве резервного копирования не может быть прочитано. Существует множество причин, по которым может возникнуть ошибка файловой знаки. К числу причин относятся следующие:
На устройстве, где находится резервное копирование, может произойти сбой мультимедиа.
При создании резервного копирования может возникнуть сбой записи.
Например, потеря подключения может произойти во время резервного копирования сети. Или, отказ пути IO, чтобы смыть записи на диск может произойти после записи на диск был SQL серверу, как успешно.
Обходной путь
Чтобы разрешить SQL Server для выполнения новых резервных копий на резервное устройство, необходимо вручную удалить или удалить устройство с помощью следующей команды:
Если сообщение об ошибке возникает во время операции восстановления, можно получить другие наборы резервного копирования с устройства, указав номер файла. Например, если три резервных копии (3) находились на одном (1) резервном устройстве, можно использовать наборы резервного копирования 1 и 2. Чтобы определить, есть ли на устройстве несколько наборов резервного копирования, запустите следующий код из анализатора запросов:
Каждый набор резервного копирования имеет одну запись в выходе. Чтобы указать определенный набор резервных копий, используйте этот код:
FileNumber — это номер резервного копирования, который необходимо восстановить.
Дополнительная информация
В следующем списке содержатся важные заметки о резервном копировании и SQL Server.
После SQL Server обнаруживает ошибку файла на устройстве, SQL Server не записываю дополнительные сведения на устройство.
SQL Server хранит все резервные копии в формате Ленты Майкрософт, независимо от того, сделана ли резервная копия на диск или на ленту. Формат ленты Майкрософт использует файлмарки для удержания сведений, таких как размер блока и количество блоков в резервной копии, а также другие сведения о резервном копировании. Формат ленты Майкрософт также использует файлмарки для делимитации резервных копий на резервном устройстве. Тот факт, что файлмарка отсутствует или повреждена, указывает на то, что по крайней мере одна резервная копия на устройстве не действительна.
Несмотря на возможность восстановления некоторых наборов резервного копирования с поврежденного устройства, необходимо проверить целостность восстановленной базы данных.
SQL Server записи сведений об успехе или сбое во время операции резервного копирования или восстановления в журнале ошибок SQL Server и в таблицах истории резервного копирования в базе данных системы msdb.
Если при восстановлении журнала транзакций или резервного копирования базы данных произошла ошибка 3266, изучите следующие журналы, чтобы получить дополнительные сведения:
Если в этих журналах нет сведений о сбое, может возникнуть неопортаемая ошибка. Если вам нужна помощь, обратитесь в службы поддержки продуктов Майкрософт.
Restore of database failed что делать
No entry in sysdevices for backup device ‘LDS_Complex’. Update sysdevices and rerun statement. [SQLSTATE 42000] (Error 3206) RESTORE FILELIST is terminating abnormally. [SQLSTATE 42000] (Error 3013) Associated statement is not prepared [SQLSTATE HY007] (Error 0) Logical file ‘LDS_Complex_data’ is not part of database ‘LDS_Complex’. Use RESTORE FILELISTONLY to list the logical file names. [SQLSTATE 42000] (Error 3234) RESTORE DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.
������:
��� ������?
 Re: �� ���������� RESTORE DATABASE [new] | |
| Glory Member ������: | �������� ������ FILELISTONLY ����� ����� ��������, �� ��� ��������� �����-������, � � ������� �� �����, � ������� ��������. RESTORE FILELISTONLY FROM DISK=’g:\mywind.dmp’ |
| 19 ��� 03, 19:04����[425258] �������� | ���������� �������� ���������� | |