sql数据库备份和恢复常用操作

下面就是小编给大家分享的sql数据库备份和恢复常用操作，本文共8篇，希望大家喜欢!本文原稿由网友“july1314”提供。

篇1：sql数据库备份和恢复常用操作

1.新建一个同名的数据库

2.再停掉sql server(注意不要分离数据库)

3.用原数据库的数据文件覆盖掉这个新建的数据库

4.再重启sql server

5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用

数据库的脚本创建一个新的数据库,并将数据导进去就行了.

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'

Go

sp_dboption '置疑的数据库名', 'single user', 'true'

Go

DBCC CHECKDB('置疑的数据库名')

Go

update sysdatabases set status =28 where name='置疑的数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

sp_dboption '置疑的数据库名', 'single user', 'false'

Go

篇2：sql数据库备份和恢复常用操作

事情的起因

昨天，系统管理员告诉我，我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB，于是我决意缩小这个日志文件。经过收缩数据库等操作未果后，我犯了一个自进入行业以来的最大最愚蠢的错误：竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道：“无论如何都要保证数据库日志文件存在，它至关重要”，甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的？！

这下子坏了！这个数据库连不上了，企业管理器在它的旁边写着“(置疑)”。而且最要命的，这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器，应用倒是能用了，但是少了许多记录、表和存储过程。真希望这只是一场噩梦！

没有效果的恢复步骤

附加数据库

_Rambo讲过被删除日志文件中不存在活动日志时，可以这么做来恢复：

1，分离被置疑的数据库，可以使用sp_detach_db

2，附加数据库，可以使用sp_attach_single_file_db

但是，很遗憾，执行之后，SQL Server质疑数据文件和日志文件不符，所以无法附加数据库数据文件。

DTS数据导出

不行，无法读取XXX数据库，DTS Wizard报告说“初始化上下文发生错误”。

紧急模式

怡红公子讲过没有日志用于恢复时，可以这么做：

1，把数据库设置为emergency mode

2，重新建立一个log文件

3，把SQL Server 重新启动一下

4，把应用数据库设置成单用户模式

5，做DBCC CHECKDB

6，如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉

我实践了一下，把应用数据库的数据文件移走，重新建立一个同名的数据库XXX，然后停掉SQL服务，把原来的数据文件再覆盖回来。之后，按照怡红公子的步骤走。

但是，也很遗憾，除了第2步之外，其他步骤执行非常成功。可惜，重启SQL Server之后，这个应用数据库仍然是置疑！

不过，让我欣慰的是，这么做之后，倒是能够Select数据了，让我大出一口气。只不过，组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 'XXX' 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。”

最终成功恢复的全部步骤

设置数据库为紧急模式

停掉SQL Server服务；

把应用数据库的数据文件XXX_Data.mdf移走；

重新建立一个同名的数据库XXX；

停掉SQL服务；

把原来的数据文件再覆盖回来；

运行以下语句，把该数据库设置为紧急模式；

运行“Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go”

执行结果：

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。

接着运行“update sysdatabases set status = 32768 where name = 'XXX'”

执行结果：

（所影响的行数为 1 行）

重启SQL Server服务；

运行以下语句，把应用数据库设置为Single User模式；

运行“sp_dboption 'XXX', 'single user', 'true'”

执行结果：

命令已成功完成。

ü         做DBCC CHECKDB；

运行“DBCC CHECKDB('XXX')”

执行结果：

'XXX' 的 DBCC 结果。

'sysobjects' 的 DBCC 结果。

对象 'sysobjects' 有 273 行，这些行位于 5 页中。

'sysindexes' 的 DBCC 结果。

对象 'sysindexes' 有 202 行，这些行位于 7 页中。

'syscolumns' 的 DBCC 结果。

………

ü         运行以下语句把系统表的修改选项关掉；

运行“sp_resetstatus “XXX”

go

sp_configure 'allow updates', 0

reconfigure with override

Go”

执行结果：

在 sysdatabases 中更新数据库 'XXX' 的条目之前，模式 = 0，状态 = 28（状态 suspect_bit = 0），

没有更新 sysdatabases 中的任何行，因为已正确地重置了模式和状态。没有错误，未进行任何更改。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。

重新建立另外一个数据库XXX.Lost；

DTS导出向导

运行DTS导出向导；

复制源选择EmergencyMode的数据库XXX，导入到XXX.Lost；

选择“在SQL Server数据库之间复制对象和数据”，试了多次，好像不行，只是复制过来了所有表结构，但是没有数据，也没有视图和存储过程，而且DTS向导最后报告复制失败；

所以最后选择“从源数据库复制表和视图”，但是后来发现，这样总是只能复制一部分表记录；

于是选择“用一条查询指定要传输的数据”，缺哪个表记录，就导哪个；

视图和存储过程是执行SQL语句添加的

篇3：linux中mysql数据库备份与恢复linux操作系统

在linux中对数据库或表进行备份与恢复我们会要用于数据库常用命令mysqldump，下面我来利用mysqldump对mysql数据库进行备份与恢复操作，

