teCaТеперь при попытке накатить лог транзакций, восстановление проходит до 100%, а после задача отваливается с вот такой ошибкой:
авторSystem.Data.SqlClient.SqlError: MODIFY FILE encountered operating system error 112 (There is not enough space on the disk.) While attempting to expand the physical file 'G: \ SQL \ MlgPrism.mdf'.

Разумеется место на диске есть.А какая фаловая система на G?
И это не сетевой диск?

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

teCaalexeyvgА какая фаловая система на G?
И это не сетевой диск?NTFS
Сервер виртуальный, как диски на нем организованы не могу сказать. На диске свободно 47Гб свободного места, лог транзакций весит 63мб.А параметры FILEGROWTH как настроены?

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

teCaКажется понял, действительно, на исходнике mdf весит 358Gb, на получателе 307Gb, с учетом этого 47 свободных гигов на получателе не достаточно.Мда, а говорили, "места достаточно", не верили серверу :-)

Список создаваемых во время восстановления файлов, с размерами, можно посмотреть командой

msLexalexeyvg



рестроили лог, в логе запись о расширением файла данных.

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

В том числе, в файле бакапа лога будут в списке и те файлы базы, которые появились после предыдущего бакапа лога (и тем более после полного бакапа).

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

TaPaKalexeyvg,

тогда почему всё это ждало ~100% выполнения чтобы понять что место то и не хватало сразу?Не знаю, это такой алгоритм у сиквела - пытается увеличить файл, а у него не получается.

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

Или это связано с тем, что это голый RTM, и у него баг.

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

При ресторе лога, изменение размеров файлов в любом случае происходит только в момента обработки конкретной записи (расширения файла) в логе.Это да, я имел в виду, что список файлов там вообще есть.

Притом список файлов базы в файл бакапа пишутся 2 раза - перед начало бакапа, и при его завершении :-)
Как я понял, посмотрев в этот файл бакапа.
msLexВ любом случае, RESTORE FILELISTONLY FROM DISK не панацея.
На момент создания бекапа файл данных мог быть уже меньше чем максимальный по записям в логе.

Т.е. при следующие последовательности действий

полный бекап
условный ребилд огромной таблицы, увеличивший размер файла данных
шринк файла данных
бекап лога

RESTORE FILELISTONLY FROM DISK ни с полного бекапа, ни с бекап лога не будут содержать необходимое место на диске, достаточное для рестора логаЭто да, скорее всего, если файл был увеличен, и уменьшен, то в списке файлов это не отразится...

А ещё непонятно, если файл в базе будет создан, а потом удалён, будет ли это отражено в списке? Наверное, не будет.

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