I've just installed a trial SQL Virtual Restore 2.3 on one of our test servers to see whether this would be suitable in some of our dev/test environments.
From an initial footprint and restore time perspective this is looking great!
However I've done some testing on data changes and have noticed that the behaviour of the .vldf file is inconsistent with what I see with a normal database restore.
The database is mounted using Virtual Restore from a 1GB .hbc backup (~7GB uncompressed) in SIMPLE recovery mode.
If I make a data change as part of a large transaction that affects about a million records and spawns several triggers, with a NORMAL database my transaction log grows to about 2GB.
If I make the same database change with my VIRTUAL database, my .vldf file grows by approximately 2GB PER TRANSACTION. That is, if I run the process 3 times, I now have a 6GB file.
I can see no mechanism to shrink the .vldf file (A DB shrink doesn't work), so if I run this process half a dozen times I actually end up losing space compared to a full DB restore.
Is this expected behaviour?