SQL Server 2012完全备份.差异备份.事务日志备份和还原操作: 1.首先,建立一个测试数据库,TestA:添加一张表,录入二条数据:备份操作这里我就不详细截图和讲解了.相信大家都会备份,我只是作了区别,TestA-full.bak.TestA-diff.bak.Test-log.bak. 2.然后再进行TestA数据库的完全备份的还原:这里的TestA,只是我测试用的,实际以你自己的数据库名为准. 3.还原数据库的“选项”页,需要选择的地方进行标识: 4.现在还原状态一直处于正在还原

SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志 作者:Tony Davis,2012/01/27 翻译:赖慧芳 译文: 该系列   本文是Stairway系列的一部分:SQL Server中事务日志管理的阶梯 当事情进展顺利时,没有必要特别注意事务日志的功能或工作方式. 您只需要确信每个数据库都有正确的备份机制. 当出现问题时,了解事务日志对于采取纠正措施非常重要,尤其是在需要对数据库进行时间点恢复时! 托尼戴维斯给出了每个DBA应该知道的正确程度的细节. 在此级别中,

SQL Server中事务日志管理的步骤,第5级:完全恢复模式管理日志 作者:Tony Davis,2012/01/27 系列 本文是进阶系列的一部分:SQL Server中事务日志管理的步骤 当事情进展顺利时,无需特别注意事务日志的作用或工作方式.您只需要确信每个数据库都有正确的备份机制.当出现问题时,了解事务日志对于采取纠正措施很重要,特别是在需要紧急恢复数据库的时间点时!Tony Davis给出了每个DBA都应该知道的正确的细节级别. 在此级别中,我们将回顾在完全恢复模式下工作时进行日志备

简介 本文将介绍SQL Server的事务日志中记录了哪一些信息,如何来读懂这些事务日志中信息.首先介绍一个微软没有公开的函数fn_dblog,在文章的接下来的部分主要用到这个函数来读取事务日志. fn_dblog(@StartingLSN,@EndingLSN) --@StartingLSN:表示起始的LSN号,如果为NULL值则表示从首日志记录开始查询. --@EndingLSN:表示结束的LSN号,如果为NULL值则表示查询到尾日志记录. --需要注意的是我们平时所看到的LSN都是十六进制

原文:http://blog.csdn.net/tjvictor/article/details/5251463     日志序列编号(LSN)是事务日志里面每条记录的编号. 当你执行一次备份时,一些LSN值就被同时存储在文件本身及msdb..backupset表中.你可以使用RESTORE HEADERONLY语法来从备份文件中获取LSN值.   注意:在SQL Server 2000中,有一列叫做DifferentialBaseLSN.但在SQL Server 2005中,相同的列名称变成了

原文 原文:http://blog.csdn.net/tjvictor/article/details/5251351   如果你的数据库运行在完整或是批量日志恢复模式下,那么你就需要使用作业(job)来定期备份事务日志,保持你的事务文件大小处在一个可管理的范围.当你需要还原事务日志时,你就需要按照创建事务日志的顺序来恢复它们.你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序,使用FirstLSN和LastLSN列的值作参考.当你备份时,这些备份信息就会存在backup

1 基本介绍 每个数据库都具有事务日志,用于记录所有事物以及每个事物对数据库所作的操作. 日志的记录形式需要根据数据库的恢复模式来确定,数据库恢复模式有三种: 完整模式,完全记录事物日志,需要定期进行日志备份. 大容量日志模式,适用于批量操作的数据库,可以以更压缩的方式处理日志,需要定期进行日志备份. 简单模式,也有日志文件,只是该模式下可以通过checkpoint自动重用virtual log file,所以日志文件会处于一直重复使用的过程,保持一定大小,但是,如果有一个事务启动,很久没有co

原文:http://blog.csdn.net/tjvictor/article/details/5256906   事务日志结尾经常提交数据库未备份的事务日志内容.基本上,每一次你执行事务日志备份时,你都在执行事务日志结尾的备份. 那为什么会这么设计呢?因为也许由于介质的损坏,当数据库已经不再可用时,麻烦就来了.如果下一个逻辑步骤正好就是要备份当前事务日志的话,可以应用这个备份来使数据库处于等待(Standby)状态.你甚至可以在数据库文件不可用的状态下使用NO_TRUNCATE来备份事务日志

由于SQL2008对文件和日志管理进行了优化,所以以下语句在SQL2005中可以运行但在SQL2008中已经被取消:(SQL2005) Backup Log DataBaseName with no_log go dump transaction DataBaseName with no_log go USE DataBaseName ) Go (SQL2008):在SQL2008中清除日志就必须在简单模式下进行,等清除动作完毕再调回到完全模式. USE[master] GO ALTER DAT

原文:SQL Server高可用--日志传送(4-3)--使用 顺接上一篇:SQL Server高可用--日志传送(4-2)--部署 本文为本系列最重要的一篇,讲述如何使用日志传送及一些注意事项.从上一篇可以看到,其实配置不难,难是难在一旦出现问题,如何处理.这些是4大高可用的同性.配置都不会很难,只是如何故障排除而已. 监控日志传送: 在配置好日志传送之后,需要进行监控,监控备份.复制及还原的作业运作情况.这三类作业任何一个没有成功都意味着日志传送失败. 有两种方法可以监控辅助服务器是否与主服

