sql server 的最大負載能力是多大？能支持多大的數(shù)據(jù)庫？

主要考慮到數(shù)據(jù)均衡的

創(chuàng)新互聯(lián)專業(yè)成都做網(wǎng)站、成都網(wǎng)站制作，集網(wǎng)站策劃、網(wǎng)站設(shè)計、網(wǎng)站制作于一體，網(wǎng)站seo、網(wǎng)站優(yōu)化、網(wǎng)站營銷、軟文發(fā)稿等專業(yè)人才根據(jù)搜索規(guī)律編程設(shè)計，讓網(wǎng)站在運行后，在搜索中有好的表現(xiàn)，專業(yè)設(shè)計制作為您帶來效益的網(wǎng)站！讓網(wǎng)站建設(shè)為您創(chuàng)造效益。

SQLServer支持多CPU并發(fā),CPU越多,效率越好,一般來說,百萬級也有用SQLSERVER的,

但如果超過百萬級,達到千萬或更多,就應(yīng)該考慮用ORACLE了..

SQL SERVER 2008 服務(wù)器CPU滿負荷，求檢查方法

至強E5-2640 為六核心 十二線程的 看的出你得服務(wù)器上有兩個處理器，此類處理器還是帶的動500人同時訪問，沒必要換。你的內(nèi)存使用量太高了，建議關(guān)閉不必要后臺。如果你要找出是數(shù)據(jù)庫的造成問題 那么你得把數(shù)據(jù)庫代碼發(fā)出來 不然是無法為你找的 你給的只是CPU和內(nèi)存在任務(wù)管理器里使用率，服務(wù)器長時間不關(guān)機 也是導致運行緩慢的原因之間，windows系統(tǒng)開時間長了系統(tǒng)占用資源很大臨時文件很多，建議使用linux或unix系統(tǒng)關(guān)閉不必要的端口服務(wù) 數(shù)據(jù)庫建議使用oracle或者my sql數(shù)據(jù)庫。

希望我的回答對你有幫助

怎樣查出SQLServer的性能瓶頸

硬件性能瓶頸 內(nèi)存 內(nèi)存對SQL Server性能的影響勝過任何其他硬件。因此，對SQL Server系統(tǒng)的內(nèi)存使用情況進行定期監(jiān)視以確保內(nèi)存的可用百分比高于20%是很有必要的。如果用戶遭遇性能問題，同時可用內(nèi)存百分比低于20%，那么此問題一定是內(nèi)存分配不足導致的。這要求技術(shù)人員密切關(guān)注顯示平均頁面預期壽命的性能計數(shù)器，并確保平均頁面預期壽命總是高于300秒（5分鐘）。一旦放生少于此標準的情況，就說明要么是糟糕的索引設(shè)計導致了磁盤輸入/輸出（I/O）的增加，要么就是對內(nèi)存的利用效率很低，或者是實際的內(nèi)存不足。技術(shù)人員需要監(jiān)視SQL Server系統(tǒng)上的分頁率，并確保它們常規(guī)為1000頁每秒。檢查PerfMon object MSSQL Buffer Manager（性能監(jiān)視對象MSSQL緩沖管理器）和Memory Performance Counters（內(nèi)存性能計數(shù)器）。 同樣，還要監(jiān)視計數(shù)器，即PerfMon object SQL Server Memory Manager Counters中的Memory Grants Pending。此計數(shù)器顯示的是每秒鐘等待工作負載分配的進程總數(shù)。一般來講，小型OLTP事務(wù)不需要大內(nèi)存分配。

如何測試sqlserver性能

對于DBA來講，我們都會做新服務(wù)器的性能測試。我會從TPC的基準測試入手，使用HammerDB做整體性能評估（前身是HammerOra），跟廠商數(shù)據(jù)對比。再使用DiskSpd針對性的測試磁盤IO性能指標（前身是SQLIO），再到SQLIOSIM測試存儲的完整性，再到ostress并發(fā)壓力測試，對于數(shù)據(jù)庫服務(wù)器遷移，我們還會收集和回放Profiler Trace，并收集期間關(guān)鍵性能計數(shù)器做對比。

下面我著重談?wù)勈褂肏ammerDB的TPC-C來做SQL Server基準測試。

自己寫負載測試代碼很困難

為了模擬數(shù)據(jù)庫的負載，你想要有多個應(yīng)用程序用戶和混合數(shù)據(jù)讀寫的語句。你不想總是對單一行更新相同的值，或者只是重復插入假的值。