备份与恢复

比如我们要备份mysql中已经存在的名为linux的数据库，要用到命令mysqldump

命令格式如下：

[root@linuxsir01 root]# mysqldump -u root -p linux >/root/linux.sql

Enter password:在这里输入数据库的密码

例如：将上例创建的aaa库备份到文件back_aaa中

1、备份

代码如下复制代码

[root@test1 root]# cd /home/data/mysql (进入到库目录，本例库已由val/lib/mysql转到/home/data/mysql，见

上述第七部分内容)

代码如下复制代码

[root@test1 mysql]# mysqldump -u root -p –opt aaa >back_aaa

2、恢复

代码如下复制代码

[root@test mysql]# mysql -u root -p ccc < back_aaa

篇4：如何紧急恢复SQL Server主数据库备份恢复

本文介绍如何紧急恢复SQL Server主数据库，这样就不用再在SQL Server的主数据库崩溃导致数据库服务器停止工作的情况下不知所措了，

如果主数据库发生故障，那么微软的SQL Server可能会怦然倒下。看看如何面对这种事件，了解如何用企业管理器和查询分析器修复主数据库。

作为一名微软SQL Server的管理员，您必须知道如何修复一个崩溃的主数据库。主数据库保存有您的登录信息，以及最重要的、指向您所有数据库的指针。如果没有主数据库，您就无法成功地启动SQL Server。在本文里，我将向您介绍在发生崩溃的情况下如何修复主数据库，并告诉您如何重建主数据库，如果有必要的话。

制定预案

制定一个应对崩溃和／或主数据库故障的预案十分重要。这将有助于您在碰到灾难的情况下按照既定的方法进行处理，而不是迫于压力仓促作出反应。我碰到过很多很容易就陷入惊慌的状况，但是由于保持冷静并按照正确的方法来处理问题，我最后成功地度过了所有的困境。

怎么才能知道您的主数据库已经崩溃？

在正式开始讨论碰到系统故障如何修复和重建的主数据库之前，我们需要先了解如何辨别它已经崩溃了。要说明这一点，我会弄垮一个主数据库，告诉您主数据库崩溃会发生什么样的症状。

现在让我们假设您的公司碰到了电涌，造成SQL Server重启。在重新启动的时候，SQL Server却没有正常启动。如果查看错误日志（图A），您会看到主数据库崩溃或者丢失。既然您知道需要查看什么信息，那就让我们看看如何修复主数据库。

图A

修复您的主数据库

修复主数据库的第一步是使用“重建向导（Rebuild Wizard，Rebuildm.exe），它放在Program FilesMicrosoft SQL Server80ToolsBINN目录下。现在就让我们来看看重建向导是如何工作的。

双击Rebuildm.exe启动图B所示的对话框。

图B

在这个对话框里，您可以指定数据库服务器的修复设置，以及原始安装的数据文件的位置。要让这一过程更容易和更快，就要把x86目录从SQL的光盘上复制到硬盘上，并把指向改到本地的副本。一旦验证完了所有的信息，点击“重建（Rebuild）”。然后系统就会提示您确认操作，如图C所示。

图C

点击“确定（Yes）”。一旦重建过程完成，您会看到一条重建成功的消息，

您现在就有了一个全新的主数据库，准备好修复主数据库了。

首先，打开命令行提示符，输入Program FilesMicrosoft SQL ServerMSSQLBINN目录下的sqlservr.exe –c –m命令，启动单用户模式下的SQL Server。结果如图D所示。

图D

在单用户模式下启动SQL Server之后，您可以利用备份文件修复主数据库。您可以用“查询分析器（Query Analyzer）”或者“SQL企业管理器（SQL Enterprise Manager）”来修复它。如果使用查询分析器，您就要像图E一样运行查询。

图E

如果使用

关 键 字：MYSQL

篇5：靠BCP恢复SQL Server 数据库备份恢复

本文以图示的方式，阐述某个大学的一次SQL Server 2000数据库数据恢复过程，同时也详细阐述了BCP实用工具的详细用法，希望这个处理过程和处理方法能对大家有所启示。

SQL Server 2000在很多企业、电子商务网站的信息化平台得到了普遍的应用。可在日常运行中，因种种原因会造成SQL Server 2000运行出现故障，轻则出现“置疑”，重则数据库系统崩溃。本文以图示的方式，阐述某个大学的一次数据库数据恢复过程。同时也详细阐述了BCP实用工具的详细用法，希望这个处理过程和处理方法能对大家有所启示。

本文恢复数据使用PC环境如下：

1）Windows 2000 Server（简体中文）+SP4

2）Microsoft SQL Server 2000企业版（简体中文）+SP3a

故障现象

1）游泳馆收费系统连接不上SQL Server 2000数据库。

2）启动SQL Server服务失败。

3）打开企业管理器，启动服务也是失败（看不到数据库树目录）。

要命的是当技术员发现问题，已经卸载SQL Server 2000后重新安装过了，想利用master数据库是不可能了。更要命的是，居然没有的备份数据库，只有6月的数据库备份文件。