原文:SQL Server高可用--日志传送(4-1)--概论 本文作为学习总结,部分内容出自联机丛书及其他书籍 日志传送是什么? SQLServer 2012之前(2012出现了AlwaysOn),SQLServer存在四大高可用(集群/群集.日志传送.镜像和复制).本主题主要讨论其中的日志传送功能.但是由于工作原因,只能谈论到使用级别,不做太深入的研究. 现在先来说说日志传送(Log Shipping)是什么? 它是高可用的其中一种,可以搭配其他高可用实现更有效的备份机制.而且从2000(2

2000现在用的估计不多了,把之前收集的一些复制问题整理发布出来.可能都是些很白很二的问题,但人总是由最初的无知不断成长●-● SQL Server 2000事务复制问题服务器A(发布) 服务器B(分发+订阅)1.创建发布时对表identity属性问题因为该发布不允许使用可更新的订阅,当 IDENTITY 列被传输到订阅服务器时,不会传输 IDENTITY 属性.(例如,在发布服务器上定义为 INT IDENTITY 的列在订阅服务器上将定义为 INT.)如果想将 IDENTITY 属性传输到订

SQL Server无法收缩日志文件 2 因为逻辑日志文件的总数不能少于 2问题 最近服务器执行收缩日志文件大小的job老是报错 我所用的一个批量收缩日志脚本 USE [master] GO /****** Object: StoredProcedure [dbo].[ShrinkUser_DATABASESLogFile] Script Date: 01/05/2016 09:52:39 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON

  随着公司业务的发展,数据量增长迅速,在解决Scale Out的同时,还要考虑到主从的复制延迟问题,尽量降到1s以内满足线上业务,如果不调整,SQL Server默认的配置可能平均要3s左右.生产的复制架构采用的是推送方式进行事务复制,发布服务器下面有4个从节点,两两指向同一虚拟IP,构成负载均衡,服务于不同的线上业务.对于4个节点,发布库和分法库的压力都很大,订阅库每秒I/O能达到5M,高峰时能达到数十兆.研究并试验了一些时间,给出一些优化建议: 1.硬件.数据库设计: 使用SSD磁盘,有钱

SQL Server 2008 收缩日志 清空删除大日志文件 由于SQL2008对文件和日志管理进行了优化,所以以下语句在SQL2005中可以运行但在SQL2008中已经被取消:(SQL2005)Backup Log DNName with no_loggodump transaction DNName with no_loggoUSE DNNameDBCC SHRINKFILE (2)Go-----------------------------------------------------

1.当数据库已经建好在DB里,SQL Server 2005 和 SQL Server 2008使用.Bak文件还原的时候,会出现 error : "The backup set holds a backup of a database other than the existing" 查了网上的方法: 方法一[未验证] [sql] view plaincopy --返回由备份集内包含的数据库和日志文件列表组成的结果集. --主要获得逻辑文件名 --返回由备份集内包含的数据库和日志文件

一.背景 在复制的运用场景中,事务发布是使用最为广泛的,我遇到这样一个场景:在Task数据库中有Basic与Group两个表,需要提供这两个表的部分字段给其它程序读取放入缓存,程序需要比较及时的获取到这些数据,作为DBA你需要从权限和性能控制的角度出发,我采用了SQL Server的事务复制技术和timestamp,下面只讲述事务复制的搭建过程: 二.实现过程 (一) 环境信息 系统环境:Windows Server 2008 + SQL Server 2008 R2 发布服务器:192.168

原文:SQL Server 2008收缩日志文件--dbcc shrinkfile参数说明 DBCC SHRINKFILE 收缩相关数据库的指定数据文件或日志文件大小. 语法 DBCC SHRINKFILE     ( { file_name | file_id }         { [ ,target_size ]             | [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]         }     ) 参数 file_nam

    在SQL Server中,利用日志的WAL来保证关系数据库的持久性,但由于硬盘的特性,不可能使得每生成一条日志,就直接向磁盘写一次,因此日志会被缓存起来,到一定数据量才会写入磁盘.这部分已经生成的,却没有写入磁盘的日志,就是所谓的In-Flight日志.     在SQL Server中,In-Flight的日志的大小取决于两个因素,根据Paul Randal的说法,In-Flight日志不能超过60K,因此In-Flight的日志最大是60K,此外,如果In-Flight日志没有到60

事务是什么 在SQL Server中事务是构成一个工作逻辑单元的一系列任务,也就说多个任务放在一起执行,这些任务要么全部执行成功,要么全部执行失败. 通过事务我们可以保证数据的完整性,例如:用户A给用户B转1000块钱,如果从用户A的账号中扣了1000块,但是在向用户B账号添加1000块的时候执行失败,这个时候用户A说自己转了,用户B却有没收到,两个还不得打起来.所以针对于这种情况,需要使用事务,其中从用户A账号扣除1000块钱是一个任务,向用户B账号添加1000块是另一个任务,这两个任务如果都

BEGIN DISTRIBUTED TRANSACTION指定一个由 Microsoft 分布式事务处理协调器 (MS DTC) 管理的 Transact-SQL 分布式事务的起始. 语法BEGIN DISTRIBUTED TRAN [ SACTION ] [ transaction_name | @tran_name_variable ] 参数transaction_name 是用户定义的事务名,用于跟踪 MS DTC 实用工具中的分布式事务.transaction_name 必须符合标识符规