pdanes (4/23/2013)
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?
The backup process reads the data files (extent at a time), after finishing it reads and adds to the backup file all the log records from time that the backup started or oldest open transaction at the time the backup completed, whichever is older (I incorrectly said 'started' earlier) to the last log record at the time that the data copying portion completed. Since that is done after the data copying portion completed, that's a fixed portion of the log and can't change further (no need to back up log records that were added while backing up log records, they're not needed for a consistent restore).
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?
You can pretty much say it's the time that the backup completed, because unless you have some odd case where half the database changes during the backup, the data copying portion of the backup is the vast majority of the time.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability