灰太狼的博客

在SQL Server中，除了系统数据库外，你创建的每一个数据库都有三种可供选择的恢复模型: Simple(简单), full(完整), bulk-logged(批量日志)。 下面这条语句可以显示出所有在线数据库的恢复模型:SELECT name, (SELECT DATABASEPROPERTYEX(name, RECOVERY)) RecoveryModel FROM master..sy

下图显示了数据库备份时文件读写的过程： 在备份期间，SQL Server会在数据库文件这边为每一盘符(Volume)创建一个读线程。读线程的工作很简单，就是从文件中的数据内容。每次这个线程都会从文件中读出部分数据，然后把数据存到缓冲中(buffer)。因为有多个缓冲可用，所以只要有缓冲可以写入数据，读线程可以不停的读数据。SQL Server也同时创建一个写线程，把缓冲中的数据写入磁盘或是

SQL Server在msdb数据中维护了一系列表，用来存储执行所有备份和还原的细节信息。即使你正在使用第三方的备份应用程序，只要这个应用程序使用SQL Server的虚拟设备接口(Virtual Device Interface---VDI)来执行备份和还原执行，那么执行细节依然被存储在这一系列表中。存储细节的表包括：backupset  backupfile  backup

如果能从备份文件中只恢复一个表的数据，那不是很好吗？比如，你备份了AdventureWorks数据库，现的你只恢复里面Vendor表数据。不幸的是，SQL Server本身并不支持这样还原，你需要从第三方提供的工具中来执行这样的任务。提供这种功能的程序都是一些SQL Server第三方备份工具。它们可以让你从备份文件中抽取或是读取单个表数据。但是这里有一点要注意是，假如你选择恢复一个完整数

对于一个数据库完整备份来说，备份的速度很大程度上取决于下面两个因素：读磁盘数据、日志文件的吞吐量，写磁盘数据文件的吞吐量。下图是备份过程中磁盘的变化情况： 读吞吐量读吞吐量的大小取决于磁盘读取数据的速度，而磁盘读取的速度又取决于数据文件在磁盘中的位置。因此，位于不同盘符上不同数据库文件的读取速度都不相同。测量读吞吐量的一个方法就是进行一次数据库完整备份，然后使用Windows性

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

当SQL Server截断事务日志时，它仅仅是在虚拟日志文件中做个标记，以便不再使用它，然后准备以重用形式来做备份(假如运载在完整或是批量日志恢复模型)。也就是说，在使用简单恢复模型时，事务日志包括如下的日志记录： 当checkpoint发生时，虚拟日志文件1、2不再被使用，因为事务1、2已经被提交了，而且日志记录也不再需要回滚了。然后SQL Server重用虚拟日志文件1、2，如下图：

事务日志里面“藏”着很多有用的信息。虽然SQL Server本身并没有提供分析工具，但是我们可以使用第三方工具来一探究竟。Red Gate软件提供了一款叫做SQL Log Rescue的免费工具，但是只支持SQL Server 2000。ApexSQL和Lumigent公司提供的两款软件分别叫做ApexSQL Log和Log Explorer，它们支持SQL Server7、2000和2005

你创建的每一个备份都是一个备份设备，关于它的细节信息都存储在msdb..backupset表中。一个备份设备可以被存储在单一文件，或是多个文件中。同样，一个文件也可以存储多个备份设备。所以，假如你每次备份都使用相同的文件名，文件就会一直增长。一个普遍的误解是：如果你每次使用相同的文件名，那旧的备份设备就会被覆盖。但事实却不是这样的。 那我们怎么分辨一个文件中是否包括多个备份设备呢？你可

你遇到的最糟糕的事莫过于备份文件无法还原数据库了。我这里并不是说缺少磁盘空间或者类似的事导致的无法还原，而是一个100%确认已经被损坏的备份文件。你会问，那我怎么办呢？别着急，SQL Server有一个完善的还原功能来验证备份文件。举个例子，当你第一次创建了一个备份文件，它应该是好的，但这仅仅是“应该”。每一次，这个文件被拷贝到另一个地方时，文件就会存在被损坏的风险。确认这个备份文件可以继续使

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

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

SQL Server中的数据库都是由一或多个数据文件以及一或多个事务日志文件组成的。顾名思意，数据文件主要存储数据库的数据，包括数据库内容结构，数据页，索引页等等。那么事务日志到底是干什么的呢？它主要是用来保存数据库修改记录的，如下图：SQL Server的工作原理为什么这样呢？为什么不把数据立刻写入数据文件呢？原因很简单：为了得到更高的效率和性能。数据文件为了适应新的数据可能会扩展，

SQL Server允许使用简单的Copy方式来备份数据库的数据和日志文件吗？答案是肯定的。但前提是数据文件不再被SQL Server使用。当数据库处于活动状态，你不能简单的copy它的文件，推荐方式是使用完整数据库备份(备份类型)。这是因为数据库的数据和日志文件不能处于非一致状态。这会导致仅仅在事务日志中被修改的数据页可能无法写入数据文件。这也会影响进程中的事务无法提交或是回滚已经写入文件中

假设在下面几个时间段中，一个数据库积累插入了如下数据： 1.完整数据库备份故名思意，完整数据库备份包括完整的数据库信息。它包括数据库的数据文件和备份结尾的部份活动事务日志。 完整备份基本语法如下：BACKUP DATABASE AdventureWorks TO DISK = g:/backups/AdventureWorks.bak2.差异性数据库备份

影响数据库还原速度的因素和影响数据库备份速度的因素相同。除此之外，假如你使用SQL Server 2005的话，你还可以启动另外一个优化任务来还原当前不存在的数据库，运行环境为Windows XP，Windows 2003 Server 或更新版本。Perform Volume Maintenance Tasks当你还原一个新的完整数据库是，SQL Server读备份文件头，然后创建原始数