August 2, 2018 at 8:35 pm
Comments posted to this topic are about the item Verifying the restore
August 2, 2018 at 11:49 pm
Interesting question, thanks Steve
Learned something, which is a great way to end the week
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
August 3, 2018 at 4:56 am
Didn't know about the checking for available space so learned something new,
Cheers Steve
---------------------------------------------------------------------------------------
The more you know, the more you know that you dont know
August 3, 2018 at 5:31 am
Heck, I didn't know it checked for available space.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 6, 2018 at 5:43 am
The whole, valid command would be (plus maybe some with-options)RESTORE VERIFYONLY FROM DISK='\\SERVER1\Backup\my_big_db\FULL\SERVER1_my_big_db_FULL_20180803_210600.bak'
Sorry, but checking the disk space does not make any sense, since I do not specify, where I want to restore the database. It could be my local 128-GB SSD which would be never sufficient for a 500 GB database or it could be the 3 TB SAN drive. I could drop or overwrite the old database before executing the restore. I could increase the SAN-drive or could delete some old stuff...
God is real, unless declared integer.
August 6, 2018 at 8:02 am
The restore location is the original file locations, or you can use RESTORE VERIFYONLY ... WITH MOVE to specify somewhere else. Either way, the restore location is always defined.
October 6, 2018 at 10:55 pm
Grant Fritchey - Friday, August 3, 2018 5:31 AMHeck, I didn't know it checked for available space.
New one on me too, thanks Steve.
...
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply