数据库-事务处理的概念和理论简介

在看这一部分内容之前，我对数据库一些基础概念和基础操作的认识十分浅薄，也没有一些数据库管理的经验，因此当学这一部分的时候遇到了贼多理解上的误区和困难。难受。。。但是我已经没有时间先从头仔细学习数据库基础再学这一部分了，因此只能在泥泞中前行。即使在本文结束之前，好多概念我还是以猜测的方式去理解，因此肯定会有很多错误，请有缘人指正。

什么是事务？为什么数据库系统要强调事务的概念？

http://www.hollischuang.com/archives/898
在上面博文的基础上，我想说明事务的四大特性是其理想属性，在并发控制的调度中我们的原则就是遵循事务的四大特性，但是难免会出现违反特性的情况，因此就需要采取正确的方法进行并发控制。

在多用户系统中事务的并发执行意味着什么？讨论并发控制的必要性并给出一个常见的例子

在多用户系统中事务的并发执行意味着事务存在同一数据资源的可能性，即可能会发生数据冲突，并产生一系列意想不到的错误。但是事务可以并发执行的确可以加快整个系统的执行效率，因此有必要对事务的并发执行做出控制，使之得到令人期望的效果。

上述提到的并发执行引起错误的类型有哪些？

• 更新丢失：
• 暂时更新（脏读）：
• 错误求和：
• 不可重复读：

讨论故障的不同类型。灾难性的故障意味着什么？

• 计算机系统崩溃：系统在执行期间可能会发生硬件，软件，网络等错误。还有硬件崩溃如主存错误。
• 事务导致系统错误：事务中的某些操作也会导致事务故障，如整数溢出或者除零。不正确的参数值或者逻辑程序设计也会导致事务故障。此外，用户可能在事务执行期间进行中断事务。
• 并发控制仲裁：并发控制可能会因事务违反了可串行性，或几个事务之间出现死锁状态从而需要做出撤销事务的操作。被撤销后的事务还可能需要在稍后被重启。
• 磁盘故障：一些磁盘可能会因为读写故障导致数据丢失。在事务进行读写期间可能会发生这种故障。
• 物理问题：电源故障，蓄意损坏，误写磁盘以及操作员误操作等。

讨论这些故障的原因不言而喻。在设计数据库系统时必须提前想到尽可能多的故障类型并根据需要对其中的故障类型提前准备好应对措施，尽可能的降低损失。

数据库事务中读写操作

首先需要明白数据项的读写操作是发生在内存和磁盘之间，从磁盘到内存的数据传输基本单元是块，内存中组织形势是页。在数据库系统磁盘文件管理模块中要注意两者的联系与区别。

• 读（read_item）：将数据库项X从磁盘读到内存里。为了简化表示，假设程序变量名也是X

1. 找到包含数据项X的磁盘块地址。
2. 将磁盘块复制到内存的一个缓冲区页面中。
3. 将数据项X从缓冲区复制到名为X的程序变量中去。

• 写（write_item）：将数据库项X从内存写到磁盘里。

1. 找到包含数据项X的磁盘地址。
2. 将磁盘块复制到内存的一个缓冲区页面中。
3. 将数据项X从程序变量X中复制到它在缓冲区的正确位置。
4. 将更新后的块从缓冲区写回到磁盘中。

事务的状态

系统日志的作用？系统日志中的典型记录类型是什么？什么是事务的提交点？他们的重要性？

日志是一些存储在磁盘上的文本文件，单纯的用来记录事务的一些操作。在内存缓冲区中有一部分内容用来记录最晚的日志内容，等到用于日志缓存的缓冲区满或者达到其他条件时就将这部分内容追加到磁盘的文本内容中。一些典型的日志记录如下所示：

• [start_transaction, T] : 表示事务T开始执行。
• [write_item, T, X, old_value, new_value ] : 事务T对数据项X进行写操作，还记录了旧值和新值。
• [read_item, T, X] : 事务T读取数据项X。
• [commit T] : 事务T被提交。表明事务T结束。
• [abort T] : 事务T被撤销。没有更新到磁盘上的操作被忽视，已经更新到磁盘上的事务被回滚，撤销对磁盘上内容做出的更改。
  事务被提交就意味着数据库系统不能通过日志对事务进行撤销操作。比如说一条sql的更新语句，当这条更新语句的操作被提交之后，对数据所作的更改已经保存到磁盘，当然不被提交也可以保存到磁盘，数据库系统不能自动的进行撤销操作。但这不代表着这条语句不能被撤销，可以人为的再进行update回原先的值。这是人为的又执行了另一条事务抵消了上一条事务的影响。当然了解到这里并不代表数据库系统不能自行撤销，但这就意味着违反了事务的持久性。。。矛盾呀，这个矛盾肯定来自于这两个地方的理解偏差。给自己留个坑吧。。。要是我设计的话我就允许系统可以根据日志做出撤销操作，当然也是我显示的给出一条撤销的指令。。。晕。。。
  事务提交点使用来表征事务所有访问数据库的操作已经完成，并且日志已经记录了事务对数据库产生的影响并已被保存到磁盘。Mysql操作中savepoint

