SQL Server – Understanding ‘Suspect’ Database

The fastest way is to restore the MSDB database, but if it's your first time doing that, here's an easier shortcut.

1. Restore the MSDB backup onto an existing (working) database server, but use a different database name than MSDB. The restore should go quickly (because MSDB is typically very small), and you can then verify that your objects are in there.
2. Detach the database, and copy the mdf/ldf files over to the broken instance.
3. Move the broken mdf/ldf files somewhere for safekeeping, and replace them with your newly restored mdf/ldf files.

Start the SQL Server instance again, and you're set.

One gotcha - in step 1, make sure you're restoring onto the same major version of SQL Server. If the broken server is SQL Server 2005, don't do the restore on SQL Server 2012, because the SQL 2005 instance won't be able to attach databases that have been touched by a newer version of SQL Server.

Recently I have faced with the same issue. I have googled for a while and found that this is a problem in the Microsoft products. I wrote the article according to this error message, so you can find more information there.

Disclaimer: I am the Marketing Manager for Pranas.NET, maker of the Sql Backup and FTP tool promoted in that article.

So, to solve this issue and restore your database to point-in-time use T-SQL commands:

Restore your last full backup

RESTORE DATABASE your_database FROM DISK = 'd:/full' WITH NORECOVERY, REPLACE

Restore your last differential backup

RESTORE DATABASE your_database FROM DISK = 'd:/diff' WITH NORECOVERY

And restore your transaction log backups, when you will restore the last transaction log backup point the time you need to restore your database

RESTORE LOG your_database FROM DISK = 'd:/log1' WITH NORECOVERY

RESTORE LOG your_database FROM DISK = 'd:/log2' WITH STOPAT = '2016-01-05 13:29:59.000', RECOVERY