想了解SQLServer2008以上误操作数据库恢复方法——日志尾部备份的新动态吗？本文将为您提供详细的信息，我们还将为您解答关于sqlserver2008日志满了怎么办的相关问题，此外，我们还将为您

想了解SQLServer 2008以上误操作数据库恢复方法——日志尾部备份的新动态吗？本文将为您提供详细的信息，我们还将为您解答关于sql server 2008日志满了怎么办的相关问题，此外，我们还将为您介绍关于SQL Server 2008 及更高版本数据库恢复方法之日志尾部备份、SQL server 2008 数据安全(备份和恢复数据库)、SQL Server 2008/2012 完整数据库备份+差异备份+事务日志备份 数据库完整还原（一）、SQL server 2008R2 操作数据库表命令的新知识。

• SQLServer 2008以上误操作数据库恢复方法——日志尾部备份（sql server 2008日志满了怎么办）
• SQL Server 2008 及更高版本数据库恢复方法之日志尾部备份
• SQL server 2008 数据安全(备份和恢复数据库)
• SQL Server 2008/2012 完整数据库备份+差异备份+事务日志备份 数据库完整还原（一）
• SQL server 2008R2 操作数据库表命令

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份（sql server 2008日志满了怎么办）

如果发现备份不了可以用下面语句查看，并把spid杀掉：

SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID('AdventureWorks')  

SQL Server 2008 及更高版本数据库恢复方法之日志尾部备份

 经常看到有人误删数据，或者误操作，特别是 update 和 delete 的时候没有加 where，然后就喊爹喊娘了。人非圣贤孰能无过，做错可以理解，但不能纵容，这个以后再说，现在先来解决问题。

        遇到这种情况，一般都是没有做备份，不然也不会来发问了。首先要冷静，否则会有更大的灾难。直到你放弃。

解决方法：

       对于这类问题，主要是找回误操作之前的数据，在 2008 之前，有个很出名的工具 Log Exploer，听说还挺好用的，这个网上大把教程，这里就不多说了。但是唯一遗憾的是，不支持 2008 及更高版本，这时除了其他第三方工具，那么最常用的就是本文提到的方法 —— 日志尾部备份。本文实验环境 2008R2，对于 2008 及其以上版本可以使用这个方法，其实 2005 也可以，2000 很少用，没试过，只是 2008 之前可以使用 Log Exploer，所以就没必要用这种方法。

      下面图文并茂讲解操作方法，至于原理，不属于本文范围，而且我相信真遇到误操作的时候，估计没人会看原理了。

步骤：

（1）、检查数据库的恢复模式，如图：

或者使用脚本检查：

SELECT recovery_model,recovery_model_desc 
FROM sys.databases 
WHERE name =''

结果如下：

        确保数据库的恢复模式最起码不能为【简单】。至于如何修改成完整模式，我觉得这些应该没必要多说了。 

       切记，对于任何重要环境，不仅仅是客户正式环境（俗称生产环境），都强烈建议使用【完整恢复模式】，虽然对于另外两种（大容量日志（BULK_LOGGED）、简单（SIMPLE））来说，完整恢复模式产生的日志会大，但是在出现问题的时候，就会觉得这些都不算什么了。并且我也想不到任何理由对于正式环境不使用完整恢复模式。只要管理得当，完整恢复模式的日志也不会太变态。 

（2）、这里其实隐含另外一步，曾经做过最少一次的完整备份。因为所有类型的备份都基于完整备份，如果没有最少一次完整备份，其他类型的备份都是多余的，所以在这里强调一下，在创建完一个新数据库之后，强烈建议甚至强制做一次完整备份。

SELECT database_name,recovery_model,name
FROM ms

使用上面的语句粗略可以看到有那些数据库做过备份，由于测试，所以做了几次备份，可以看到我这个时间点已经做了备份了。

（3）、确保别人不再连接数据库，然后做一次日志尾部备份：

首先先创建一点数据：

