系统架构师:数据库的故障与恢复

数据库的故障可用事务的故障来表示,主要分为四类:

  • 事务故障。事务在运行过程中由于种种原因,如输入数据的错误、运算溢出、违反了某些完整性限制、某些应用程序的错误,以及并发事务发生死锁等,使事务未运行至正常终止点就被撤销,这种情况称为“事务故障”。
  • 系统故障。系统故障是指系统在运行过程中,由于某种原因(如操作系统或数据库管理系统代码错误、操作员操作失误、特定类型的硬件错误(如 CPU 故障)、突然停电等造成系统停止运行),致使事务在执行过程中以非正常方式终止,这时内存中的信息丢失,但存储在外存储设备上的数据不会受影响。
  • 介质故障。系统在运行过程中,由于某种硬件故障,如磁盘损坏、磁头碰撞或由于操作系统的某种潜在的错误、瞬时强磁场干扰,使存储在外存上的数据部分损失或全部损失,称为“介质故障”。这类故障比前两类故障的可能性虽然小得多,但破坏性却最大。
  • 计算机病毒。计算机病毒是一种人为破坏计算机正常工作的特殊程序。通过读写染有病毒的计算机系统中的程序与数据,这些病毒可以迅速繁殖和传播,危害计算机系统和数据库。目前大多数病毒是在 PC 和其兼容机上传播的。有的病毒一侵入系统就马上摧毁系统,有的病毒有较长的潜伏期,有的病毒则只在特定的日期发生破坏作用,有的病毒感染系统所有的程序和数据,有的只影响特定的程序和数据。在数据库系统中,恢复的基本含义就是恢复数据库本身。也就是说,在发生某种故障使数据库当前的状态已经不再正确时,把数据库恢复到已知为正确的某一状态。目前数据库系统中最常用的恢复方法是转储和登记日志文件,可根据故障的不同类型,采用不同的恢复策略。

事务故障的恢复。事务故障是指事务未运行至正常终止点前被撤销,这时恢复的系统应对此事务做撤销处理。事务故障的恢复是由系统自动完成的,不需要用户干预,步骤如下:

  1. 反向扫描文件日志,查找该事务的更新操作。
  2. 对该事务的更新操作执行逆操作。
  3. 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
  4. 如此处理下去,直至读到此事务的开始标记,事务故障恢复完成。

系统故障的恢复。系统故障发生时,造成数据库不一致状态的原因有两个:一是由于一些未完成事务对数据库的更新已写入数据库;二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。系统故障的恢复是在重新启动时自动完成的,不需要用户干预,步骤如下:

  1. 正向扫描日志文件,找出在故障发生前已经提交的事务,将其事务标识记入重做(Redo)队列。同时找出故障发生时尚未完成的事务,将其事务标识记入撤销(Undo)队列。
  2. 对撤销队列中的各个事务进行撤销处理:反向扫描日志文件,对每个 Undo 事务的更新操作执行逆操作。对重做队列中的各个事务进行重做处理:正向扫描日志文件,对每个 Redo 事务重新执行日志文件登记的操作。
  3. 介质故障与病毒破坏的恢复。在发生介质故障和遭病毒破坏时,磁盘上的物理数据库被破坏,这时的恢复操作可分为三步:
    1. 装入最新的数据库后备副本,使数据库恢复到最近一次转储时的一致性状态。
    2. 从故障点开始反向读日志文件,找出已提交事务标识将其记入重做队列。
    3. 从起始点开始正向阅读日志文件,根据重做队列中的记录,重做所有已完成事务,将数据库恢复至故障前某一时刻的一致状态。

具有检查点的恢复技术。检查点记录的内容可包括:

建立检查点时刻所有正在执行的事务清单。

