September 16, 2011 at 6:55 am
Ok, so it's Friday and I probably have better things to be thinking about, but it just dawned on me that I don't know how this piece of software works. I'm assuming a SQL Server backup file (I admit I'm not too hot on the internals of this) includes some sort of low level data backup of the MDF and log files, therefore the internal structure would be similar to that of a regular database, just all lumped into one or more files.
Does the tool really get down to all the internal structures of SQL Server data files, pages, extents etc. (along with all the transactional consistency magic) and effectively emulate a SQL engine? If so, that seems like it would involve a massive amount of knowledge of the internals of each specific SQL version and be way too hard to maintain. Or am I missing some simple trick, or does MS provide libraries with an interface into this that are maintained along with SQL Server builds?
September 20, 2011 at 10:25 am
What it does is it gets down into the guts of the backup file and captures the calls between the two, for data & nothing else.The rest of the SQL Server behavior is still handled by SQL Server. In fact, when you create a virtual restored database, you get stub files for the data & log. Initially these are very small (about 2k on a system that doesn't have any rollforward or rollback transactions). Then, as transactions occur, they grow. Any data modified is kept in the stub files. All transactions are written to the stub's log file. Eventually, over time, if you left the database in place and hit all the data, you'd have transferred everything from the backup file to the stubs files and you'd effectively have another database again.
SQL Server still does all the heavy lifting up to the point of data access. Then that is handled by Virtual Restore.
"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
September 21, 2011 at 5:36 am
Thanks Grant - I think I have a reasonable idea about how virtual database works as it needs a SQL engine to function, but Object Level Restore Native allows you to browse and look at data within a backup file without any need for a SQL engine at all and generate a script file.
Therefore it must be (to a certain extent) aware of the internal structures and how to convert all of the different table/column structures in the same way as the SQL engine does?
September 21, 2011 at 5:42 am
Yeah, absolutely. That's the same technology at work in Virtual Restore. It reads the backup like it was a database.
"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
September 21, 2011 at 1:35 pm
To add a little, both read the file and essentially index it, so they know where in the file object x is (which may be multiple places). That's the time it takes when you start the product. It builds the index, which is can use on subsequent calls.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply