面对现实吧，虽然你从来没有打算成为一名SQL Server专家，但是随着数据库引擎种类和版本的增加，这就要求一些人来专门从事并关注这方面的内容。作为“微软人”（或者称为Gal）,无论你是不是愿意，你都被选中了。这一系列的文章全都是关于帮助作为管理员而非程序员的你在使用SQL Server时更加高效。

　　在实际执行任务之前，有一点背景信息可以会起到帮助作用。那么，到底SQL Server是如何工作的呢?不管你信不信，理解“黑盒”知识几乎可以在Microsoft SQL Server的所有方面起到帮助作用，例如从备份与存储到复制与镜像。

　　SQL Server将数据存储在磁盘中8KB大小的块中，称为页。在内存中,SQLServer操作的也是那些8KB大小的块，这意味着SQL Server中处理的数据最小单元也是8KB。

　　当数据写入磁盘时，每一整行数据必须符合8KB大小的页。SQL Server允许多行数据共享一个页,但是不允许一行数据跨多个页。因此，如果一个客户表包含列：Name,Address,City,State,以及Phone,那么，所有的数据组合必须小于8KB。对于某种特定的数据类型来说则有一个例外，这个时候，实际的页只包含对真实数据的指针，如二进制数据（图片或文本大字段），其真实数据可以存储在多个页上，或者存储在一个文件中（那是特殊的FILESTREAM类型）。SQL Server将这所有的这些8KB大小的页收集在一起放入磁盘的一个简单文件中，这种文件通常有一个.MDF或.NDF的文件扩展名。

　　当SQL Server被告知要做什么时，它是通过由结构化查询语言（SQL）语法写的查询来实现的。以下是最先发生的：SQL Server的内部查询优化器监视着此查询并构造一个处理计划来执行它（例如：指出从磁盘中取出数据所要遵循的步骤）。这实际上相当复杂，因为SQL Server有大量可使用的技术，而且部分技术在某特定条件下比其它的要好。

　　一旦SQL Server构造成功此计划，它将执行此计划并从磁盘取出需要的数据。如果接收到查询，数据将通过网络流动到正在请求的客户端。如果更改了查询，SQL Server则会修改内存中页的数据，但不会将修改写回磁盘。那有点愚蠢，因为可能在页上还有其它的随之发生的修改，并且系统加载时可能不提供一个很好的向磁盘写数据的机会。然而，SQL Server所做的是生成被修改查询的一个副本，并将其保存在一个指定的事务日志文件中。这个文件有一个.LDF的扩展文件名，保存着SQL Server执行的每一个事务的记录。

　　最后---也许几秒钟以后---SQL Server决定把修改后的页写到磁盘中。当它这样处理时，它查找事务日志并取消产生修改的事务。从本质上讲，也就是“OK，我做了修改并且此修改已经写入磁盘。”这样一来，SQL Server知道这些修改在磁盘中是安全的。

　　在SQL Server垮掉的情况下,它有自一个动恢复模式,可在开始备份时进行切换。它直接打开事务日志并查找未提交的或者未取消的事务。众所周知，当服务器死机时,未取消的事务在磁盘中是安全的，其它任何数据没有被写到磁盘中，而是仍然存留在内存中。因此,SQL Server从那些事务日志文件中读取日志,重新执行它们,并迅速将受影响的页写入磁盘。这个过程允许SQL Server捕获进程中的所有操作，并确保你不会丢失任何数据——提供给你的磁盘文件是完好的，当然，现在想一想这个重要事实—SQL Server中发生的每一事件只通过事务日志产生，并且SQL Server可以重读日志来重现所发生的事务。这个过程使得SQL Server几乎可以实现每一件事情。

　　当然，这仅仅是默认情况，你可以修改它。个人数据库可被从完全恢复模式（我已经在前边描述过）切换到简单恢复模式，简单恢复模式不使用事务日志（好吧，它使用，但取消的事务会被自动移除从而保持日志文件比较小）。简单恢复仅适用于那些没有被修改的只读数据库。没有被修改，在死机中就不会丢失数据。

　　那就是数据如何从磁盘向内存中移动的过程。这整个过程绝对是SQL Server的大多数功能实际工作的本质,比如如何管理它。在我的下一篇文章中，我将关注SQL Server中的灾难恢复是如何处理的，以及如何才能为你的数据库实现一个合理的，安全的灾难恢复计划。