由于 tempdb 永远为简单恢复模式，所以不适合做案例。 
这里使用微软的示例数据库 AdventureWorks 

*/ 
USE AdventureWorks 
GO 
IF OBJECT_ID(''testRestore'') IS NOT NULL
 DROP TABLE testRestore 
GO 
CREATE TABLE testRestore 
 ( 
  id INT IDENTITY(1, 1) , 
  NAME VARCHAR(50) 
 ); 
--插入测试数据：  
INSERT INTO testRestore(Name) 
SELECT ''test1''
UNION ALL
SELECT ''test2''
UNION ALL
SELECT ''test3''
UNION ALL
SELECT ''test4''
UNION ALL
SELECT ''test5''
UNION ALL
SELECT ''test6''
UNION ALL
SELECT ''test7''
UNION ALL
SELECT ''test8''
SELECT * FROM testRestore 

检查一下结果：

然后来做个删除操作，为了定位是啥时候发生的，我加了一个 waitfor 命令，让它在某个时间发生，这样恢复的时候就有准确性：

USE AdventureWorks 
GO 
WAITFOR TIME ''21:45''
DELETE FROM dbo.testRestore

现在来看看数据：

USE AdventureWorks 
GO 
SELECT * FROM dbo.testRestore

到这一步，灾难出现了，但是切记要冷静。

下面就是本文的重点开始，做一次日志备份，最重要是选择【备份日志尾部】

然后在【选项】页选择：除【事务日志】除，其他红框包裹的地方为强烈建议勾选的地方。并且保证数据库不要有别人在连接，因为备份日志尾部会使数据库处于还原状态，拒绝其他会话的连接，如果不断开其他连接，是备份不了的。

然后按确定，当然，可以使用上方的【脚本】来生成语句：

