SQL Server最重要的职责之一就是保护数据，这是通过备份数据库来完成的，包括：完全备份、文件备份、文件组备份、差异备份、事务日志备份。另外，通过SQL Server 2008中新增加的压缩改进功能，可以大大减小备份的大小。


一、这里特别提到的一个问题是日志满的问题，当日志满后，可能会导致这个sql server挂起，无法进行DML操作。

我觉得可能有2个方面原因：

正常情况下，日志文件中的空间会循环使用，不会出现满的现象。

     1.你的日志文件限制最大的大小了，也就是当日志文件增长的时候，由于你的日志文件时限制最大大小，比如就是最多只有10M，那么当你的系统有一个大的事务，那么可能日志空间就不够了，导致日志满。

     2.如果你的数据库的恢复模式full，那么你必须通过备份数据库日志，来释放日志空间，让系统再循环使用日志空间，因为如果你不备份，系统认为你还需要这些日志，不会释放这些空间，所以日志就会满。 所以按时备份日志，能让SQL Server自动截断日志，让日志空间循环使用。


二、备份的基本问题：

     1、是否要备份数据库。数据库是否应该备份基于公司如何看待SQL Server实例及其数据库的价值，对于专用数据库实例来说，其商业价值可能不太重要，也可能是不能丢失任何数据。如果你不能承受丢失数据，或者在数据库中重新生成数据，那么就应该做数据库备份。


     2、备份的频度，多久要开始下一次备份。你可以忍受丢失多少数据，能忍受丢失一天的数据，还是一个小时，还是一分钟？如果你能忍受丢失24小时的数据，那么依据数据库的大小，一天一次的完全备份数据库的备份计划是可以接受的；如果你根本不能忍受丢失30分钟以上的数据修改，你还是应该考虑每30分钟执行一次事务日志备份；如果你你能承受丢失的数据越多，那么就越要经常的备份数据库。


     3、是否有异地的存储设施。如果数据是很重要的，而灾难发生时设备被淋湿或者被烧毁，你需要通过磁带、网络把数据转移到另一个安全的外部地点。应该考虑将备份生成的文件归档到网络上的另一台服务器或磁带上，如果SQL Server实例的主机损坏了，就肯定需要从离线服务器或异地源上的备份来恢复。


     4、可以承受的停机时间，时间越少，那么需要更多的备份，或使用高可用性。你的恢复目标时间是什么，也就是希望花多少时间来恢复数据库？你的应用可以承受多长的停机时间？在丢失数据库的所有数据后，需要多少时间才能把所有数据恢复并且运行起来？每小时的停机时间会是业务损失多少？如果数字很大，那么需要考虑在冗余上投资来避免停机的影响。如果数据库很大，并且允许的停机时间非常短，而通过备份来还原需要的时间可能比较长，那么可能需要考虑对现有的数据库，通过数据库镜像、RAID镜像、日志传送、复制、SAN技术、或者在两个、更多个SQL Server实例之间，提供有效的数据副本。


故障转移集群也能通过排除单点故障来提高SQL Server实例的可用性。如果硬件损坏了，在现场有没有可用于替换的部件，或者去商店买一个？对于高可用性需求，需要考虑任何可能发生的单点故障，把单点指定为冗余部分。

 


三、备份恢复策略：


     1、需要知道每个连接到数据库的应用程序的主要联系人？谁和最终用户保持联系？


     2、 如果一个数据库损坏了，IT部门中谁来负责启用备用服务器、安装操作系统、移动文件、切换DNS名称、从备份恢复数据。


     3、如果整个现场被破坏，是否有另一个备选现场，是否有移动到这个备选现场的操作手册；是否有备用部件、可用的备用服务器；是否有硬件供应商、软件供应商的支持计划，是否有注册码、服务代码、联系方式。

 

四、如果整个服务器都坏了，那么需要从头创建服务器：

谁负责重建服务器，数据库运行在什么OS版本上，你是否有重新安装OS的光盘及注册码。


重新安装SQL Server的光盘及注册码，是否有其他应用程序安装、配置在SQL Server服务器，是否记录了安装SQL Server的步骤，需要哪种排序规则，是否安装了所有组件，还是只安装了数据库引擎。


