您现在正在浏览：站长之家 >> 数据库 >> 详细内容

备份SQLServer

时间:2007-12-23 来源:不详作者:迈克DB

________________________________________
人为错误
　
第三种重要的错误类型是人为错误。人为错误可能在任何时候不经意的发生。人为的错误所造成的损坏可轻可重，麻烦的是，这类型错误很轻易被忽视个几天甚至几周，使得回复更加困难。和使用者建立良好的互动关系（包括良好的通讯管道），就可以快速的回复使用者造成的错误。使用者不会害怕立即报告错误，当然越早发现错误越好。下面的故障可能是由人为错误引起的：
• 数据库服务器损失人为错误会造成服务器故障的情形包括：不小心关闭电源、没有先关闭 SQL Server 就关闭服务器。当 SQL Server 重新启动时，回复将自动执行，当然这要花上一些时间。不过由于磁盘上的数据库未受损伤，所以不需要还原。
　
• 遗失数据可能是有人不小心删除数据文件所造成。必须执行还原与回复操作来使数据库返回故障点前的状态。
　
• 数据表遗失或被破坏的数据假如误删数据表，或者由于某种因素误改资料，可以使用备份和还原来将资料表返回到它的原始状态。由于遗失的单一数据表或一小组数据不能只从备份还原，因此这种故障类型的回复可能相当复杂。我们将在第 33 章中讨论回复这类型故障的范例。
　
SQL Server 记录文件

本文来自织梦

　
要了解备份和还原操作如何与数据库回复共同作业的，必须先了解 SQL Server记录文件的运作方式。这一节将提供关于 SQL Server 记录和检查点的概述，并将告诉您如何备份交易记录文件。
交易记录文件
　
交易记录文件（transaction log）用来记录所有的交易以及这些交易对数据库做出的修改。这个记录让回复可以进行。当认可一个交易时，只要认可记录还没写入交易记录文件，认可操作就不算完成。由于对于数据库的变更并不需要立即写入磁盘中，这个记录文件只是一种在系统故障事件中可以回复交易的方法。
________________________________________
说明
假如一个数据文件受到损坏必须透过备份还原时，所有发生在这个数据文件上的交易都必须重复执行一次，才能将数据库回复到故障的那一点。由于交易记录文件是这个过程的要害，而且空间有限，所以必须执行交易记录文件备份。您必须保存从上次备份到现在产生的所有交易记录数据，这样才能回复数据库。假如您只对上一次备份的还原感爱好，您可以跳过交易记录文件备份，但是目前的交易记录文件将不能回复那次备份以后发生的交易。
________________________________________
延迟写入器执行绪
　
在数据库上的变更是最先写入 SQL Server 快取区中的资料。变更快取区中的数据主要是为了提升效能，因为等待 I/O 运作是相当费时的。这些变更最终还是会写入磁盘，只是这个过程在背景执行，而使用者并不知道。由于修改的页面储存在快取区，在这些页面（称为Dirty分页）被 SQL Server 执行绪写入磁盘之前，会耗费相当大量的时间。这个执行绪称为延迟写入器执行绪（lazywriter thread）.

延迟写入器执行绪使用近来最少使用的页面清单，这表示近来最少使用的数据将放在写入磁盘的清单开头，而刚刚才被使用的数据放在清单结尾，而且也最不可能被写入磁盘中。那些经常被修改的页面（因此总是不断地被移到清单的结尾）可能永远不会被延迟写入器执行绪写入磁盘中。这样会增加回复时间，因为可能必须读取许多交易记录才能将所有的变更应用在数据上。
例如，在一个具有超过 1 GB 的 RAM 的大规模系统中，要对数据库做很多变更的话，回复过程将花费好几个小时。除了延迟写入器执行绪之外，检查点（checkpoint）执行绪也将 Dirty 页面写入到磁盘中。（我们将在本节的后面具体讨论检查点执行绪。）
顺序记录
　
因为交易记录文件是交易的历史记录，交易记录文件的 I/O 运作主要是写入，并且一般是按照时间顺序。在交易复原事件中，交易记录文件将被读取，且 I/O 的时间顺序将被破坏。由于复原相当少见（因为系统崩溃很少见，而且使用者不会经常复原交易），交易记录文件中的 I/O 模式相当稳定。您可将交易记录文件放在它自己的磁盘或 RAID 数组中来增强 I/O 效能，就像第 4 章和第 5 章讨论过的。您应该使用 RAID 保护交易记录文件，因为这些交易纪录对于数据库回复是很重要的。