自己動手使用Powershell、C#等語言寫負載測試腳本也不是不可能，只是太消耗時間，你需要創(chuàng)建或者恢復數(shù)據(jù)庫，并做對應(yīng)的測試。

免費而簡單的壓測SQL Server：使用HammerDB模擬OLTP數(shù)據(jù)庫負載

HammerDB是一個免費、開源的工具，允許你針對SQL Server、Oracle、MySQL和PostgreSQL等運行TPC-C和TPC-H基準測試。你可以使用HammerDB來針對一個數(shù)據(jù)庫生成腳本并導入測試。HammerDB也允許你配置一個測試運行的長度，定義暖機階段，對于每個運行的虛擬用戶的數(shù)量。

首先，HammerDB有一個自動化隊列，讓你將多個運行在不同級別的虛擬用戶整合到一個隊列--你可以以此獲得在什么級別下虛擬用戶性能平穩(wěn)的結(jié)果曲線。你也可以用它來模擬用于示范或研究目的的不同負載。

用于SQL Server上的HammerDB的優(yōu)缺點

HammerDB是一個免費工具，它也極易訪問和快速的啟動基準測試和模擬負載的方法。它的自動程序特性也是的運行工作負載相當自動。

主要缺點是它有一個學習曲線。用戶界面不是很直觀，需要花費時間去習慣。再你使用這個工具一段時間之后，將會更加容易。

HammerDB也不是運行每一個基準測試。它不運行TPC-E基準，例如，SQL Server更熱衷于當前更具發(fā)展的OLTP基準TPC-E。如果你用HammerDB運行一個TPC-C基準，你應(yīng)該理解它不能直接與供應(yīng)商提供的TPC-C基準結(jié)果相比較。但是，它是免費的、快速的、易用的。

基準測試使用案例

基準測試負載不能精確模擬你的應(yīng)用程序的特點。每個負載是唯一的，在不同的系統(tǒng)有不同的瓶頸。對于很多使用案例，使用預定義的基準測試仍然是非常有效的,包括以下性能的比較：

多個環(huán)境（例如：舊的物理服務(wù)器，新的虛擬環(huán)境）

使用各種因素的不同及時點（例如：使用共享存儲和共享主機資源的虛擬機的性能）

在配置改變前后的點

當然，對一個數(shù)據(jù)庫服務(wù)器運行基準測試可以影響其他SQL Server數(shù)據(jù)庫或者相同主機上其他虛擬機的性能，在生產(chǎn)環(huán)境你確保有完善的測試計劃。

對于自學和研究來說，有預配置的負載非常棒。

開始使用基準測試

你可以從閱讀HammerDB官方文檔的“SQL Server OLTP Load Testing Guide”開始。

怎樣利用緩存服務(wù)器來負載均衡

根據(jù)一些專家的調(diào)查分析，發(fā)現(xiàn)企業(yè)在使用數(shù)據(jù)庫的時候，90%以上主要用來查詢。有些企業(yè)這個比例甚至更高。也就說，用戶對數(shù)據(jù)庫的操作，其實更新操作占的比例很少。大部分的操走都只是查詢操作。

如一些論壇，大部分用戶只會看貼，而不會發(fā)帖。這就是一個典型的查詢操作比例大大超過更新操作比例的例子。針對這種情況，其查詢操作往往是其數(shù)據(jù)庫性能的瓶頸。如何有效提高查詢的性能，這就使各個數(shù)據(jù)庫專家在考慮的問題。在SQL Server數(shù)據(jù)庫中，已經(jīng)有了一個現(xiàn)成的解決方案。數(shù)據(jù)庫管理員可以利用緩存服務(wù)器來提高數(shù)據(jù)庫的性能。筆者這里就以SQLServer2008為例，談?wù)勅绾卫镁彺娣?wù)器來實現(xiàn)負載均衡，來提高數(shù)據(jù)庫的查詢效率。

一、 數(shù)據(jù)查詢與數(shù)據(jù)更新分開走。

如上圖所示，如果用戶要查看某個帖子，其就會打開某個連接。此時WEB應(yīng)用服務(wù)器就會從后臺數(shù)據(jù)庫中查詢相關(guān)的記錄。這里需要注意的是，由于其只是查看帖子，而不涉及到更新的操作，為此WEB應(yīng)用服務(wù)器就只從緩存服務(wù)器中讀取數(shù)據(jù)。這個緩存服務(wù)器中的記錄跟數(shù)據(jù)庫服務(wù)器的內(nèi)容是同步的。WEB應(yīng)用服務(wù)器在從數(shù)據(jù)庫緩存服務(wù)器讀取數(shù)據(jù)之前，還會先判斷一下哪臺數(shù)據(jù)庫服務(wù)器比較空。會優(yōu)先連接到比較空閑的數(shù)據(jù)緩存服務(wù)器中，然后從這臺服務(wù)器中讀取數(shù)據(jù)。所以，當訪問這個論壇的用戶比較多時，這個數(shù)據(jù)緩存服務(wù)器能夠?qū)崿F(xiàn)負載均衡的需要。