SQL备份文件存放的位置、备份类型。 


 

五、几种不同的备份类型：

     1、完全备份。完全备份会生成一个数据库的副本，当备份数据库时，数据库处于在线活动状态；完全备份是最耗时间的，完全备份包含了备份操作完成时的所有数据改变和日志文件，它可以允许恢复整个数据库；是日志备份、差异备份的基础。


     2、事务日志备份。事务日志备份了最后的完全备份或事务日志备份完成后发生的事务日志的活动；当备份完成后，SQL Server截断日志的不活动部分，这部分是不包含打开的事务活动的。事务日志备份具有低资源消耗的特性，并且可以频繁的执行。事务日志备份有3种模式：

当置为simple恢复模式时，允许进行完全备份、差异备份，不能执行事务日志备份。

当置为bulk_logged恢复模式时，允许执行完全备份、差异备份、事务日志备份，但是在大容量操作时，最小限度的日志被记录到事务日志。这种模式的有点是在执行大容量操作时减少了日志空间的使用，但作为代价，事务日志备份只能用来恢复到最后事务日志备份完成的时间，不允许基于时间点、事务标记的恢复。

当置为full恢复模式时，会完整的记录了所有的事务活动，包括大容量操作，所以所有的还原选项都可用，包括事务日志还原、完全备份、差异备份。

 

     3、差异备份。不像日志备份，差异备份是自包含的，只需要还原的数据库最后的完全备份



备份



