However instead of plots to overthrow my kingdom, or curses that would cause me to eat pie and lose weight, or saying my name three times in a mirror so that I become summoned and forced to bust a cap…instead of stuff like THAT…they are props for working on some code!
I made some new changes and fixed an embarrassing bug in my previous contribution for the sp_DatabaseRestore. In an ideal world I would just skip the part of this post where I point out my mistakes and explain what they were, however Github does a great job at keeping history so…
I kind a sort of left a logic check that was checking two strings to find out which was greater…it would have worked except there was still a hyphen in the strings. Typical mistake when you live with ADHD, but oh the joy of open source software.
After squashing the bugs I added the @StopAt parameter. Now sp_DatabaseRestore allows you to put in a time (formatted as YYYYMMDDHHMM) and the restore will restore all logs up to that date and time. This can be useful in any situation where you need to do a point in time restore.
I also added a testing script that will take a full backup, diff backup and 10 logs backups. It will then choose a random log backup for the @StopAt parameter and restore the logs up to that point.
Erik at Brent Ozar Unlimited® posted an issue on github where the @Debug levels were broken. I had mistakenly forgot to move the @PrintCommand flags into @Debug level 1, from @Debug Level 2. Probably because I was troubleshooting and using level 2 for commands + variables :(. I’ll be working on refining the parameters so that it’s more intuitive.
Still the script is working and working well, I’ve been testing in production…er…I mean we have already tested and put this into production for over a month and everything is working great. The code for sp_DatabaseRestore and a whole boat load of other SQL scripts can be found at @BrentOzarULTD Github repository