Ah... got it. Thanks for the amplification.
So, to be sure, the data for the database isn't actually materialized at the cloned instance. Does that make these cloned databases "read only" or can they actually be Inserted/Updated/Deleted and only those changes are materialized and only on the cloned instance? Is the latter a correct understanding on my part?
Also, since you said the clone would occupy <40MB, where is the data in the database read from when data is read? Obviously I'm concerned about the possibility of a "bottle neck" and I'm also concerned with the unplanned materialization of data on the cloned instance.
I'm also concerned about "backups" of development code. Having such a thing has saved our hinnies more than once (we treat backups on Dev boxes as seriously as we do prod).
And, to say the least, your good article has piqued more than just a bit of interest on my part.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems