GilaMonster (4/23/2013)
You write here that the database is consistent as of the completion time. Does consistent mean as it is at exactly that instant?
No, I said 'close to the end'. Specifically at the point that the data reading portion of the backup completes. The entire database will be consistent to that time.
Yeah, sorry, I grabbed that one immediately and didn't notice the subsequent edit.
What happens if a heavily loaded server keeps changing the database, forcing a do-over, faster than the backup process can ever complete?
There's no do-overs, so the question is moot.
I assume then, that the reading of log records is a one-time event? That is, after doing the primary read, it catches up with the log records once, and doesn't continually go back and check for more transactions that may have accumulated while it was catching up the previous transactions?
Or do you mean as each table was at the time the backup process got to it? If so, how do you know what 'state of the database' is in your full backup, if it spans a long time interval?
Nope, that's not going to result in a transactionally consistent database (which restores always must)
So, short of doing a restore to someplace safe and examining the data manually, there's no real way of knowing at exactly what point the backup captured the database, except that it is internally consistent?