sqlserver数据库表数据误删除了 怎么恢复

恢复sqlserver数据库表数据步骤如下：

一、心态：

1、务必冷静，事情已经发生不可慌乱。

2、立即查看当前时间，最好能够精确到秒,并做记录。

3、应立即向直接上级反映此事，不可隐瞒，防止事态扩大。

4、如果权限允许，应当立即停止相关应用，防止有新的数据写入数据库。

二、恢复：

1、构建新数据库以及写入一些数据

2、做一次完整备份，这个是前提，没有一份完整备份文件是无法进行接下来的 *** 作的。

注意：如上图所示，恢复模式一定要说完整，如果是其他类型那恐怕就没有下文了。一般来讲新建数据库的时候，默认不要去改恢复模式这个属性。

3、写入一条新数据。

4、记住此时要记录时间点。

此刻最好看一下系统时间。接下来就要演示如何进行数据恢复。

5、做事务日志备份，做事务日志备份需要注意一下一点，如图所示。

备份模式请选择事务日志，备份路径自行决定

进入选项，将可靠性第1、2勾选，事务日志选择第二个，压缩属性可以不选择点击确定备份成功，此时数据库将显示为正在还原状态

注意：如果备份失败，请检查该数据库是否正在被占用，如果是请kill。

6、还原完整备份。

数据库处于正在还原状态，右键数据库--任务--还原--文件和文件组，选择最近的一次完整备份。此时，需要在“选项”中选择第二种还原方式，具体如下图。

如上图，勾选完整数据备份文件。

如上图，恢复状态选择第二种，从字面意思就知道为什么要选择这种。

7、接着还原备份的事务日志。

完整备份还原完毕，接着要对事务日志进行还原，右键数据库--任务--还原--事务日志，如下图：

还原事务日志的时候需要特别注意“时间点”这个设置，其他不需要设置。

时间点选择为误删数据的时间点之前就可以恢复出误删的数据，所以之前强调要查看一下时间。如下图所示

点击确定，在确定等待还原成功，数据库变成可用状态。如下图。

如果查询发现数据不是你想要的，那么可以重复上述的 *** 作，从备份事务日志开始，然后最后选择时间点的时候在缩小范围。

按照正常的数据库备份 *** 作备份一下数据库，然后按照后面的 *** 作只还原数据文件 A． 我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

B． 停掉数据库服务器。

C． 将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。

D． 启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

E． 设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates ',1

go

reconfigure with override

go

F． 设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID( 'text ')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

G． 下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log( 'text ', 'D:\MSSQL7\Data\text_logldf ')

执行过程中，如果遇到下列提示信息：

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

未能排它地锁定数据库以执行该 *** 作。

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

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了text库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test ' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

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

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

H． 验证数据库一致性（可省略）

dbcc checkdb( 'text ')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test ' 中）。

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

I． 设置数据库为正常状态

sp_dboption 'text ', 'dbo use only ', 'false '

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

J． 最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates ',0

go

reconfigure with override

go

SQL Server中误删除数据的恢复本来不是件难事，从事务日志恢复即可。但是，这个恢复需要有两个前提条件：

1 至少有一个误删除之前的数据库完全备份。

2 数据库的恢复模式（Recovery mode）是“完整（Full）”。

针对这两个前提条件，会有三种情况：

情况一、如果这两个前提条件都存在，通过SQL语句只需三步就能恢复（参考文章），无需借助第三方工具。

a) 备份当前数据库的事务日志：BACKUP LOG [数据库名] TO disk= N'备份文件名' WITH NORECOVERY

b) 恢复一个误删除之前的完全备份：RESTORE DATABASE [数据库名] FROM DISK = N'完全备份文件名' WITH NORECOVERY, REPLACE

c) 将数据库恢复至误删除之前的时间点：RESTORE LOG [数据库] FROM DISK = N'第一步的日志备份文件名' WITH STOPAT = N'误删除之前的时间点' , RECOVERY

情况二、如果第1个前提条件不存在，第2个前提条件存在，需要借助第三方工具。

情况三、如果第2个前提条件不存在，无法恢复。所以，一定要将数据库恢复模式设置为“完整（Full）”。

我现在面临的是第二种情况，需要找第三方工具。

开始找的是Log Explorer for SQL Server，不支持SQL Server 2008。

后来找的是SQL Log Rescue，也不支持SQL Server 2008。

接着找到的是SysTools SQL Recovery，支持SQL Server 2008，但需要购买，Demo版并没有数据恢复功能。

最终在officerecoverycom上找到Recovery for SQL Server，虽然也是商业软件，需要购买，但Demo版可以恢复数据，只要数据库文件不超过24Gb。幸好朋友的数据库文件不大，用它完成了误删除数据的恢复。

下面分享一下用Recovery for SQL Server进行恢复的 *** 作步骤：