恢复尝试

第一招：附加数据库

拷贝SQL Server 2000数据文件zytk.mdf到d:recovery下。在企业管理器中，右键数据库，选择所有任务→附加数据库。单击浏览（“...”）按钮选择要附加的数据库mdf文件d:recoveryzytk.mdf，发现日志文件是错误的（如图1）。

此时拷贝zytk.ldf到d:recovery目录下，再进行上述步骤，日志文件仍是错误（就是那个可恶的红叉叉）。单击确定按钮，提示日志文件错误（如图2和图3）。

发现提示的日志文件路径是D:Microsoft sql servermssql data zytk_log.ldf。于是在D盘建立D:Microsoft sql servermssqldata目录，并将zytk.mdf拷贝这个目录下。继续尝试上述附加数据库步骤，日志文件的路径已经变化，仍旧没能附加数据库成功（错误1813）（如图4与图1相比）。

第二招：用T-SQL附加数据库

在查询分析器中执行SQL脚本

use master

EXEC sp_attach_db “ZYTK”, “D:Microsoft sql servermssqldataZYTK.mdf”,“D:Microsoft sql servermssqldataZYTK_log.ldf”

查询分析器提示：

服务器:消息5105，级别16，状态4，行1

设备激活错误。物理文件名 'D:Microsoft sql servermssql dataZYTK_log.ldf' 可能有误。

将D:recovery目录下zytk.mdf改名zytk-old.mdf。在企业管理器中新建数据库zytk，选择数据库文件路径为D:recoveryZYTK_Data.MDF，日志文件路径为D:recoveryZYTK_ log.LDF。在企业管理器中，右键停止，以便停止SQL Server服务。待SQL

关 键 字：MYSQL

篇6：理论篇：SQL数据库备份还原和恢复全过程

理论篇：SQL数据库备份还原和恢复过程

关于SQL数据库的恢复问题，这里首先要强调一点：不是所有的数据都能神奇般的恢复，只有满足特定条件的数据才是可逆的（可恢复），那么这就要求我们平时要养成备份文件的好习惯。下面就来为大家具体介绍下数据库的备份问题。

在完整恢复模式或大容量日志恢复模式下，必须先备份活动事务日志（称为日志尾部），然后才能在SQLServerManagementStudio中还原数据库。有关详细信息，请参阅如何备份事务日志(SQLServerManagementStudio)。若要还原已加密的数据库，您必须有权访问用于加密数据库的证书或非对称密钥。如果没有证书或非对称密钥，数据库将无法还原。

认识数据库备份和事务日志备份

数据库备份与日志备份是数据库维护的日常工作，备份的目的是在于当数据库出现故障或者遭到破坏时可以根据备份的数据库及事务日志文件还原到最近的时间点将损失降到最低点。参考文献

数据库备份

数据库备份可以手动备份和语句备份

一.手动备份数据库

1.鼠标右键选择你要进行备份的数据库-任务-备份

可以在常规选项页面你可以选择备份类型是进行完整数据库备份还是差异数据库备份

2.点击添加选项，选择数据库文件的存放路径

注意文件名记得加后缀.bak,便于恢复时的查找

3.你还可以在选项页面是追加到现有的备份集，还是覆盖所有的现有备份集，还可以选择备份验证完整性（建议选择），还可以选择是否压缩备份等。

二.语句备份数据库

use master goBACKUP DATABASE [test] TO  DISK = N'D:\\Microsoft sql server\\MSSQL10.MSSQLSERVER\\MSSQL\\Backup\\test.bak' WITH NOFORMAT, NOINIT,  NAME = N'test-完整 数据库 备份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10GO

数据库日志备份

首先需要注意，数据库日志的备份是基于数据库完整备份，也就是说你备份数据库日志之前你首先要先对数据库进行一次完整的备份，因为之间会涉及到坚持到检查点lsn，这也是本文接下来要讲的重点。

一.手动备份数据库日志

1.右键数据库-任务-备份-选择备份类型（事务日志）

2.点添加，添加日志文件备份存储路径

3.同数据库完整备份一样，你也可以选择覆盖现有备份集或者追加到现有备份集，这里现在覆盖现有备份集、验证完整性，然后确认备份

二.语句备份数据库事务日志

BACKUP LOG [test] TO  DISK = N'D:\\test.trn' WITH NOFORMAT, INIT,  NAME = N'test-事务日志  备份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10GO

数据库还原

右键数据库-还原数据库-添加需要进行还原的数据库文件路径

在还原源选项中你可以选择‘源数据库’，‘源设备’，

1.选择源数据库工具会自动显示该数据库之前的一些备份，然后直接选择需要还原的数据库备份集。

2.选择源设备点击后面的...，添加需要还原的数据库文件

2.点击确认还原数据库

数据库恢复

数据库恢复的前提是1.一个完整的数据库备份2.包含这个完整数据库备份的事务日志备份3.完整备份之间也可以存在数个差异备份

