数据库备份语句【数据库备份语句oracle】 收藏 0

超详细的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的事务存在着)

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

SQL Server 大数据搬迁之文件组备份还原实战

一.背景（Contexts）

有一个数据库大概在700G左右，需要从服务器A搬迁到服务器B，两台服务器网络传输速度可以达到8MB/s，怎么做才能更快的搬迁并且宕机时间最短呢？

数据库业务逻辑概述：这个数据库只会插入数据，每天大概有300W条数据，不会对数据进行修改，只有一个表比较大，并且这个表是以自增ID作为分区依据列的，文件组会被重用，数据库为简单恢复模式，我定时会对表数据进行交换分区删除数据；

二.解决方案（Solution）

之前我也写过关于搬迁数据库的一些文章：

1. SQL Server 数据库最小宕机迁移方案，这篇文章是通过完全备份+差异备份的方式迁移数据库的，这种方式比较合适数据库只有20G左右的数据库，宕机时间=差异备份时 间+传输差异备份时间+还原差异备份时间，一般来说这个时间都比较短，因为差异备份都不会太大；

2. SQL Server 数据库迁移偏方，这篇文章是通过作业的方式迁移数据库的，一个事务中转移N条（大约2W条）数据，N值可以通过测试进行调整（需要看网络情况而定），这种 方式比较适合数据库比较大，比如几百G的数据库，而且网络环境比较差的情况下，宕机时间≈0（当转移最后一部分数据足够小），缺点就是迁移的时间会比较 长；

3. 那么这篇文章我们再来讲讲其它方式的迁移，在上面提到的背景下，可以通过对分区文件组进行备份的方式迁移数据库，这种方式比较适合大数据库的迁移，宕机时 间=最后一个文件组备份时间+传输备份时间+还原最后一个文件组时间，缺点是宕机时间会比较大，但是整体迁移的时间会比较小；下面是逻辑结构图：

F1_文件组搬迁逻辑图

三.搬迁步骤（Procedure）

在讲述搬迁步骤之前，我们首先来看看文件组的大体情况，通过下面的SQL语句可以查看文件组的相关信息，见Figure2、Figure3；

（Figure2：文件组列表）

（Figure3：文件组列表）

下面就讲讲搬迁的步骤：

1. 首先我们先清理下数据，把不必要的数据通过交换分区的方式交换出去；

2. 查看这张大表当前的自增ID值，通过修改分区方案让新插入的数据存入到一个空的文件组（因为空的文件组在最后备份会更小一点），很多情况下，文件组是会重用的，所以要注意这个文件组是空的；

3. 设置数据库为完整恢复模式；

4. 备份除了上面提到的文件组，如果条件允许可以进行备份的压缩；（动态生成SQL）

5. 通过FTP传输备份文件到新的服务器；

6. 备份主分区，需要确保这个时候不会对主分区的数据进行修改，并传输主分区备份文件；

7. 先还原主分区的备份，再还原上面的文件组备份；（动态生成SQL）

8. 对最后一个文件组进行备份，对日志进行备份，对没有做分区对齐的索引文件组进行备份，把这3个备份传输到新服务器；

9. 还原文件组，还原日志；

四.搬迁脚本（SQL Codes）

搬迁脚本包括两个部分，一个备份使用的脚本，一个是还原使用的脚本：

1. 备份脚本，根据分区情况来自动生成对应的备份脚本；

2. 还原脚本，根据分区情况和备份文件的规则来生成对应的还原脚本，也就是说还原脚本是依据备份脚本的；

(一) 下面是用于生成备份SQL的代码，这个代码需要提供两个变量值：

1. @DataBaseName指定需要进行备份的数据库名，值为\’Barefoot.Archives\’；

2. @BackupPath在旧服务器本地备份文件组存放的地址，值为：\’E:\\DBBackup\\\’；

在旧数据库Barefoot.Archives中执行下面的SQL脚本：

上面SQL脚本的逻辑是：

1. 首先设置数据库的恢复模式为完整恢复模式，这是为了后面对数据库的日志进行备份；

