SQL Server如何提高数据库还原的速度

影响数据库还原速度的因素和影响数据库备份速度的因素相同。除此之外，假如你使用SQL Server 2005的话，你还可以启动另外一个优化任务来还原当前不存在的数据库，运行环境为Windows XP，Windows 2003 Server 或更新版本。

Perform Volume Maintenance Tasks

当你还原一个新的完整数据库是，SQL Server读备份文件头，然后创建原始数据库中数据和日志文件需要的磁盘空间。假如SQL Server服务启动帐户没有“Perform Volume Maintenance Tasks”权限的话，数据和日志文件就需要被初始化为0，也就是说，SQL Server先创建这些文件，然后用0来填充它们。对于一个大数据库来说，这将花费很多时间。我记得使用SQL Server 2000从磁带上还原一个320GB的数据库时，总是奇怪为什么总是有30分钟的时间，还原进程一点称进展都没有。

然后，假如SQL Server服务启动帐户有“Perform Volume Maintenance Tasks”权限的话，它就会根据大小来创建数据文件，跳过“填充0”这个阶段。

下图使用secpolmsc来显示权限

你可以设想一下它会节省你多少还原大型数据库的时间。注意，事务日志文件仍然需要“填充0”，仅仅是数据文件可以跳过这一步。

注意：当然使用新权限时，要启动SQL Server服务来使之生效

下面是一个还原20GB数据和5GB事务日志所消耗时间的对照表

还原消耗时间

未使用”Perform Volume Maintenance Tasks” 5:05

使用“Perform Volume Maintenance Tasks” 1:01

消耗1:01时间是因为SQL Server仍然要把事务日志文件进行“填充0” *** 作，未使用”Perform Volume Maintenance Tasks”的情况下，SQL Server需要把数据文件和事务日志都进行“填充0”的 *** 作，所以还原时间显示变长了。

你可以用下面这个脚本来快速确定当前是否使用了PVMT(Perform Volume Maintenance Tasks)。

CREATE DATABASE test_InstantInit ON

PRIMARY (name = 'test_InstantInit', filename = 'k:/temp/test_InstantInitmdf', size = 1GB)

LOG ON (name = 'test_InstantInit_log', filename = 'k:/temp/test_InstantInitldf', size = 1MB)

DROP DATABASE test_InstantInit

整个脚本如果在几秒内完成就证明使用了PVMT。

这里还有一点需要说明的地方。当SQL Server跳过“填充0”阶段空间时，如果数据文件所占用的空间里面包括以前的数据，那么使用DBCC PAGE命令或是其他16进制编辑器就可以看到未被数据页占据的空间内容。这就是说，如果一个包括敏感重要内容的数据虽然已经被删除了，但是如果新数据库占用了这片空间，那么敏感数据就有可能被部分泄露出来。

注意：当PVMT处于活动状态时，那么新建数据库，新建数据文件，数据文件增长等情况都会使用它。详情请看Database File Initialization [SQL2005]

综上所述，那么我从备份文件还原一个数据库之前是否要删除这个数据库呢？

下面的表格显示了还原同一个数据不同 *** 作的效果：

还原时间

还原1GB数据库 0:40

还原2GB数据库 1:08

还原1GB数据库，当前有个同名的2GB数据库存在 0:29

还原2GB数据库，当前有个同名的1GB数据库存在 0:56

结果显示，假如你执行一个完整数据库恢复且覆盖已经存在的同名数据库，那么恢复速度会快于直接恢复(表中行1与行3，或行2与行4的对比)。这看起来好像是因为没有对已经存在的数据文件执行“填充0” *** 作而节省了时间。不过这也仅仅局限于你恢复的数据库有同名的文件。如果你使用MOVE选项来重定位数据库文件，那么无论你事先是否已经删除数据库，这都不再有什么区别了。

还原状态同样影响还原速度

另外一个影响还原速度的因素就是你所选择的还原后的数据库的状态，前提是recovery没有被选中。通常出于为以后升级做准备的需求，当你选择不完全恢复数据库时，有两个选项可以使用NORECOVERY或是STANDBY。NORECOVERY使数据库处于“恢复中”模式，允许你进行后续的升级，而且此时数据库是不可读状态。STANDBY也使数据库处于“恢复中”状态，允许你进行后续升级，但是此时数据库可读。

当你使用STANDBY选项时，你要为回滚文件提供一个名字。这个文件包括从未提示的事务中回滚 *** 作结果。你的未提交事务越多，这个文件越大，那么随后还原时间越长。

下面的例子中有4个事务日志，每个大约131MB左右。除了第三个事务日志外，所有的备份都仅包括提交的事务，第三个事务日志包括32MB未提交事务，结果如下图：

使用NORECOVERY选项还原事务日志：

使用STANDBY选项还原事务日志：

