Ever since the upgrade from SQL Server 6.5 to 7.0 one of the most requested features I’ve heard people complain about loosing was the ability to backup a single table. During my tenure as Product Manager for Quest’s SQL Litespeed extracting tables was one of the things we were constantly asked about. Eventually built it, and it worked. So, believe me when I tell you it is no easy feat to extract data from a backup file, let alone make it look like a normal database and attach it to a running SQL Server instance. The holy grail to me was always “select * from backup”. Virtual Database is as close to using a backup file as a real database that I have ever seen.

Setting Up Your Virtual Database

The main screen isn’t your traditional style of GUI. This is where everything happens. It has options to attach backup files, ether a single full or multiple files to a point in time. There is a run queries option, which is redundant since you can use management studio to access the database like you would any other database. The Tips @Tricks is a little pointless since this is installed on your server and if you are like me it is locked down pretty tight so cruising web sites is out. Finally, Help & More it a lot more important than you think.

To attach a full backup is dead simple. Give it the file name, SQL Server instance name and a new database name.

 

If you have used Idera’s SQL Safe to do the initial backup with and had it generate the content map file the attach time is fast. I didn’t test with native backup files since we don’t do any native backups where I work. If the content file isn’t there it will have to generate it and depending on the size of the backup file it can take a while.

 

Attaching multiple files is a little more difficult. The wizard steps you through it though.

 

If you accessing files from a network share it will prompt you for credentials so it can read the backup files. Virtual Database fully supports UNC mounting.

If you have encrypted your backups using SQL Safe, it will prompt you for the password as well. You are encrypting your backups right?

 

It looks through the backup files to pull out key information needed to do the point in time recovery. This is also very fast. I actually had to do it a few times to get this screen shot!

 

Once you have the files added it will show them sorted. Any files it thinks there is a problem with it will highlight in red for you. These were LSN out of sync errors. It doesn’t stop you from going to the next screen though.

 

Once you have settled on a file list you can now choose your point in time. You can have multiple full, differential, or transaction log backup files specified. When you choose a point in time it selects the files needed to do the recovery. It will choose the backup files that are needed. If you have done what I just did and selected everything in a folder it won’t apply three full backups plus all the transaction log files.

 

Like the single file attachment process, you still need to provide an instance name and database name.

 

Finally, it gives you a summary of what is going to happen. After that the database is ether attached, or fails. If it fails you have to start all over.

Configuration Options

There are very few configuration changes that you can make the product.

I’m not thrilled with this screen setup. It’s got a lot going on and some of the functions like most of the help stuff, doesn’t work on my locked down server.

Where you put your support files may an impact on performance. SQLvdb has some support files it needs to do its magic. This is also where it records changes you make. If you plan on making a lot of changes you may want to move the location from the C drive to another faster and larger drive.

Some files aren’t deleted when you drop the virtual database and require a manual cleanup step. You can do it here or through the command line tool.

 

The drive letter is basically a protection mechanism. SQLvdb is looking for a specific set of file extensions like .mxf or .lxf. So, don’t use those extensions for anything else. You can change it if you do have a file extension collision.

The service connection allows you to change the port but not the server name. This means I can’t have the GUI installed on my desktop and access my SQL Server where the services and driver is installed. I don’t know if this is supposed to be this way or if it is a bug.

The Good

What can I say, it is select * from backup. You mount it and like magic your backup file is a live database again.

You can also create objects in this new database. That’s right, you can create a new table and put data in it. That data and structure aren’t stored in the backup file though and if you remove the database all changes are lost. You can do a backup of the “new” database just like you would a normal backup though, saving your changes to a new backup file.

You can also drop tables, alter stored procedures you name it. I haven’t found a DDL statement I couldn’t execute yet. Just like before, if you need to reset the database just drop it and re-attach it, just like magic you have a clean slate again.

It works across the network. If you don’t have enough space on your machine for the backup file you can still mount it via UNC. This allows me to look at backup files from my development or test servers without having to consume the space to house the database. Don’t expect the performance to be great, you are accessing a file across the network.

Any tool that works with SQL Server works with this. If you have a favorite scripting tool you can use it. Written your own programs? No problem you can use them too. 

Never having to restore to a test or development environment again. When you are working with large databases getting an exact duplicate for functional testing is a huge undertaking, not to mention expense. You still have to buy all the disk space. Before SQLvdb I would restore the database, set it to simple mode, issue a checkpoint and then shrink all the files to the bare minimum. On our largest database this would take eleven hours or more. Now, I copy the backup file and attach the virtual database. Copying takes about an hour an the attachment takes about 20 minutes. This is a 380GB backup file of a 1.2TB database. If I didn’t mind accessing it from a network share it would cut that down to 10 or 20 minutes tops.

Never having to restore the entire database to get a single object from a backup again. Same as above but now I don’t have the boss standing behind me for several hours asking “Is it done restoring yet?”

Doing it all from the command line. This means I can automate a ton of stuff and build processes around SQLvdb.

The Bad

The User Interface

I really don’t like the GUI. It is a far enough departure from what we are familiar with that it it makes it difficult to use. Why split up single file and multiple file attachment? It took me some time to find where to change the configuration options as well.

Do I need a Run Queries option? The whole point of the product is being able to use SSMS or whatever you need to access the database. What if I don’t have SSMS installed on my production server?

Tips & Tricks is also a waste of screen space. Why isn’t this in the help system? It doesn’t point out the more creative uses like offsetting restores to development boxes that I can find.

Can’t use the console remotely. It has the option built in but greyed out. With a locked down server getting remote access may be a problem, not to mention all the help is build into the GUI as well.

The wizard for multiple file attach will warn you in one stage about missing or invalid backup files but doesn’t in the second stage. It will let you attempt to attach the virtual database then fail. You can’t edit the virtual database ether. Your only choice is to drop it and start over.

The Command Line

Almost zero documentation on the command line options. I had to root around and play with the options to figure out that there is some switches that are order dependent.

The GUI allows you to kill all users out of a SQLvdb before dropping it, the CLI doesn’t seem to have that option. This is just an extra step I have to put into my automation scripts and hope I get it right.

Other Issues

You can’t run a DBCC CHECKDB on it. Since DBCC uses sparse files and snapshots to get a consistent look at the data it can’t run on a SQLvdb. SQLvdb is also using sparse files to do some of the things it does. What’s worse is the DBCC command just hangs out and looks like it is running OK. I let it run for a couple of hours before killing it.

Doing anything in Management Studio that requires it to pull a list of databases locks up SSMS while the attach is in progress. If you leave SSMS alone it will come back. If you don’t and keep clicking around it can lock it up or crash it all together. I’ve been told they are working on a fix for this.

I ran into some other odd issues that may be bugs or something wrong with my server I don’t know yet. I am working with Idera to identify the problem, when I do I’ll update this post.

Final Thoughts

I can honestly say that this is a great product. It is everything I had hoped it would be. Aside from the small issues it has been a solid purchase. I don’t think Idera sees all the uses for SQLvdb. Being able to get a table or stored procedure from a backup file is nice, but it is an insurance policy. Being able to offset eleven ours of restores to development every week and cut disk space usage by 70%, well that is money in the bank.