靠BCP恢复SQL Server 数据库备份恢复（整理7篇）由网友“宁静以致远”投稿提供，以下是小编为大家汇总后的靠BCP恢复SQL Server 数据库备份恢复，希望能够帮助到大家。
篇1：靠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
篇2：备份和恢复概述数据库教程
理主要是为防止非法登录者或非授权用户对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）。选择批日志恢复模式所采用的备份策略与完全恢复所采用的恢复策略基本相同。
从以上的论述中我们可以看到，在实际应用中，备份策略和恢复策略的选择不是相互孤立的，而是有着紧密的联系。我们并不仅仅是因为数据库备份为数据库恢复提供了 “原材料”这一事实，以便在采用何种数据库恢复模式的决策中考虑该怎样进行数据库备份，更多是因为在选择该使用哪种备份类型时我们必须考虑到当使用该备份进行数据库恢复时，它能把遭到损坏的数据库“带”到怎样的状态（是数据库失败的时刻，还是最近一次备份的时刻）。但有一点我们必须强调，即备份类型的选择和恢复模式的确定都应服从于这一目标：尽最大可能，以最快速度减少或消灭数据丢失。
篇3：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
篇4：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语句添加的
篇5：差异备份的恢复问题数据库
A :情况是这样的 create database test create table t(a int) insert into test..t select 1 然后进行一次完整备份 backup database test to disk='c:\test.bak' insert into test..t select 2 再进行一次完整备份 backup database test to disk='c:\test.b
A : 情况是这样的
create database test
create table t(a int)
insert into test..t select 1
然后进行一次完整备份
backup database test to disk='c:\test.bak'
insert into test..t select 2
再进行一次完整备份
backup database test to disk='c:\test.bak'
insert into test..t select 3
此时用 restore database test from disk='c:\test.bak' with file=1
结果为 1, 此为正确
用 restore database test from disk='c:\test.bak' with file=2
结果为 1,
2 此也为正确
当表t中为1,2,3的时候，在插入一条纪录结果为1,2,3,4然后进行一次差异备份
backup database test to disk='c:\test.bak' with differential
然后往执行delete from t 删除所有纪录
我现在想恢复最后的那次差异备份（结果为1,2,3,4），用语句改如何实现呢？
---------------------------------------------------------------
下面的是详细的过程,在我的电脑上测试成功:
--清除环境,防止现有的数据影响测试结果
exec master..xp_cmdshell 'del c:\text.bak'
if exists(select * from master..sysdatabases where name='test')
drop database test
go
--创建数据库
create database test
go
--打开创建的数据
use test
go
--创建测试表
create table t(a int)
--切换回master数据库
use master
go
--插入数据1
insert into test..t select 1
go
--然后进行一次完整备份
backup database test to disk='c:\test.bak'
go
--插入数据2
insert into test..t select 2
go
--再进行一次完整备份
backup database test to disk='c:\test.bak'
go
--插入3,4
insert into test..t select 3
insert into test..t select 4
go
--差异备份:
backup database test to disk='c:\test.bak' with differential
--删除数据库
drop database test
--还原数据库和差异数据库备份
--还原完整备份
restore database test from disk='c:\test.bak' with file=2,norecovery
--还原差异备份的内容
restore database test from disk='c:\test.bak' with file=3,recovery
--显示恢复后的数据
select * from test..t
---------------------------------------------------------------
都已经说的好明白了，怎么可能会不行呢？
前段时间我就做过类似程序的！
必须说明的是：在恢复差异备份时，必须恢复最后一次的完整备份！！（切记）
而且下面的两个语句必须同时执行,即放在一个事务中，
差异备份的恢复问题数据库
，
restore database test from disk='c:\test.bak' with file=离你要恢复的差异备份最近一次的完整备份号,norecovery
restore database test from disk='c:\test.bak' with file=你要还原的差异备份号,recovery
具体的备份号可以从下面得到：（你可以认真研究一下backupfile,backupset,backmediaset,backupmediafamily几个表，可以发现规律）
select backup_start_date as 备份时间,position as 备份号,
case type when 'D' then '完整备份' when 'I' then '差异备份' end as 备份类型
from msdb..backupset where database_name='test'
and media_set_id in
(select distinct media_set_id from msdb..backupmediafamily where physical_device_name='c:\test.bak')
order by position
如果还不行的话，可以给我留言~
---------------------------------------------------------------
---执行下面的序列：
create database test
go
use test
go
create table test..t(a int)
insert test..t select 1
backup database test to disk='c:\test.bak'
insert test..t select 2
backup database test to disk='c:\test.bak'
insert test..t select 3
insert test..t select 4
backup database test to disk='c:\test.bak' with differential
delete test..t
go
--下面开始恢复：
restore database test from disk='c:\test.bak' with file=2,norecovery --对应你最后一次的完整备份
restore database test from disk='c:\test.bak' with file=3 --对应你要还原的差异备份
go
select * from test
原文转自：www.ltesting.net
篇6：ecshop数据库备份和数据库恢复的步骤
这篇文章主要介绍了ecshop数据库备份和数据库恢复的步骤,需要的朋友可以参考下
1、数据库备份 如图 1 所示：
（1）备份类型：
有四种备份类型：
全部备份: 就是备份ECShop所有的表，一般选择这个方式，这个方式可以在灾难恢复的时候快速恢复。
标准备份：备份一些常用的表。
最小备份: 备份重要的一些数据表。
自定义备份：可以指定备份那些表。这种方法比较灵活。如图 2 所示：
（2）其他选项:
使用扩展插入(Extended Insert)方式：
推荐选择“否”，选“是”可能会导致数据恢复的时候由于 SQL 语句过长而等问题，
两种方式优缺点对比：选“是”：备份数据会比较小；选“否”：备份数据的兼容性比较高。
分卷备份 - 文件长度限制(kb)：这个最好设置为 2048 ，因为这样会减少恢复数据的时候的超时等问题。
备份文件名称：这个可以设置一个唯一的备份名称即可。
填写好上面对应的选项后就可以备份了。
2、数据库恢复
在数据库备份的又上角有一恢复备份的链接，如图 3 所示：
点击链接后，进去可以看到恢复的选项，如图 5 所示：
恢复备份的数据来源，可以有两个方式，方式一是从本地提供sql文件来恢复。即从本地的电脑上的备份数据恢复到服务器数据库里面。这个方式直接选择本地的备份文件上传提交即可。
从服务器备份来恢复数据，这个 比较方便，重要选择你需要恢复的备份，选择第一卷的导入操作，就可以自动完成恢复。
篇7：sybase数据库恢复
使用load database加载备份到现有数据库，数据库可以是用于创建转储的数据库，也可以不是，语法为：
load database 数据库名 from 转储设备名/物理文件名
load transaction数据库名 from 转储设备名/物理文件名
●利用备份恢复数据库举例：
某数据库数据和日志分别存储在两个独立的磁盘上，正常运转时的执行的备份计划如下，每天的17:00执行整个数据库的备份，每天的10:00、12:00、14:00、16:00点执行增量备份：
周一17:00磁带1（100M）周二10:00磁带2（30M）周二12:00磁带3（30M）周二14:00磁带4（30M）周二16:00磁带5（30M）周二17:00磁带6（30M）
DumpdatabaseDumptransactionDumptransactionDumptransactionDumptransactionDumpdatabase
若数据磁盘在周二的下午六点损坏，可以采用如下步骤恢复数据库：
（1）使用dump transaction with no_truncate获得当前的事务日志转储，磁带7；
（2）使用load database转载最新的数据库转储，磁带6；（offline）
（3）使用load transaction提交最新的事务日志转储，磁带7；
（4）使用online database把数据库状态设置为online，
若数据磁盘在周二的下午4:50损坏，恢复过程如下：
（1）使用dump transaction with no_truncate获得当前的事务日志转储，磁带7；
（2）使用load database转载最新的数据库转储，磁带6；（offline）
（3）使用load transaction依次装载磁带2、3、4、5上的事务日志；
（4）使用load transaction提交最新的事务日志转储，磁带7；
（5）使用online database把数据库状态设置为online。
★ 存储过程实现分页
【靠BCP恢复SQL Server 数据库备份恢复（整理7篇）】相关文章：
数据库工程师工作的职责2023-03-16
基于IBMTivoliTSM系统构建某局备份系统实施方案2023-08-29
基于Client/Server 的课件系统的设计与实现2023-03-13
数据库实训总结2024-01-27
计算机三级数据库技术考前基础训练题2022-09-12
优化其索引的小技巧数据库教程2022-12-31
网络信息安全自查报告2024-01-25
医院BS结构信息管理系统分析论文2023-05-22
信息安全解决方案2022-09-13
旅游管理信息系统设计应用论文2022-09-24