USE Master 
GO 
BACKUP LOG [AdventureWorks] TO DISK = N''E:\AdventureWorks.bak'' WITH NO_TRUNCATE , NOFORMAT, NOINIT, NAME = N''AdventureWorks-事务日志 备份'', SKIP, NOREWIND, NOUNLOAD, NORECOVERY , COMPRESSION, STATS = 10, CHECKSUM 
GO 
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N''AdventureWorks'' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N''AdventureWorks'' ) 
if @backupSetId is null begin raiserror(N''验证失败。找不到数据库“AdventureWorks”的备份信息。'', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N''E:\AdventureWorks.bak'' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND 
GO 

此时，数据库会处于【正在还原】的状态

如果发现备份不了可以用下面语句查看，并把 spid 杀掉：

SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID(''AdventureWorks'') 

执行结果：

然后 kill 掉。

接着继续备份。

 然后进行还原，如图：

先要还原完整备份，选择最近的那次，由于日志备份的特性（以后其他文章再说），只认最后一次备份，所以要选择最新的那次，否则还原不了。

这里又有一个注意事项，记得选择：

接着还原日志文件，这是最最重要的一步：

然后：

由于实验的时候出了点问题，后面重做了，所以时间选择到 22：19 分，我是在 22：20 分删除数据的。这里不用太在意，只要把时间点指定到你误删除的时间之前即可。而由于日志尾部备份都是最后一个备份文件，所以这里选则红框部分即可：

现在再检查一下：

可以看到，数据已经还原成功。

总结：

平时不做备份，出问题来喊急，这是苟有自取，还有一些脑袋发热的人喜欢看到 ldf 很大就直接删除，那以后出问题就别怪微软了。

本文中的方法看上去有点繁琐，但是实操几次就觉得好了，但是步骤建议严格按照上面说的，因为一旦操作错误，就很麻烦，此时再次强调 —— 冷静冷静再冷静！！！！！！

这种方法有几个缺点：

1、如果你发现误操作以后还有很多人做了操作，那么你还原成功后，别人的操作就会冲掉，所以发生误操作后，要马上停止别人对数据库的操作。

2、 这个方法要对数据库独占，所以你想偷偷恢复是不行的了。勇敢承认错误吧。

对于核心数据表，还是要先做好预防操作，可以看：SQLServer 恢复表级数据。

SQL server 2008 数据安全(备份和恢复数据库)

备份和恢复数据库对于数据库管理员来说是保证数据安全性的一项重要工作。SQL server 2008提供了高性能的备份和恢复功能，可以实现多种方式的数据库备份和恢复操作，避免了由于各种故障造成的损失而丢失数据

下边是我对部分内容的总结，里边偏向了T-SQL语句实现的总结，对于SQL Server Management Studio中对象管理器的操作并没有太多的总结，因为这些都有一些向导，而且，大部分都是在对应的节点，右击找相应的操作，相应的对象，然后根基向导去操作！

首先是大概知识点的总结：

下边是一些T-SQL语句对应的总结，1，管理备份设备的语句：

2，备份的语句：

3，数据恢复的对应语句：

最后，

上边讲到了备份有完全备份,差异备份,事务日志备份和文件组和数据文件备份,恢复有简单恢复，简单恢复，大容量日志恢复。但是这四种备份方式有什么不同呢,有什么各自的用处呢?这三种恢复又需要什么条件呢？这里,我给大家剖析一下:

备份：

1,完全备份:备份内容,包括备份数据库中的所有数据,文件组或数据文件;适用类型:对于小型数据库和中型数据库,完全备份是最常用的技术.缺点:此过程非常耗时,一旦开始备份就不能中途停止.

2,差异备份:备份内容:记录自最后一次去备份以来改变的数据;适用类型:使用于进行过完全备份的数据库;缺点:还原时非常耗时,还原需要还原最后一次完全备份和以后所有的差异备份.

3,事务日志备份:备份内容,备份数据库中已经完成的事务,实现了备份可以真正灵活的时间点恢复;适用类型:数据库处于完全恢复和大容量日志恢复模式;

4,文件组备份:内容,对于与数据库中某个文件有关的所有数据文件的备份.类似于完全备份,但可以是小分支的备份.例如,可以备份一个公司中一个部门或工作组的备份.

5,数据文件备份:内容,只对文件组中的一个文件进行备份,同单独还原一个数据文件的功能协同工作.优点,时间短,可以选择性的备份数据库中的某些文件.

恢复：

1，简单恢复：需要：进行数据库恢复时仅使用数据库备份和差异备份而不涉及事务日志备份。效果：可以恢复到上一次备份的状态，但无法恢复到失败点的状态。

2，完全恢复：需要，采用数据库备份，差异备份和事务日志备份来恢复到失败点的时刻，需要将所有的数据库操作都写入到日志文件中；效果，不造成任何损失。

3，大容量日志备份：需要，和完全备份基本相同；效果，在性能上要优于上边两种方式，它最大努力减少了批操作所需要的存储空间。

SQL Server 2008/2012 完整数据库备份+差异备份+事务日志备份 数据库完整还原（一）

还原方案

数据库级（数据库完整还原）

还原和恢复整个数据库。数据库在还原和恢复操作期间会处于离线状态。SQL SERVER不允许用户备份或还原单个表。还原方案是指从一个或多个备份中还原数据、继而恢复数据库的过程。

不同恢复模式所支持的各种还原方案

简单恢复模式下

这是基本的还原策略，数据库完整还原可能涉及完整数据库备份的简单还原和恢复。另外，完整的数据库还原还可能涉及还原完整数据库备份，以及还原和恢复差异备份

完整/大容量日志恢复模式下

这是基本的还原策略，数据库完整还原涉及还原完整数据库备份或差异备份，以及所有后续日志备份（按顺序）。通过恢复并还原上一次日志备份，完成数据库完整还原。

在恢复数据库前，SQL Server 数据库引擎都会保证整个数据库在逻辑上的一致性。例如，还原一个文件以后，必须恢复完整的一套日志文件备份，以便将该文件里的事务前滚足够长度，与数据库保持一致，才能恢复该文件并使其在线。

数据库完整还原

在简单情况下，还原操作只需要一个完整数据库备份，一个差异数据库备份和后续日志备份。

数据库还原到故障点操作步骤

1. 首先备份活动事务日志（日志的”尾部“）
2. 按备份的创建顺序还原最新的完整数据库备份，最新的差异备份（如果有）及所有后续日志备份

若源数据库是简单模式，则没有相应的日志备份。恢复工作仅限于还原一个完整数据库备份，以及最后的一个差异备份。

数据库发生灾难后，如何将之恢复到一个特定的恢复点

• 场景

一个关键数据表被人在中午 12 点 01 份误删，如何将其恢复到 12 点的那个状态呢？

• 解决方案 通过恢复日志文件到指定恢复点的方式来实现。有以下几个先决要求，而且是要在灾难发生之前，数据库就必须满足以下所有条件：

1. 数据库的恢复模式必须是完整恢复模式
2. 灾难发生前，数据库曾做过一个完整数据库备份
3. 在上次完整数据库备份后，若做过任何日志备份，这些日志备份现在每个都能找到。

符合以上三个要求的数据库就可以使用备份恢复方法将数据库恢复到完整备份后的任意一个时间点。

将数据库恢复到故障点的基本步骤如下：

1. 备份活动事务日志（也称为日志尾部）。此操作将创建尾日志备份。如果活动事务日志在灾难发生后变得不可用，则该日志部分的所有事务都将丢失。
2. 还原最新完整数据库备份，而且不做事务恢复
3. 如果存在差异备份，则还原最新的差异备份，而不做事务恢复
4. 从还原备份后创建的第一个事务日志备份开始，使用 NORECOVER 依次还原日志
5. 恢复数据库到某个时间点(RESTORE DATABASE database_name with stopat=''???'', RECOVERY)

完整数据库备份+差异备份+事务日志备份 示例

示例前准备 清空表 msdb..backupset 上 2018/09/28 之前的记录，注意时间

USE msdb;  
GO  
EXEC sp_delete_backuphistory @oldest_date = ''09/28/2018'';  

将 AdventureWorksDW2018 库的恢复模式修改为完整恢复模式，否则会报 4208 错误

USE master ;  
ALTER DATABASE AdventureWorksDW2018 SET RECOVERY FULL ;

-- 显示 AdventureWorksDW2018 这个数据库历史上曾经的备份信息。
use msdb;
select distinct s.first_lsn, s.last_lsn,
                s.database_backup_lsn, s.backup_start_date, s.backup_finish_date,
				s.type, y.physical_device_name 
  from msdb..backupset s inner join 
       msdb..backupfile f on f.backup_set_id = s.backup_set_id inner join
	   msdb..backupmediaset m on s.media_set_id = m.media_set_id inner join
	   msdb..backupmediafamily y on m.media_set_id = y.media_set_id
 where (s.database_name = ''AdventureWorksDW2018'')
 order by s.backup_finish_date desc;

示例操作内容

将创建 AdventureWorksDW2018 数据库的尾日志备份，将还原较早的完整数据库备份和日志备份，最后还原尾日志备份。事务恢复动作将在最后的尾日志恢复步骤中完成，在此之前数据库不能被访问。

1. 对数据库做一个全备份

   	BACKUP DATABASE [AdventureWorksDW2018] TO DISK=''F:\backup\AdvFull1.bak''
   

2. 对数据库做一个操作，然后做一个日志备份

   	  --drop table t2;
   	  use AdventureWorksDW2018;
   	  create table t2(number int, name nvarchar(50));
   	  insert into t2 values(1, ''a'');
   	  go 
   	  BACKUP LOG [AdventureWorksDW2018] TO DISK=''F:\backup\AdvLog2.bak''
   

3. 对数据库做一个操作

   	  use AdventureWorksDW2018;
   	  insert into t2 values(2, ''b'');
   	  go
   

4. 此时灾难发生，试图创建一个尾日志备份

   	use master
   	backup log [AdventureWorksDW2018] to disk = ''F:\backup\AdvLogTail.bak'' with norecovery;
   	go
   

5. 删除 AdventureWorksDW2018 数据库

   	drop database [AdventureWorksDW2018];
   

6. 从备份恢复一个全备份

   	restore database [AdventureWorksDW2018] from disk = ''F:\backup\AdvFull1.bak'' with norecovery;
   

7. 从备份中恢复一个正常的日志备份

   	restore log [AdventureWorksDW2018] from DISK=''F:\backup\AdvLog2.bak'' with norecovery;
   

8. 用 STOPAT 恢复尾日志文件

   	restore log [AdventureWorksDW2018] from DISK=''F:\backup\AdvLogTail.bak'' with stopat = ''2018-09-27 16:23:00.000'', recovery;
   	go
   

9. 验证数据完整性

   	use AdventureWorksDW2018
   	select * from t2;
   

方案缺点 要做一次数据库的完整备份恢复，这在时间上和空间上都是代价高昂的

• 时间上 SQL Server 需要很长的时间来重建整个数据库。在此过程中，数据库是不能访问的。重建时间的长短基本由硬盘的速度决定。一个上TB的数据库做一个完整恢复可能需要近一天的时间，这个等待时间很多系统不能接受。

• 空间上 一个完整备份的大小和数据库已使用空间大小基本一致。若备份要放在硬盘上，需要硬盘能提供2倍的存储空间，一份放数据库，一份放备份。

参考资料

<<SQL Server 2012 实施与管理实战指南>>

SQL server 2008R2 操作数据库表命令

1.修改数据表字段长度语句：

ALTER TABLE tableName（表名） ALTER COLUMN columnName（字段名） VARCHAR(n（长度）)

2.DROP,TRUNCATE和DELETE的区别。

使用这3个命令时一定要谨慎，都是删除表数据的命令。

按删除实力分：第一、DROP；第二、TRUNCATE；第三、DELETE

无条件时都是删除表中的全部数据‘。TRUNCATE比DELECTE速度快，占用系统资源少。以下是详细区分：

DROP：命令DROP  TABLE tableName（表名）------删除内容和定义，释放空间。即删除整个表，包括表结构，数据，定义。无法回滚，恢复，要恢复只能重新新建一个表。非常暴力。

TRUNCATE：命令 TRUNCATE TABLE tableName（表名）------删除内容，释放空间但不删除定义结构，只清空表数据。保留表结构（字段），属性。所谓释放空间就是删除表的ID标识列，在插入数据时，标识列（ID）重新从1开始，DELETE是做不到的。

          a.TRUNCATE不能删除行数据，要删就清空整张表。

          b.删除数据速度来说，TRUNCATE三者中最快，属于DDL语言，将被隐式提交时若有ROLLBACK（回滚）命令， TRUNCATE不会被撤销（回滚），但DELETE可以。

          c.重新设置高水平线和所有的索引。在对整张表和索引进行完全浏览时，经过TRUNCATE操作后的表比DELETE操作后的表要快很多。

          d.TRUNCATE不能清空父表，不能触发任何DELETE触发器，当表被清空后表与表的索引将重新设置成初始大小，而DELETE则不能。

DELETE:命令DELETE TABLE tableName（表名）------也可以删除整个表数据，但是非常慢，系统是一行一行删除，效率低。后面可以跟条件，如：DELETE TABLE tableName（表名） WHERE (条件)  。只删除数据内容，不删除定义结构，不释放空间。

我们今天的关于SQLServer 2008以上误操作数据库恢复方法——日志尾部备份和sql server 2008日志满了怎么办的分享就到这里，谢谢您的阅读，如果想了解更多关于SQL Server 2008 及更高版本数据库恢复方法之日志尾部备份、SQL server 2008 数据安全(备份和恢复数据库)、SQL Server 2008/2012 完整数据库备份+差异备份+事务日志备份 数据库完整还原（一）、SQL server 2008R2 操作数据库表命令的相关信息，可以在本站进行搜索。