前言
SQL Server 2000從上市到現在已經整整五個年頭。現在望眼欲穿的SQL Server 2005 終於發佈了。五年磨一劍，SQLServer 2005 將是微軟具有里程碑性質的企業級數據庫產品。本文從用戶關心的技術要點出發比較和討論SQL Server 2005 相對它的前版本SQL Server 2000所做的重大改進或新增功能，介紹了SQL Server 2005 中最值得你爲之升級的10 個理由。無論你是想了解或學習SQL Server 2005，還是正在評估或考慮升級到SQL Server 2005，本文都將對您有很好的參考作用。
升級理由一：數據分區
只有到了2005 版本SQL Server才擁有了真正的表和索引數據分區技術。這個技術一下子使SQL Server數據庫從“青壯年”成長爲成熟的企業級數據庫產品，是一個里程碑性質的標誌。數據分區技術極大加強了表的可伸縮性和可管理性，使得SQLServer 處理海量數據的能力有了質的飛躍，是我認爲最值得升級的一個理由。
數據庫隨着硬件和業務的發展變得越來越大。五年前大多數數據庫還不過是十幾個GB大小，很少超過TB級別的。現在幾百個GB大小的數據庫系統隨處可見。如果沒有數據分區技術而想對大數據庫進行高效管理是很困難的。SQL Server 2005以前版本的一個問題是隨着時間的推移數據庫越來越大，備份需要的空間越來越多，如何處理數據庫中的歷史數據是很棘手的事情。有些客戶可能會使用DELETE語句定期定量刪除大表中的歷史記錄，如在每個週末備份數據庫後刪除一個星期以前的所有數據。但是如果表有上千萬行十幾個GB 大小，那麼使用DELETE語句刪除數據庫中上萬行或高達20%數據的話，其性能很差。如果是在7 × 24小時運行的聯機系統做這樣的數據維護操作那麼還會引起比較嚴重的阻塞問題。另外有些客戶針對這個問題直接在方案設計上下功夫，比如按照年份月份星期設計表，然後定期把一些過時的歷史數據表（注意是“表”）備份並DROP掉，使得數據庫大小以及系統性能都能保持相對穩定。但是這種方法有一個弊端，即應用程序必須做相應的配合根據不同的時間訪問對應的表，增加了數據庫管理以及數據庫訪問邏輯的複雜性。
大表還容易帶來性能問題。你也許會想到SQL Server 2000中的本地分區視圖或分佈式分區視圖技術。是的，SQL Server2000 中的確已經有分區視圖的概念，從SQL Server 7.0開始就有了。可惜分區視圖的一個令人討厭的地方是其管理、設計和開發比較困難，特別是分佈式分區視圖。如如何更新分佈式視圖就是個難題。所以儘管一個設計良好的分區視圖系統會有很不錯的性能改善，卻因爲繁瑣的配置，管理和開發使得其沒有在實際中得到充分應用。
現在，SQL Server 2005 引入了真正的數據水平分區技術，上面討論的數據庫增長問題和性能問題就迎刃而解。這個進步絕對不是一小步。數據庫的大小不再是個問題。你可以根據字段值的範圍將表和索引劃分爲多個分區從而可以輕鬆管理一個幾個TB大小的數據庫系統。無論數據如何增長，你都可以使用分區技術使得數據庫大小保持相對穩定。其中特別值得稱讚的地方是SQL Server 2005 中分區的管理和使用非常簡單。分區的刪除，添加，拆分、合併和移動，以及分區的數據裝載等管理都非常容易。你可以對單獨的分區進行維護而不是整個表。如果你需要大量裝載數據，那麼你可以先把數據並行的裝入到一個新分區當中，建立索引，然後把該分區合併到當前分區中來。這個動作需要的時間極短。如果你需要刪除歷史數據，假設你已經設計好了歷史數據分區，那麼你僅僅需要把該分區移除即可，幾乎可以一瞬間完成。分區也使得大型表的併發訪問性能得到改善，特別是有多個CPU的數據庫系統。那些需要交叉訪問大量數據的查詢將從分區技術中獲益不少。
升級理由二：可編程性
CLR 集成
SQL Server 2005的可編程性是值得升級的第二個重要理由。從來沒有哪一個版本能像SQL Server 2005 這樣帶來這麼多編程方面的變革。說老實話，在我知道的瞬間我是驚呆了。有些變化是革命性的。如CLR（Common Language Runtime,公共語言運行時）集成。就先說說CLR集成。CLR集成是指你可以使用任何一種.NET 語言編寫SQL Server 2005 的存儲過程，觸發器，函數，自定義類型，甚至是自定義的聚合函數。估計不少數據庫軟件開發商會爲這個功能歡呼雀躍。想想以前的擴展存儲過程，編程非常不容易。代碼中一不小心就會引起內存泄漏。而且由於擴展存儲過程運行在SQL Server 的進程空間中，不好的代碼容易引起訪問違規（Access Violation）導致SQLServer 異常。
現在有了CLR 集成，你可以輕鬆利用.NET語言的優勢如其面向對象的封裝、繼承和多態特性，編寫出那些需要對數據進行復雜數值計算或邏輯的代碼，如字符串處理，數據加密算法，XML數據操作等等。由於CLR代碼宿於SQL Server進程，你可以非常容易訪問數據庫中的數據。有了CLR，你不再侷限於T-SQL，你現在立即擁有了.NET 框架類庫提供的各種各樣的類和例程，以及.NET語言提供的一致的編程模型，如錯誤處理。展現在你面前的是一個可以無限擴展的編程空間。你現在需要的僅僅是考慮什麼時候使用T-SQL 語言，什麼時候使用CLR。我猜測那些SQL Server軟件開發商幾乎會立即升級到SQLServer 2005 享受數據庫編程的便捷。
T-SQL 語言增強
SQL Server 2005 中的T-SQL語言有了非常大的改進。其中筆者最爲稱道的是現在可以使用和C++或C#類似的TRYCATCH結構對T-SQL 進行錯誤處理了，大大簡化了T-SQL錯誤處理編程。SQL Server 2005以前的版本通過設置@@error變量表示最後的T-SQL 語句執行成功與否。爲避免@@error變量被新執行的語句重置，你必須爲每一條可能出錯的TSQL語句後面立即檢查或保存@@error變量的值，並使用相應的G O T O 語句進行跳轉，使得代碼變得複雜難讀。現在SQLServer 2005 有了TRY-CATCH結構你只需要把相關的一組語句放在TRY塊裏面即可。如果TRY塊裏面任何語句發生錯誤，就會執行相應的CATCH 塊。你甚至可以使用嵌套的TRYCATCH來實現複雜錯誤處理流程。估計很多T-SQL語言使用者可能就爲了這個TRY-CATCH 結構而迫不及待地升級到SQL Server 2005。
除了傳統的DML（INSERT/UPDATE/DELETE）觸發器，SQL Server 2005 現在也可以對DDL 語言（CREATE、ALTER或DROP 開頭的語句）創建觸發器了。這對於那些需要對DDL語言執行管理任務如審覈以及規範數據庫操作的用戶特別有用。以前很多客戶問我如何跟蹤或避免表的刪除操作，現在終於有了答案。你可以簡單建立一個針對DROP 語句的觸發器然後在觸發器裏面ROLLBACK 事務就可以回滾DROP 動作了。
SQL Server 2005 T-SQL 中還有一個很酷的OUTPUT 子句。現在你不費吹灰之力就可以獲得INSERT 、UPDATE 或DELETE語句所影響的每行的信息。對於在INSERT或UPDATE操作之後需要檢索標識列或計算列的值的場合OUTPUT子句非常有用。如獲得數據INSERT 後該行的Identity的值，產生一些唯一流水號，驗證剛剛插入的數據等等。一個有趣的例子是Identity值的取得。在SQL Server 2000 中你可以在INSERT 語句後立即調用IDENT_CURRENT()或SCOPE_IDENTITY()函數來得到INSERT 語句的Identity。現在你僅僅需要在INSERT 語句中指定output子句就直接得到剛剛插入的Identity值，實在太簡單了，不是嗎？
SQL Server 2005 中T-SQL 語言新增或加強的功能還有很多。如SQL Server 2005 新增加了一類排名函數RANK/DENSE_RANK/NTILE/ROW_NUMBER，輕鬆解決了開發者要求返回數據行中提供行號等排序功能。新增的P I V O T 和UNPIVOT運算符使得對結果集進行行和列的旋轉變換十分簡單。公用表表達式(CTE)解決了T-SQL語言的遞歸查詢問題，而使用OPENROWSET 語句現在可以直接從文件裏面執行大容量操作了。我覺得每一個改進都是那麼有針對性，以至於使我相信這些T-SQL增強必定是SQL Server開發小組真正聆聽數據庫開發者心聲的結果。
升級理由三：安全
SQL Server 2005 的安全功能是我認爲值得升級的第三個理由。SQL Server 2005 的安全達到了前所未有的強大水平，有着比以前版本更清晰的安全模型即主體，安全對象和權限。在SQLServer 2000 中是用服務器級權限、數據庫角色和數據用戶權限的混合方式管理權限。而SQL Server 2005 統一使用GRANT語句管理主體對安全對象的權限，簡化了安全管理。其中我認爲最大的改進是用戶和架構（schema）分離。在SQL Server 2000中如果用戶不是DBO 且擁有對象，那麼移除該用戶將是很麻煩的事情。你需要首先使用sp_changeobjectowner改變該用戶擁有的對象所有權，然後把所有引用該對象的代碼做相應的修改。而在SQL Server 2005 中就不需要這樣麻煩了，因爲現在用戶不再擁有對象。擁有對象的是schema 而不是用戶。數據庫中的所有對象都屬於某個schema。對象的完整名字是server.database.schema.object，符合SQL-99 標準，而不是以前的server.database.user.object 方式。刪除用戶僅需要改變schema的owner就可以了。不需要修改任何已存在的數據庫訪問代碼，真的很方便。用戶和架構分離還有一個好處就是對象的權限管理變得簡單。你可以把某些對象集中於某個架構裏面，然後對該架構設置權限，那麼架構裏面的所有對象就自動繼承了同樣的權限。
如果你需要保護數據庫中的敏感數據，那麼SQL Server2005 中的數據加密功能絕對值得考慮。以前不止一次有客戶問我如何加密數據庫中的某些數據，是否可以使用一些內部不公開的函數如PWDENCRYPT加密數據。我的回答是使用Windows的EFS（加密文件系統）功能加密數據庫文件或在應用程序層對數據加密後再存儲。現在用戶期盼已久的數據加密功能終於在SQL Server 2005 中得到實現，那些有機密數據需要保護的用戶值得高興了。SQL Server 2005不是簡單的提供一些加密函數，而是把市場上已經成熟的數據安全技術引進到數據庫中，有一個清晰的加密層次結構。SQL Server 2005 支持證書（certificate），非對稱密鑰和對稱密鑰算法，一是防止敏感數據被泄漏，二是防止數據被篡改。對稱密鑰支持RC4，RC2，TripleDES 和AES算法，而非對稱密鑰使用RSA 算法。證書其實就是非對稱密鑰中公鑰的容器。密鑰管理是安全中比較弱的部分。SQL Server 2005 每一層都使用證書、非對稱密鑰和對稱密鑰的組合對它下面的一層進行加密，提高了密鑰安全性。出於性能考慮，一般不用加密強度大的非對稱密鑰或證書直接加密數據，而是使用對稱密鑰加密數據獲得較快的性能，然後使用證書或非對稱密鑰加密對稱密鑰。
升級理由四：快照隔離
你還在爲系統出現的阻塞（blocking）或死鎖（deadlock）現象苦惱嗎？快試試SQL Server 2005 中的快照隔離吧。通過行版本（row versioning）控制技術，SQL Server 2005 除了原來支持的四種事務隔離級別（髒讀、提交讀、可重複讀、可串行讀）外新增了一個快照（SNAPSHOT）隔離級別，有可能使阻塞或死鎖成爲歷史。SQL Server在TEMPDB中存放不同版本的數據行，select 語句讀取這些不同版本的行，讀操作不阻塞寫數據，寫操作也不阻塞讀操作，這樣那些由於讀/ 寫爭用導致的大量死鎖的系統將從中獲得無窮益處。如果你的系統複雜難優化，那麼升級到SQL Server 2005 試試快照隔離級別，也許會有意想不到的效果。
SQL Server 2005中的快照隔離可細分爲兩種即READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION。建議大家多使用前者，因爲已提交讀隔離可用於大多數現有應用程序，而不需要進行任何更改，其佔用的TEMPDB空間也少。可以預見如果使用快照隔離級別，那麼需要特別關注TEMPDB的大小和性能。你也許需要把TEMPDB放在有足夠空間的單獨磁盤上以提高性能。
考慮到快照隔離在避免阻塞和死鎖方面的作用，我把它作爲升級的第四個理由。
升級理由五：數據庫鏡像
對於那些要求高可用性的用戶來說，數據庫鏡像也許是考慮升級的唯一理由。SQL Server 2005的前版本在高可用性方面提供了故障轉移羣集（Failover Cluster）和Log shipping方案。羣集方案的一個好處是在一臺機器發生問題時它可以提供極快的故障轉移能力，在備份服務器上聯機數據庫，應用程序只需重新連接即可。羣集方案的一個缺點是數據庫放在共享盤上，有單點失效這個缺點，一旦共享盤失敗將導致整個系統崩潰。所以羣集方案一般都要結合嚴緊的備份方案一起使用。而logshipping系統有一個時間上的延遲，且如果日誌備份很大，傳送速度也是個問題。SQL Server 2005引入的數據庫鏡像可作爲故障轉移羣集或Log shipping 的替代或補充方案來提高數據庫的高可用性。鏡像的主要優點是它比前兩者更容易管理，沒有羣集的單點失效缺點,也沒有log shipping 的時間延遲。鏡像服務器可以放在很遠的地方，提高了作爲備份服務器的高可用性。
數據庫鏡像需要兩臺或三臺服務器。主服務器通過傳送事務日誌中的每個事務到鏡像服務器來進行數據同步。每當數據庫commit一個事務，該事務就會被同步到鏡像服務器。如果事務安全設置爲FULL，傳送操作將爲同步操作。同步操作可以確保將提交的事務提交給兩個服務器，但可能會增加事務提交的時間。如果事務安全設置爲OFF，操作將爲異步操作。事務會在不等待鏡像服務器的情況下提交，這將不影響主服務器事務的提交時間，但不能確保鏡像也提交了該事務，所以在出現故障那一刻有可能有部分日誌丟失。對於需要嚴格同步數據的鏡像系統可以採取同步模式。而僅僅希望有個備份服務器又不影響性能的情況下可以使用異步模式（高性能模式）。無論那種模式，一旦主服務器出現問題，你可以手動實現故障轉移或配置系統實現自動故障轉移。
升級理由六：商務智能BI 增強
SQL Server 2005 對已經有或打算開發基於SQL Server 的商務智能方案的用戶吸引力極大。SQL Server 2005中有關商務智能方面的增強很多，是升級的很好理由。首先是傳統的DTS（Data Transformation Services）被新的IS（Integration Services）代替。SQL Server 2000 中的DTS用來在不同服務器之間轉移數據，但對於複雜重複的工作流DTS倍感吃力。IS重新改寫了DTS的數據流引擎，引入提取、轉換和加載（ETL）數據的新編程體系，將數據流與控制流分開，開發能力大大加強，包部署、管理和性能方面也比DTS上了一個數量級。筆者看來，DTS終於從原來的小打小鬧成長爲成熟的IS 數據集成服務體系。
分析服務（Analysis Services）在SQL Server 2005 中也有很多改進。原來沒有profiler想跟蹤分析服務裏面的語句非常痛苦。現在2005 終於支持profiler了。Profiler對性能調優和排查錯誤將非常有用。分析服務2005 真正具備了實時分析能力，新增加了四種數據挖掘算法，也支持.NET語言進行開發（如存儲過程等）。至於報表服務，2005 版本中添加了報表生成器和模型設計器這兩個新工具，支持報表拖拉設計。2005 的報表改進如新的打印功能、多值參數等。設計過報表的人員會深深知道多值參數的妙處。
另外，無論是IS、報表服務等都可以在類似Visual Studio的環境中開發，任務完成不過鼠標拖拉之間，非常容易上手。
升級理由七：全文搜索增強
相對前版本SQL Server 2005中性能提升最多的部分當數全文檢索。SQL Server 2000 中的全文本檢索和SQL Server 7.0中的差別不大，處於能用的水平。在SQL Server 2000中使用全文檢索一個最大的痛苦是建立全文索引的性能不好，需要的時間太長，特別是在表很大的情況下。一個幾千萬行數據的表也許需要數個小時到數天時間才能完成全文索引的建立。SQL Server 2005全文檢索在開發的時候就集中於三點：性能，集成，和可擴展性。據開發小組人員的簡單測試，原來在SQL Server 2000中建立全文索引需要14天的表，現在只需要幾個小時！幾乎有上百倍的性能提升，只能用“驚異”來形容。其相關的全文檢索語句也有30％～50％甚至更高的性能提高。性能方面的提高得益於全新設計的全文檢索引擎。其中關鍵的一點設計是全文檢索引擎現在使用共享內存和SQL Server 進行數據大規模併發交互，而不是原來基於逐行的方式，使得性能上了好幾個數量級。
除了性能，SQL Server 2005 中的全文索引的集成性也大大加強。在SQL Server 2000 中很難對全文檢索進行備份。一旦有數據庫恢復或移動，你得重新重建索引。對於幾百個GB的數據庫，重建索引幾乎是不能接受的惡夢。現在終於可以和數據庫一起備份和恢復全文索引了。你不再需要在恢復數據庫後重建全文索引了！惡夢終於成爲歷史。除了可以備份外，你也可以方便的改變全文索引的磁盤位置。你甚至可以在一個熱備機器上把全文索引建立好，然後copy 這個索引到生產服務器上使用。
升級理由八：可用性功能增強
索引聯機操作。除了數據庫鏡像，SQL Server 2005 中可用性還有很多其他提高。索引現在可以使用ONLINE關鍵字進行在線建立或重建或刪除了。它的技術要點是在內存裏面動態生成索引的另一個副本從而不影響原來查詢的進行。一旦索引副本完成操作即替代原來索引成爲當前索引。我認爲索引聯機操作的意義是很大的，因爲很多數據庫系統都有定期調整或維護索引方面的需求。有了2005 你無需擔心業務的正常運行而大膽的對索引進行維護或修改。
頁校驗和。SQL Server 2005中的數據庫頁引入校驗和增強了數據的可靠性。除了原來SQL Server 2000 中已有的TORN_PAGE_DETECTION 外，SQL Server 2005 新增實現了頁的檢驗和（CHECKSUM）。你使用ALTER DATABASE語句的SET PAGE_VERIFY子句即可指定。它的原理是向磁盤中寫入8K數據頁面時，SQL Server計算整個8K頁面內容的校驗和並將該值存儲在頁頭中。再次從磁盤中讀取頁時，SQL Server動態計算讀取到的頁面內容的校驗和，並與存儲在頁頭中的校驗和值進行比較。如果不相等則意味着頁面有物理損壞，需要檢查IO硬件。另外設置檢驗和的另一個好處是還可以在備份和還原操作過程中使用RESTORE VERIFYONLY語句驗證每一數據頁的完整性從而確認備份文件沒有物理損壞。
在線還原。在數據庫的某一部分未恢復前，用戶無法對該部分進行訪問，但可以訪問所有其他數據。SQL Server 2000中如果數據庫在還原或recovery當中，用戶不能訪問數據庫。這樣如果數據庫很大需要rollback或rollforward的事務很多的話，recovery的時間會出奇的長。SQL Server 2005 的在線還原功能使得數據庫在很短的時間內變得可用。
升級理由九：複製增強
SQL Server 2000 中的複製功能已經很好。我這裏把複製作爲升級的一個理由因爲SQL Server 2005在原來的基礎上又增添了不少的功能。如peer-to-peer對等複製，可以在參與者之間相互進行復制，這樣你可以採用對等複製在複製參與者之間建立某種程度的負載平衡。合併複製現在支持通過HTTPS進行數據同步，可以方便建立基於INTERNET 的複製。發佈表現在可以使用標準的T-SQL語句如Alter Table等進行結構修改然後被複制而不是僅僅侷限於使用sp_repladdcolumn和sp_repldropcolumn存儲過程。在SQL Server 2000 中，僅支持向其他數據庫（如DB2或Oracle）發佈數據，而在SQL Server 2005 中，可將Oracle 數據庫直接複製到SQL Server。可以從備份中初始化事務性訂閱而不是僅僅侷限於從快照對複製進行初始化，等等……
升級理由十：異步處理能力
SQL Server 2005 通過引入全新的Service Broker 提供了革命性的異步處理能力。Service Broker提供了一個功能強大的異步編程模型。它爲數據庫應用程序增加了可靠、可擴展、分佈式異步功能異步編程，允許程序僅僅在資源可用時纔去執行佔用大量資源的任務，以此來縮短響應時間，提高吞吐量。在我看來，Broker的最大好處一是異步執行能力，提高了可伸縮性，二是可靠執行，三是集成於數據庫中，備份數據庫就備份了broker 的消息隊列。SQL Server 2005 中的查詢通知就是基於Service Broker的應用。你可以使用查詢通知功能來發送一個命令到SQL Server請求在查詢結果發生變化時接收SQL Server的通知。這樣就可以只有在程序以前檢索的結果發生變化時，才需要重新查詢數據庫。一個可以預見的應用是在使用緩存的Web 站點中。Web站點首先發送語句到數據庫服務器，獲得數據，緩存到本地，然後只有在收到查詢通知的時候才清理緩存，重新查詢數據。這個機制避免了重複輪詢SQL Server，大大減輕了服務器的負載，也提高了Web 站點的伸縮性。
因爲SQL Server 2005 的Service Broker帶來了數據庫編程異步處理能力的革命，我把它作爲升級的第十個理由。
總結語
上面列出的十大理由僅僅是基於筆者的考慮，並沒有囊括SQL Server 2005 所有的功能。SQL Server 2005 還有其他很多非常優秀或重大的改進。比如支持通過HTTP SOAP協議直接訪問數據庫，增加XML數據類型，支持Xquery，使用新的SQL ServerManagement Studio 等等。有一點我必須提一下，就是現在可以調用sp_create_plan_guide來強制指定SQL Server總是使用某個執行計劃運行語句，避免SQL Server動態生成不夠優化的查詢計劃，實在太棒了。在筆者看來，SQL Server 2005 帶來的好處遠遠大於升級導致的工作量，升級到SQL Server 2005 是遲早的事情。早升級早擁有，對SQL Server 2005，你準備好了嗎？
