Восстановление базы данных с помощью графического интерфейса - неверный файл для восстановления

Я просто возиться с графическим интерфейсом SSMS и изучаю варианты задачи «восстановление».

Одна вещь, которую я заметил, когда я нажимаю «создать скрипт», первая строка запроса:

 RESTORE DATABASE [MyDatabase] FROM  DISK = N'Server_Patch\Database_name_LOGSHIPPING.BKP' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5 ( and a lot of log backups for point in time )

Хорошо, нет проблем, но я делаю ежедневные резервные копии этой базы данных. это Database_name_LOGSHIPPING.BKPбыло имя файла, который я сделал для доставки журналов месяц назад.

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

С помощью этого запроса от MSSQLTIPS я вижу все резервные копии из этой базы данных:

SELECT 
CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
msdb.dbo.backupset.database_name, 
msdb.dbo.backupset.backup_start_date, 
msdb.dbo.backupset.backup_finish_date, 
msdb.dbo.backupset.expiration_date, 
CASE msdb..backupset.type 
WHEN 'D' THEN 'Database' 
WHEN 'L' THEN 'Log' 
END AS backup_type, 
msdb.dbo.backupset.backup_size, 
msdb.dbo.backupmediafamily.logical_device_name, 
msdb.dbo.backupmediafamily.physical_device_name, 
msdb.dbo.backupset.name AS backupset_name, 
msdb.dbo.backupset.description 
FROM msdb.dbo.backupmediafamily 
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 
WHERE (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7)   and  msdb..backupset.type ='D'
ORDER BY 
msdb.dbo.backupset.database_name, 
msdb.dbo.backupset.backup_finish_date 

Что здесь может быть не так? Я не использую ТОЛЬКО КОПИРОВАТЬ.

EDIT2:

Я делаю ежедневные ручные резервные копии для тестирования, и даже таким образом, SQL Server выбирает ту старую резервную копию, которая больше не существует. При запуске RESTORE HEADERONLY...он говорит (очевидно), что файл не существует.

РЕДАКТИРОВАТЬ 3:

Это печать GUI:

Вау вау вау ПОДОЖДИТЕ МИНУТУ !

Эта база данных была восстановлена ​​с другого сервера (тот же сервер, другие экземпляры). Huuum ... Я думаю, что проблема здесь.

Ребята, вы можете увидеть на "сервере" на втором рисунке? у него 2 сервера. Я использую один с именами экземпляра GDLIC2014.

сценарий:

Сценарий резервного копирования:

DECLARE @Patch varchar(1000)

SELECT @Patch = (SELECT 'PATCH\FULL\DATABASE_ ' + convert(varchar(500),GetDate(),112) + '.bkp') 

BACKUP DATABASE DATABASE TO DISK=@Patch with compression

С помощью того же запроса от MSSQLTIPS я смог найти эти результаты, используя его без диапазона дат:

Красный квадрат - неправильная резервная копия из более старого экземпляра, синий квадрат - последняя сохраненная копия (ее должен использовать графический интерфейс)

РЕДАКТИРОВАТЬ 4:

Что ж, с помощью этого запроса к списку истории резервного копирования, я вижу, что все журналы и полные записи правильно перечислены:

SELECT TOP 100
s.database_name,
m.physical_device_name,
CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
CAST(DATEDIFF(second, s.backup_start_date,
s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
s.backup_start_date,
CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
CASE s.[type]
WHEN 'D' THEN 'Full'
WHEN 'I' THEN 'Differential'
WHEN 'L' THEN 'Transaction Log'
END AS BackupType,
s.server_name,
s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY backup_start_date DESC, backup_finish_date
GO

EDIT5:

Есть ли что перезапустить заголовок базы данных

(У меня нет идей)

Скорее всего, что-то в таблицах истории резервного копирования вышло из синхронизации, и пользовательский интерфейс переходит к последнему «согласованному» полному резервному копированию. Если вам действительно интересно, почему он делает то, что делает, запустите трассировщик профилировщика, ограниченный вашей учетной записью, пройдите этапы восстановления в графическом интерфейсе и просмотрите команды, записанные в трассировке, которые показывают, что пользовательский интерфейс делает за кулисами. , Это даст вам точный ответ, который вы ищете.

Если вы хотите просто пройти мимо этого, вы можете очистить свою историю резервного копирования через EXEC [msdb].[dbo].[sp_delete_backuphistory] @oldest_date=getdate()(в зависимости от того, когда вы в последний раз запускали это, вы можете очистить ее по месяцу за раз), а затем взять новую полную и т. Д. Я будет подозревать, что это сбросит графический интерфейс для использования надлежащих резервных копий в будущем.

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