如果用戶看了某個帖子，現(xiàn)在需要發(fā)表一個評論，此時后臺數(shù)據(jù)庫會怎么操作呢?注意，當WEB應(yīng)用服務(wù)器發(fā)送了一個 Update更新操作的時候，其應(yīng)用服務(wù)器會自動連接到數(shù)據(jù)庫服務(wù)器，而不會再連接到數(shù)據(jù)庫緩存服務(wù)器。而是直接向數(shù)據(jù)庫服務(wù)器發(fā)送更新操走的語句。當數(shù)據(jù)庫服務(wù)器更新了相關(guān)的內(nèi)容之后，會與數(shù)據(jù)庫緩存服務(wù)器實現(xiàn)數(shù)據(jù)的同步。從上圖中可以看出，整個數(shù)據(jù)查詢與數(shù)據(jù)更新WEB應(yīng)用服務(wù)器是分兩條路走。其實這就好像是公路上分道行駛，機動車走機動車道;非機動車走非機動車道。

如此的話，就不會因為非機動車比較慢，而影響到機動車的速度。在這個方案中，將數(shù)據(jù)庫的更新操作與查詢操作分開來走，也是類似的道理。在查詢時，數(shù)據(jù)流是單向流動的，所以能夠在很大程度上提高查詢的效率。從而讓數(shù)據(jù)負載均衡的效果更加明顯。總之，當某個應(yīng)用程序查詢操作大大超過更新操作時，通過在多個數(shù)據(jù)庫間緩存只讀數(shù)據(jù)，并在數(shù)據(jù)庫間均勻連接客戶端以分發(fā)負載，則就可以向外擴展工作負荷的讀取分區(qū)，即實現(xiàn)負載均衡的目的。

二、 采用這個方案需要注意的地方。

在部署這個解決方案時，仍然有些數(shù)據(jù)庫管理員需要關(guān)注的內(nèi)容。如以下這些內(nèi)容，數(shù)據(jù)庫管理員需要根據(jù)企業(yè)的實際情況來進行調(diào)整，以提高這個方案的價值。

首先需要考慮數(shù)據(jù)緩存服務(wù)器與數(shù)據(jù)庫服務(wù)器之間同步的頻率問題。這個同步操作是一把雙刃劍。若同步的頻率太高，會影響數(shù)據(jù)庫服務(wù)器與緩存服務(wù)器的性能;若同步頻率比較低的話，則數(shù)據(jù)庫緩存服務(wù)器中的數(shù)據(jù)得不到及時的更新。

如此的話，用戶查詢時可能在短時間內(nèi)無法獲取最新的數(shù)據(jù)。所以，一般來說，系統(tǒng)滯后的時間應(yīng)該盡量的短，即數(shù)據(jù)庫服務(wù)器的更新內(nèi)容必須盡快與數(shù)據(jù)庫緩存服務(wù)器進行同步。

理想的狀態(tài)時，在更新數(shù)據(jù)庫服務(wù)器的同時更新數(shù)據(jù)庫緩存服務(wù)器。但是，這么做是以犧牲數(shù)據(jù)庫與數(shù)據(jù)庫緩存服務(wù)器的性能為代價的。為此數(shù)據(jù)庫管理員在實施這個解決方案時，往往不會這么做。而是設(shè)置在一段時間之后同步。如可以設(shè)置為10秒、60秒、300秒或者更長的時間后進行同步。

具體這個同步的時間間隔多少為好，沒有一個統(tǒng)一的標準。這需要數(shù)據(jù)庫管理員根據(jù)企業(yè)對數(shù)據(jù)同步的要求不同而定。一般來說，數(shù)據(jù)庫管理員在滿足用戶需要的前期下，可以將這個時間設(shè)置的相對長一點。這可以避免因為過多的同步操作而降低了這個方案的價值。其實，對于大部分用戶來說，60秒左右的時間差異還是可以接受的。如在論壇中，一個人發(fā)帖后，在一分鐘之后看到一般不會有什么問題。對于人的感覺來說，這個一分鐘時間不長。但是對于數(shù)據(jù)庫服務(wù)器來說，這一分鐘可以做很多事情。所以，適當延長這個同步時間，卻可以在很大程度上提高數(shù)據(jù)庫服務(wù)器性能。這個時間的代價，有時候還是值得的。

