如何申请一个网站 做视频直播,网站制作需要多少钱k,google秒收录方法,wordpress怎么让文章只显示摘要一.事务
1.1事务的概念【重要】
事务#xff1a;“将一组数据库操作打包起来形成一个逻辑独立的单元#xff0c;这个工作单元不可分割#xff0c;其中包含的数据要么全部都发生#xff0c;要么全部都不发生”。
在SQL中#xff0c;界定事务的语句有三条#xff1a;
B…一.事务
1.1事务的概念【重要】
事务“将一组数据库操作打包起来形成一个逻辑独立的单元这个工作单元不可分割其中包含的数据要么全部都发生要么全部都不发生”。
在SQL中界定事务的语句有三条
BEGIN TRANSCATION //开始一个事务事务开始标记COMMIT //提交当前事务成功结束标记ROLLBACK //撤销(回滚)当前事务失败结束标记
1.2事务的特性【重要】
一个逻辑独立的工作单元要成为事务必须满足4个特性“原子性”、“一致性”、“隔离性”、“持久性”简称“ACID特性”。
1.2.1原子性(Atomicity)
原子性指事务的不可分割性组成事务的所有操作要么全部被执行要么全部不执行。
1.2.2一致性(Consistency)
一致性是指在事务执行之前和执行之后数据库都必须处于一致性状态即事务的执行使得数据库从一个一致性状态转变到另一个一致性状态。
通俗来说就是使数据库满足完整性约束。
例如“银行的一个账户存款与取款之差应该等于余额如果存款或者取款时不修改余额就会造成数据库处于不一致状态”。
1.2.3隔离性(Isolation)
隔离性是指多个事务并发执行时必须相互独立不能相互干扰。
并发执行的事务不必关心其它事务执行如何。
1.2.4持久性(Durability)
持久性也称持续性是指已经提交的事务对数据库的改变应该是永久的、持续存在的、即便以后系统发生故障事务的这种影响也不应该丢失。
二.数据库恢复
数据库恢复是指“把数据库从一个错误状态恢复到某一已知的正确状态(即一致状态或完整状态)”
DBMS的恢复机制根据数据库错误类型有两种处理方法
未完成事务撤销未完成事务对数据库的一切影响保证事务的原子性。已提交事务恢复事务对数据库的更新影响保证事务的持久性。
2.1数据库系统的故障
数据库系统中可能发生的故障大致有四类“事物内部故障”、“系统故障”、“介质故障”、“计算机病毒”。
2.1.1事务内部故障
事物内部故障指在事务内部操作执行过程中可能发生的故障可以分为“预期故障”、“非预期故障”。
预期故障即在程序中程序员应该预先估计到并加以处理的错误。非预期故障即在程序运行中发生的无法预估并能预处理的错误。
2.1.2系统故障
系统故障又称软故障指造成系统停止运转并要求系统重新启动的事件。
造成系统故障的原因可能有“CPU故障”、“操作系统故障”、“突然断电”等。
2.1.3介质故障
介质故障又称硬故障指在数据库系统运行过程中因“磁盘损坏”、“磁头碰撞”、“强磁场干扰”等导致数据库的数据库部分或全部丢失的一类故障(外力因素/物理层次)。
2.1.4计算机病毒
计算机病毒指一组能够自我复制传播的计算机指令或者程序代码能够破坏计算机功能或破坏数据影响计算机包括数据库系统的使用。
2.2数据库恢复的实现技术
数据库恢复的基本原理是建立“冗余”即在数据库正常运行时重复存储一些数据和信息保证有足够的信息用于故障恢复。
通常数据库系统中利用“数据转储”和“日志文件”两种方法来建立冗余数据。
2.2.1通过数据转储建立冗余
数据转储就是由DBA(数据库管理员)定期地将整个数据库复制到磁盘或另一个磁盘上面的过程转储的数据库叫作“数据库副本”或“后备副本”、“后援副本”。
当数据库发生故障时就可以将最近的后备副本或重新装入把数据库恢复起来。
显然此时数据库只能恢复到最近转储时的状态。 转储按照存储状态可以分为“静态转储”、“动态转储”。
静态转储静态转储是在系统中没有事务运行的时候进行的转储操作缺点是效率低。动态转储动态转储允许对数据库进行存取或更新即存储和用户事务可以并发执行缺点是没办法保证副本和数据库的一致性。
转储按照存储方式可以分为“海量转储”、“增量转储”。
海量转储转出全部数据库内容增量转储只转储更新过的数据 数据的“增量转储”和“海量转储”也可以分别在“动态”和“静态”两种状态下进行因此数据转储的方法可以分为4类“动态海量转储”、“动态增量转储”、“静态海量转储”、“静态增量转储”。
2.2.2通过日志文件建立冗余
日志文件是用来记录事务对数据库所做的每一次更新活动的文件。
每一次更新活动的内容作为一条日志记录写入日志文件也成为登记日志。
一条日志记录的主要内容包括“事务标识”、“操作类型”、“对象标识”、“前像”、“后像”。 事务标识唯一地标识执行更新操作的事务。操作类型“start”、“commit”、“rollback”、“update”、“insert”、“delete”。对象标识唯一地标识更新操作所针对的数据对象。前像数据对象在更新操作执行之前的旧值后像数据对象在更新操作执行之后的新值 事务执行过程中如果发生如下事件或者操作就在日志文件中写一个日志记录。
事务T开始日志记录为(T,start,,,)事务T修改对象A日志记录为(T,update,A,前像,后像)事务T插入对象A日志记录为(T,insert,A,,后像)事务T删除对象A日志记录为(T,delete,A,前像,)事务T提交日志记录(T,commit,,,)事务T回滚日志记录(T,rollback,,,)
登记日志时必须遵循如下两条原则
登记的次序必须严格按照并发事务执行的时间次序。必须先写日志文件然后写数据库并且日志文件不能和数据库放在同一物理磁盘上。
2.3故障恢复
不同的故障需要采用不同的策略恢复
2.3.1事务内部故障的恢复
事务内部故障必定发生在当前事务提交之前这时应撤销(UNDO)事务对数据库的一切更新影响。
故障恢复由DBMS自动完成步骤如下
反向扫描日志文件查找该事务的更新操作。若查到是更新操作则将日志文件“前像”写入数据库若是插入操作则将数据对象删去若是删除操作则做插入操作插入数据对象的值为日志记录中的“前像”。继续反向扫描日志文件找出其他的更新操作并做同样的处理直至找到该事务的start标记为止。
2.3.2系统故障的恢复
系统故障会使主存中的数据丢失此时已提交事务对数据库的更新可能还驻留在内存工作区而未写入数据库为保证已提交事务的更新不会丢失需要重做(REDO)已提交事务
此外对未提交的事务还必须撤销所有对数据库的更新。
系统故障恢复由DBMS自动完成步骤如下
从头扫描日志文件找出在故障发生前已提交的事务(即有satrt记录和commit记录的事务)将其计入重做(REDO)队列。同时找出尚未完成的事务(即只有start记录而没有commit或rollback的记录)将其计入(UNDO)队列。对REDO队列中每个事务进行REDO操作即正向扫描日志文件根据登入日志文件中日志记录次序重新执行登记操作。对UNDO队列中咩个食无进行UNDO操作即反向扫描日志文件根据登入日志文件中相反次序对每个更新操作执行你操作。
2.3.3介质故障的恢复
发生介质故障后磁盘以及磁盘上的数据均可能被破坏。
这时恢复的方法是“重装数据库”重做已经完成的事务具体措施如下
必要时更换磁盘修复系统重新启动系统。装入最近的数据库后备副本使数据库恢复到最近一次转储时的可用状态。装入日志文件副本根据日志文件重做最近一次转储之后提交的所有事务。
2.3.4检查点技术
如果日志文件很大(几GB)那么系统在执行恢复操作时要遍历一个庞大的日志文件容易造成系统宕机因此引入“检查点技术”可减少系统故障恢复时扫描日志记录的数目。
检查点是数据库的一个内部事件在系统运行过程中DBMS按一定时间间隔在日志文件中设置一个检查点。
设置检查点需要执行以下操作
暂停事务的执行在日志文件中写一条检查点开始记录。将上一个检查点之后已提交的事务留在内存工作区所有更新的数据写入数据库(即磁盘上)在日志文件中写入一个检查点结束记录。