什么是冲突？

冲突就是当事务按照不同的次序执行的时候最终得到的不同的结果，这就叫做冲突。

什么是调度？介绍可恢复调度，无级联调度，严格调度的定义，并比较他们的可恢复性。

• 调度：当系统中存在几个事务时，安排一种事务的执行次序就叫做调度。（每一个事务可以分为若干个操作，这若干个操作可以有交叉的执行）
• 可恢复调度：事务的可恢复性是指当错误发生时，事务是可以恢复的。比如说因为断电而违反了事务的原子性和持久性或一致性，那么就可以采用一定的方法使数据库系统恢复到一个一致性状态。可恢复调度就是指：在一个调度S中，当存在这种情况的时候-T需要要读取T‘ 写过后的数据项X，发生这种情况的时候当且仅当满足T’ 的写操作先提交，而T的读操作后提交，这样的调度就 就叫做可恢复调度。因为调度只要满足这种条件，并且日志文件中有足够充分的记录信息，就可以从这个调度中设计一个恢复算法进行恢复。（按照前面的定义，事务的读取操作包括从磁盘中读取某个数据项X，而不是直接在缓冲区寻找以前别的事务已经读取过X，此时读操作的提交代表真的从磁盘中读取了这个数据项了，而不是我的操作语句处于挂起等待状态，只是声明了一下并没有完全的执行；同样事务的写操作包括需要先把数据项X从磁盘读取到缓冲区X中，然后再保存程序变量的堆里更改变量值，再复制到相应的缓冲区，再写回到磁盘中，此时写操作的提交代表整个过程已经完成，而不是只执行了一部分，比如说数据项只是在缓冲区中做了修改，而没有写回到磁盘）。
• 完备调度：存在冲突的操作顺序在一个调度中和其所在的事务的调度顺序是相同的。
  比如说一对写写冲突w1(x)和w2(x)，在S中事务的执行次序是T1，T2，所以w1(x)的执行需要先于w2(x)的执行。
• 严格调度：在某个事务的写操作完成之前不允许别的事务中冲突操作执行。是完全可恢复的。
• 级联回滚：事务T读了T’修改过的数据，但是T‘在撤销之前被撤销了，当然T也需要撤销。这种级联撤销就叫做级联回滚。

什么是串行调度？什么是可串行化的调度？Why is a serial schdule considered correct?Why is a serializable schdule considered correct?

这个很简单，并没有什么理解上的障碍。。。所以不写了。

介绍一下事务等价不同的衡量标准，冲突等价和视图等价有什么区别？

• 衡量标准如：对数据库的影响结果相同，比如说两个事务对同一数据项进行修改后的值相等，但存在一定的偶然性，所以不用；另一个事务等价的定义就是在不同的事务中，对数据项修改的操作的相对顺序相同就可以。。。
• 冲突等价：在两个调度中，冲突操作的相对顺序相同。
• 视图等价：在两个调度中，相同的读操作读到的内容来自于的各自调度中相同的写操作产生的结果。

可串行化是怎么用来进行并发控制的？

可以这样理解：可串行化保证事务的调度是正确的，如果设计的并发控制协议保证了可串行化，那么就可以保证事务调度的正确性。在这里事务调度的正确性就是指可以保证事务的ACID特性。其中可串行化包括冲突可串行化和视图可串行化，预测一个调度是否为冲突可串行化在实际中不可行，因为受到的影响因素太多；而检测是否是视图可串行化的算法又被证明是NP难的问题，所以呀，在实际中都是通过设计一定的并发控制协议来保证调度的冲突可串行性或者视图可串行性，从而来保证事务的ACID特性。

什么是严格写和非严格写？

• 严格写表示一个事务中对数据项X进行写操作之前需要现有读操作。换句话说，写操作的数据和读操作的数据是一毛一样的。

可串行性如何用于并发控制？为什么可串行性过于严格？

在实际中很难在一个调度执行之前就可以做出其是否可行性的判断。因此，实际中都是设定一定的协议或者算法来保证调度是可串行性的。

描述SQL中四种隔离级别

给出下列情况引起的违规定义：脏读，不可重复读，幻想

• 脏读：一个事务修改了一个数据项的值，但没有提交；而正好此时另一个事务读取了这个没有被提交的值；但是第一个事务又做出了撤销操作，此时就会发生脏读现象。
• 不可重复读：一个事务读取了一个数据项，但是过一会再次读取的时候这个值被另一个事务修改了，那么就会发生前后两次读取的数据项的值不一致的情形，就叫做不可重复读。（其实再这里我感觉这是一个正常现象，有时候确实会发生这种情况，比如说，读取的某个值被更新了，很正常，但在某些特殊场景下一个事务会两次读取这个数据值并要求这两次读取的数据值相等，按照我的感觉发生这样事件的概率很小。。。但也不能忽略呀）
• 幻像：当是一个事务做查询时读取了一些符合where条件的元组，但是一会另一个事务又插进去一些符合where条件的元组，这样当第一个事务再做查询时就会发生两次查询不一致的情况，而这种情况在某些实际场景下是不被允许的，就会产生错误。。。