这些事务最近一个日志记录的地址。采用检查点的恢复步骤如下:

  1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录。
  2. 由该检查点记录得到检查点建立时所有正在执行的事务清单队列A。建立重做队列R和撤销队列U,把 A 队列放入 U 队列中,R 队列为空。
  3. 从检查点开始正向扫描日志文件,若有新开始的事务 T1,则把 T1 放入 U 队列,若有提交的事务 T2,则把T2从U队列移到R队列,直至日志文件结束。
  4. 对 U 队列的每个事务执行 Undo 操作,对 R 队列的每个事务执行 Redo 操作。

DBA 要做的基本操作是:

  1. 重装最近转储的后援副本。
  2. 运行日志文件,执行系统提供的恢复命令。

数据库安全和恢复是数据库系统正常运行的保证。大型数据库管理系统一般都提供了实现安全机制的保证,即由系统提供了相应的功能,但小型的数据库管理系统并非都具有相应功能,因此有时需要人工的辅助措施,用以保证数据库的安全和恢复。

SQL还原数据库备份方法

我们以SQL2012版本为例子讲解还原数据库备份文件的方法。

1、首先我们在电脑操作系统程序目录中找到企业管理器SQL Server Management Studio 如图1

图1

2、鼠标点击SQL Server Management Studio 进入企业管理器界面,默认对象实例服务器名称以.或者127.0.0.1,身份验证以Windows 身份验证登录-图2(windows身份验证不用输入sa密码,用sql server 身份验证需输入sa密码)

图2

3.在对象资源管理器中找到数据库文件夹。如图3

图3

4.鼠标右键点击数据库文件夹,弹出菜单列表选项,点击选择还原数据库。如图4

图4

5.弹出还原数据库集窗口,如图5。在源选框中,我们点击选择设备。如图6

图5

图6

6.在源选框设备地址栏中,我们点击地址栏右边三个…的按钮。图7

图7

7.弹出的选择备份设备窗口,我们点击增加按钮。如图8

图8

8.弹出的定位备份文件窗口中,我们可以看到左边是备份文件的位置选择,中间空白区域是每个文件夹下显示的内容明细,右下角是备份文件类型。图9

图9

10.我们从备份文件位置中,找到我们数据库备份文件存放的磁盘路径和所在的文件夹。在E盘数据库备份文件夹中找到数据库备份文件hbposv10_20200831.bak。如图10

图10

注意:选择数据库备份文件这个地方系统默认备份文件类型是.bak,trn后缀名的文件,有些数据库备份是.dat或者是无后缀名的,那么数据库文件要找到还原,请在文件类型下拉框中点击所有文件,窗口就显示所有文件类型明细出来了。图10-1

图10-1

11.在内容明细区域中选择数据库备份文件hbposv10_20200831.bak,图11,点击确定进行添加到还原设备介质窗口列表中,然后点击确定。图12

图11

图12

12、点击如下图13还原数据库备份集文件,目标数据库默认名为hbposv10,这个数据库名称可以修改成你们想要的如hbposv10_1。

图13

13.我们在还原数据库集界面中点击确定后,开始还原数据库,等待还原成功.如下图14

图14

14.数据库还原成功之后,我们点击确定回到对象资源管理器中,刷新数据库可以看到有还原的数据库名hbposv10. 图15

图15

以上就是通过SQL2012企业管理器SQL Server Management Studio 进行数据库还原操作的方法,你们学会了么。

另外下面提供通过SQL语句进行数据库还原的执行操作

SQL还原数据库备份语句:restore database 数据库 from disk=\’c:你的备份文件名\’

在SQL查询分析器中按照SQL语句格式操作,还原如上案例:

restore database hbposv10 from disk=\’E:\\数据库备份\\hbposv10_20200831.bak\’

超详细的pg12.2数据库五种备份恢复机制总结,值得收藏

备份重于一切,今天主要介绍PG的五种备份方式,仅供参考。

ps:前四种重点掌握

1、语法

可以在本地及远程进行备份,只需要表的读权限即可备份。pg_dump创建的备份是一致的,在pg_dump运行时数据库产生快照,不阻塞数据库的DML操作,但是会阻塞需要排他锁的操作,如alter table等。特别注意的是,pg_dump一次只能备份一个单独的数据库,且不能备份角色和表空间信息(因为这些信息是cluster-wide,而不是在某个数据库中(per-database))。

