遷移至64位SQL Server 2005

來源:互聯網
上載者:User

  相當長一段時間以來,在64位平台上運行SQL Server一直是提高資料庫效能和擴充性的一種選擇,不過配置方面的選項有限,而且不是沒有問題。舉例說,SQL Server 2000隻能在昂貴的安騰系列處理器上面運行;而且SQL Server的用戶端工具與64位平台不相容。另一方面,SQL Server 2005卻提供了新的選項可以充分利用64位架構的強大功能;而且完全沒有在過去導致人們不太需要64位的問題。

  使用SQL Server的公司為什麼應當改用64位架構?

  要解答這個問題,最重要的答案就是,64位平台與32位系統相比,大大提高了記憶體訪問能力。32位系統最多隻能本地訪問4GB的記憶體。32位的SQL Server系統使用地址視窗擴充(AWE)及相關技術後,最多可以訪問64GB的記憶體,不過地址虛擬技術帶來了開銷:AWE需要建立虛擬“視窗”來訪問更高記憶體。訪問高端記憶體的每個請求都必須通過這個視窗進行,開銷要比請求訪問本地記憶體大得多。因而,在高使用率情況下,訪問更大記憶體的功能實際上妨礙了而不是有助於效能。此外,AWE記憶體只是被SQL Server用於緩衝器緩衝,而不是用於過程緩衝,而且不會有助於對利用許多即席查詢(ad-hoc query)的伺服器進行最佳化。AWE記憶體也不會被用於協助記憶體中的排序、散列串連(hash join)或者其他資料密集型操作。

  如今的64位系統最多可本地訪問512GB的記憶體。這意味著,效能不會受到地址視窗的影響,額外記憶體可以供任何SQL Server緩衝而不僅僅是緩衝器緩衝使用。這種增加記憶體的功能在許多情況下直接提高了效能。由於更多的資料儲存在緩衝裡面,勢必會減少磁碟的I/O操作。你還會注意到使用中間排序、散列串連或者指標的查詢在效能上得到提高。所有這些在記憶體裡面進行求值要比換到磁碟上進行求值來得快。

  為什麼64位採用遲緩?

  有人不由得會想:既然好處這麼顯著,為什麼到目前為止64位SQL Serve的採用似乎很遲緩?SQL Server 2000的64位選項很有限,因為SQL Server 2000惟一支援的64位配置就是安騰伺服器運行在Windows Server 2003上面。也沒有哪個SQL Server 2000用戶端工具可在64位伺服器上面運行,包括企業管理器、查詢分析器和SQL Profiler。連資料轉換服務(DTS)軟體包也無法在64位伺服器上運行,這意味著DTS無法充分利用64位的更強功能。

  SQL Server 2005 64位架構有什麼優點?

  SQL Server 2005為企業帶來了64位架構的優點,而與以往相比價位較低、功能較多。最重要的是,SQL Server 2005支援可以安裝在安騰和價格低得多的x64伺服器兩種平台上。所以,除了節省費用外,資料庫管理員現在就可以使用英特爾處理器或者AMD處理器。

  SQL Server 2005用戶端工具與64位伺服器完全相容,所有SQL Server支援服務都可以在64位配置環境下與SQL Server 2005一起使用,這包括:分析服務、SQL Server整合服務、報表格服務和通知服務。所有這些服務都能夠利用訪問更多記憶體的功能,有助於提高安裝的SQL Server的效能、滿足業務整合需求。

  哪種安裝環境應當升級至64位?

  升級主要有兩個市場:需要向上擴充的32位單伺服器安裝環境;以及需要合并的32位多伺服器安裝環境。每種情境都有明顯的優點。

  表明單伺服器安裝配置可能屬於向上擴充類別的最明顯跡象就是,深度查詢磁碟活動、較低的緩衝器快取命中率以及較短的頁面生命週期。所有這些問題都可以使用效能計數器來評估,可通過能夠訪問更多記憶體的64位系統來加以解決。

  另一方面,確定多伺服器安裝環境是不是非常適合合并來得困難一點。應當進行認真測試,評估所有資料庫總共需要多少記憶體、處理器能不能處理所有資料庫的並發查詢、磁碟系統能不能處理同時讀寫帶來的更大壓力。做出這個決策比升級單一伺服器困難得多,不過就整體的管理簡易性而言,會獲得巨大回報。

  改用64位會在SQL Server的效能和擴充性方面帶來重大影響。SQL Server 2005提供的選項使得從32位進行升級合理得多。如果你投資新硬體用於新的資料庫管理系統(DBMS),就應當調查分析64位選項,尤其是基於價格較低的x64位處理器的那些選項。

  我要不要使用新的XML資料類型把所有XML資料儲存在SQL Server 2005裡面?

  XML酷似CLR使用者定義型別(UDT),它現在是SQL Server 2005中新的第一類資料類型。開發人員現在可能會忍不住使用這種資料類型,以免編寫代碼把XML資料“分割”到表裡面(即不是使用OPENXML往表裡面批量載入資料)。

  遺憾的是,像這樣使用XML資料類型存在與使用使用者定義型別表示資料同樣的許多問題。開發人員應當把效能記在心頭,因為對XML列的一個節點進行查詢需要引擎對錶中每一行的不同XML查詢進行求值。與使用CLR UDT一樣,還存在正常化問題。在過多使用XML資料類型的資料庫裡面,要確保資料完整性極其困難。



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

11.11 Big Sale for Cloud

Get Unbeatable Offers with up to 90% Off,Oct.24-Nov.13 (UTC+8)

Get It Now >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。