【数据库系统】考虑题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. 实验结论

1. rollback只会取消对应transaction的操作，不影响其他transaction的正常操作。
2. 事务之间相互是独立的，不要在同一块内存上考虑，因为有数据库锁机制在保护。

 

 

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。