Steal/No-force 缓冲管理

steal 回答“内存不够时，能否把尚未结账的草稿先放进档案柜”；force 回答“结账时，是否必须立刻把所有正式页面归档”。一个看提交前，一个看提交点，不能把它们当成互为反义的单轴选择。

工程上最常见的 steal/no-force 让热页可以自由换出，又让 commit 只顺序刷日志而不等待分散的数据页。恢复算法于是承担“先重现崩溃现场，再撤掉未完成工作”的复杂性。

两个名称描述许可而非频率。steal 系统可以在内存充足时长期不偷页，no-force 系统也可以后台主动刷完某个事务的全部页；不能从一次 trace 没发生 steal 就把系统分类成 no-steal。

缓冲池只有两个帧。未提交事务 $T_1$ 把页 $P$ 从 4 改成 5；为装入新页，系统在相应 undo 日志稳定后把 $P=5$ 写盘，这是一笔 steal。另一个事务 $T_2$ 把页 $Q$ 从 8 改成 9，稳定写入更新日志和 commit 记录后返回成功，却让 $Q$ 仍留在内存，这是 no-force。

此时崩溃，磁盘可能含未提交的 $P=5$，却仍是已提交前的 $Q=8$。恢复必须 undo $T_1$，把 $P$ 还原为 4；同时 redo $T_2$，把 $Q$ 推进到 9。两个方向来自两笔不同事务和不同页面，不是对同一更新既撤销又重做。

若采用 no-steal，$T_1$ 的脏页在结束前不能成为替换受害者；一个修改页数超过缓冲容量的大事务便需要私有溢出区或其他设计，不能凭定义假设所有页都留在 RAM。若采用 force，提交要等待数据页稳定，但仍可能需要日志处理页撕裂、系统事务或媒体恢复。

同一页混有多个事务更新时，force 的归属也需精确定义。把页写盘可能顺带持久化另一个未提交事务的字节，若系统允许这种情况便表现出 steal；“我是为了已提交事务刷页”不能改变页面实际携带的更新集合。

ARIES公理库ARIES 恢复算法ARIES recovery algorithm · ARIES通过 Analysis、重复历史 Redo 与选择性 Undo 三阶段，在 steal/no-force 环境中恢复到仅含已提交事务效果的状态。以 steal/no-force 为主要环境：redo 阶段重复历史，undo 阶段只撤销 loser。Dirty Page Table 记录哪些页可能尚未稳定，Transaction Table 记录哪些事务可能需要撤销，正好对应两条策略造成的不确定性。

性能比较必须算清 I/O 位置与批量。force 并非只多写几个字节，它可能把顺序日志提交变成多个随机页写；no-steal 也不只是占用内存，它会限制页替换和长事务规模。策略名称描述允许性，不代表系统每次都会选择最早 steal 或永不主动刷 no-force 页。

恢复测试应构造一对互补页面：一个只含 loser 的已落盘更新，一个只含 winner 的未落盘更新。重启后前者必须回退、后者必须前进；只测试单页单事务，容易把 redo 与 undo 路径互相遮蔽。