对于数据库维护空间始终是一个比较头疼的问题，特别是对于大型数据库而言，每天的日志文件增长是庞大的，很多数据库管理员会定时对数据库日志文件进行收缩，但是经常收缩会存在收缩完日志文件还是不能减少，这是因为存在很多活动的日志无法收缩可以用

DBCC LOGINFO('数据库名称')

我们看到

status=0的日志，代表已经备份到磁盘的日志文件；而

status=2的日志还没有备份。当我们收缩日志文件时，收缩掉的空

间其实就是

status=0的空间，如果日志物理文件无法减小，这里一

定能看到非常多 status=2的记录

解决办法：1.可以分离要收缩的数据库，然后手动删除日志文件，然后附加数据库，数据库就会产生一个很小的日志文件（不推荐使用这种方法）

2.右键要出来的数据库选择“属性”-“选项”，将恢复模式改成“简单”，然后利用收缩工具可以讲日志文件收缩到很小，收缩完记得讲恢复模式改成“完整”

也可以用语句进行处理(dbname是你要进行收缩的数据库名，dbname_log是你要进行收缩的数据库的逻辑日志名称)

USE [master]

GO    ALTER DATABASE [dbname] SET recovery SIMPLE WITH NO_WAIT    GO

ALTER DATABASE [dbname] SET RECOVERY SIMPLE   --简单模式

GO

USE [dbname]

GO

DBCC SHRINKFILE (N'dbname_log' , 11, TRUNCATEONLY)    GO

USE [master]

GO

ALTER DATABASE [dbname] SET RECOVERY FULL WITH NO_WAIT    ALTER DATABASE [dbname] SET RECOVERY FULL

对于第一种方法不赞同使用，首先对于数据库的分离与附加有时候会破坏数据库，造成数据库无法还原，还有就是对于在线数据库也不允许进行分离操作。

对于第二种方法是slq收缩日志文件的一种方法，但是此方法也不能使用过于频繁，因为进行数据库恢复模式的更改会截断事务日志文件，这样的话当时利用事务日志文件进行恢复的时候检查点不能包含数据库文件，而且当你要对事务日志进行备份的时候会重新提示你需要对数据库进行完整备份。

举个例子：比如你昨天晚上进行了一次完整备份，然后同时你也进行了一次日志备份（提前日志未被截断），然后你每个小时进行过一次差异备份，最近的差异备份时间点是14点，如果此时数据库错误修改了数据，你可以立马备份一个日志文件将数据库恢复到日志备份开始到日志备份终点前的任意时间点 。

如果此时你进行了修改数据库模式，截断日志进行了收缩，那么你的数据只能恢复到昨天晚上备份的那个日志备份时间前的任意时间点，也就是今天所做的数据库更改无法再恢复了，因为日志文件已经被截断了，不知道这样解释是否明白

因为日志文件的检查点（lsn）是连续的，每一次日志备份都是在上一次备份的基础上lsn往后增加的，lsn的范围也包括了数据库文件的lsn，也只有日志文件的lsn包括了数据库文件的lsn,才能将数据库文件进行回滚。

上图中总共有三个备份文件，一个完整备份、一个差异备份、一个日志备份，大家可以注意观察完整备份的第一个lsn与最后一个lsn,和检查点

第二个差异备份文件的的第一个lsn与最后一个lsn,和检查点，最后的日志备份的第一个lsn和最后一个lsn包含了前面两个备份文件的lsn,这种情况数据库就可以恢复到日志文件备份前的任意时间点，如果日志文件没有包含数据库文件的最后一个lsn也就无法恢复了。

今天学习了SQL数据备份还原和恢复的问题的理论知识，后续会有实战演练（干货），教你一步步完成数据库重要文件的恢复。

篇7：备份和恢复概述数据库教程

理主要是为防止非法登录者或非授权用户对SQL Server 数据库或数据造成破坏，但在有些情况下这种安全管理机制显得力不从心，

备份和恢复概述数据库教程

。例如合法用户不小心对数据库数据做了不正确的操作或者保存数据库文件的磁盘遭到损坏或者运行SQL Server 的服务器因某种不可预见

的事情而导致崩溃。所以我们需要提出另外的方案即数据库的备份和恢复来解决这种问题。本章的主要目的就是介绍备份、恢复的含

义，数据库备份的种类以及备份设备等基本的概念，以及如何创建备份和恢复数据库，使读者对其有全面的了解和认识，能够自主制定自己的备份和恢复计划。

15.1.1 备份和恢复

备份和恢复组件是SQL Server 的重要组成部分。备份就是指对SQL Server 数据库或事务日志进行拷贝，数据库备份记录了在进行备份这一操作时数据库中所有数据的状态，如果数据库因意外而损坏，这些备份文件将在数据库恢复时被用来恢复数据库。

由于SQL Server 支持在线，备份所以通常情况下可一边进行备份，一边进行其它操作，但是，在备份过程中不允许执行以下操作：

创建或删除数据库文件；

创建索引；

执行非日志操作；

自动或手工缩小数据库或数据库文件大小。如果以上各种操作正在进行当中，且准备进行备份则备份，处理将被终止；如果在备份过程中，打算执行以上任何操作，则操作将失败而备份继续进行。

