相當(dāng)長(zhǎng)一段時(shí)間以來，在64位平臺(tái)上運(yùn)行SQL Server一直是提高數(shù)據(jù)庫(kù)性能和擴(kuò)展性的一種選擇，不過配置方面的選項(xiàng)有限，而且不是沒有問題。舉例說，SQL Server 2000只能在昂貴的安騰系列處理器上面運(yùn)行；而且SQL Server的客戶端工具與64位平臺(tái)不兼容。另一方面，SQL Server 2005卻提供了新的選項(xiàng)可以充分利用64位架構(gòu)的強(qiáng)大功能；而且完全沒有在過去導(dǎo)致人們不太需要64位的問題。

　　使用SQL Server的公司為什么應(yīng)當(dāng)改用64位架構(gòu)？

　　要解答這個(gè)問題，最重要的答案就是，64位平臺(tái)與32位系統(tǒng)相比，大大提高了內(nèi)存訪問能力。32位系統(tǒng)最多只能本地訪問4GB的內(nèi)存。32位的SQL Server系統(tǒng)使用地址窗口擴(kuò)展（AWE）及相關(guān)技術(shù)后，最多可以訪問64GB的內(nèi)存，不過地址虛擬技術(shù)帶來了開銷：AWE需要?jiǎng)?chuàng)建虛擬“窗口”來訪問更高內(nèi)存。訪問高端內(nèi)存的每個(gè)請(qǐng)求都必須通過這個(gè)窗口進(jìn)行，開銷要比請(qǐng)求訪問本地內(nèi)存大得多。因而，在高使用率情況下，訪問更大內(nèi)存的功能實(shí)際上妨礙了而不是有助于性能。此外，AWE內(nèi)存只是被SQL Server用于緩沖器緩存，而不是用于過程緩存，而且不會(huì)有助于對(duì)利用許多即席查詢（ad-hoc query）的服務(wù)器進(jìn)行優(yōu)化。AWE內(nèi)存也不會(huì)被用于幫助內(nèi)存中的排序、散列連接（hash join）或者其他數(shù)據(jù)密集型操作。

　　如今的64位系統(tǒng)最多可本地訪問512GB的內(nèi)存。這意味著，性能不會(huì)受到地址窗口的影響，額外內(nèi)存可以供任何SQL Server緩存而不僅僅是緩沖器緩存使用。這種增加內(nèi)存的功能在許多情況下直接提高了性能。由于更多的數(shù)據(jù)保存在緩存里面，勢(shì)必會(huì)減少磁盤的I/O操作。你還會(huì)注意到使用中間排序、散列連接或者指針的查詢?cè)谛阅苌系玫教岣摺Ｋ�有這些在內(nèi)存里面進(jìn)行求值要比換到磁盤上進(jìn)行求值來得快。

　　為什么64位采用遲緩？

　　有人不由得會(huì)想：既然好處這么顯著，為什么到目前為止64位SQL Serve的采用似乎很遲緩？SQL Server 2000的64位選項(xiàng)很有限，因?yàn)镾QL Server 2000惟一支持的64位配置就是安騰服務(wù)器運(yùn)行在Windows Server 2003上面。也沒有哪個(gè)SQL Server 2000客戶端工具可在64位服務(wù)器上面運(yùn)行，包括企業(yè)管理器、查詢分析器和SQL Profiler。連數(shù)據(jù)轉(zhuǎn)換服務(wù)（DTS）軟件包也無法在64位服務(wù)器上運(yùn)行，這意味著DTS無法充分利用64位的更強(qiáng)功能。

　　SQL Server 2005 64位架構(gòu)有什么優(yōu)點(diǎn)？

