ORACLE_OCP之事务

ORACLE_OCP之事务

一、事务和oracle的一致性

事务：万事皆事务
时间、地点、任务、起因、经过、结果—>所有事情或者所有事务都有开始和结局。
小型机：HPUX、AIX、SOLARIS、富士通、浪潮
中型机：
大型机：OS390

事务的四特性：ACID

A：原子性，事务要不然提交，要不然就回滚，commit记录redo、rollback不记录redo。

• 提交（commit）：确认修改，并告知数据库事务完成，数据库记录操作
  update xxx/insert xxx/delete —> 检查一下（认为主动检查） (1)—> 检查无误 —> 提交
  (2)—> 检查有误 —> 回滚
• 回滚（rollback）：撤销你刚才操作的所有DML（INSERT DELETE UPDATE 语句）,数据库不记录操作

C：一致性，事务发生的前后，不影响数据库当前的整体状态。

• startup
  • 前滚：将已提交未写入的重新发生一遍
  • 回滚：将未提交已写入的回滚出数据库 —> 保证数据库的一致性

I：隔离性，两个事务之间不能互相干扰。
D：持久性，事务一旦提交，就不能被回滚，（记忆小技巧：把工资交给老婆）。

补充：MYSQL的事务管理：

• MYSQL是自动提交，发生完DML语句以后自动执行COMMIT；建议大家把AUTO_COMMIT=FALSE。

dual是oracle的伪表，只有当数据库处于在open/open read only状态下这张伪表才能真正的打开。

事务-数据并发与事务隔离级别

• oracle数据库是单人使用的数据库还是多用户多任务数据库？
• 多用户多任务数据库（多用户多任务系统）最核心的一点是什么？-- 并发
• 并发：在同一时刻，多个用户可能会发起多个任务请求。
• 在并发问题中，什么是核心点？
  • 保证资源的安全
    • 在关系型数据库中，我们的资源要保证事务级的安全。

PS.在数据库里数据分为：用户数据与元数据。

PS.难道数据提交之后真的不能再回滚了吗？
不一定：因为从事务角度上来说ACID中的D就是持久性，这个持久性是事务一旦被提交就不能再被回滚了，（一旦被commit就不可以再rollback了），但是从备份恢复的角度来说，我们可以通过物理级别的RMAN基于时间的不完全恢复或逻辑级别的闪回操作等，让过去发生重演。

PS：数据库中所有的改变，都是以事务形式产生的，并且这些事务可能来自多个用户。

PS：在所有的关系型数据库数据库中，并发操作可能会产生问题！

第一个问题：脏读，在oracle中永远都不会发生，但是不代表其他数据库就不发生，脏读过去曾经是一个普遍现象，但是现在在SQL192标准后的后的数据库中，已经大量的使用了一致性读（提交读）的方式代替了原有的数据加载模式，所以基本上已经杜绝了脏读这个现象。

• SELECT…FOR UPDATE操作，将所有SELECT查到的行加锁，不允许任何用户发生修改，为了保证数据的强制一致性。使用commit将该事务完成。

第二个问题：不可重复读，事务A早上九点查询的结果集做了记录，事务B在九点十五分修改了数据并提交，事务A早上九点半重新查询了结果集，发现结果集已经产生了修改，和上一次记录不符，我们称这种操作为不可重复读，虽然不可重复读从技术和事务的层面是正确的，但是有时候，公司业务可能要做T+1操作，这时修改的数据就会对原有的统计产生严重的影响，所以我们不得不使用SELECT…FOR UPDATE将数据进行人为锁定，执行相关的报表业务，报表业务完成后，将锁放开。

• 如果要实现可重复读，就要使用强制一致性手段。

PS.T+1：所谓的T+1操作，指的是第二天去处理之前一天的数据。

PS.SELECT…FOR UPDATE不影响其他事务发生查询，只影响其他事务发生UPDATE和DELETE操作。

第三个问题：幻读，事务A早上九点查询的结果集做了记录，事务B在九点十五分插入了数据并提交，事务A早上九点半重新查询了结果集，发现结果集已经产生了插入，和上一次记录不符，我们称这种操作为幻读，虽然幻读从技术和事务的层面是正确的，但是有时候，公司业务可能要做T+1操作，这时修改的数据就会对原有的统计产生严重的影响，所以我们必须要标记好时间维度，不能使用SELECT…FOR UPDATE操作去避免或减小影响。

第四个问题：串行化，串行化隔离的事务只能看到事务执行前就已经提交的数据和业务。

• oracle的隔离级别：
  1.第一种，已提交读/一致性读
  2.第二种，串行化
  3.第三中，read only（只读模式）