面對現實吧，雖然你從來沒有打算成爲一名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中的災難恢復是如何處理的，以及如何才能爲你的數據庫實現一個合理的，安全的災難恢復計劃。