数据库讲解---(数据库保护)【上】

本文主要是介绍数据库讲解---(数据库保护)【上】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一.事务

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操作，即反向扫描日志文件，根据登入日志文件中相反次序，对每个更新操作执行你操作。