--樓主的語句語法是沒問題的
成都創(chuàng)新互聯(lián)公司服務項目包括桓臺網(wǎng)站建設、桓臺網(wǎng)站制作、桓臺網(wǎng)頁制作以及桓臺網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，桓臺網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到桓臺省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
--只是樓主 不太清楚函數(shù)str的用法
--過程我?guī)湍愀南?然后 “但是數(shù)據(jù)表卻沒有創(chuàng)建出來” 你這句話 可以判斷 你只是編譯 沒有運行
---運行 是會報錯的 編譯能成功（因為語法沒有問題）
alter proc newproc1
@i int,
@name varchar(10)
as
set @i=1
while @i=5
begin
set @name='test'+str(@i,1,0)
exec('create table '+@name+' (id int not null,name varchar(10))')
set @i=@i+1
end
--下面說一下str函數(shù)的用法
str可以只有一個參數(shù) select str(1) --不指定長度和小數(shù)位數(shù) 就默認小數(shù)位數(shù)是0 長度是10 不夠
--就在前面補空格 所以你的上面的str(@i,3,0) @i是一位數(shù)字 所以前面會有兩個空格 所以才會
--報錯
str可以只有有兩個參數(shù) select str(23,2) 第二個參數(shù)代表長度 這個長度一定要比第一個長度長或相等 否則就是結果是一串*****
第3個參數(shù)是小數(shù)位數(shù) 這個好理解 有什么不明白的可以隨時問我 希望采納
樓主執(zhí)行存儲過程 可以執(zhí)行：newproc1 1,''
正常的版本就可以裝了，
win7上面安裝SQL server2005是非常方便的，你到控制面板中“控制面板\程序\打開關閉windows功能”將“IIS”相關功能打開。就可以了，其實主要是一個“.NET”框架和IIS的相關安全驗證。這樣就ok了，還有一個是您的win7的版本，如果您的是“home basic”版本的話估計裝不上。我用的是旗艦版的。
希望你能成功?。。?！
---------------------------------------------------------------------
如果你要裝xp還保留win7的話，可以裝雙系統(tǒng)，或者在win7上裝虛擬機，推薦使用虛擬機，這樣可以靈活使用多個系統(tǒng)，對于開發(fā)測試都是很有好處的。
前言
SQL Server 2000從上市到現(xiàn)在已經(jīng)整整五個年頭。現(xiàn)在望眼欲穿的SQL Server 2005 終于發(fā)布了。五年磨一劍，SQLServer 2005 將是微軟具有里程碑性質的企業(yè)級數(shù)據(jù)庫產(chǎn)品。本文從用戶關心的技術要點出發(fā)比較和討論SQL Server 2005 相對它的前版本SQL Server 2000所做的重大改進或新增功能，介紹了SQL Server 2005 中最值得你為之升級的10 個理由。無論你是想了解或學習SQL Server 2005，還是正在評估或考慮升級到SQL Server 2005，本文都將對您有很好的參考作用。
升級理由一：數(shù)據(jù)分區(qū)
只有到了2005 版本SQL Server才擁有了真正的表和索引數(shù)據(jù)分區(qū)技術。這個技術一下子使SQL Server數(shù)據(jù)庫從“青壯年”成長為成熟的企業(yè)級數(shù)據(jù)庫產(chǎn)品，是一個里程碑性質的標志。數(shù)據(jù)分區(qū)技術極大加強了表的可伸縮性和可管理性，使得 SQLServer 處理海量數(shù)據(jù)的能力有了質的飛躍，是我認為最值得升級的一個理由。
數(shù)據(jù)庫隨著硬件和業(yè)務的發(fā)展變得越來越大。五年前大多數(shù)數(shù)據(jù)庫還不過是十幾個GB大小，很少超過TB級別的?，F(xiàn)在幾百個GB大小的數(shù)據(jù)庫系統(tǒng)隨處可見。如果沒有數(shù)據(jù)分區(qū)技術而想對大數(shù)據(jù)庫進行高效管理是很困難的。SQL Server 2005以前版本的一個問題是隨著時間的推移數(shù)據(jù)庫越來越大，備份需要的空間越來越多，如何處理數(shù)據(jù)庫中的歷史數(shù)據(jù)是很棘手的事情。有些客戶可能會使用 DELETE語句定期定量刪除大表中的歷史記錄，如在每個周末備份數(shù)據(jù)庫后刪除一個星期以前的所有數(shù)據(jù)。但是如果表有上千萬行十幾個GB 大小，那么使用DELETE語句刪除數(shù)據(jù)庫中上萬行或高達20%數(shù)據(jù)的話，其性能很差。如果是在7 × 24小時運行的聯(lián)機系統(tǒng)做這樣的數(shù)據(jù)維護操作那么還會引起比較嚴重的阻塞問題。另外有些客戶針對這個問題直接在方案設計上下功夫，比如按照年份月份星期設計表，然后定期把一些過時的歷史數(shù)據(jù)表（注意是“表”）備份并DROP掉，使得數(shù)據(jù)庫大小以及系統(tǒng)性能都能保持相對穩(wěn)定。但是這種方法有一個弊端，即應用程序必須做相應的配合根據(jù)不同的時間訪問對應的表，增加了數(shù)據(jù)庫管理以及數(shù)據(jù)庫訪問邏輯的復雜性。
大表還容易帶來性能問題。你也許會想到SQL Server 2000中的本地分區(qū)視圖或分布式分區(qū)視圖技術。是的，SQL Server2000 中的確已經(jīng)有分區(qū)視圖的概念，從SQL Server 7.0開始就有了?？上Х謪^(qū)視圖的一個令人討厭的地方是其管理、設計和開發(fā)比較困難，特別是分布式分區(qū)視圖。如如何更新分布式視圖就是個難題。所以盡管一個設計良好的分區(qū)視圖系統(tǒng)會有很不錯的性能改善，卻因為繁瑣的配置，管理和開發(fā)使得其沒有在實際中得到充分應用。
現(xiàn)在，SQL Server 2005 引入了真正的數(shù)據(jù)水平分區(qū)技術，上面討論的數(shù)據(jù)庫增長問題和性能問題就迎刃而解。這個進步絕對不是一小步。數(shù)據(jù)庫的大小不再是個問題。你可以根據(jù)字段值的范圍將表和索引劃分為多個分區(qū)從而可以輕松管理一個幾個TB大小的數(shù)據(jù)庫系統(tǒng)。無論數(shù)據(jù)如何增長，你都可以使用分區(qū)技術使得數(shù)據(jù)庫大小保持相對穩(wěn)定。其中特別值得稱贊的地方是SQL Server 2005 中分區(qū)的管理和使用非常簡單。分區(qū)的刪除，添加，拆分、合并和移動，以及分區(qū)的數(shù)據(jù)裝載等管理都非常容易。你可以對單獨的分區(qū)進行維護而不是整個表。如果你需要大量裝載數(shù)據(jù)，那么你可以先把數(shù)據(jù)并行的裝入到一個新分區(qū)當中，建立索引，然后把該分區(qū)合并到當前分區(qū)中來。這個動作需要的時間極短。如果你需要刪除歷史數(shù)據(jù)，假設你已經(jīng)設計好了歷史數(shù)據(jù)分區(qū)，那么你僅僅需要把該分區(qū)移除即可，幾乎可以一瞬間完成。分區(qū)也使得大型表的并發(fā)訪問性能得到改善，特別是有多個CPU的數(shù)據(jù)庫系統(tǒng)。那些需要交叉訪問大量數(shù)據(jù)的查詢將從分區(qū)技術中獲益不少。
升級理由二：可編程性
CLR 集成
SQL Server 2005的可編程性是值得升級的第二個重要理由。從來沒有哪一個版本能像SQL Server 2005 這樣帶來這么多編程方面的變革。說老實話，在我知道的瞬間我是驚呆了。有些變化是革命性的。如CLR（Common Language Runtime,公共語言運行時）集成。就先說說CLR集成。CLR集成是指你可以使用任何一種.NET 語言編寫SQL Server 2005 的存儲過程，觸發(fā)器，函數(shù)，自定義類型，甚至是自定義的聚合函數(shù)。估計不少數(shù)據(jù)庫軟件開發(fā)商會為這個功能歡呼雀躍。想想以前的擴展存儲過程，編程非常不容易。代碼中一不小心就會引起內存泄漏。而且由于擴展存儲過程運行在SQL Server 的進程空間中，不好的代碼容易引起訪問違規(guī)（Access Violation）導致SQLServer 異常。
現(xiàn)在有了CLR 集成，你可以輕松利用.NET語言的優(yōu)勢如其面向對象的封裝、繼承和多態(tài)特性，編寫出那些需要對數(shù)據(jù)進行復雜數(shù)值計算或邏輯的代碼，如字符串處理，數(shù)據(jù)加密算法，XML數(shù)據(jù)操作等等。由于CLR代碼宿于SQL Server進程，你可以非常容易訪問數(shù)據(jù)庫中的數(shù)據(jù)。有了CLR，你不再局限于T-SQL，你現(xiàn)在立即擁有了.NET 框架類庫提供的各種各樣的類和例程，以及.NET語言提供的一致的編程模型，如錯誤處理。展現(xiàn)在你面前的是一個可以無限擴展的編程空間。你現(xiàn)在需要的僅僅是考慮什么時候使用T-SQL 語言，什么時候使用CLR。我猜測那些SQL Server軟件開發(fā)商幾乎會立即升級到SQLServer 2005 享受數(shù)據(jù)庫編程的便捷。
T-SQL 語言增強
SQL Server 2005 中的T-SQL語言有了非常大的改進。其中筆者最為稱道的是現(xiàn)在可以使用和C++或C#類似的TRYCATCH結構對T-SQL 進行錯誤處理了，大大簡化了T-SQL錯誤處理編程。SQL Server 2005以前的版本通過設置@@error變量表示最后的T-SQL 語句執(zhí)行成功與否。為避免@@error變量被新執(zhí)行的語句重置，你必須為每一條可能出錯的TSQL語句后面立即檢查或保存@@error變量的值，并使用相應的G O T O 語句進行跳轉，使得代碼變得復雜難讀?，F(xiàn)在SQLServer 2005 有了TRY-CATCH結構你只需要把相關的一組語句放在TRY塊里面即可。如果TRY塊里面任何語句發(fā)生錯誤，就會執(zhí)行相應的CATCH 塊。你甚至可以使用嵌套的TRYCATCH來實現(xiàn)復雜錯誤處理流程。估計很多T-SQL語言使用者可能就為了這個TRY-CATCH 結構而迫不及待地升級到SQL Server 2005。
除了傳統(tǒng)的DML（INSERT/UPDATE/DELETE）觸發(fā)器，SQL Server 2005 現(xiàn)在也可以對DDL 語言（CREATE、ALTER或DROP 開頭的語句）創(chuàng)建觸發(fā)器了。這對于那些需要對DDL語言執(zhí)行管理任務如審核以及規(guī)范數(shù)據(jù)庫操作的用戶特別有用。以前很多客戶問我如何跟蹤或避免表的刪除操作，現(xiàn)在終于有了答案。你可以簡單建立一個針對DROP 語句的觸發(fā)器然后在觸發(fā)器里面ROLLBACK 事務就可以回滾DROP 動作了。
SQL Server 2005 T-SQL 中還有一個很酷的OUTPUT 子句?，F(xiàn)在你不費吹灰之力就可以獲得INSERT 、UPDATE 或DELETE語句所影響的每行的信息。對于在INSERT或UPDATE操作之后需要檢索標識列或計算列的值的場合OUTPUT子句非常有用。如獲得數(shù)據(jù)INSERT 后該行的Identity的值，產(chǎn)生一些唯一流水號，驗證剛剛插入的數(shù)據(jù)等等。一個有趣的例子是Identity值的取得。在SQL Server 2000 中你可以在INSERT 語句后立即調用IDENT_CURRENT()或SCOPE_IDENTITY()函數(shù)來得到INSERT 語句的Identity?，F(xiàn)在你僅僅需要在INSERT 語句中指定output子句就直接得到剛剛插入的Identity值，實在太簡單了，不是嗎？
SQL Server 2005 中T-SQL 語言新增或加強的功能還有很多。如SQL Server 2005 新增加了一類排名函數(shù)RANK/DENSE_RANK/NTILE/ROW_NUMBER，輕松解決了開發(fā)者要求返回數(shù)據(jù)行中提供行號等排序功能。新增的 P I V O T 和UNPIVOT運算符使得對結果集進行行和列的旋轉變換十分簡單。公用表表達式(CTE)解決了T-SQL語言的遞歸查詢問題，而使用 OPENROWSET 語句現(xiàn)在可以直接從文件里面執(zhí)行大容量操作了。我覺得每一個改進都是那么有針對性，以至于使我相信這些T-SQL增強必定是SQL Server開發(fā)小組真正聆聽數(shù)據(jù)庫開發(fā)者心聲的結果。
升級理由三：安全
SQL Server 2005 的安全功能是我認為值得升級的第三個理由。SQL Server 2005 的安全達到了前所未有的強大水平，有著比以前版本更清晰的安全模型即主體，安全對象和權限。在SQLServer 2000 中是用服務器級權限、數(shù)據(jù)庫角色和數(shù)據(jù)用戶權限的混合方式管理權限。而SQL Server 2005 統(tǒng)一使用GRANT語句管理主體對安全對象的權限，簡化了安全管理。其中我認為最大的改進是用戶和架構（schema）分離。在SQL Server 2000中如果用戶不是DBO 且擁有對象，那么移除該用戶將是很麻煩的事情。你需要首先使用sp_changeobjectowner改變該用戶擁有的對象所有權，然后把所有引用該對象的代碼做相應的修改。而在SQL Server 2005 中就不需要這樣麻煩了，因為現(xiàn)在用戶不再擁有對象。擁有對象的是schema 而不是用戶。數(shù)據(jù)庫中的所有對象都屬于某個schema。對象的完整名字是server.database.schema.object，符合SQL- 99 標準，而不是以前的server.database.user.object 方式。刪除用戶僅需要改變schema的owner就可以了。不需要修改任何已存在的數(shù)據(jù)庫訪問代碼，真的很方便。用戶和架構分離還有一個好處就是對象的權限管理變得簡單。你可以把某些對象集中于某個架構里面，然后對該架構設置權限，那么架構里面的所有對象就自動繼承了同樣的權限。
如果你需要保護數(shù)據(jù)庫中的敏感數(shù)據(jù)，那么SQL Server2005 中的數(shù)據(jù)加密功能絕對值得考慮。以前不止一次有客戶問我如何加密數(shù)據(jù)庫中的某些數(shù)據(jù)，是否可以使用一些內部不公開的函數(shù)如PWDENCRYPT加密數(shù)據(jù)。我的回答是使用Windows的EFS（加密文件系統(tǒng)）功能加密數(shù)據(jù)庫文件或在應用程序層對數(shù)據(jù)加密后再存儲?，F(xiàn)在用戶期盼已久的數(shù)據(jù)加密功能終于在 SQL Server 2005 中得到實現(xiàn)，那些有機密數(shù)據(jù)需要保護的用戶值得高興了。SQL Server 2005不是簡單的提供一些加密函數(shù)，而是把市場上已經(jīng)成熟的數(shù)據(jù)安全技術引進到數(shù)據(jù)庫中，有一個清晰的加密層次結構。SQL Server 2005 支持證書（certificate），非對稱密鑰和對稱密鑰算法，一是防止敏感數(shù)據(jù)被泄漏，二是防止數(shù)據(jù)被篡改。對稱密鑰支持RC4，RC2， TripleDES 和AES算法，而非對稱密鑰使用RSA 算法。證書其實就是非對稱密鑰中公鑰的容器。密鑰管理是安全中比較弱的部分。SQL Server 2005 每一層都使用證書、非對稱密鑰和對稱密鑰的組合對它下面的一層進行加密，提高了密鑰安全性。出于性能考慮，一般不用加密強度大的非對稱密鑰或證書直接加密數(shù)據(jù)，而是使用對稱密鑰加密數(shù)據(jù)獲得較快的性能，然后使用證書或非對稱密鑰加密對稱密鑰。
升級理由四：快照隔離
你還在為系統(tǒng)出現(xiàn)的阻塞（blocking）或死鎖（deadlock）現(xiàn)象苦惱嗎？快試試SQL Server 2005 中的快照隔離吧。通過行版本（row versioning）控制技術，SQL Server 2005 除了原來支持的四種事務隔離級別（臟讀、提交讀、可重復讀、可串行讀）外新增了一個快照（SNAPSHOT）隔離級別，有可能使阻塞或死鎖成為歷史。 SQL Server在TEMPDB中存放不同版本的數(shù)據(jù)行，select 語句讀取這些不同版本的行，讀操作不阻塞寫數(shù)據(jù)，寫操作也不阻塞讀操作，這樣那些由于讀/ 寫爭用導致的大量死鎖的系統(tǒng)將從中獲得無窮益處。如果你的系統(tǒng)復雜難優(yōu)化，那么升級到SQL Server 2005 試試快照隔離級別，也許會有意想不到的效果。
SQL Server 2005中的快照隔離可細分為兩種即READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION。建議大家多使用前者，因為已提交讀隔離可用于大多數(shù)現(xiàn)有應用程序，而不需要進行任何更改，其占用的TEMPDB空間也少?？梢灶A見如果使用快照隔離級別，那么需要特別關注TEMPDB的大小和性能。你也許需要把TEMPDB放在有足夠空間的單獨磁盤上以提高性能。
考慮到快照隔離在避免阻塞和死鎖方面的作用，我把它作為升級的第四個理由。
升級理由五：數(shù)據(jù)庫鏡像
對于那些要求高可用性的用戶來說，數(shù)據(jù)庫鏡像也許是考慮升級的唯一理由。SQL Server 2005的前版本在高可用性方面提供了故障轉移群集（Failover Cluster）和Log shipping方案。群集方案的一個好處是在一臺機器發(fā)生問題時它可以提供極快的故障轉移能力，在備份服務器上聯(lián)機數(shù)據(jù)庫，應用程序只需重新連接即可。群集方案的一個缺點是數(shù)據(jù)庫放在共享盤上，有單點失效這個缺點，一旦共享盤失敗將導致整個系統(tǒng)崩潰。所以群集方案一般都要結合嚴緊的備份方案一起使用。而 logshipping系統(tǒng)有一個時間上的延遲，且如果日志備份很大，傳送速度也是個問題。SQL Server 2005引入的數(shù)據(jù)庫鏡像可作為故障轉移群集或Log shipping 的替代或補充方案來提高數(shù)據(jù)庫的高可用性。鏡像的主要優(yōu)點是它比前兩者更容易管理，沒有群集的單點失效缺點,也沒有l(wèi)og shipping 的時間延遲。鏡像服務器可以放在很遠的地方，提高了作為備份服務器的高可用性。
數(shù)據(jù)庫鏡像需要兩臺或三臺服務器。主服務器通過傳送事務日志中的每個事務到鏡像服務器來進行數(shù)據(jù)同步。每當數(shù)據(jù)庫commit一個事務，該事務就會被同步到鏡像服務器。如果事務安全設置為FULL，傳送操作將為同步操作。同步操作可以確保將提交的事務提交給兩個服務器，但可能會增加事務提交的時間。如果事務安全設置為OFF，操作將為異步操作。事務會在不等待鏡像服務器的情況下提交，這將不影響主服務器事務的提交時間，但不能確保鏡像也提交了該事務，所以在出現(xiàn)故障那一刻有可能有部分日志丟失。對于需要嚴格同步數(shù)據(jù)的鏡像系統(tǒng)可以采取同步模式。而僅僅希望有個備份服務器又不影響性能的情況下可以使用異步模式（高性能模式）。無論那種模式，一旦主服務器出現(xiàn)問題，你可以手動實現(xiàn)故障轉移或配置系統(tǒng)實現(xiàn)自動故障轉移。
升級理由六：商務智能BI 增強
SQL Server 2005 對已經(jīng)有或打算開發(fā)基于SQL Server 的商務智能方案的用戶吸引力極大。SQL Server 2005中有關商務智能方面的增強很多，是升級的很好理由。首先是傳統(tǒng)的DTS（Data Transformation Services）被新的IS（Integration Services）代替。SQL Server 2000 中的DTS用來在不同服務器之間轉移數(shù)據(jù)，但對于復雜重復的工作流DTS倍感吃力。IS重新改寫了DTS的數(shù)據(jù)流引擎，引入提取、轉換和加載（ETL）數(shù)據(jù)的新編程體系，將數(shù)據(jù)流與控制流分開，開發(fā)能力大大加強，包部署、管理和性能方面也比DTS上了一個數(shù)量級。筆者看來，DTS終于從原來的小打小鬧成長為成熟的IS 數(shù)據(jù)集成服務體系。
分析服務（Analysis Services）在SQL Server 2005 中也有很多改進。原來沒有profiler想跟蹤分析服務里面的語句非常痛苦?，F(xiàn)在2005 終于支持profiler了。Profiler對性能調優(yōu)和排查錯誤將非常有用。分析服務2005 真正具備了實時分析能力，新增加了四種數(shù)據(jù)挖掘算法，也支持.NET語言進行開發(fā)（如存儲過程等）。至于報表服務，2005 版本中添加了報表生成器和模型設計器這兩個新工具，支持報表拖拉設計。2005 的報表改進如新的打印功能、多值參數(shù)等。設計過報表的人員會深深知道多值參數(shù)的妙處。
另外，無論是IS、報表服務等都可以在類似Visual Studio的環(huán)境中開發(fā)，任務完成不過鼠標拖拉之間，非常容易上手。
升級理由七：全文搜索增強
相對前版本SQL Server 2005中性能提升最多的部分當數(shù)全文檢索。SQL Server 2000 中的全文本檢索和SQL Server 7.0中的差別不大，處于能用的水平。在SQL Server 2000中使用全文檢索一個最大的痛苦是建立全文索引的性能不好，需要的時間太長，特別是在表很大的情況下。一個幾千萬行數(shù)據(jù)的表也許需要數(shù)個小時到數(shù)天時間才能完成全文索引的建立。SQL Server 2005全文檢索在開發(fā)的時候就集中于三點：性能，集成，和可擴展性。據(jù)開發(fā)小組人員的簡單測試，原來在SQL Server 2000中建立全文索引需要14天的表，現(xiàn)在只需要幾個小時！幾乎有上百倍的性能提升，只能用“驚異”來形容。其相關的全文檢索語句也有30％～50％甚至更高的性能提高。性能方面的提高得益于全新設計的全文檢索引擎。其中關鍵的一點設計是全文檢索引擎現(xiàn)在使用共享內存和SQL Server 進行數(shù)據(jù)大規(guī)模并發(fā)交互，而不是原來基于逐行的方式，使得性能上了好幾個數(shù)量級。
除了性能，SQL Server 2005 中的全文索引的集成性也大大加強。在SQL Server 2000 中很難對全文檢索進行備份。一旦有數(shù)據(jù)庫恢復或移動，你得重新重建索引。對于幾百個GB的數(shù)據(jù)庫，重建索引幾乎是不能接受的惡夢?，F(xiàn)在終于可以和數(shù)據(jù)庫一起備份和恢復全文索引了。你不再需要在恢復數(shù)據(jù)庫后重建全文索引了！惡夢終于成為歷史。除了可以備份外，你也可以方便的改變全文索引的磁盤位置。你甚至可以在一個熱備機器上把全文索引建立好，然后copy 這個索引到生產(chǎn)服務器上使用。
升級理由八：可用性功能增強
索引聯(lián)機操作。除了數(shù)據(jù)庫鏡像，SQL Server 2005 中可用性還有很多其他提高。索引現(xiàn)在可以使用ONLINE關鍵字進行在線建立或重建或刪除了。它的技術要點是在內存里面動態(tài)生成索引的另一個副本從而不影響原來查詢的進行。一旦索引副本完成操作即替代原來索引成為當前索引。我認為索引聯(lián)機操作的意義是很大的，因為很多數(shù)據(jù)庫系統(tǒng)都有定期調整或維護索引方面的需求。有了2005 你無需擔心業(yè)務的正常運行而大膽的對索引進行維護或修改。
頁校驗和。SQL Server 2005中的數(shù)據(jù)庫頁引入校驗和增強了數(shù)據(jù)的可靠性。除了原來SQL Server 2000 中已有的TORN_PAGE_DETECTION 外，SQL Server 2005 新增實現(xiàn)了頁的檢驗和（CHECKSUM）。你使用ALTER DATABASE語句的SET PAGE_VERIFY子句即可指定。它的原理是向磁盤中寫入8K數(shù)據(jù)頁面時，SQL Server計算整個8K頁面內容的校驗和并將該值存儲在頁頭中。再次從磁盤中讀取頁時，SQL Server動態(tài)計算讀取到的頁面內容的校驗和，并與存儲在頁頭中的校驗和值進行比較。如果不相等則意味著頁面有物理損壞，需要檢查IO硬件。另外設置檢驗和的另一個好處是還可以在備份和還原操作過程中使用RESTORE VERIFYONLY語句驗證每一數(shù)據(jù)頁的完整性從而確認備份文件沒有物理損壞。
在線還原。在數(shù)據(jù)庫的某一部分未恢復前，用戶無法對該部分進行訪問，但可以訪問所有其他數(shù)據(jù)。SQL Server 2000中如果數(shù)據(jù)庫在還原或recovery當中，用戶不能訪問數(shù)據(jù)庫。這樣如果數(shù)據(jù)庫很大需要rollback或rollforward的事務很多的話，recovery的時間會出奇的長。SQL Server 2005 的在線還原功能使得數(shù)據(jù)庫在很短的時間內變得可用。
升級理由九：復制增強
SQL Server 2000 中的復制功能已經(jīng)很好。我這里把復制作為升級的一個理由因為SQL Server 2005在原來的基礎上又增添了不少的功能。如peer-to-peer對等復制，可以在參與者之間相互進行復制，這樣你可以采用對等復制在復制參與者之間建立某種程度的負載平衡。合并復制現(xiàn)在支持通過HTTPS進行數(shù)據(jù)同步，可以方便建立基于INTERNET 的復制。發(fā)布表現(xiàn)在可以使用標準的T-SQL語句如Alter Table等進行結構修改然后被復制而不是僅僅局限于使用sp_repladdcolumn和sp_repldropcolumn存儲過程。在SQL Server 2000 中，僅支持向其他數(shù)據(jù)庫（如DB2或Oracle）發(fā)布數(shù)據(jù)，而在SQL Server 2005 中，可將Oracle 數(shù)據(jù)庫直接復制到SQL Server?？梢詮膫浞葜谐跏蓟聞招杂嗛喍皇莾H僅局限于從快照對復制進行初始化，等等……
升級理由十：異步處理能力
SQL Server 2005 通過引入全新的Service Broker 提供了革命性的異步處理能力。Service Broker提供了一個功能強大的異步編程模型。它為數(shù)據(jù)庫應用程序增加了可靠、可擴展、分布式異步功能異步編程，允許程序僅僅在資源可用時才去執(zhí)行占用大量資源的任務，以此來縮短響應時間，提高吞吐量。在我看來，Broker的最大好處一是異步執(zhí)行能力，提高了可伸縮性，二是可靠執(zhí)行，三是集成于數(shù)據(jù)庫中，備份數(shù)據(jù)庫就備份了broker 的消息隊列。SQL Server 2005 中的查詢通知就是基于Service Broker的應用。你可以使用查詢通知功能來發(fā)送一個命令到SQL Server請求在查詢結果發(fā)生變化時接收SQL Server的通知。這樣就可以只有在程序以前檢索的結果發(fā)生變化時，才需要重新查詢數(shù)據(jù)庫。一個可以預見的應用是在使用緩存的Web 站點中。Web站點首先發(fā)送語句到數(shù)據(jù)庫服務器，獲得數(shù)據(jù)，緩存到本地，然后只有在收到查詢通知的時候才清理緩存，重新查詢數(shù)據(jù)。這個機制避免了重復輪詢 SQL Server，大大減輕了服務器的負載，也提高了Web 站點的伸縮性。
因為SQL Server 2005 的Service Broker帶來了數(shù)據(jù)庫編程異步處理能力的革命，我把它作為升級的第十個理由。
去網(wǎng)上找找吧，這類的介紹很好找的
索引可以提高的，like的話要看是“%abc%”還是“abc%”的，前者速度比較慢，后者就快了，和“=”差不多，前者可以用全文索引來彌補
還可以用Top n來查詢，提高速度
在SQL SERVER 2005中，將表中字符串轉換為數(shù)字的函數(shù)共2個：
1. convert(int,字段名) 例如：select convert(int,'3')
2. cast(字段名 as int) 例如：select cast('3' as int)
其實，一般情況下沒有必要把字符串轉換為數(shù)字類型
假如需要比較兩個字段是否相等，但是一個字段為字符串類型，一個為數(shù)字類型，用“=”比較兩個值是否相等時，SQL SERVER會自動把字符串轉換為數(shù)字再比較的！
例如：
select da.TITLE_NAME,dsc.NAME
from dbo.DV_DUTY dd
inner join DV_SECOND_CLASS dsc on (dsc.ID=dd.AREA)
left join DV_ASSET da on(da.ID=dd.RECORD_ID and dd.TYPE='2')
where dd.AREA is not null
這個SQl中，inner join DV_SECOND_CLASS dsc on (dsc.ID=dd.AREA) 中dsc.ID為數(shù)字類型，dd.AREA為字符類型，相當于這樣on(1='1')的判斷，這時候就會自動吧字符串的'1'轉換為數(shù)字類型再比較的。
但是也有弊端，一旦字符類型轉換為數(shù)字類型出錯（說明字符串的確就非數(shù)字組成的），SQL就會拋出異常。
SQL SERVER 2005中有判斷字段是否為數(shù)字的函數(shù)：
ISNUMERIC（字段名） -----假如字段是數(shù)字類型返回1，不是就返回0
但是好像有的時候不好使，比如：select isnumeric('3,34') 就返回1
說明這個函數(shù)對字段值中全是數(shù)字但是數(shù)字間用“,”和“.”（逗號或點）隔開的都視為數(shù)字了！
重慶分公司
重慶分公司