其次，在數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間，應(yīng)該建立比較直接的、快速的網(wǎng)絡(luò)連接。當用戶比較多時，數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間若發(fā)生同步操作，則會造成很多的網(wǎng)絡(luò)流量。有時候同步操作發(fā)生時，影響這個工作的效率可能并不是數(shù)據(jù)庫服務(wù)器或者數(shù)據(jù)庫緩存服務(wù)器本身，而是他們之間的網(wǎng)絡(luò)連接。

由于其可用的帶寬跟不少數(shù)據(jù)庫服務(wù)器系統(tǒng)的吞吐量，從而影響到了同步操作的效率。為此，在數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間的網(wǎng)路連接，應(yīng)該盡量的直接。如最好不要在中間夾著其他的不必要的網(wǎng)絡(luò)設(shè)備;也最好不要在他們之間配備防火墻等安全策略。這些安全策略與網(wǎng)絡(luò)設(shè)備都會在很大程度上影響到這個同步操作的效率。

另外，最好也不要有其他的應(yīng)用服務(wù)來爭搶帶寬。所以簡單的說，如果可能的話，在數(shù)據(jù)庫服務(wù)器上部署多張網(wǎng)卡，直接與數(shù)據(jù)庫源服務(wù)器實現(xiàn)雙機互聯(lián)，而那傳輸同步操作需要的數(shù)據(jù)，這是一個很不錯的手段。由于其數(shù)據(jù)傳輸更直接、而且其他設(shè)備或者應(yīng)用服務(wù)也會來爭奪其帶寬，同時又可以克服他們的非法攻擊。為此，只要他們之間多距離比較短的話，采用這種方案可能效果會比較好，可以在最大程度內(nèi)縮短這個同步操作所需要的時間，從而讓其他用戶盡早看到更新的數(shù)據(jù)。

第三為同步選擇合適的復制方案。

那么該如何實現(xiàn)數(shù)據(jù)庫服務(wù)器與緩存服務(wù)器之間的同步呢?在SQLServer數(shù)據(jù)庫中，有三個方案可供數(shù)據(jù)庫管理員選擇。這三個方案分別為快照復制、合并復制與事務(wù)復制。這三個復制模型各有各的特點。不過從最終效果來看，其都可以實現(xiàn)數(shù)據(jù)庫服務(wù)器與數(shù)據(jù)庫緩存服務(wù)器之間的同步。不過由于其內(nèi)部的實現(xiàn)機制不同，為此其雖然結(jié)果相同，但是從性能等方面考慮，還是有差異的。

各種復制模型的原理與特點屬于基本知識的范疇，筆者在這里就不做過多闡述了。筆者認為，在利用這個數(shù)據(jù)庫緩存服務(wù)器來實現(xiàn)負載均衡的方案中，最好采用事務(wù)復制的同步方案。因為相比其他方案來說，事務(wù)日志能夠滿足事務(wù)的一致性、數(shù)據(jù)庫服務(wù)器系統(tǒng)比較大的吞吐量、同步時盡量少的開銷、以及系統(tǒng)比較短的滯后時間等等需求。

另外在有些企業(yè)中采用這個方案的話，還要考慮到表與記錄的過濾需求。而通過事務(wù)復制的話，就可以實現(xiàn)對列和行的過濾。而其他復制模型的話，只能夠部分滿足這些需求。

所以，筆者認為，在選擇數(shù)據(jù)同步方案時，可能選擇事務(wù)復制來實現(xiàn)同步，更加的合適。不過最終是否真是如此，還是要求數(shù)據(jù)庫管理員根據(jù)企業(yè)的實際需要，然后分別采用幾個復制模型來進行測試，才能夠得出真正合理的結(jié)果。

SQLSERVER怎么搭建服務(wù)器集群實現(xiàn)負載均衡

很多組織機構(gòu)慢慢的在不同的服務(wù)器和地點部署SQL Server數(shù)據(jù)庫——為各種應(yīng)用和目的——開始考慮通過SQL Server集群的方式來合并。

將SQL Server實例和數(shù)據(jù)庫合并到一個中心的地點可以減低成本，尤其是維護和軟硬件許可證。此外，在合并之后，可以減低所需機器的數(shù)量，這些機器就可以用于備用。