use master go if not exists(select name from sys.databases where name = 'Test') begin create database test end use test go select * into dbo.SalesOrderDetail from AdventureWorks.Sales.SalesOrderHeader --1.完全备份 backup database test to disk = 'c:\test_1.bak' --2.查看数据库压缩的配置信息 select name, description, value_in_use, --是否启用此参数 is_dynamic, --动态参数 is_advanced --不是高级参数 from sys.configurations where name ='backup compression default' --启动服务器级别的数据库压缩选项 exec sp_configure 'backup compression default',1 reconfigure go --再次完全备份 backup database test to disk ='c:\test_compressd.bak' --显示压缩前和压缩后的备份集 select b.database_name, b.backup_size, b.compressed_backup_size, --压缩后的大小 f.filegroup_name, f.physical_name from msdb..backupset b inner join msdb..backupfile f on b.backup_set_id = f.backup_set_id where database_name = 'test' --3.给备份集添加名称和说明信息 backup database test to disk = 'c:\test_description.bak' with description = 'test数据库的备份', --说明备份集的文本 name = 'test backup 2012-10-31', --备份集的名称 mediadescription = 'backups for 2012-10-31', --说明媒体集的文本 medianame = 'test_2012-10-31' --备份媒体集的名称 /*================================================ 4.1设置备份集的保留天数 如果在备份之前,备份文件不存在,它会在backup命令的执行期间创建. 如果文件已存在,默认会在已经存在的备份文件上附加备份数据,保留文件上的其他备份 ==================================================*/ backup database test to disk = 'c:\test_check.bak' with retaindays = 3 --retaindays：指定必须经过多少天才能覆盖这个备份媒体集 --expiredate：制定了备份集到期允许被覆盖的日期 /*=============================================== 4.2设置是否覆盖已经存在的备份集 显示： 消息 4030，级别 16，状态 1，第 1 行 设备 'c:\test_check.bak'上的介质于 11 3 2012 5:44:53:000PM 过期，无法覆盖。 消息 3013，级别 16，状态 1，第 1 行 BACKUP DATABASE 正在异常终止。 =================================================*/ backup database test to disk = 'c:\test_check.bak' with init --init：覆盖已存在的备份集,但保留媒体标头，如果备份集没有过期会报错 --noinit：默认选项，备份集将追加到磁盘或磁带设备上 --4.3是否写入新的媒体标头 backup database test to disk = 'c:\test_check.bak' with format --format：在备份操作的所有卷上写入一个新的媒体标头，原有的标头被覆盖， --如果现有设备中存在条带，则整个媒体集都不可用 --noformat：不会把媒体标头写入备份操作的所有卷 --4.4由于skip禁用了备份集的过期和名称检查，所以不会报错 backup database test to disk = 'c:\test_check.bak' with init, skip --skip：禁用了备份集的过期和名称检查 --noskip：检测日期和名称，是确保备份不会被不恰当的覆盖的安全措施 /*============================================== 5.条带化备份: 1.可以使用一个以上的设备(磁盘,磁带)进行单个备份集操作， 当执行备份时，可以最多使用64个设备。 2.当在备份非常大的数据库时，条带化备份是非常有用的， 因为通过分离的磁盘/陈列条带化备份文件，同时以对称的方式写入每个文件， 也就是使用并行写操作，可以显著提高备份操作的速度，增强备份性能。 ================================================*/ --这个备份创建3个文件,每个文件存储了三分之一的还原数据库时需要的备份信息 backup database test to disk = 'c:\test_stripping.bak', disk = 'c:\test_stripping.bak', disk = 'e:\test_stripping.bak' --尝试在任何一个设备上进行备份,会报错 backup database test to disk = 'c:\test_stripping.bak' --6.1增加备份设备 exec sp_addumpdevice @devtype = 'disk', --设备类型 @logicalname = 'testBackup', --逻辑名称 @physicalname = 'c:\testBackup.bak' --物理路径 --6.2查看新建的备份设备 exec sp_helpdevice @devname = 'testBackup' --参数值默认为NULL --6.3备份到备份设备 backup database test to testBackup --设备的逻辑名称 --6.4删除备份设备 exec sp_dropdevice @logicalname = 'testBackup', @delfile = null --输入'delfile'表示不仅删除备份设备,而且删除物理文件 --7.1镜像备份 backup database test to disk = 'c:\test_original.bak' mirror to disk = 'c:\test_mirror_1.bak' mirror to disk = 'c:\test_mirror_2.bak' mirror to disk = 'c:\test_mirror_3.bak' with format --首次创建备份集是需要使用format,否则会报错 --7.2对条带备份创建镜像备份集 backup database test to disk = 'c:\test_original_stripping_1.bak', --条带1 disk = 'c:\test_original_stripping2.bak' --条带2 mirror to disk = 'c:\test_mirror_stripping_1.bak', --镜像中的条带1 disk = 'c:\test_mirror_stripping_2.bak' --镜像中的条带2 with format --首次创建备份集是需要使用format,否则会报错 --8.1事务日志备份:捕捉在最后事务日志备份,或完全数据库备份之后发生的变化 backup log test to disk ='c:\test_log.trn' /*========================================================= 8.2在事务日志尾部生成一个事务日志备份 使用NO_TRUNCATE执行的备份可能具有不完整的元数据, 该选项允许在数据库损坏时备份日志,相当于COPY_ONLY + CONTINUE_AFTER_ERROR. 数据库损坏时，如果无法使用NO_TRUNCATE备份日志尾部， 则可以通过指定CONTINUE_AFTER_ERROR而不是 NO_TRUNCATE尝试执行尾日志备份, 也就是会截断日志. ==============================================================*/ backup log test to disk ='c:\test_log_emergency.trn' with no_truncate --备份数据库最新的事务,没有截断事务日志中不活动的部分 --使用此选项时,数据库必须处于online状态 use master go --8.3备份事务日志尾部,然后使数据库处于restoring状态,这是一个还会有附加restore命令执行的状态 backup log test to disk ='c:\test_log_norecovery.trn' with norecovery --8.4执行此命令后,数据库显示:(正在还原...),无法访问 select state_desc --数据库状态 from sys.databases where name = 'test' --还原日志 restore database test from disk = 'c:\test_log_norecovery.trn' with file= 1 --8.5数据库又处于可访问状态online select state_desc from sys.databases where name = 'test' --8.6备份日志尾部,并使数据库处于只读和standby状态 backup log test to disk = 'c:\test_log_standby.trn' with standby = 'c:\test_standby.bak' --8.7显示：(备用/只读) select state_desc, is_read_only, is_in_standby from sys.databases where name = 'test' restore log test from disk = 'c:\test_log_standby.trn' with file =1 /*========================================== 8.8 若要执行最大程度的日志备份（跳过日志截断）, 并自动将数据库置于 RESTORING 状态， 请同时使用 NO_TRUNCATE 和 NORECOVERY 选项。 ============================================*/ backup log test to disk = 'c:\test_log_notruncate_norecovery.trn' with no_truncate, --跳过日志截断 norecovery --备份尾日志，将数据库置于restoring状态 /*============================================== 8.9copy_only选项创建的备份不影响正常的备份序列 如：差异备份1和事务日志备份1都依赖于之前执行的完全备份1, 而无论何时创建了其他的完全备份2,备份序列都将重新开始, 之前生成的差异备份1和日志备份1不能使用后来生成的完全备份2， 只有那些在完全备份2生成之后创建的差异2和日志备份2， 才能使用完全备份2 需要注意的是:与BACKUP DATABASE一起使用时， COPY_ONLY选项创建的完整备份不能用作差异基准。 差异位图不会被更新，因此差异备份的表现就像仅复制备份不存在一样。 后续差异备份将最新的常规完整备份用作它们的基准。 ================================================*/ --完全备份不会破坏备份序列，在有大的数据库变化之前创建的特殊的， --用来在restore时以防万一的完全备份 backup database test to disk = 'c:\test_full.bak' with copy_only --在创建备份时,事务日志不会被截断,保留未破坏的事务日志备份链 backup log test to disk = 'c:\test_log_full.trn' with copy_only --10.差异备份 backup database test to disk = 'c:\test.diff' with differential, noinit, --不覆盖已经存在的备份集 stats = 25 --每当完成25%的备份就显示一条消息 --11.对于超大型数据库,通过文件组,文件备份来减少备份时间, --可以在丢失文件组,文件的情况下执行恢复操作 create database very_large_test on primary ( name = 'vlTest', filename= 'c:\vltest.mdf' ), filegroup fg1 ( name = 'vlTest1', filename= 'c:\vltest_fg1.ndf' ), ( name = 'vlTest2', filename= 'c:\vltest_fg2.ndf' ) log on ( name = 'vlTest_log', filename = 'c:\vlTest_log.log' ) --11.1文件组备份 backup database very_large_test filegroup = 'fg1' to disk = 'c:\vlTest_fg2.bak' use very_large_test go exec sp_helpfile --11.2文件备份 backup database very_large_test file = 'vlTest1', file = 'vlTest2' to disk = 'c:\vlTest_1_2.bak' --12.部分备份 use master go --12.1修改文件组为只读 alter database very_large_test modify filegroup fg1 readonly --12.2部分备份：创建数据库中主文件组,所有在线的可读写的文件组的备份 backup database very_large_test read_write_filegroups to disk = 'c:\very_large_test_read_write_filegroups.bak' --13.查看备份元数据 --13.1该结果集包含由给定备份设备标识的备份媒体的有关信息 restore labelonly from disk = 'c:\test_full.bak' --13.2返回由备份集内包含的数据库和日志文件列表组成的结果集 restore filelistonly from disk = 'c:\test_full.bak' --13.3返回包含特定备份设备上,所有备份集的所有备份标头信息的结果集 restore headeronly from disk = 'c:\very_large_test_read_write_filegroups.bak' /*================================================== 13.4 RESTORE VERIFYONLY 执行下列检查： 1:备份集是否完整以及所有卷是否可读。 2:数据库页中的一些标头字段，例如页ID（就如同要写入数据一样） 3:校验和（如果介质中提供的话） 4:目标设备中是否有足够的空间 loadhistory选项: 指示还原操作将信息加载到msdb历史记录表.对于要验证的单个备份集， 此选项将介质集上存储的SQL Server备份相关信息, 加载到msdb数据库中的备份和还原历史记录表中 =======================================================*/ restore verifyonly from disk = 'c:\test_full.bak' with file = 1, loadhistory



 



转载于:https://blog.51cto.com/yupeigu/1368087