1 / 82

第 7 章 系统实现技术

第 7 章 系统实现技术. 本章重要概念 (1). （ 1 ）事务的定义， COMMIT 和 ROLLBACK 的 语义，事务的 ACID 性质，事务的状态 变迁图。 （ 2 ）存储器类型，稳定存储器的实现，数据传 送过程。 （ 3 ）恢复的定义、基本原则和实现方法， 故障的类型，检查点技术， REDO 和 UNDO 操作，运行记录优先原则。. 本章重要概念 (2).

aloysius-caleb
Download Presentation

第 7 章 系统实现技术

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第7章 系统实现技术

  2. 本章重要概念(1) （1）事务的定义，COMMIT和ROLLBACK的 语义，事务的ACID性质，事务的状态 变迁图。 （2）存储器类型，稳定存储器的实现，数据传 送过程。 （3）恢复的定义、基本原则和实现方法， 故障的类型，检查点技术，REDO和 UNDO操作，运行记录优先原则。

  3. 本章重要概念(2) （4）并发操作带来的三个问题，X锁、S锁、使用X锁和S锁的操作，封锁协议，活锁、饿死和死锁，并发调度、串行调度、并发调度的可串行化，SQL中事务的存取模式和隔离级别，基于时标的并发控制。 （5）完整性的定义，完整性子系统的功能，完整性规则的组成。SQL中的三大类完整性约束，SQL3中的触发器技术。 （6）安全性的定义、级别，权限，SQL中的安全性机制，几种常用的安全性措施，自然环境的安全性。

  4. 第7章 系统实现技术 • 7.1 事务 • 7.2 数据库的恢复 • 7.3 数据库的并发控制 • 7.4 数据库的完整性 • 7.5 数据库的安全性 • 7.6 小结

  5. 7.1 事务 • 7.1.1 事务的定义 • 7.1.2 事务的ACID性质 • 7.1.3 事务的状态变迁图

  6. 7.1.1事务的定义(1) • 定义7.1 事务（transaction）是构成单一逻辑工作单元的操作集合，要么完整地执行，要么完全不执行。不论发生何种情况，DBS必须保证事务能正确、完整地执行。 • 在程序中，事务以BEGIN TRANSACTION语句开始，以COMMIT语句或ROLLBACK语句结束。 • COMMIT语句表示事务执行成功地结束（提交），此时告诉系统，数据库要进入一个新的正确状态，该事务对数据库的所有更新都已交付实施（写入磁盘）。 • ROLLBACK语句表示事务执行不成功地结束（应该“回退”），此时告诉系统，已发生错误，数据库可能处在不正确的状态，该事务对数据库的所有更新必须被撤消，数据库应恢复该事务到初始状态。

  7. 7.1.1事务的定义(2) • 组织成如下事务： T： BEGIN RANSACTION； read（A）； A:=A-50； write（A）； if(A＜0)ROLLBACK； else {read（B）； B:=B+50； write（B）； COMMIT；} • 例7.1 设银行数据库中有一转账事务T，从账号A转一笔款子（$50）到账号B，其操作如下： T：read（A）； A:=A–50； write（A）； read（B）； B:=B + 50； write（B）.

  8. 7.1.1事务的定义(3) • 对数据库的访问是建立在读和写两个操作的基础上的： read（X）：把数据X，从磁盘的数据库中读到内存的缓冲区中。 write（X）：把数据X，从内存缓冲区中写回磁盘的数据库。 • 在系统运行时，write操作未必导致数据立即写回磁盘，很可能先暂存在内存缓冲区中，稍后再写回磁盘。这件事情是DBMS实现时必须注意的问题。

  9. 7.1.2事务的ACID性质 • 性质 • 原子性(Atomicity):事务是一个不可分割的工作单元。 • 一致性(Consistency):即数据不会应事务的执行而遭受破坏。 • 隔离性(Isolation):在多个事务并发执行时，系统应保证与这些事务先后单独执行时的结果一样。 • 持久性(Durability):一个事务一旦完成全部操作后，它对数据库的所有更新应永久地反映在数据库中。

  10. READ/WRITE 局部提交状态 活动状态 提交状态 失败状态 异常中止状态 图7.1 事务的状态变迁图 7.1.3事务的状态变迁图

  11. 7.2数据库的恢复 • 7.2.1 存储器结构 • 7.2.2 恢复的基本原则和实现方法 • 7.2.3 故障类型和恢复方法 • 7.2.4 检查点技术 • 7.2.5 SQL对事务的支持

  12. 7.2.1存储器结构(1) • 1.存储器类型 • 易失性存储器（volatile storage） 内存、cache存储器 • 非易失性存储器（nonvolatile storage） 磁盘和磁带 • 稳定存储器（stable storage） 这是一个理论上的概念。存储在稳定存储器中的信息是决不会丢失的。 • 2.稳定存储器的实现 • 数据备份 • 数据银行

  13. input(A) output(B) B 磁盘 内存 图7.2 块操作 A B 7.2.1存储器结构(2) • 3. 数据访问 • 块、物理块和缓冲块 • 块的操作 • input（A）：把物理块A的内容传送到内存的缓冲块中。 • Output（B）：把缓冲块B的内容传送到磁盘中恰当的物理块中

  14. 包含x的块 Bx存在，input(B) 包含x的块 Bx存在， read(X) 磁盘 事务 xi X write(X) 请求read(X) 开始 事务工作区 分配 扫描内存 系统 磁盘缓冲区 7.2.1存储器结构(3)

  15. 假设没有事务的原子性，那么重新启动事务时，要么A因为再执行一遍而为1800，要么B因从未执行而保持原值。假设没有事务的原子性，那么重新启动事务时，要么A因为再执行一遍而为1800，要么B因从未执行而保持原值。 银行转账系统 A=2000 B=1000 事务 A=A-100 B=B+100 output(A) 断电或其 他故障 output(B) 7.2.1存储器结构(4) 4. 恢复和原子性的联系

  16. 7.2.2恢复的基本原则和实现方法 • 基本原则 ：“冗余”，即数据库重复存储。 • 具体实现方法 • 平时做好两件事：转储和建立日志 • 周期地（比如一天一次）对整个数据库进行拷贝，转储到另一个磁盘或磁带一类存储介质中。 • 建立日志数据库。记录事务的开始、结束及数据每一次插入、删除和修改前后的值，并写到“日志”库中。 • 一旦发生数据库故障，分两种情况进行处理 • 如果数据库已被破坏，则装入last数据库备份，再利用日志库将这两个数据库状态之间的所有更新重新做一遍。 • 如果数据库未被破坏，但某些数据不可靠，则撤消所有不可靠的修改，把数据库恢复到正确的状态。

  17. 7.2.3 故障类型和恢复方法(1) • 1.事务故障 • 可以预期的事务故障，如存款余额透支等 • 非预期事务故障，如运算溢出、数据错误、死锁等 • 2.系统故障：硬件故障、软件错误或掉电等 重新启动时，具体处理分两种情况考虑。 • 对未完成事务作UNDO处理； • 对已提交事务但更新还留在缓冲区的事务 进行REDO处理。

  18. 7.2.3 故障类型和恢复方法(2) • 3．介质故障 在发生介质故障和遭受病毒破坏时，磁盘上的物理数据库遭到毁灭性破坏。此时恢复的过程如下： • ①重装最近转储的后备副本到新的磁盘，使数据库恢复到转储时的一致状态。 • ②在日志中找出最近转储以后所有已提交的事务。 • ③对这些已提交的事务进行REDO处理，将数据库恢复到故障前某一时刻的一致状态。 在实际中，系统故障通常称为软故障(Soft Crash)，介质故障通常称为硬故障(Hard Crash)。

  19. 故障点 检查点 检查点 事务 T1 t T2 T3 T4 T5 7.2.4检查点技术(1) • 1．检查点方法 在DBS运行时，DBMS定时设置检查点。在检查点时刻才真正做到把对DB的修改写到磁盘，并在日志文件写入一条检查点记录(以便恢复时使用)。当DB需要恢复时，只有那些在检查点后面的事务需要恢复。 事务T1不必恢复； 事务T2和事务T4必须重做(REDO)； 事务T3和事务T5必须撤消(UNDO)。

  20. 7.2.4检查点技术(2) • 2．检查点方法的恢复算法：分成两步。 （1）根据日志文件建立事务重做队列和事务撤销队列。此时，从头扫描日志文件（正向扫描）。 （2）对重做队列中的事务进行REDO处理，对撤销队列中的事务进行UNDO处理。 进行REDO处理的方法是：正向扫描日志文件，根据重做队列的记录对每一个重做事务重新实施对数据库的更新操作。 进行UNDO处理的方法是：反向扫描日志文件，根据撤销队列的记录对每一个撤销事务的更新操作执行逆操作。

  21. 7.2.5 SQL对事务的支持 • 无begin transaction • Commit • Rollback • 游标

  22. 7.3 数据库的并发控制 • 7.3.1 并发操作带来的三个问题 • 7.3.2 封锁技术 • 7.3.3 封锁带来的问题 • 7.3.4 并发操作的调度 • 7.3.5 SQL对事务处理的支持 • 7.3.6 基于时标的并发控制

  23. 7.3.1并发操作带来的三个问题(1) 1．丢失更新问题（例7.2） 图7.5 在时间t7丢失了事务T1的更新 （FIND表示从DB中读值，UPD表示把值写回到DB）

  24. 7.3.1并发操作带来的三个问题(2) 2．读脏数据问题（例7.3，用户读了“脏数据”， 但没有破坏数据库的完整性） 图7.6 事务T2在时间t4读了未提交的A值（70）

  25. 7.3.1并发操作带来的三个问题(3) 2．读脏数据问题（例7.4，用户读了“脏数据”，引起 自身的更新操作被丢失，破坏了数据库的完整性） 图7.7 事务T2在时间t4读了未提交的A值， 并在时间t8丢失了自己的更新

  26. 7.3.1并发操作带来的三个问题(4) 3.不可重复读问题（例7.5） 图7.8 事务T1两次读取A的值，却得到了不同的结果

  27. 时间 更新事务T1 数据库中A值 更新事务T2 t0 100 t1 FIND A t2 FIND A t3 A:=A-30 ① t4 A:=A*2 t5 UPD A ② t6 70 UPD A ③ t7 200 图7.5 在时间t7丢失了事务T1的更新 7.3.1并发操作带来的三个问题(5) 解决方法：

  28. 7.3.2封锁技术(1) • 定义7.3 锁（lock）是一个与数据项相关的变量，对可能应用于该数据项上的操作而言，锁描述了该数据项的状态。 • 通常在数据库中每个数据项都有一个锁。锁的作用是使并发事务对数据库中数据项的访问能够同步。 • 封锁技术中主要有两种封锁： ●排他型封锁 ●共享型封锁。

  29. 7.3.2封锁技术(2) • 1.排他型封锁（X锁，写锁） ●X锁定义：如果事务T对某个数据R（可以是数据项、记录、数据集乃至整个数据库）实现了X锁，那么在T对数据R解除封锁之前，不允许其他事务T再对该数据加任何类型的锁。这种锁称为“X锁”。 ●X锁的操作有两个：封锁操作 “XFIND R” 解锁操作 “XRELEASE R” ●X锁的解除操作应该合并到事务的结束（COMMIT或ROLLBACK）操作中。

  30. 7.3.2封锁技术(3) 例7.6 使用X锁技术，可以解决图7.5的丢失更新问题。 图7.9 等事务T1更新完成后再执行事务T2

  31. 7.3.2封锁技术(4) • 2．共享型封锁（S锁，读锁） ●定义7.5 如果事务T对某数据加上S锁后，仍允许其他事务再对该数据加S锁，但在对该数据的所有S锁都解除之前决不允许任何事务对该数据加X锁。 ●S锁的操作有三个：封锁操作 “SFIND R” 升级和写操作 “UPDX R” 解锁操作 “SRELEASE R” ●可以看出，获准S锁的事务只能读数据，不能更新数据，若要更新，则先要把S锁升级为X锁。 ●另外，由于S锁只允许读数据，因此解除S锁的操作不必非要合并到事务的结束操作中去，可以随时根据需要解除S锁。

  32. 7.3.2封锁技术(5) 例7.7使用S锁技术,也可以解决图7.5的丢失更新问题。 图7.10更新未丢失,但在时间t6发生了死锁

  33. T2 T1 7.3.2封锁技术(6) • 3．封锁的相容矩阵 注： ① N=NO，不相容的请求 Y=YES，相容的请求 ②X、S、－： 分别表示X锁，S锁，无锁 ③ 如果两个封锁是不相容 的，则后提出封锁的事务 要等待。

  34. 7.3.2封锁技术(7) • 4．封锁的粒度 • 定义7.6封锁对象的大小称为封锁的粒度 （granularity）。 • 封锁的对象 • 逻辑单元:属性值、属性值集合、元组、关系、 索引项、整个索引、整个数据库 • 物理单元:页（数据页或索引页）、块 • 封锁粒度与系统并发度和并发控制开销密切相关。粒度越大，系统中能被封锁的对象就越少，并发度就越小，但同时系统的开销也就越小； 相反，粒度越小，并发度越高，系统开销越大。

  35. 7.3.2封锁技术(8) • 5．封锁协议：三级封锁协议，分别在不同程度上解决了并发操作带来的各种问题，为并发操作的正确调度提供一定的保证。

  36. 7.3.3封锁带来的问题(1) • 1．“活锁”问题 • 定义7.7系统可能使某个事务永远处于等待状态，得不到封锁的机会，这种现象称为“活锁”（Live Lock）。 • 解决活锁问题的一种简单的方法是采用“先来先服务”的策略，也就是简单的排队方式。 • 如果运行时，事务有优先级，那么很可能使优先级低的事务，既使排队也很难轮上封锁的机会。此时可采用“升级”方法来解决，也就是当一个事务等待若干时间（譬如5分钟）还轮不上封锁时，可以提高其优先级别，这样总能轮上封锁。 ……

  37. 7.3.3封锁带来的问题(2) • 2．“饿死”问题 • 定义7.8 有可能存在一个事务序列，其中每个事务都申请对某数据项加S锁，且每个事务在授权加锁后一小段时内释放封锁，此时若另有一个事务T2欲在该数据项上加X锁，则将永远轮不上封锁的机会。这种现象称为“饿死”（starvation）。 • 可以用下列方式授权加锁来避免事务饿死。 当事务T2中请对数据项Q加S锁时，授权加锁的条件是： ① 不存在在数据项Q上持有X锁的其他事务； ② 不存在等待对数据项Q加锁且先于T2申请加锁的事务。 ……

  38. 7.3.3封锁带来的问题(3) • 3. “死锁”问题 • 定义7.9 系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称系统进入了“死锁”（Dead Lock）状态。 图7.12 在时间t4 两个事务发生死锁 ……

  39. 数据B T1 T2 数据A T2 T4 T1 T3 T2 T4 T1 T3 7.3.3封锁带来的问题(4) • 我们可以用事务依赖图的形式测试系统中是否存在死锁。图中每一个结点是“事务”，箭头表示事务间的依赖关系。 • 图7.14为无环依赖图，表示系统未进入死锁状态； • 而图7.15为有环依赖图，则表示系统进入死锁状态。

  40. 7.3.3封锁带来的问题(5) • DBMS中有一个死锁测试程序，每隔一段时间检查并发的事务之间是否发生死锁。 • 如果发生死锁，那么只能抽取某个事务作为牺牲品，把它撤消，做回退操作，解除它的所有封锁，恢复到该事务的初始状态。释放出来的资源就可以分配给其他事务，使其他事务有可能继续运行下去，就有可能消除死锁现象。 • 理论上，系统进入死锁状态时可能会有许多事务在相互等待，但是System R的实验表明，实际上绝大部分的死锁只涉及到两个事务，也就是事务依赖图中的循环里只有两个事务。有时，死锁也被形象地称作“死死拥抱”（Deadly Embrace）。

  41. 7.3.4 并发操作的调度 • 事务的调度：事务的执行次序称为“调度” 。 • 串行调度：如果多个事务依次执行，则称为事务的串行调度（Serial Schedule）。 • 并发调度:如果利用分时的方法，同时处理多个事务，则称为事务的并发调度（Concurrent Schedule）。 • 可串行化 ：如果一个并发调度的执行结果与某一串行调度的执行结果等价，那么这个并发调度称为“可串行化的调度”，否则是“不可串行化的调度” 。

  42. 7.3.5 SQL对并发处理的支持(1) • 1．事务的存取模式 READ ONLY（只读型）：事务对数据库的操作只能是读操作。 READ WRITE（读写型）：事务对数据库的操作可以是读操作，也可以是写操作。 • 这两种模式可用下列SQL语句定义： SET TRANSACTION READ ONLY SET TRANSACTION READ WRITE

  43. 7.3.5 SQL对并发处理的支持(2) • 2．事务的隔离级别 • SERIALIZABLE（可串行化）：允许事务并发执行，但须保证 并发调度可串行化，是默认级别。 • REPEATABLE READ（可重复读）：只许事务读已提交的数据， 且两次读之间不许其他事务修改此数据。 • READ COMMITTED（读提交数据）：允许事务读已提交的数 据，但不要求“可重复读”。 • READ UNCOMMITTED（可以读未提交数据）：允许事务读已 提交或未提交的数据。 • 上述四种级别可以用下列SQL语句定义： SET TRANSACTION ISOLATION LEVEL SERIALIZABLE SET TRANSACTION ISOLATION LEVEL REPEATABLE READ SET TRANSACTION ISOLATION LEVEL READ COMMITTED SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

  44. 7.3.6基于时标的并发控制(1) • 这种技术不是采用封锁的方法，因而是不会产生死锁的调度。 • 在事务Ti运行时，有唯一的时间标志，称为时标或时戳，用TS(Ti)表示。 • 时标可用下列两种方法之一实现： （1）事务开始运行时的系统时间（称为启动时间）作为事务的时标。 （2）每个事务与一个逻辑编号相联系。譬如逻辑编号可以是运行事务的顺序号。 • 如果两个事务Ti和Tj的时标分别为TS(Ti)和TS(Tj)，并且有TS(Ti) < TS(Tj)，那么称Ti是年长的事务，Tj是年轻的事务。

  45. 7.3.6基于时标的并发控制(2) • （1）在事务Ti执行read(Q)时 ① 如果TS(Ti)<W_timestamp(Q)，那么Ti应该读已经被改写的Q值。这样，应拒绝Ti的read(Q)操作，并重新启动Ti。 ② 如果TS(Ti)≥W_timestamp(Q)，那么执行read(Q)，并且置R_timestamp(Q)的值为R_timestamp(Q)和TS(Ti)中的大者。 • （2）在事务Ti执行write(Q)时 ① 如果TS(Ti)<R_timestamp(Q)，那么Ti产生的Q值应在以前的时间内写入，这已不可能。因而，应拒绝Ti的write(Q)操作，并重新启动Ti。 ② 如果TS(Ti)<W_timestamp(Q)，那么Ti企图写过时的Q值。这时，也应拒绝Ti的write(Q)操作，并重新启动Ti。 ③ 否则，执行write(Q)，并置W_timestamp(Q)的值为TS(Ti)。

  46. 7.3.6基于时标的并发控制(3) 图7.16 在t6时刻，事务T2写操作失败，将重新启动

  47. 7.3.6基于时标的并发控制(4) 图7.17 在t5时刻，事务T1写操作失败，将重新启动

  48. 7.3.6基于时标的并发控制(5) 时标顺序协议的特点： ①由于冲突操作是按时标顺序处理的，因此时标顺序协议能保证调度是可串行化的。 ②由于没有事务处于等待状态，因此并发调度时不会发生死锁。 ③时标顺序协议能做到使调度无级联回退调度。

  49. 7.4 数据库的完整性 • 7.4 数据库的完整性 • 7.4.1 完整性子系统和完整性规则 • 7.4.2 SQL中的完整性约束 • 7.4.3 SQL3中的触发器

  50. 7.4.1 完整性子系统 • 定义7.12 数据库中完整性(Integrity)一词是指数据的正确性(Correctness)、有效性(Validity)和相容性(Consistency)，防止错误的数据进入数据库。 • DBMS必须保证数据库中数据是正确的。 • 检查数据库中数据是否满足规定的条件称为“完整性检查”。数据库中数据应该满足的条件称为“完整性约束条件”，有时也称为完整性规则。 • 完整性子系统的主要功能： • 监督事务的执行，并测试是否违反完整性规则； • 若有违反现象，则采取恰当的操作，譬如拒绝操作、报告违反情况、改正错误等方法来处理。

More Related