1.1 数据库

表

页是被管理的，在内存中被 BufferManager 管理，在磁盘中被磁盘空间管理器管理。

页是 IO 的基本单位。

记录有定长的和不定长的。

页包括：页号、数据、脏位、锁、页缓存。

页面头部。

DBMS 的最底层

目的：

1.将页映射到磁盘上

2.从磁盘将页加载到内存

3.将页存回磁盘，保证写

高层调用这层来读/写页，分配、取消分配逻辑页。

Record id=(Page,Location in Page)

Delete

事务管理器：通过 XID 文件记录事务的状态。可以快速访问和更新事务状态

8 字节、1 字节、1 字节

[00 00 00 00 00 00 00 00][01][02][01][01][00][01]

事务是为了保证一堆状态打包执行。比如说转账，扣钱和加钱要同时执行。

考虑下面情况

T1 begin
T2 begin
T2 U(x)
T1 R(x)
...
T1 commit
崩溃

由于 T1 读到了 T2 没有提交的事务。导致错误

规定 1

正在进行的事务，不会读取其他任何未提交的事务产生的数据

第二种情况，假设 x 的初值是 0

plaintext
T1 begin
T2 begin
T1 set x = x+1 // 产生的日志为(T1, U, A, 0, 1)
T2 set x = x+1 // 产生的日志为(T1, U, A, 1, 2)
T2 commit
MYDB break down

在系统崩溃时，T1 仍然是活跃状态。那么当数据库重新启动，执行恢复例程时，会对 T1 进行撤销，对 T2 进行重做，但是，无论撤销和重做的先后顺序如何，x 最后的结果，要么是 0，要么是 2，这都是错误的。

出现这种问题的原因，归根结底是因为我们的日志太过简单，仅仅记录了”前相”和”后相”. 并单纯的依靠”前相”undo, 依靠”后相”redo. 这种简单的日志方式和恢复方式，并不能涵盖住所有数据库操作形成的语义

规定 2

正在进行的事务，不会修改其他任何未提交的事务修改或产生的数据。

可以恢复崩溃的事务。

日志规定