Hot answers tagged


You have to start over and restore full and diffs with no recovery and then the tlogs with stand by option. This will allow you to restore tlogs later as well. You can configure logshipping with option of stand by, so you can read from the secondary database. There will be a .tuf (transaction undo file) file created when you restore tlogs with standby ...


You should use WITH STATS = 10 so that SSMS can show your the progress. Also, if you restored an older version of backup to a newer version of sql server, sql server will undergo an upgrade process .. something along the lines database 'your db name' running the upgrade step from version 661 to version 668 ..


I don't believe this is possible, typically the database would need to be shrunk before or after a restore. If this were me I'd restore the database on another server, maybe on a dev server, shrink the files, and then copy and restore locally.


Are you looking to do something like a re-name swap? Something like this: Load DB2 Rename DB1 to DB_temp Rename DB2 to DB1 Rename DB_temp to DB2 Then you re-load DB2 again the next time? If so you can simply alter the name of the DB rather than deal with the time a restore takes (the file names will remain the same but that really doesn't matter in ...


You need to check the actual size of the database files which you can check by running RESTORE FILELIST ONLY FROM <backup_device> This will give you information about the files contained in the backup and their sizes in bytes You need the same space available on the server as the database file size, the backups can be compressed. Now you need ...


dont use "mysqldump" while restoring backup. Use "mysql". mysqldump is for taking backup, not for restoring.

Only top voted, non community-wiki answers of a minimum length are eligible