1 运行Recovery for SQL Server

2 点击菜单中的 File > Recover，选择要恢复的数据库的数据文件（mdf）

3 Next > Next，进入 Recovery Configuration 界面，选择Custom（选择了Custom才可以选择从日志中恢复误删除的数据）。

4 Next 进入 Recovery options 窗口，选中 Search for deleted records，并选择要恢复的数据库的日志文件路径（log file path）。

5 Next 并选择目标文件夹（Destination folder），用于存放恢复过程中生成的SQL语句与bat文件。

6 点击Start，开始恢复 *** 作（在上一步选择的目标文件夹中生成相应的SQL文件与Bat文件），然后，出现 SQL Server Database Creation Utility 窗口。

7 Next，选择被恢复数据存放的目标数据库。

8 Next, 选择 Import availiable data from both database and log files

9 Next, Next, 然后就完成数据的恢复！

管理员可以选择在运行时对系统的影响最小，同时又能满足还原要求的备份过程。管理员还根据资源要求选择数据库的恢复模式。恢复模式将针对完全恢复数据的重要程度来平衡记录开销。恢复模式包括：

◆完全

数据非常重要并且必须能够恢复到故障点。记录所有的数据修改。可使用SQL Server 2000的所有恢复选项。

◆大容量日志记录

如有必要，可重播某些大容量 *** 作（大容量复制 *** 作、select INTO、文本处理），因此不完全记录这些 *** 作。只能恢复到上一次数据库或日志备份的末尾。

◆简单

自上次备份后所做的所有数据更改都是可替代的，或是可重做的。记录开销最小，但不能恢复自上次备份结束后的内容。

SQL Server数据库有三种恢复模式：简单恢复模式、完整恢复模式和大容量日志恢复模式。

Simple 简单恢复模式,

Simple模式的旧称叫”Checkpoint with truncate log“，其实这个名字更形象，在Simple模式下，SQL Server会在每次checkpoint或backup之后自动截断log，也就是丢弃所有的inactive log records，仅保留用于实例启动时自动发生的instance recovery所需的少量log，这样做的好处是log文件非常小，不需要DBA去维护、备份log，但坏处也是显而易见的，就是一旦数据库出现异常，需要恢复时，最多只能恢复到上一次的备份，无法恢复到最近可用状态，因为log丢失了。

Simple模式主要用于非critical的业务，比如开发库和测试库，但是道富这边的SQL Server（即使是生产库）大都采用Simple模式，是因为这边的SQL Server大都用于非critical的业务（critical的数据库大都采用Oracle和DB2)，可以忍受少于1天的数据丢失(我们的job每天都会定时备份全库）。

Full 完整恢复模式,

和Simple模式相反，Full模式的旧称叫”Checkpoint without truncate log“，也就是SQL Server不主动截断log，只有备份log之后，才可以截断log，否则log文件会一直增大，直到撑爆硬盘，因此需要部署一个job定时备份log。Full的好处是可以做point-in-time恢复，最大限度的保证数据不丢失，一般用于critical的业务环境里。缺点就是DBA需要维护log，增加人员成本（其实也就是多了定时备份log这项工作而已）。

Bulk-logged 大容量日志恢复

Bulk-logged模式和full模式类似，唯一的不同是针对以下Bulk *** 作，会产生尽量少的log：

1) Bulk load operations (bcp and BULK INSERT)

2) SELECT INTO

3) Create/drop/rebuild index

众所周知，通常bulk *** 作会产生大量的log，对SQL Server的性能有较大影响，bulk-logged模式的作用就在于降低这种性能影响，并防止log文件过分增长，但是它的问题是无法point-in-time恢复到包含bulk-logged record的这段时间。

Bulk-logged模式的最佳实践方案是在做bulk *** 作之前切换到bulk-logged，在bulk *** 作结束之后马上切换回full模式。

数据库中的数据被删除后，可以恢复。但至少需要满足两个条件：

1、在误删之前，至少有完整备份之前的数据库。

2、数据库的恢复模式（Recoverymode）是“完整（Full）”。

只有满足这两个条件，才可以恢复数据库中误删的数据。

针对这两个前提条件，有三种方式可以恢复数据：

方式一：如果，这两个前提条件都满足，可以通过SQL语句进行数据恢复，而且只需三步即可恢删除的数据，无需第三方工具。

方式二：当不满足第一个条件，而满足第二个条件时，需要借助第三方工具，才能恢复数据。

方式三：如果两个条件都不满足，数据则无法恢复。所以，一定将数据库的恢复模式，调整为“完整（Full）”。

以上就是关于sqlserver数据库表数据误删除了 怎么恢复全部的内容，包括:sqlserver数据库表数据误删除了 怎么恢复、SQL数据库完整恢复模式下恢复数据库、如何还原sqlserver数据库等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！