2. 通过当前数据库的系统表sys.filegroups拿到文件组的名称，这里把默认文件排在最后面，这是因为有可能会对配置表进行的操作，所以把这个文件组放到最后备份；

3. 使用游标的方式来循环文件组，生成文件组对应的备份SQL语句；

4. 最后备份数据库的日志，对文件组的还原是需要通过日志备份才能还原的；

在旧数据库执行上面的SQL脚本，将会产生生成下面的SQL（只保留了部分SQL）：

执行完上面的脚本，会生成下图所示的备份文件：

F4_备份文件列表

(二) 下面是用于生成还原SQL的代码，这个代码需要提供几个变量值：

1. @DataBaseName指定需要进行备份的数据库名，值为\’Barefoot.Archives\’；

2. @BackupPath在新服务器文件组备份的地址，值为：\’E:\\DBBackup\\\’；

3. @SavePath_Drive存在数据文件的盘符，值为：\’F:\\\’；

4. @SavePath_FolderName存放数据文件的文件夹，值为：\’DataBase\\\’；

5. @SavePath_SubFolderName存放ndf文件的文件夹，值为：\’FG_Archive\\\’；

6. @IsSamePath表示是否延续之前的physical_name值，值为1表示延续，这样会使用@SavePath_Drive替换 physical_name的盘符，这样@SavePath_FolderName和@SavePath_SubFolderName就不会起作用了，值 为0表示不延续，这样physical_name的 值=@SavePath_Drive+@SavePath_FolderName+@SavePath_SubFolderName；

在旧数据库Barefoot.Archives中执行下面的SQL脚本：

上面SQL脚本的逻辑是：

1. 通过系统表sys.filegroups找到默认文件组，先还原这个主文件；

2. 使用游标的方式来循环系统表sys.filegroups，拿到文件组名称，生成文件组对应的还原SQL语句；

3. 接着还原数据库的日志；

4. 最后还原在线，让数据库在线；

执行上面的SQL脚本，将会产生生成下面的SQL（只保留了部分SQL）：

在新服务器上执行上面的SQL脚本还原数据库，需要注意的是：在还原在线之前数据库都是一直处于：正在还原的状态的；

五.注意事项（Attention）

1. 在实际运用中，可以结合本文和SQL Server 数据库迁移偏方进行灵活结合运用，当通过本文件组备份后，旧库继续进数据，在花销时间最大的网络传输过程和还原过程继续对老库进数据，这样当还原好数据库之后使用SQL Server 数据库迁移偏方来转移最新的数据，这样宕机的时间会趋向于0；

2. 其实为了确保某些文件组不被修改，可以设置文件组的只读属性，这样可以确保只有某个文件组在进新数据，可惜的是设置了只读也无法拷贝这些文件组文件通过FTP传输，提示：操作无法完成，因为文件已在SQL Server（MSSQLSERVER）中打开。

3. 上面脚本的每个文件组中只包含了一个文件，如果一个文件组包含多个文件，那就需要修改下脚本了；

4. 高文佳曾经说过，可以先删除索引，再压缩备份，还原之后再创建索引，是的，这不防是一个好方法，不过需要考虑两点，一个是在还原之后创建索引的速度与时 间，如果磁盘速度不算快，那你就要考虑删除索引是否适合了；另外一点是你的数据库是否能停机让你删除索引，这个跟具体的业务有关；

六.疑问（Questions）

1. 对primary进行完整文件组备份（作为基备份），对FG1进行完整文件组备份（作为基备份）这些描述有问题吧？对primary进行完整文件组备份应该不会生成基线的吧？ SQL文件组备份和还原

2. 如果在同一个文件组中有两个以上的分区值，就是把两个段的分区方案中同指向同一个分区文件组，那在备份和还原有什么需要注意的呢？能成功备份还原嘛？

解答：从备份和还原的代码可以看出只是把FILEGROUP与bak对应，与ndf文件对应，所以是不需要理会这个文件组中包含了多少个逻辑分区；

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