In pre-SQL Server 7.0 releases, the checkpoint writes out any page that had changed since the last checkpoint and that another process hadn't already written out between checkpoints. So, any recovery process would begin at the last checkpoint, because any transaction committed before that checkpoint would have been written to both the transaction log and the database and would no longer be a concern.
However, SQL Server Books Online (BOL) says that in SQL Server 7.0, instead of writing out all pages changed since the previous checkpoint, the checkpoint process writes out to disk all pages that were marked as dirty before the previous checkpoint and that haven't been written out by some other process using spare CPU cycles. In other words, according to BOL, the checkpoint process doesn't write out a changed page at the next checkpoint, but at the one after that, giving the change a better chance of being written out by a worker thread or the lazywriter. The result is that each checkpoint should have less to do. In turn, the recovery process would then begin not from the last checkpoint before the system shutdown, but from the one before that. However, the BOL documentation isn't correct; the checkpoint does indeed write all changed pages to disk immediately.