恢复就是把遭受破坏或丢失数据或出现错误的数据库恢复到原来的正常状态，这一状态是由备份决定的，但是为了维护数据库的一致性，在备份中未完成的事务并不进行恢复。

进行备份和恢复的工作主要是由数据库管理员来完成的。实际上数据库管理员日常比较重要、比较频繁的工作就是对数据库进行备份和恢复。

注意：如果在备份或恢复过程中发生中断，则可以重新从中断点开始执行备份或恢复。这在备份一个大型数据库时极有价值。

15.1.2 数据库备份的类型

在SQL Server 中有四种备份类型，分别为；

数据库备份（Database Backups）

事务日志备份（Transaction Log Backup）

差异备份（Differential Database Backups）

文件和文件组备份（File and File Group Backup）下面我们将详细介绍其所表述的内容，并涉及到一些使用时注意事项。

1 数据库备份（Database Backups）

数据库备份是指对数据库的完整备份，包括所有的数据以及数据库对象。实际上备份数据库过程就是首先将事务日志写到磁盘上，

然后根据事务创建相同的数据库和数据库对象以及拷贝数据的过程。由于是对数据库的完全备份，所以这种备份类型不仅速度较慢，

而且将占用大量磁盘空间。正因为如此，在进行数据库备份时，常将其安排在晚间，因为此时整个数据库系统几乎不进行其它事务操作，从而可以提高数据库备份的速度。

在对数据库进行完全备份时，所有未完成的事务或者发生在备份过程中的事务都不会被备份。如果您使用数据库备份类型，

则从开始备份到开始恢复这段时间内发生的任何针对数据库的修改将无法恢复。所以我们总是在一定的要求或条件下才使用这种备份类型，比如：

数据不是非常重要，尽管在备份之后恢复之前数据被修改，但这种修改是可以忍受的；

通过批处理或其它方法，在数据库恢复之后可以很容易地重新实现在数据损坏前发生的修改；

数据库变化的频率不大。在进行数据库备份时，如果您在备份完成之后又进行了事务日志备份，则在数据库备份过程中发生的事务将被备份：但若只进行数据库备份，常将数据库选项“trunc.log onchkpt” 设置为true， 这样每次在运行到检查点（checkpoint） 时，都会将事务日志截断。

注意：如果对数据一致性要求较高（将数据库恢复到发生损坏的刻），则不应使用数据库备份。

2 事务日志备份（Transaction Log Backup）

事务日志备份是指对数据库发生的事务进行备份，包括从上次进行事务日志备份、差异备份和数据库完全备份之后，所有已经完成的事务。在以下情况下我们常选择事务日志备份。

不允许在最近一次数据库备份之后发生数据丢失或损坏现象；

存储备份文件的磁盘空间很小或者留给进行备份操作的时间有限，例如兆字节级的数据库需要很大的磁盘空间和备份时间；

准备把数据库恢复到发生失败的前一点；

数据库变化较为频繁。由于事务日志备份仅对数据库事务日志进行备份，所以其需要的磁盘空间和备份时间都比数据库备份（备份数据和事务）少得多，这是它的优点所在。正是基于此，我们在备份时常采用这样的策略，即每天进行一次数据库备份，而以一个或几个小时的频率备份事务日志。这样利用事务日志备份，我们就可以将数据库恢复到任意一个创建事务日志备份的时刻。

但是，创建事务日志备份却相对比较复杂。因为在使用事务日志对数据库进行恢复操作时，还必须有一个完整的数据库备份，而且事务日志备份恢复时必须要按一定的顺序进行。比如在上周末对数据库进行了完整的数据库备份，在从周一到本周末的每一天都进行一次事务日志备份，那么若要打算对数据库进行恢复，则首先恢复数据库备份，然后按照顺序恢复从周一到本周末的事务日志备份。

有些时侯数据库事务日志会被中断，例如数据库中执行了非日志操作（如创建索引、创建或删除数据库文件、自动或手工缩小数据库文件大小），此时应该立即创建数据库或差异备份，然后再进行事务日志备份。以前进行的事务日志备份也没有必要了。

3 差异备份（Differential Database Backups）

差异备份是指将最近一次数据库备份以来发生的数据变化备份起，来因此差异备份实际上是一种增量数据库备份，

与完整数据库备份相比，差异备份由于备份的数据量较小，所以备份和恢复所用的时间较短。通过增加差异备份的备份次数，可以降低丢失数据的风险，将数据库恢复至进行最后一次差异备份的时刻，但是它无法像事务日志备份那样提供到失败点的无数据损失备份。

但在实际中为了最大限度地减少数据库恢复时间以及降低数据损失数量，我们常一起使用数据库备份、事务日志备份和差异备份，而采用的备份方案是这样的；

首先有规律地进行数据库备份，比如每晚进行备份；

其次以较小的时间间隔进行差异备份，比如三个小时或四个小时；

最后在相临的两次差异备份之间进行事务日志备份，可以每二十或三十分钟一次。

