Page LSNs and Recovery
Every database page has an LSN in the page header that reflects the location in the transaction log of the last log entry that modified a row on this page. Each log record for changes to a data page has two LSNs associated with it. In addition to the LSN for the actual log record, it also keeps track of the LSN which was on the data page before the change recorded by this log record. During a redo operation of transactions, the LSNs on each log record are compared to the page LSN of the data page that the log entry modified. If the page LSN is equal to the previous page LSN in the log record, the operation indicated in the log entry is redone. If the LSN on the page is equal to or higher than the actual LSN for this log record, SQL Server will skip the REDO operation. These two possibilities are illustrated in Figure 5-2. The LSN on the page cannot be in between the previous and current value for the log record.
数据库中存储的每一个page在其header中都有一个LSN，这个LSN用来标记最后修改这个page的log record,我们称它为page LSN。而每一个log record都有两个LSN，其中一个LSN就是log record当前的LSN，用来标识log record本身，我们叫他Actual LSN。而另外一个LSN是在这一次日志记录发生更改之前，data page上所记录的LSN，我们叫他Prev LSN。
Redo操作与LSN比较
if(Page LSN==Prev LSN) redo operation else if(Page LSN>=Actual LSN) skip redo operation
在我们执行redo操作的时候，如下图1所示，我们的事务日志中的一个log record需要更新page 1:25，该log record的actual LSN=2:210:6，prev LSN=2:200:7；而要修改的页page 1:25的header中我们发现Page LSN=2:200:7，则Page LSN==Prev LSN，那么表示我们可以执行当前LSN的log record的修改。
同理我们再来看图2，我们发现log record需要修改Page1:42，而该页中header存储的Page LSN=2:200:10，我们log record的actual LSN=2:290:6，那么Page LSN>Actual LSN，那么跳过这个修改操作。这是因为当前data page中的内容比我们要修改的内容更新，所以我们可以跳过当前log record的redo操作。
Figure 5-2. Comparing LSNs to decide whether to process the log entry during recovery
Because recovery finds the last checkpoint record in the log (plus transactions that were still active at the time of the checkpoint) and proceeds from there, recovery time is short, and all changes committed before the checkpoint can be purged from the log or archived. Otherwise, recovery could take a long time and transaction logs could become unreasonably large. A transaction log cannot be truncated prior to the point of the earliest transaction that is still open, no matter how many checkpoints have occurred since the transaction started and no matter how many other transactions have started or completed. If a transaction remains open, the log must be preserved because it's still not clear whether the transaction is done or ever will be done. The transaction might ultimately need to be rolled back or rolled forward.