In step 3 you provide information about the destination of the virtual restore operation, such as the name of the virtual database, the path to its files and its recovery state. Note that even a virtual database needs some physical presence, but more on this later on.
As with every good wizard, the last page is a summary page informing you about the steps to be carried out. Additionally SQL Virtual Restore checks if it is configured correctly for the upcoming restore. Since everything is green, we are ready to go for the restore operation.
Before we actually start the restore, let us have a look at the script that has been generated to carry out the virtual restore.
For illustration purposes we have copied over the script from the pop-up that opens after clicking on the “View Script” button into SQL Server Management Studio (SSMS). At first the script looks like a bulk-standard restore script. However, when you have a closer look at it, you will notice the “unusual” file extensions .vmdf and .vldf. These extensions indicate a virtual database and have been preconfigured during installation for use with SQL Virtual Restore. We will see in just a moment what happens to these files.
Enough talking, let’s get to the meat and virtually restore our AdventureWorks database…
Depending on the size of the backup it may take a while until the virtual restore operation completes. But since the AdventureWorks sample database is relatively small in size, the whole restore takes just a few moments. In fact, the restore of the virtual database takes only about half the time compared to a normal restore. In our, by no means scientific test, the normal restore of AdventureWorks 2008 took about 20 seconds, while the virtual restore was at about 10 – 11 seconds. And it is not really hard to predict that with growing backup sizes the time for the normal restore will grow faster than the time for the virtual restore. So, here we have a first strong argument for SQL Virtual Restore. A second one will follow in just a few moments.
After restoring and recovering the database is ready to be used and SQL Virtual Restore has done its job.
Once you have clicked on the “OK” button in the above screen, SQL Virtual Restore shuts itself down. From this point onwards you have a fully functional and operational database that is mounted from a backup. You can access this database from now on with the same set of tools and/or applications that you use to access any other SQL Server database. So, we leave SQL Virtual Restore for now. But before we switch to SQL Server Management Studio (SSMS), let us first have a look at what has happened during the virtual restore on the file system-level.
