SQL Server uses write-ahead logging so that changes (committed or not) are always written to the log file prior to being written to any data file.
Records written to the transaction log do not necessarily reflect the entire page being modified. Log records typically consist of compensation data that allow transactions to be rolled forward and back. COMMIT
flushes the log buffer along with a record of the commit to guarantee durability. See the documentation.
In addition to commit, log buffers are flushed when they become full and during checkpoint operations. The log may contain uncommitted transactions and it doesn't matter how long transactions run. During crash recovery, all transactions from the last completed checkpoint are rolled forward from log records and then uncommitted transactions are rolled back. The database is then consistent, containing only committed transactions.
The above was converted from comments made by Dan Guzman
log cache
, as i understand (correct me if i'm wrong), Uncommitted Trans = Dirty Pages in Buffer Cache, and Buffer Cache got core-relation withLOG CACHE
(for ongoing changes) which only written to disk (log file) upon transaction commit. In the case of Long Running Transactions, since the modifications remains inLOG CACHE
, any failure happens, i would consider the LOG file doesn't have particular uncommitted transactions.