　　SQL Server 2005為企業(yè)帶來了64位架構(gòu)的優(yōu)點(diǎn)，而與以往相比價(jià)位較低、功能較多。最重要的是，SQL Server 2005支持可以安裝在安騰和價(jià)格低得多的x64服務(wù)器兩種平臺(tái)上。所以，除了節(jié)省費(fèi)用外，數(shù)據(jù)庫(kù)管理員現(xiàn)在就可以使用英特爾處理器或者AMD處理器。

　　SQL Server 2005客戶端工具與64位服務(wù)器完全兼容，所有SQL Server支持服務(wù)都可以在64位配置環(huán)境下與SQL Server 2005一起使用，這包括：分析服務(wù)、SQL Server集成服務(wù)、報(bào)表服務(wù)和通知服務(wù)。所有這些服務(wù)都能夠利用訪問更多內(nèi)存的功能，有助于提高安裝的SQL Server的性能、滿足業(yè)務(wù)集成需求。

　　哪種安裝環(huán)境應(yīng)當(dāng)升級(jí)至64位？

　　升級(jí)主要有兩個(gè)市場(chǎng)：需要向上擴(kuò)展的32位單服務(wù)器安裝環(huán)境；以及需要合并的32位多服務(wù)器安裝環(huán)境。每種場(chǎng)景都有明顯的優(yōu)點(diǎn)。

　　表明單服務(wù)器安裝配置可能屬于向上擴(kuò)展類別的最明顯跡象就是，深度查詢磁盤活動(dòng)、較低的緩沖器緩存命中率以及較短的頁面生命周期。所有這些問題都可以使用性能計(jì)數(shù)器來評(píng)估，可通過能夠訪問更多內(nèi)存的64位系統(tǒng)來加以解決。

　　另一方面，確定多服務(wù)器安裝環(huán)境是不是非常適合合并來得困難一點(diǎn)。應(yīng)當(dāng)進(jìn)行認(rèn)真測(cè)試，評(píng)估所有數(shù)據(jù)庫(kù)總共需要多少內(nèi)存、處理器能不能處理所有數(shù)據(jù)庫(kù)的并發(fā)查詢、磁盤系統(tǒng)能不能處理同時(shí)讀寫帶來的更大壓力。做出這個(gè)決策比升級(jí)單一服務(wù)器困難得多，不過就整體的管理簡(jiǎn)易性而言，會(huì)獲得巨大回報(bào)。

　　改用64位會(huì)在SQL Server的性能和擴(kuò)展性方面帶來重大影響。SQL Server 2005提供的選項(xiàng)使得從32位進(jìn)行升級(jí)合理得多。如果你投資新硬件用于新的數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS），就應(yīng)當(dāng)調(diào)查分析64位選項(xiàng)，尤其是基于價(jià)格較低的x64位處理器的那些選項(xiàng)。

　　我要不要使用新的XML數(shù)據(jù)類型把所有XML數(shù)據(jù)保存在SQL Server 2005里面？

　　XML酷似CLR用戶定義類型（UDT），它現(xiàn)在是SQL Server 2005中新的第一類數(shù)據(jù)類型。開發(fā)人員現(xiàn)在可能會(huì)忍不住使用這種數(shù)據(jù)類型，以免編寫代碼把XML數(shù)據(jù)“分割”到表里面（即不是使用OPENXML往表里面批量載入數(shù)據(jù)）。

　　遺憾的是，像這樣使用XML數(shù)據(jù)類型存在與使用用戶定義類型表示數(shù)據(jù)同樣的許多問題。開發(fā)人員應(yīng)當(dāng)把性能記在心頭，因?yàn)閷?duì)XML列的一個(gè)節(jié)點(diǎn)進(jìn)行查詢需要引擎對(duì)表中每一行的不同XML查詢進(jìn)行求值。與使用CLR UDT一樣，還存在規(guī)范化問題。在過多使用XML數(shù)據(jù)類型的數(shù)據(jù)庫(kù)里面，要確保數(shù)據(jù)完整性極其困難。

關(guān)鍵字：SQL Server、數(shù)據(jù)庫(kù)