SQL Server误区:在破坏日志备份链后需要完整备份来重新开始日志链

误区 #20:在破坏日志备份链之后,需要一个完整备份来重新开始日志链

错误

事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话,那就从上一次完整备份开始)。有好几种类型的操作会中断事务日志的连续性,也就是说除非重新开始新的日志链,SQL Server无法再进行日志备份。下面这几种操作都有可能引起日志链断裂:

由完整恢复模式或大容量事务日志恢复模式转为简单恢复模式

从数据库镜像进行恢复

备份日志时指定了NO_LOG 或 WITH TRUNCATE_ONLY(还好在SQL Server 2008中这个选项被取消了)

更多请看:post BACKUP LOG WITH NO_LOG - use, abuse, and undocumented trace flags to stop it

通过下面的例子对此进行阐述:

CREATE DATABASE LogChainTest; GO ALTER DATABASE LogChainTest SET RECOVERY FULL; GO BACKUP DATABASE LogChainTest TO DISK = 'C:\SQLskills\LogChainTest.bck' WITH INIT; GO BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log1.bck' WITH INIT; GO ALTER DATABASE LogChainTest SET RECOVERY SIMPLE; GO ALTER DATABASE LogChainTest SET RECOVERY FULL; GO

结果是:

已为数据库 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)处理了 168 页。

已为数据库 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)处理了 2 页。

BACKUP DATABASE 成功处理了 170 页,花费 0.224 秒(5.916 MB/秒)。

已为数据库 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)处理了 3 页。

BACKUP LOG 成功处理了 3 页,花费 0.121 秒(0.137 MB/秒)。

我首先创建了一个数据库,将其设置为完整恢复模式,这个是日志链的起点,然后转为简单恢复模式,再转为完整恢复模式。

下面我再尝试进行日志备份

BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log2.bck' WITH INIT;

GO

则会得到如下报错信息:

消息 4214,级别 16,状态 1,第 1 行

无法执行 BACKUP LOG,因为当前没有数据库备份。

消息 3013,级别 16,状态 1,第 1 行

BACKUP LOG 正在异常终止。

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/SQLServer/

SQL Server已经记录了我破坏日志链的操作以及与进行日志 备份无法备份自上次日志备份以来所有的日志,所以SQL Server不允许我进行日志备份。

这个误区是说此时就需要完整备份才能恢复日志链,但实际上,我只需要做一个差异备份(这个差异备份的跨度超过日志链断裂的间隙),代码如下:

BACKUP DATABASE LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT, DIFFERENTIAL;

GO

BACKUP LOG LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT;

GO

得到的结果:

已为数据库 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)处理了 64 页。

已为数据库 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)处理了 1 页。

BACKUP DATABASE WITH DIFFERENTIAL 成功处理了 65 页,花费 0.119 秒(4.267 MB/秒)。

已为数据库 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)处理了 1 页。

BACKUP LOG 成功处理了 1 页,花费 0.052 秒(0.150 MB/秒)。

不得不说这种方式更Cool一些,因为你不再需要一个完整备份才能继续进行日志备份。

如果你的备份策略中包含了文件或是文件组的备份,你甚至只需要单个文件的差异备份就能继续进行日志备份。但前提是这个备份的跨度超过了断裂LSN的程度,当然这是更深的话题了。

又揭穿了一个误区!

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索数据库
, 日志
, 文件
, 备份
, 处理
, backup
, 处理log
日志链
sql server 2008、sql server、sql语句、sql server 2012、sql server 2005,以便于您获取更多的相关知识。

时间: 2024-10-03 13:58:27

SQL Server误区:在破坏日志备份链后需要完整备份来重新开始日志链的相关文章

SQL Server误区:在服务器故障转移后,正在运行的事务继续执行

误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

SQL Server误区30日谈 第7天 一个实例多个镜像和日志传送延迟_MsSql

误区 #7:一个数据库可以存在多个镜像 错误 这个误区就有点老生常谈了.每一个主体服务器只允许一个镜像服务器.如果你希望存在多个主体服务器的副本,那么请使用事务日志传送,事务日志传送允许针对每一个主体存在多个辅助实例. 使用事务日志传送的一个优点是允许其中一个或多个辅助服务器存在延迟还原备份.这也是就是说对主体服务器进行日志备份(无论你喜欢与否,这几种高可用性技术各自有各自的术语): 数据库镜像:主体服务器-镜像服务器 事务日志传送:主要服务器-辅助服务器 复制:发布服务器-订阅服务器 当使用镜

SQL Server误区:有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

SQL Server误区30日谈 第30天 有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区:26个有关还原(Restore)的误区

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步. 事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. Myth #24:26个有关还原(Restore)的误区 都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点 当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到

SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区_MsSql

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行_MsSql

误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

SQL Server误区:数据库镜像在故障发生后马上就能发现

误区10.数据库镜像在故障发生后,马上就能发现 错误 市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移. 但事实并不是这样,检测到故障发生的速度要取决于故障的类型. 检测故障发生的最快的情况是,镜像中的主体实例崩溃,从而镜像服务器每秒一次的PING就无法返回值,从而知道主体服务器上不再有这个进程侦听相应的TCP端口,这种情况下,镜像服务器几乎瞬间就能发现故障. 检测到故障发生第二快的情况是主体服务器的操作系统崩溃.此时主体服务器不再响应镜像服务器的PING,从而在镜像服