Добрый день.

От прошлого админа остался скрипт которым обновляли тестовые базы 1С. Я проверил, что он работает и в него особо не вглядывался. Но на базу erp понадобилось добавить второй файл лога и скрипт работать перестал. Я решил в нем поправить эту часть, чтобы опять заработало, но изучив скрипт не понял, почему он вообще работал...

Текст запроса:


Указывать нужно БД куда восстанавливаем, фулл бекап и ели есть - дифф.
Пути на проде и тесте разные, имена файлов тоже. Но скрипт восстанавливал с перемещением и переименованием под БД.mdf и БД.ldf

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

Пока тестировал выяснил: не работает, если базы нет.
Работает не с любым названием, а в основном с erp_фамилия разраб, причем erp_случайная фамилия не сработало.
Триггеров на сервере нет, в базе мастер тоже ничего.
При восстановлении базы с дополнительным логов проблема возникла только с ним, на mdf и первый лог move похоже работал.
Вообще выглядит как будто есть объект в котором есть имя базы и пути файлов для перемещения и при ресторе через скрипт автоматом мувит.
у кого какие идеи насчёт возможной реализации, интересно как такое реализовано.

Yasha123,

Через принт проверил, что да - скрипт восстановления похож на Ваш вариант.

Разве при восстановлении по умолчанию берутся данные существующей базы, а не те, что были у базы, чей бекап?
Я привык при восстановлении всегда точно указывать куда. Ну если только не эту же базы из бекапа поднимаю.
Может и туплю с этим вариантом.

Сейчас ещё раз попробовал, создал БД test123 и попробовал туда восстановить фулл бекап базы hrm (mdf+log).
Ошибки:

Msg 5133, Level 16, State 1, Line 1
Directory lookup for the file "D:\SQL\hrm.mdf" failed with the operating system error 2(The system cannot find the file specified.).
Msg 3156, Level 16, State 3, Line 1
File 'hrm' cannot be restored to 'D:\SQL\hrm.mdf'. Use WITH MOVE to identify a valid location for the file.
Msg 5133, Level 16, State 1, Line 1
Directory lookup for the file "D:\SQL\hrm_log.ldf" failed with the operating system error 2(The system cannot find the file specified.).
Msg 3156, Level 16, State 3, Line 1
File 'hrm_log' cannot be restored to 'D:\SQL\hrm_log.ldf'. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 1
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Путь D:\SQL на сервере откуда бекап. Выглядит, что по умолчанию пытается восстановиться в директорию базы откуда бекап. На тесте дефолтные пути сервера E:\DATA\ и E:\LOG\

Пункт, что не может создать снимается, это падает на этапе USE [master]; ALTER DATABASE ' + @db + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Просто так базы разработчиков перезаписать нельзя и придется ждать обращения от них.
Можно будет на hrm базе проверить работает ли ещё скрипт (у erp 2 лога и не работает), если да (а по идее ничего не менялось), то вытянуть текст запроса во время восстановления. Будет ли там конструкция с move или просто RESTORE DATABASE который получаю через принт без запуска.

Yasha123,

Интересно, а куда кстати восстанавливается без указания, если дефолтные пути и пути восстанавливаемой базы разные?

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

Выходит похоже на то, что у restore database свой алгоритм и иногда восстанавливает где была база (или пути в параметрах сервера), а иногда начинает в пути из бекапа.

Тогда возможно в моём случае именно после восстановления в базу с 1 лог файлом начало восстанавливать по путям бекапа и какой-то схемы с скрытыми триггерами, как подумал сначала нет. Будет задача на обновление базы, проверю точно.
А пока можно перечитать, что Microsoft пишет по этому поводу.

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

Ну там всегда и было другое имя. Продуктивная база в БД_фамилияРазраба.

Yasha123,

Проветрился и появились идеи, но проверять буду уже завтра.
Понятно, что реплейс позволяет перезаписать базу оставив от неё только название.

В моих попытках и ошибках была закономерность: пыталось восстановить по пути из бекапа файлы с отличными от бекапа логическими именами. В попытке, где выдало ошибку только по логу 2, у mdf и первого лога были логические имена с продуктива, а когда создал руками - было вида erp_разраб.

Случаем не идёт сравнение логического имени файла перезаписываемой базы с бекапом, если совпало, то путь перезаписываемой, если нет, то путь из бекапа.

Вариант с проверкой логических имен похоже тоже мимо. Сделал логические имена, как на продуктиве те же ошибки.
Причем на тестовой базе разраба опять ругается только на второй файл лога (добавление к тестовой до восстановления с лог. именем прода не помогло). При этом когда открываешь окно восстановления в SSMS, выбираешь файлы бекапа, базу куда восстанавливать и переходишь на вкладку с путями, то там всё ок. Настройки для перемещения файлов по дефолтным путям сервера, где восстанавливаешь.

Изначальное предположение, что скрипт работал со скрытым триггером или ещё чем-то не подтвердилось.

Это именно свойства RESTORE DATABASE. Я предпочту продолжать использовать явный MOVE при восстановлении на другом сервере.

После успешного восстановления через SSMS начало нормально работать и просто через RESTORE DATABASE. При этом восстанавливает по путям перезаписываемой базы, даже если не совпадет с дефолтными путями сервера.

Yasha123,

А в последнем примере путь у базы db2 2012 сервера такой и был? C:\...\MSSQL11.SQL_2012\...\db2.mdf?
Тогда на 2016 попробовало восстановиться по пути из бекапа. А попробуйте этот бекап на 2016 восстановить руками с move, а потом опять просто restore database. Скорее всего сработает.

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

Интересно, что в информации от Microsoft пояснений по логике Restore не нашел, не удивлюсь, если она ещё и от версии сервера менялась.

alexeyvg,

Я своё сообщение медленно в это же время набирал:)

Не очень понял, что перестало работать:

Рестор с move - всё ок.
Рестор просто - всё ок.
Один и тот же бекап.

Потом был снят новый бекап с db1 и
на db2 уже не восстановился?

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