當尋找一個備用，比如高可用性的環(huán)境，企業(yè)常常決定部署Microsoft的集群架構(gòu)。我常常被問到小的集群(由較少的節(jié)點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構(gòu)之后，我讓你們自己做決定。

什么是Microsoft集群服務(wù)器

MSCS是一個Windows Server企業(yè)版中的內(nèi)建功能。這個軟件支持兩個或者更多服務(wù)器節(jié)點連接起來形成一個“集群”，來獲得更高的可用性和對數(shù)據(jù)和應(yīng)用更簡便的管理。MSCS可以自動的檢查到服務(wù)器或者應(yīng)用的失效，并從中恢復。你也可以使用它來(手動)移動服務(wù)器之間的負載來平衡利用率以及無需停機時間來調(diào)度計劃中的維護任務(wù)。

這種集群設(shè)計使用軟件“心跳”來檢測應(yīng)用或者服務(wù)器的失效。在服務(wù)器失效的事件中，它會自動將資源(比如磁盤和IP地址)的所有權(quán)從失效的服務(wù)器轉(zhuǎn)移到活動的服務(wù)器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。

MSCS不要求在客戶計算機上安裝任何特殊軟件，因此用戶在災(zāi)難恢復的經(jīng)歷依賴于客戶-服務(wù)器應(yīng)用中客戶一方的本質(zhì)。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應(yīng)用、文件共享等等。進一步，為了災(zāi)難恢復，集群的節(jié)點可以處于分離的、遙遠的地點。

在集群服務(wù)器上的SQL Server

SQL Server 2000可以配置為最多4個節(jié)點的集群，而SQL Server 2005可以配置為最多8個節(jié)點的集群。當一個SQL Server實例被配置為集群之后，它的磁盤資源、IP地址和服務(wù)就形成了集群組來實現(xiàn)災(zāi)難恢復。

SQL Server 2000允許在一個集群上安裝16個實例。根據(jù)在線幫助，“SQL Server 2005在一個服務(wù)器或者處理器上可以支持最多50個SQL Server實例，”但是，“只能使用25個硬盤驅(qū)動器符，因此如果你需要更多的實例，那么需要預先規(guī)劃。”

注意SQL Server實例的災(zāi)難恢復階段是指SQL Server服務(wù)開始所需要的時間，這可能從幾秒鐘到幾分鐘。如果你需要更高的可用性，考慮使用其他的方法，比如log shipping和數(shù)據(jù)庫鏡像。

單個的大的SQL Server集群還是小的集群

下面是大的、由更多的節(jié)點組成的集群的優(yōu)點：

◆更高的可用新(更多的節(jié)點來災(zāi)難恢復)。

◆更多的負載均衡選擇(更多的節(jié)點)。

◆更低廉的維護成本。

◆增長的敏捷性。多達4個或者8個節(jié)點，依賴于SQL版本。

◆增強的管理性和簡化環(huán)境(需要管理的少了)。

◆更少的停機時間(災(zāi)難恢復更多的選擇)。

◆災(zāi)難恢復性能不受集群中的節(jié)點數(shù)目影響。

下面是單個大的集群的缺點：

◆集群節(jié)點數(shù)目有限(如果需要第9個節(jié)點怎么辦)。

◆在集群中SQL實例數(shù)目有限。

◆沒有對失效的防護——如果磁盤陣列失效了，就不會發(fā)生災(zāi)難恢復。

◆使用災(zāi)難恢復集群，無法在數(shù)據(jù)庫級別或者數(shù)據(jù)庫對象級別，比如表，創(chuàng)建災(zāi)難恢復集群。

虛擬化和集群

虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發(fā)生問題。SQL Server實例可以在虛擬機上，但是性能可能會受用影響，這依賴于實例所消耗的資源。在虛擬機上安裝SQL Server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。

在這種靈活的架構(gòu)中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如，使用虛擬機上的SQL Server實例開發(fā)應(yīng)用。然后在你需要對開發(fā)實例進行壓力測試的時候，將它災(zāi)難恢復到集群中更強的物理機器上。

集群服務(wù)器可以用于SQL Server的高可用性、災(zāi)難恢復、可擴展性和負載均衡。單個更大的、由更多的節(jié)點組成的集群往往比小的、只有少數(shù)節(jié)點的集群更好。大個集群允許更靈活環(huán)境，為了負載均衡和維護，實例可以從一個節(jié)點移動到另外的節(jié)點。

網(wǎng)站欄目：sqlserver負載,win sqlserver負載均衡
URL標題：http://chinadenli.net/article25/dsgceji.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、ChatGPT、網(wǎng)站排名、動態(tài)網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)