使用pg_dump的自定义转储格式。. 如果PostgreSQL所在的系统上安装了zlib压缩库,自定义转储格式将在写出数据到输出文件时对其压缩。这将产生和使用gzip时差不多大小的转储文件,但是这种方式的一个优势是其中的表可以被有选择地恢复。

下面的命令使用自定义转储格式来转储一个数据库:pg_dump -Fc dbname > filename自定义格式的转储不是psql的脚本,只能通过pg_restore恢复,例如:pg_restore -d dbname filename

2、常见用法

pg_dump只备份数据库集群中的某个数据库的数据,它不会导出角色和表空间相关的信息。pg_dumpall则可以导出整个数据库集群中所有的数据库中的数据,同时也会导出角色、用户和表空间的定义信息。

执行pg_dumpall需要超级用户权限。

1、语法

2、常用用法

COPY在PostgreSQL表和文件之间交换数据。 COPY TO把一个表的所有内容都拷贝到一个文件,而COPY FROM从一个文件里拷贝数据到一个表里(把数据附加到表中已经存在的内容里)。 COPY TO还能拷贝SELECT查询的结果。

如果声明了一个字段列表,COPY将只在文件和表之间拷贝已声明字段的数据。 如果表中有任何不在字段列表里的字段,那么COPY FROM将为那些字段插入缺省值。

带文件名的COPY指示PostgreSQL服务器直接从文件中读写数据。 如果声明了文件名,那么服务器必须可以访问该文件,而且文件名必须从服务器的角度声明。 如果使用了PROGRAM选项,则服务器会从指定的这个程序进行输入或是写入该程序作为输出。 如果使用了STDIN 或STDOUT选项,那么数据将通过客户端和服务器之间的连接来传输。

注意:copy命令必须在plsql命令行执行,执行用户必须为superuser,普通用户进行执行,需要在copy前面加入 “\\”,即 \\copy。

COPY只能用于表,不能用于视图,不过可以用于COPY (SELECT * FROM viewname) TO …

1、语法

copy to的导出速度非常之快,经测试10W的数据量只需要3秒左右的时间。

COPY FROM能够识别下列特殊反斜杠字符:

2、常见用法

1、基础备份

2、恢复

PostgreSQL有一个导出和导入事务快照的功能,这个功能在9.2版本开始支持,允许事务共享它当时的snapshot给其他的事务使用。SET TRANSACTION SNAPSHOT命令允许新的事务使用与一个现有事务相同的快照运行。已经存 在的事务必须已经把它的快照用pg_export_snapshot函数导出。该函数会返回一个快照标识符,SET TRANSACTION SNAPSHOT需要被给定一个快照标识符来指定要导入的快照。需要注意的是:只有事务是SERIALIZABLE以及 repeatable read时,DEFERRABLE 事务属性才会有效。

PostGreSQL采用“快照”方式来实现MVCC。具体地说,这意味着每一个事务中的查询仅能看到:

1)该事务启动之前已经提交的事务所作出的数据更改。

2)当前事务中该查询之前的查询所作出的更改。

下面基于事务隔离级别repeatable read进行测试

1、建表

2、session1:

3、session2(插入一条新数据并提交):

4、session3(能查看到会话2插入的数据):

5、session4 (导入s1的第一个snapshot, 因此看不到s2提交的数据) :

6、session5 (导入s1的第二个snapshot, 因此看不到s2提交的数据, 同时验证了看不到s1修改过的数据):

7、session1(提交):

8、session4 (s1提交后, 这个snapshot还存在, 只要还有导入了这个snapshot的事务存在着) :

9、session5 (s1提交后, 这个snapshot还存在, 只要还有导入了这个snapshot的事务存在着)

篇幅有限,基于时间点恢复的内容后面单独介绍吧,感兴趣的朋友可以关注下!

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com

点赞 0
收藏 0

文章为作者独立观点不代本网立场,未经允许不得转载。