这样在进行恢复时，我们可先恢复最近一次的数据库备份，接着进行差异备份，最后进行事务日志备份的恢复。

但是，在更多的情况下我们希望数据库能恢复到数据库失败那一时刻，那么我们该怎样做呢？下面的方法也许会有大帮助。

首先如果能够访问数据库事务日志文件则应备份当前正处于活动状态的事务日志；

其次恢复最近一次数据库备份；

接着恢复最近一次差异备份；

最后按顺序恢复自差异备份以来进行的事务日志备份。当然，如果无法备份当前数据库正在进行的事务，则只能把数据库恢复到最后一次事务日志备份的状态，而不是数据库失败点。

4 文件和文件组备份（File and File Group Backup）

文件或文件组备份是指对数据库文件或文件夹进行备份，但其不像完整的数据库备份那样同时也进行事务日志备份。使用该备份方法可提高数据库恢复的速度，因为其仅对遭到破坏的文件或文件组进行恢复。

但是在使用文件或文件组进行恢复时，仍要求有一个自上次备份以来的事务日志备份来保证数据库的一致性。所以在进行完文件或文件组备份后应再进行事务日志备份。否则备份在文件或文件组备份中所有数据库变化将无效。

如果需要恢复的数据库部分涉及到多个文件或文件组，则应把这些文件或文件组都进行恢复。例如，如果在创建表或索引时，表或索引是跨多个文件或文件组，则在事务日志备份结束后应再对表或索引有关的文件或文件组进行备份，否则在文件或文件组恢复时将会出错。

15.1.3 备份和恢复的策略

通常而言，我们总是依赖所要求的恢复能力（如将数据库恢复到失败点） 、备份文件的大小（如完成数据库备份或只进行事务日志的备份或是差异数据库备份）以及留给备份的时间等来决定该使用哪种类型的备份。常用的备份选择方案有：仅仅进行数据库备份、或在进行数据库备份的同时进行事务日志备份，或使用完整数据库备份和差异数据库备份。

选用怎样的备份方案将对备份和恢复产生直接影响，而且也决定了数据库在遭到破坏前后的一致性水平。所以在做出该决策时，您必须认识到以下几个问题：

如果只进行数据库备份，那么将无法恢复自最近一次数据库备份以来数据库中所发生的所有事务。这种方案的优点是简单，而且在进行数据库恢复时操作也很方便；

如果在进行数据库备份时也进行事务日志备份，那么可以将数据库恢复到失败点，那些在失败前未提交的事务将无法恢复，但如果您在数据库失败后立即对当前处于活动状态的事务进行备份，则未提交的事务也可以恢复。

从以上可以看出，对数据库一致性的要求程度成为我们选择这样或那样的备份方案的主要的普遍性原因。但在某些情况下对数据库备份提出更为严格的要求，例如在处理比较重要业务的应用环境中，常要求数据库服务器连续工作，至多只留有一小段时间来执行系统维护任务，在该情况下一旦出现系统失败，则要求数据库在最短时间内立即恢复到正常状态，以避免丢失过多的重要数据，由此可见备份或恢复所需时间往往也成为我们选择何种备份方案的重要影响因素。

那么如何才能减少备份和恢复所花费时间呢？SQL Server 提供了几种方法来减少备份或恢复操作的执行时间。

使用多个备份设备来同时进行备份处理。同理，可以从多个备份设备上同时进行数据库恢复操作处理；

综合使用完整数据库备份、差异备份或事务日志备份来减少每次的需要备份的数据数量；

使用文件或文件组备份以及事务日志备份，这样可以只备份或恢复那些包含相关数据的文件，而不是整个数据库。

另外需要注意的是，在备份时我们也要决定该使用哪种备份设备如磁盘或磁带，并且决定如何在备份设备上创建备份，比如将备份添加到备份设备上或将其覆盖。在SQL Server 2000 中，有三种数据库恢复模式，它们分别是：简单恢复（SimpleRecovery）、完全恢复（Full Recovery）、批日志恢复（Bulk-logged Recovery）。

1 简单恢复（Simple Recovery）

所谓简单恢复就是指在进行数据库恢复时仅使用了数据库备份或差异备份，而不涉及事务日志备份。简单恢复模式可使数据库恢复到上一次备份的状态，但由于不使用事务日志备份来进行恢复，所以无法将数据库恢复到失败点状态。当选择简单恢复模式时常使用的备份策略是：首先进行数据库备份，然后进行差异备份。

2 完全恢复（Full Recovery）

完全数据库恢复模式是指通过使用数据库备份和事务日志备份将数据库恢复到发生失败的时刻，因此几乎不造成任何数据丢失，这成为对付因存储介质损坏而数据丢失的最佳方法。为了保证数据库的这种恢复能力，所有的批数据操作比如SELECT INGO、创建索引都被写入日志文件。选择完全恢复模式时常使用的备份策略是：

首先进行完全数据库备份；

然后进行差异数据库备份；

最后进行事务日志的备份。

