考虑题4所示的日志记录_【数据库系统】考虑题4所示的日志记录，假设开始时A、B、C的值都是0 (1) 如果系统故障发生在14之后，写出系统恢复后A、B、C的值...

目录

T5.考虑题4所示的日志记录，假设开始时A、B、C的值都是0

1. 实验 Transaction 性质

2. 实验结论

3. 题目

3.1 如果系统故障发生在14之后，写出系统恢复后A、B、C的值

3.2. 如果系统故障发生在12之后，写出系统恢复后A、B、C的值

3.3 如果系统故障发生在10之后，写出系统恢复后A、B、C的值

3.4 如果系统故障发生在9之后，写出系统恢复后A、B、C的值

3.5 如果系统故障发生在7之后，写出系统恢复后A、B、C的值

3.6 如果系统故障发生在5之后，写出系统恢复后A、B、C的值

T5.考虑题4所示的日志记录，假设开始时A、B、C的值都是0

1. 实验 Transaction 性质

首先做实验研究下transaction之间影不影响。这个很困扰我。

现在数据已经到了磁盘中，并重新读到内存为0，0，0。

下面测试一下事务的ROLLBACK怎么工作的。

关闭嵌套事务自动提交：

时刻1 & 2，开始事务T1，更新A 在内存中的值Set A, A=10：

此时刷新表test_rollback:

因为没有commit，所以A的值没有改变。

时刻3：事务 T2 开始

很可惜，一创建新的transaction，之前的事务就被强制提交了。

这种测试方法无法得到结论。

也许可以创建两个数据库连接来测试一下，console一个，navicat一个：

首先还原A的值：

然后在navicat中也创建一个transaction:

这样就有了两个transaction了：

然后再从头来模拟一下一个事件：

需要验证的问题是如果两个事务A,B之间已经产生了嵌套：

再来一遍：

T1：transaction navicat set A = 10;

刷新一下，可以看到此时没有更新：

T2: transaction navicat set b = 10;

Transaction console set c = 10;

刷新一下表，发现仍然没有更新，这次也没有发生强制更新的情况：

T3: transaction navicat rollback;

T4: transaction console commit;

刷新，发现：

此时C依然被更新成功，得到结论：

2. 实验结论

rollback只会取消对应transaction的操作，不影响其他transaction的正常操作。

事务之间相互是独立的，不要在同一块内存上考虑，因为有数据库锁机制在保护。

3. 题目

3.1 如果系统故障发生在14之后，写出系统恢复后A、B、C的值

T1, T2, T3重做，T4撤销。

相当于T1,T2,T3有效，T4无效。

等效于下图中T13的状态：

而T2自己回滚了且成功回滚，所以等效于删了T2，所以可以进一步简化为：

从头到尾推理一遍，所有值都取最新的，可以得到：A = 8，B = 7, C = 11。

3.2. 如果系统故障发生在12之后，写出系统恢复后A、B、C的值

T1, T2重做，T3, T4撤销。

相当于T1, T2 有效，T3, T4无效。

T2回滚没影响删掉，最终等效于下图对应的状态：

也就是等效于只有T1，所以A = 10, B = 0, C = 11。

3.3 如果系统故障发生在10之后，写出系统恢复后A、B、C的值

T3，T4撤销，T1重做。

此时T2回滚成功，相当于T2没有发生，此时也可以等效为只有T1：

所以答案和第二问相同，依然是A = 10, B=0, C=11。

3.4 如果系统故障发生在9之后，写出系统恢复后A、B、C的值

此时T2 回滚失败，T2全部撤销，此时也可以等效为只有T1：

所以答案仍然为A = 10, B = 0，C = 11。

3.5 如果系统故障发生在7之后，写出系统恢复后A、B、C的值

答案为A = 10, B = 0，C = 11不变，理由同(4)。

3.6 如果系统故障发生在5之后，写出系统恢复后A、B、C的值

此时T1,T2,T3,T4全部撤销，等效于没有有效事务发生。

答案为 A=0, B=0,C=0。