总体来说，与NORECOVERY相比使用STANDBY还原事务日志会慢一些。因为当有未提交的事务时，SQL Server会花费额外的时间来创建回滚文件(undo file)。

还有说明的是，如果你要还原多个事务日志而且你想让数据库处于只读模式，那么你应该先使用NORECOVERY选项来还原事务日志，然后当所有日志都恢复完成后，你可以把数据库切换到STANDBY的只读模式，如下：

RESTORE DATABASE mydb WITH STANDBY = 'g:/data/mydb/mydb_unddat'

使用这个方法，你仅仅创建了回滚文件一次，避免了还原多个事务日志时创建多次回滚文件的过程，加速了恢复过程。

一般的，停止standby数据库之前，要先停用primary库，如果直接停用standby库，可能导致primary库也直接shutdown(最大保护模式)。

对于测试环境可以进行如下步骤：

一 主库暂时取消向备库传输日志

ORCL>alter system set log_archive_dest_state_2=defer;

系统已更改。

二 备库上停止redo应用：

TESTDG>alter database recover managed standby database cancel;

数据库已更改。

三 关闭standby库

TESTDG>shutdown immediate

ORA-01109: 数据库未打开

已经卸载数据库。

ORACLE 例程已经关闭。

1----备库取消归档应用

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2----备库确定 lowest scn

col current_scn for 99999999999999

SELECT CURRENT_SCN FROM V$DATABASE;

select min(fhscn) from x$kcvfh;

select min(ffhscn) from x$kcvfh f, v$datafile d

where fhxfil =dfile#

and denabled != 'READ ONLY' ;

取上述查询中的最小值

SQL> col current_scn for 999999999999999999

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN

-------------------

12611050666604

SQL> select min(fhscn) from x$kcvfh;

MIN(FHSCN)

----------------

12611050666605

SQL> select min(ffhscn) from x$kcvfh f, v$datafile d

where fhxfil =dfile#

and denabled != 'READ ONLY' ; 2 3

MIN(FFHSCN)

----------------

12611050666605

3-----on primary db 端根据第2步中获取的最小scn 来进行增量备份

BACKUP INCREMENTAL FROM SCN 12611050666604 DATABASE FORMAT '/lixora/ForStandby_%U' tag 'FORSTANDBY';

4-----拷贝备份到 备库

$scp ForStandby_07pqprm4_1_1 192168010:/tmp

5----on standby db 在备库端注册备份片，注意用户属主，权限

RMAN> CATALOG START WITH '/lixora/ForStandby';

6----执行恢复

RMAN> RECOVER DATABASE NOREDO;

7-----on primary db 生成新的standby 控制文件

RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/lixora/ForStandbyCTRLbck';

8----把主库端生成的standby 控制文件拷贝到备库，注意用户属主，权限

RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/lixora/ForStandbyCTRLbck';

scp /lixora/ForStandbyCTRLbck 192168010:/tmp

9------备份备库数据文件信息，用于在恢复新的standby 控制文件后比对

spool datafile_names_step8txt

set lines 200

col name format a60

select file#, name from v$datafile order by file# ;

spool off

10------on standby Db 恢复新的standby 控制文件

RMAN> SHUTDOWN IMMEDIATE ;

RMAN> STARTUP NOMOUNT;

RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/ForStandbyCTRLbck';

11-----更新控制文件中的数据文件信息

使新的standby 控制文件生效

RMAN> SHUTDOWN;

RMAN> STARTUP MOUNT;

CATALOG START WITH '+DATA/zhglptdg/datafile/';

12------on primary db。确保在备库发生日志gap 后，主库没有添加过新的数据文件。

SELECT FILE#, NAME FROM V$DATAFILE WHERE CREATION_CHANGE# > 12611050666604；

如果有记录，则不能进行witch *** 作，可以参考一下文档来恢复：

Note 15310311 Steps to perform for Rolling forward a standby database using RMAN incremental backup when datafile is added to primary

13-----重命名数据文件

RMAN> SWITCH DATABASE TO COPY;

14-----再次确认在恢复增量备份片后主库和备库scn 差距没有太大

SQL> col current_scn for 99999999999999

SELECT CURRENT_SCN FROM V$DATABASE;

select min(fhscn) from x$kcvfh;

select min(ffhscn) from x$kcvfh f, v$datafile d

where fhxfil =dfile#

and denabled != 'READ ONLY' ;

CURRENT_SCN

---------------

12614205662375

MIN(FHSCN)

----------------

12614205076072

MIN(FFHSCN)

----------------

12614205076072

15------ On standby database, 清理standby 日志组

select from v$standby_log;

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 3;

16------启动redo data apply

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

以上就是关于SQL Server如何提高数据库还原的速度全部的内容，包括:SQL Server如何提高数据库还原的速度、如何停止standby数据库、如何通过rman的增量备份恢复dataguard中standby端的数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！