如果准备让数据库恢复到失败时刻必须对数据库失败前正处于运行状态的事务进行备份。3 批日志恢复（Bulk-logged Recovery）

批日志恢复在性能上要优于简单恢复和完全恢复模式，它能尽最大努力减少批操作所需要的存储空间。这些批操作主要是：SELECT INTO 批装载操作（如bcp 操作或批插入操作）、创建索引针对大文本或图像的操作（如WRITETEXT、UPDATETEXT）。选择批日志恢复模式所采用的备份策略与完全恢复所采用的恢复策略基本相同。

从以上的论述中我们可以看到，在实际应用中，备份策略和恢复策略的选择不是相互孤立的，而是有着紧密的联系。我们并不仅仅是因为数据库备份为数据库恢复提供了 “原材料”这一事实，以便在采用何种数据库恢复模式的决策中考虑该怎样进行数据库备份，更多是因为在选择该使用哪种备份类型时我们必须考虑到当使用该备份进行数据库恢复时，它能把遭到损坏的数据库“带”到怎样的状态（是数据库失败的时刻，还是最近一次备份的时刻）。但有一点我们必须强调，即备份类型的选择和恢复模式的确定都应服从于这一目标：尽最大可能，以最快速度减少或消灭数据丢失。

篇8：SQL SERVER2000数据库备份和恢复存储过程(加强版本)数据库教程

server|备份|存储过程|恢复|数据|数据库

SQL SERVER2000数据库备份和恢复存储过程(加强版本)

我自己写的2个过程和一个函数,用于SQL SERVER2000数据库备份和恢复

拿出来和大家交流一下,过程和函数的详细说明在代码中

谢谢

/*备份数据库的过程*/

if exists(

select * from sysobjects

where name='pr_backup_db' and xtype='p'

)

begin

drop proc pr_backup_db

end

go

create proc pr_backup_db

@flag varchar(20) out,

@backup_db_name varchar(128),

@filename varchar(1000) --路径＋文件名字

as

declare @sql nvarchar(4000),@par nvarchar(1000)

if not exists(

select * from master..sysdatabases

where name=@backup_db_name

)

begin

select @flag='db not exist' /*数据库不存在*/

return

end

else

begin

if right(@filename,1)'\\' and charindex('\\',@filename)0

begin

select @par='@filename varchar(1000)'

select @sql='BACKUP DATABASE '+@backup_db_name+' to disk=@filename with init'

execute sp_executesql @sql,@par,@filename

select @flag='ok'

return

end

else

begin

select @flag='file type error' /*参数@filename输入格式错误*/

return

end

end

GO

说明:pr_backup_db过程是备份你的数据库

/*创建函数,得到文件得路径*/

if exists(

select * from sysobjects

where name='fn_GetFilePath' and xtype='fn'

)

begin

drop function fn_GetFilePath

end

go

create function fn_GetFilePath(@filename nvarchar(260))

returns nvarchar(260)

as

begin

declare @file_path nvarchar(260)

declare @filename_reverse nvarchar(260)

select @filename_reverse=reverse(@filename)

select @file_path=substring(@filename,1,len(@filename)+1-charindex('\\',@filename_reverse))

return @file_path

end

GO

/*恢复数据库的过程*/

if exists(

select * from sysobjects

where name='pr_restore_db' and xtype='p'

)

begin

drop proc pr_restore_db

end

go

CREATE proc pr_restore_db

@flag varchar(20) out,   /*过程运行的状态标志,是输入参数*/

@restore_db_name nvarchar(128), /*要恢复的数据名字*/

@filename nvarchar(260)        /*备份文件存放的路径+备份文件名字*/

as

declare @proc_result tinyint /*返回系统存储过程xp_cmdshell运行结果*/

declare @loop_time smallint /*循环次数*/

declare @max_ids smallint   /*@tem表的ids列最大数*/

declare @file_bak_path nvarchar(260) /*原数据库存放路径*/

declare @flag_file bit  /*文件存放标志*/

declare @master_path nvarchar(260) /*数据库master文件路径*/

declare @sql nvarchar(4000),@par nvarchar(1000)

declare @sql_sub nvarchar(4000)

declare @sql_cmd nvarchar(100)

declare @sql_kill nvarchar(100)

/*

判断参数@filename文件格式合法性，以防止用户输入类似d: 或者 c:\\a\\ 等非法文件名

参数@filename里面必须有'\\'并且不以'\\'结尾

*/

if right(@filename,1)'\\' and charindex('\\',@filename)0

begin

select @sql_cmd='dir '+@filename

EXEC @proc_result = master..xp_cmdshell @sql_cmd,no_output

IF (@proc_result0) /*系统存储过程xp_cmdshell返回代码值:0(成功）或1（失败）*/

begin

select @flag='not exist'  /*备份文件不存在*/

return /*退出过程*/

end

/*创建临时表,保存由备份集内包含的数据库和日志文件列表组成的结果集*/

create table #tem(

LogicalName nvarchar(128), /*文件的逻辑名称*/

PhysicalName nvarchar(260) , /*文件的物理名称或操作系统名称*/

