达梦事务管理

达梦事务管理，全部参照官方文档。

1. 数据库是一个共享资源，可以被大量应用程序所共享，这些应用程序可以串行运行，但在绝大多数情况下，为了有效地利用数据库资源，多个应用程序会并发的访问数据库，这就是数据库的并发操作。此时若不对并发操作进行控制，则会存取不正确的数据，或破坏数据的一致性。DM通过提供事务管理相关技术来解决上述问题。
2. 数据库事务是指作为单个逻辑工作单元的一系列操作的集合。一个典型的事务由应用程序中的一组操作序列组成，对于DM数据库来说，第一次执行SQL语句时，隐式的启动一个事务，以COMMIT或ROLLBACK语句/方法显式的结束事务。另外，在执行DDL语句之前，DM数据库会自动把前面的操作进行提交，DDL前面的操作作为一个完整的事务结束，DDL语句本身所属的事务则根据“DDL_AUTO_COMMIT”配置参数决定是否隐式的提交（注意，无论DDL_AUTO_COMMIT参数如何设置，ALTER TABLESPACE和ALTER USER操作总是自动提交的。DDL_AUTO_COMMIT取值为1表示自动提交，取值为0表示手动提交。当COMPATIBLE_MODE为1时，DDL_AUTO_COMMIT的实际值均为0）。
3. COMMIT会将该语句所对应的事务对数据库的所有更新持久化（即写入磁盘），数据库此时进入一个新的一致性状态，同时该事务成功地结束。ROLLBACK操作将该语句所对应的事务对数据库的所有更新全部撤销，把数据库恢复到该事务初启动前的一致性状态。
4. 为了提高事务管理的灵活性，DM数据库还提供了设置保存点（SAVEPOINT）和回滚到保存点的功能。保存点提供了一种灵活的回滚，事务在执行过程中可以回滚到某个保存点，在该保存点以前的操作有效，而以后的操作被回滚掉。可以使用SAVEPOINT SAVEPOINT_NAME命令创建保存点，使用ROLLBACK TO SAVEPOINT SAVEPOINT_NAME命令来回滚到保存点SAVEPOINT_NAME。如：CREATE TABLE TEST(A INT,B VARCHAR); INSERT INTO TEST VALUES (1,’HAHA’); SAVEPOINT S1; SELECT * FROM TEST; INSERT INTO TEST VALUES (2,’HEHE’); SELECT * FROM TEST; ROLLBACK TO SAVEPOINT S1; SELECT * FROM TEST;
5. 一个逻辑工作单元必须表现出四种属性，即原子性、一致性、隔离性和持久性，这样才能成为一个有效的事务。
6. 事务的原子性保证事务包含的一组更新操作是原子不可分的，也就是说这些更新操作是一个整体，对数据库而言全做或全不做，不能部分地完成。这一性质即使在系统崩溃之后仍能得到保证，在系统崩溃之后将进行数据库恢复，用来恢复和撤销系统崩溃时处于活动状态地事务对数据库地影响，从而保证事务地原子性。系统对磁盘上的任何实际数据的修改之前都会将修改操作本身的信息记录到磁盘上。当发生崩溃时，系统能根据这些操作记录当时该事物处于何种状态，以确定是撤销该事物所作出的所有修改操作还是将修改的操作重新执行。
7. 数据一致性是指表示客观世界同一事务状态的数据，不管出现在何时何处都是一致的、正确的、完整的。即数据一致性是任何点上保证数据以及内部数据结构的完整性，如B树索引的正确性（？什么叫B树索引的正确性？）。一致性要求事务执行完成后，将数据库从一个一致性状态转变到另一个一致性状态，事务的一致性属性要求事务在并发执行的情况下事务的一致性仍然满足。
8. 事务是隔离的，意味着每个事物的执行效果与系统中只有该事物的执行效果一样，也就是说，某个并发事务所作的修改必须与任何其它的并发事务所作的修改相互隔离。这样只有当某个值被一个事务修改并提交完成后才会影响到另一个事务。事务只会识别零一并发事务修改之前或修改完成之后的数据，不会识别处于这中间状态的数据。事务的隔离行为依赖于指定的隔离级别。
9. 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其它操作和数据库故障不应该对其有任何影响。即一个事务一旦提交，DBMS保证它对数据库中数据的改变应该是永久性的。若DM数据库或操作系统出现故障，那么在DM数据库重启的时候，数据库会自动恢复。若某个数据驱动器出现故障，并且数据丢失或者被损坏，可以通过备份和联机重做日志来恢复数据库。需要注意的是，若备份驱动器也出现故障，且系统没有准备其他的可靠性解决措施，备份就会丢失，那么就无法恢复数据库了。
10. 提交事务就是提交事务对数据库所作的修改，将从事务开始时的所有更新保存到数据库中，任何更改的记录都被写入日志文件并最终写入到数据文件，同时提交事务还会释放由事务占用的资源，如锁。若提交时数据还没有写入到数据文件，DM数据库后台线程会在适当时机（如检查点、缓冲区满）将它们写入。
11. 具体说来，在一个修改了数据的事务被提交之前，DM数据库进行了以下操作：生成回滚记录，回滚记录包含了事务中各SQL语句所修改的数据的原始值；在系统的重做日志缓冲区中生成重做日志记录，重做日志记录包含了对数据页和回滚页所进行的修改，这些记录可能在事务提交之前被写入磁盘；对数据的修改已经被写入数据缓冲区，这些修改也可能在事务提交之前被写入磁盘。
12. 已提交事务中对数据的修改被存储在数据库的缓冲区中，它们不一定被立即写入数据文件内。DM数据库自动选择适当的时机进行写操作以保证系统的效率。因此写操作既可能发生在事务提交之前，也可能在提交之后。
13. 当事务提交之后，DM数据库进行以下操作：将事务任何更改的记录写入日志文件并最终写入到数据文件中；释放事务上的所有锁，将事务标记为完成；返回提交成功消息给请求者。
14. 在DM数据库中还存在有3中事务模式：自动提交模式、手动提交模式和隐式提交模式。
15. 除了命令行交互式工具DISQL外，DM数据库缺省都采用自动提交模式，用户通过DM数据库的其它管理工具、编程接口访问DM数据库时，若不手动/编程设置提交模式，所有的sql语句都会在执行结束后提交，或者在执行失败后回滚，此时每个事务都只有一条sql语句。（？管理工具和编程接口不是都需要手动提交吗？要么是执行commit，或者点提交按钮。怎么就成自动提交了？）在DISQL中，用户也可以通过执行SET AUTOCOMMIT ON;命令来设置当前会话为自动提交模式，也可以在DISQL中使用show autocommit;命令查看当前的提交模式。
16. 在手动提交模式下，DM数据库用户或应用开发人员应该明确定义事务的开始和结束，这些事务也称为显式事务。在DISQL中，没有设置自动提交时，就是出于手动提交模式，此时DISQL连接到服务器后第一条语句或事务结束后的第一条语句就标记着事务的开始，可以执行COMMIT或ROLLBACK来提交或回滚事务。
17. 在手动提交模式下，当遇到DDL语句时，DM数据库会自动提交前面的事务，然后开始一个新的事务执行DDL语句。这种事务提交模式被称为隐式提交。DM数据库遇到以下sql语句时自动提交前面的事务：CREATE; ALTER; TRUNCATE; DROP; GRANT; REVOKE; 审计设置语句。
18. 回滚事务是撤销该事务所作的任何更改。回滚有两种形式：DM数据库自动回滚，或通过程序/ROLLBACK命令手动回滚。除此之外，还有混滚到保存点和语句级回滚。
19. 若事务运行期间出现连接断开，DM数据库都会自动回滚该连接所产生的事务。回滚会撤销事务执行的所有数据库更改，并释放此事务使用的所有数据库资源。DM数据库在恢复时也会使用自动回滚。如在运行事务时服务器突然断电，接着系统重启，DM数据库就会在重启时执行自动恢复。自动恢复要从事务重做日志中读取信息以重新执行没有写入磁盘的已提交的事务，或者回滚故障时还没有来得及提交的事务。（数据库重启时有三个步骤：redo、undo、purge）
20. 一般来说，在实际应用中，当某条sql语句执行失败时，用户会主动使用ROLLBACK语句或者编程接口提供的回滚函数来回滚整个事务，避免不合逻辑的事务污染数据库，导致数据不一致。若发生错误后确实只用回滚事务中的一部分，则需要用到回滚到保存点的功能。
21. 除了回滚整个事务之外，DM数据库的用户还可以部分回滚未提交的事务，即从事务的最末端回滚到事务中任意一个被称为保存点的标记处。用户在事务内可以声明多个被称为保存点的标记，将一个大事务划分为几个较小的片段。之后用户在对事务进行回滚操作时，就可以选择从当前执行位置回滚到事务内的任意一个保存点。将事务回滚到某个保存点的过程如下：只回滚保存点之后的语句；保留该保存点，其后创建的保存点都将被清除；释放此保存点之后获得的所有锁，保留该保存点之前的锁。被部分回滚的事务依然处于活动状态，可以继续执行。
22. 如果在一个SQL语句执行过程中发生了错误，此语句对数据库产生的影响将被回滚，回滚后就如同此语句从未执行过，这种操作被称为语句级回滚。语句级回滚只会使此语句所作的数据修改无效，不会印象此语句之前所作的数据修改。当INI参数ROLL_ON_ERR为缺省值0时，在SQL语句执行过程中发生的错误，将会导致语句级回滚，例如违反唯一性约束、死锁（访问相同数据而产生的竞争）、运算溢出等。在SQL语句解析的过程中发生错误（如语法错误），由于未对数据产生任何影响，因此不会产生语句级回滚。当ROLL_ON_ERR为1时，SQL语句执行过程中发生错误将会回滚整个事务。
23. DM数据库支持多用户并发访问、修改数据，有可能出现多个事务同时访问、修改相同数据的情况。若对并发操作不加控制，就可能会访问到不正确的数据，破坏数据的一致性和正确性。封锁机制是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据库对象进行操作前，需要先对其封锁。封锁后事务就对该数据库对象有了一定的控制，在该事务释放锁之前，其它事务不能对此数据库对象进行相应操作。
24. 锁模式指定并发用户如何访问锁定资源。DM数据库使用四种不同的锁模式：共享锁、排他锁、意向共享锁和意向排他锁。共享锁（SHARE LOCK，简称S锁）用于读操作，防止其他事务修改正在访问的对象。这种封锁模式允许多个事务同时并发读取相同的资源，但是不允许任何事物修改这个资源；排他锁（EXCLUSIVE LOCK，简称X锁）用于写操作，以独占的方式访问对象，不允许其它任何事务访问被封锁的对象，防止多个事务同时修改相同的数据，引发数据错误，防止访问一个正在被修改的对象，避免引发数据不一致。一般在修改对象定义时使用；意向锁（INTENT LOCK）用于读取或修改被访问对象数据时使用，多个事务可以同时对相同对象上意向锁，DM支持两种意向锁：意向共享锁（INTENT SHARE LOCK，简称IS锁）一般在只读访问对象时使用；意向排他锁（INTENT EXCLUSIVE LOCK，简称IX锁）一般在修改对象数据时使用。（意向锁和前面两种锁有什么不一样？什么操作对应什么锁？没搞清楚哦）
25. 按照封锁对象的不同，锁可以分为TID锁和对象锁。
26. TID锁以事务号为封锁对象，为每个活动事务生成一把TID锁，代替了其它数据库行锁的功能，防止多个事务同时修改同一行记录。DM实现的是行级多版本，每一行记录隐含一个TID字段，用于事务可见性判断。执行INSERT、UPDATE和DELETE操作时，设置事务号到TID字段，这相当于隐式的对记录上了一把TID锁，INSERT、UPDATE和DELETE操作不再需要额外的行锁，避免了大量行锁对系统资源的消耗。只有多个事务同时修改一行记录时才会产生新的TID锁。例如，当事务T1（事务号为TID1）试图修改某行数据，而该行数据正在被另一个事务T2（事务号为TID2）修改，此时事务T1会生成一个新的TID锁，其锁对象为事务号TID2，而非事务T2。同时多版本写不阻塞读的特性，SELECT操作已经消除了行锁，因此DM中不再有行锁的概念。
27. 对象锁是DM新引入的一种锁，通过统一的对象ID进行封锁，将对数据字典的封锁和表锁合并为对象锁，以达到减少封锁冲突、提升系统并发性能的目的。通常数据字典锁和表锁各自应承担的功能如下：数据字典锁用来保护数据字典对象的并发访问，解决DDL/DML并发问题，防止多个事务同时修改同一个对象的字典定义，确保对同一个对象的DDL操作是串行执行的，并防止一个事务在修改字典定义的同时，另外一个事务修改对应表的数据；表锁用来保护表数据的完整性，防止多个事务同时采用批量方式插入、更新一张表（不使用批量方式就可以了？），防止向正在使用FAST LOADER工具装载数据的表中插入数据等，保证这些优化后数据操作的正确性，此外，表锁还有一个作用，避免对存在未提交修改的表执行ALTER TABLE、TRUNCAT TABLE操作。
28. 为了实现与数据字典锁和表锁相同的封锁效果，从逻辑上将对象锁的封锁动作分为四类：独占访问（EXCLUSIVE ACCESS）不允许其它事务修改对象，不允许其他事务访问对象，使用X方式封锁；独占修改（EXCLUSIVE MODIFY）不允许其他事务修改对象，允许其它事务共享访问对象，使用S + IX方式封锁；共享修改（SHARE MODIFY）允许其他事务共享修改对象，允许其它事务共享访问对象，使用IX方式封锁；共享访问（SHARE ACCESS）允许其他事务共享修改对象，允许其他事务共享访问对象，使用IS方式封锁。
29. 用户可以根据自己的需要显式的对表对象进行封锁，语法：LOCK TABLE <TAB_NAME> IN <LOCK_MODE> MODE [NOWAIT]; 其中LOCK_MODE是锁定的模式，可以选择的模式有INTENT SHARE（意向共享）、INTENT EXCLUSIVE（意向排他）、SHARE（共享）和EXCLUSIVE（排他）。意向共享：不允许其他事务独占修改该表，意向共享锁定后，不同事务可以同时增删改查表的数据，也支持在该表上创建索引，但不支持修改表的定义；意向排他：不允许其它事务独占访问和独占修改该表，被意向排他后，不同事务可以同时增删改查该表的数据，不支持在该表上创建索引，也不支持修改该表定义；共享：只允许其它事务共享访问该表，仅允许其他事务查询表中的数据，但不允许增删改该表的数据；排他：以独占访问方式锁定整个表，不允许其他事务访问该表，是封锁力度最大的一种封锁方式。当使用NOWAIT时，若不能立即上锁则立刻返回报错信息，不再等待。如：LOCK TABLE TEST IN INTENT SHARE MODE NOWAIT;
30. 为了方便用户查看当前系统中锁的状态，DM数据库提供了一个V$LOCK动态视图，通过该视图，用户可以查看到系统当前所有锁的详细信息，如锁的内存地址、所属事务ID、锁类型、锁模式等。详细字段如下：ADDR（锁的内存地址）、TRX_ID（锁所属的事务ID）、LTYPE（锁类型，可能是OBJECT对象锁或TID锁）、LMODE（锁模式，可取值有S、IS、X、IX）、BLOCKED（表示锁是否处于上锁等待状态，0表示已上锁成功，1表示处于上锁等待状态）、TABLE_ID（对于对象锁，表示对象或字典对象的ID，对于TID锁，表示封锁记录对应的表ID）、ROW_IDX（表示TID锁封锁记录的行信息）、TID（为TID锁对象事务ID）
31. 在多版本控制以前，数据库仅通过锁机制来实现并发控制。数据库对读操作上共享锁，写操作上排他锁，这种锁机制虽然解决了并发问题，但影响了并发性。例如当一个事务对表进行查询时，另一个对表更新的事务就必须等待。DM数据库的多版本实现完全消除了行锁对系统资源的消耗，查询永远不会被阻塞也不需要上行锁，并通过TID锁机制消除了插入、删除、更新操作的行锁。数据库的读操作与写操作不会相互阻塞，并发度大幅度提高。DM数据库基于物理记录和回滚记录实现行级多版本支持，数据页中只保留物理记录的最新版本，通过回滚记录维护历史版本，所有事务针对特定的版本进行操作。
32. 为了适应多版本机制，高效的获取历史记录，每一条物理记录中包含了两个字段：TID和RPTR。TID保存修改记录的事务号，RPTR保存回滚段中上一个版本回滚记录的物理地址。插入、删除和更新物理记录时，RPTR指向操作生成的回滚记录的物理地址。物理记录格式如下：|物理记录|TID|RPTR|。新物理记录的RPTR指向当前回滚记录的物理地址。
33. 回滚记录与物理记录一样，增加了两个字段，TID和RPTR。TID保存回滚记录对应的事务号，RPTR保存回滚段中上一个版本回滚记录的物理地址。格式：|回滚记录|TID|RPTR|。插入物理记录时，由于没有更老的版本数据，回滚记录的RPRT值为NULL，更新和删除物理记录时，RPTR指向原始物理记录的RPTR。
34. 实现多版本控制的关键是可见性判断，找到对当前事务可见的特定版本数据。DM通过活动事务表，确定事务的可见性。根据事务的隔离级的不同，在事务启动时（串行化），或者语句执行时（读提交），收集这一时刻所有活动事务，并记录系统中即将产生的事务号NEXT_TID。DM多版本可见性原则：物理记录的TRXID等于当前事务号，说明是本事务修改的物理记录，物理记录可见；物理记录的TRXID不在活动事务表中，并且TRXID小于NEXT_ID，物理记录可见；物理记录的TRXID包含在活动事务表中，或者TRXID大于等于NEXT_ID，物理记录不可见（TRXID怎么可能大于NEXT_ID呢？）。
35. 当物理记录对当前事务不可见时，根据物理记录和回滚记录的RPTR指针，向前回溯一个历史版本记录，通过此历史版本记录的TID字段，依据事务可见性原则判断此版本的记录对当前事务是否可见。若可见即获取到了满足当前事务的历史版本数据，若不可见则继续向前回溯，若一直不能找到对当前事务的可见版本（例如此纪录是一个活动事务插入的新纪录），则此纪录将不会添加到查询结果集中。
36. 由于需要根据回滚记录回溯、还原物理记录的历史版本信息，因此不能在事务提交时立即清除当前事务产生的回滚记录。但是若不及时清理回滚段，可能造成回滚段空间的不断膨胀，占用大量磁盘空间。DM提供了自动清理、回收回滚段空间的机制。系统定时（缺省是每间隔1秒）扫描回滚段，根据回滚记录的TID，判断是否需要保留回滚记录清除那些对所有活动事务可见的回滚记录空间。
37. 脏读（dirty read）：所谓脏读就是对脏数据的读取，而脏数据所指的就是未提交的已修改数据。也就是说一个事务正在对一条记录做修改，在这个事务完成并提交之前，这条数据是处于待定状态的（可能提交也可能回滚），这时，第二个事务来读取这条没有提交的数据，并据此做进一步处理，就会产生未提交的数据依赖关系，这种现象称为脏读。若一个事务在提交操作结果之前，另一个事务可以看到该结果，就会发生脏读。
38. 不可重复读（non-repeatableRead）：一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。若一个事务在读取了一条记录后，另一个事务修改了这条记录并提交了事务，再次读取记录时若获取到的是修改后的数据，这就发生了不可重复读情况。
39. 幻像读（phantomRead）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的数据，这种现象称为幻像读。
40. 在SQL-92标准中，定义了四种隔离级别：读未提交、读提交、可重复读和串行化。DM数据库支持三种事务隔离级别：读未提交、读提交和串行化。其中读提交是DM数据库默认使用的事务隔离级别。可重复读升级为更严格的串行化隔离级。
41. DM数据库的读提交隔离可以确保只访问到已提交事务修改的数据，保证数据库处于一致性状态，能够满足大多数应用的要求，并最大限度保证系统并发性能，但可能会出现不可重复读取和幻像读。用户可以在事务开始时使用SET TRANSACTION ISOLATION LEVEL READ COMMITTED;命令设置事务为读提交隔离级。
42. 在要求消除不可重复读取或幻像读的情况下，可以设置事务隔离级为串行化。跟读提交隔离级相比串行化事务的查询本身不会增加任何代价，但修改数据可能引发“串行化事务被打断”的错误。具体来说，当一个串行化事务试图更新或删除数据时，而这些数据在此事务开始后被其他事务修改并提交时，DM数据库将报错“串行化事务被打断”。若系统中存在长时间运行的写事务，并且该长事务所操作的数据还会被其它短事务频繁更新的话，最好避免使用串行化事务。可以在事务开始时使用SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;命令设置事务为串行化隔离级。
43. 读未提交隔离级别是最不严格的隔离级别。实际上在使用这个隔离级别时，有可能发生脏读、不可重复读和幻像读，一般来说，读未提交隔离级别通常只用于访问只读表和只读视图，以消除可见性判断带来的系统开销，提升查询性能。可使用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;命令在事务开始时设置事务为读未提交隔离级别。
44. DM数据库还支持只读事务，只读事务只能访问数据，但不能修改数据，并且只读事务不会改变事务原有的隔离级。用户可以在事务开始时用SET TRANSACTION READ ONLY;命令设置事务为只读事务。
45. 阻塞和死锁是会与并发事务一起发生的两个事件，他们都与锁相关。当一个事务正在占用某个资源的锁，此时另一个事务正在请求这个资源上与第一个锁相冲突的锁类型时，就会发生阻塞。被阻塞的事务将一直挂起，直到持有锁的事务放弃锁定的资源为止。死锁与阻塞的不同之处在于死锁包括两个或者多个已阻塞的事务，它们之间形成了等待环，每个都等待其他事务释放锁，若数据库中发生了死锁，DM数据库会选择牺牲掉其中一个事务。
46. 当用户不慎操作导致错误的删改数据时，希望有一种简单快捷的方式可以恢复数据。闪回技术就是为了用户可以迅速处理这种数据逻辑损坏的情况而产生的。闪回技术主要是通过回滚段存储的UNDO记录来完成历史记录的还原。设置ENABLE_FLASHBACK为1后（默认不开启），开启闪回功能。DM会保留回滚段一段时间，回滚段保留的时间代表着可以闪回的时间长度，由UNDO_RETENTION指定。
47. 开启闪回功能后，DM会在内存中记录下每个事务的起始时间和提交时间。通过用户指定的时刻，查询到该时刻的事务号，结合当前记录和回滚段中的UNDO记录，就可以还原出特定事物的记录号。即指定时刻的记录状态，从而完成闪回查询。闪回查询完全依赖于回滚段的管理，对于DROP等误操作不能恢复。
48. 闪回特性可以用在以下方面：自我维护过程中的修复，当一些重要的记录被意外删除，用户可以向后移动到一个时间点，查看丢失的行并把它们重新插入现在的表内恢复；用于分析数据变化，可以对同一张表的不同闪回时刻进行链接查询，以此查看变化的数据。