Type char(1), /*数据文件 (D) 或日志文件 (L)*/

FileGroupName nvarchar(128), /*包含文件的文件组名称*/

[Size] numeric(20,0), /*当前大小（以字节为单位）*/

[MaxSize] numeric(20,0) /*允许的最大大小（以字节为单位）*/

)

/*

创建表变量，表结构与临时表基本一样

就是多了两列,

列ids（自增编号列）,

列file_path,存放文件的路径

*/

declare @tem table(

ids smallint identity, /*自增编号列*/

LogicalName nvarchar(128),

PhysicalName nvarchar(260),

File_path nvarchar(260),

Type char(1),

FileGroupName nvarchar(128)

)

insert into #tem

execute('restore filelistonly from disk='''+@filename+'''')

/*将临时表导入表变量中,并且计算出相应得路径*/

insert into @tem(LogicalName,PhysicalName,File_path,Type,FileGroupName)

select LogicalName,PhysicalName,dbo.fn_GetFilePath(PhysicalName),Type,FileGroupName

from #tem

if @@rowcount>0

begin

drop table #tem

end

select @loop_time=1

select @max_ids=max(ids) /*@tem表的ids列最大数*/

from @tem

while @loop_time<=@max_ids

begin

select @file_bak_path=file_path

from @tem where ids=@loop_time

select @sql_cmd='dir '+@file_bak_path

EXEC @proc_result = master..xp_cmdshell @sql_cmd,no_output

/*系统存储过程xp_cmdshell返回代码值:0(成功）或1（失败）*/

IF (@proc_result0)

select @loop_time=@loop_time+1

else

BREAK /*没有找到备份前数据文件原有存放路径，退出循环*/

end

select @master_path=''

if @loop_time>@max_ids

select @flag_file=1  /*备份前数据文件原有存放路径存在*/

else

begin

select @flag_file=0 /*备份前数据文件原有存放路径不存在*/

select @master_path=dbo.fn_GetFilePath(filename)

from master..sysdatabases

where name='master'

end

select @sql_sub=''

/*type='d'是数据文件,type='l'是日志文件 */

/*@flag_file=1时新的数据库文件还是存放在原来路径，否则存放路径和master数据库路径一样*/

select @sql_sub=@sql_sub+'move '''+LogicalName+''' to '''

+case type

when 'd' then case @flag_file

when 1 then File_path

else @master_path

end

when 'l' then case @flag_file

when 1 then File_path

else @master_path

end

end

+case type

when 'd' then @restore_db_name

+'_DATA'

+convert(sysname,ids) /*给文件编号*/

+'.'

+right(PhysicalName,3) /*给文件加入后缀名,mdf or ndf*/

+''','

when 'l' then @restore_db_name

+'_LOG'

+convert(sysname,ids)  /*给文件编号*/

+'.'

+right(PhysicalName,3) /*给文件加入后缀名,mdf or ndf*/

+''','

end

from @tem

select @sql='RESTORE DATABASE @db_name FROM DISK=@filename with '

select @sql=@sql+@sql_sub+'replace'

select @par='@db_name nvarchar(128),@filename nvarchar(260)'

/*关闭相关进程，把相应进程状况导入临时表中*/

select identity(int,1,1) ids, spid

into #temp

from master..sysprocesses

where dbid=db_id(@restore_db_name)

if @@rowcount>0 --找到相应进程

begin

select @max_ids=max(ids)

from #temp

select @loop_time=1

while @loop_time<=@max_ids

begin

select @sql_kill='kill '+convert(nvarchar(20),spid)

from #temp

where ids=@loop_time

execute sp_executesql @sql_kill

select @loop_time=@loop_time+1

end

end

drop table #temp

execute sp_executesql @sql,@par,@db_name=@restore_db_name,@filename=@filename

select @flag='ok'  /*操作成功*/

end

else

begin

SELECT @flag='file type error' /*参数@filename输入格式错误*/

end

GO

--run

--备份数据库test_database

declare @fl varchar(10)

execute pr_backup_db @fl out,'test_database','c:\\test_database.bak'

select @fl

--恢复数据库,输入的参数错误

declare @fl varchar(20)

exec pr_restore_db @fl out,'sa','c:\\'

select @fl

--恢复数据库,即创建数据库test_database的复本test_db

declare @fl varchar(20)

exec pr_restore_db @fl out,'test_db','c:\\test_database.bak'

select @fl

以上过程和函数在MS SQL2000运行成功,由于MS SQL7不支持用户自定义函数和表变量,要在MS SQL7下使用可以把函数fn_GetFilePath改写成过

程,把过程pr_restore_db中的表变量改写为临时表即可运行,有兴趣的朋友可以试试!

我的Email:aierong@2118.cn

欢迎大家交流

逻辑备份与恢复实战数据库教程

PL/SQL Developer数据库教程

SYBASE ASA数据库恢复方法数据库

Python SQLite3数据库操作类

PL/SQL流程控制数据库教程

sql数据库备份和恢复常用操作.doc

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档