2010-01-12 71 views
2

我有一個非常大的(100 +演出)SQL Server 2005數據庫,它接收大量的插入和更新,並且選擇頻率較低。這些選擇需要很多索引來保持它們的正常運行,但似乎索引的數量影響了插入和更新的效率。使用重複的SQL Server數據庫進行查詢

問題:是否有一種方法可以保留數據庫的兩個副本,其中一個用於插入和更新,而另一個則用於選擇?第二個副本不需要實時更新,但不應超過一個小時。是否可以在保留每個數據庫副本上的不同索引的同時進行這種複製?也許你有其他解決方案?

回答

4

您正在尋找使用複製來設置主/子數據庫拓撲。使用SQL服務器,您需要在兩個數據庫之間設置複製(最好在單獨的硬件上)。主數據庫您應該用於插入和更新。孩子將服務你所有的選擇查詢。您還需要優化他們將執行的工作類型的數據庫配置設置。如果您在子數據庫上有大量選擇查詢,則可能還需要設置視圖,以使查詢的表現比表上的複雜聯接更好。

上覆制一些參考材料:

http://technet.microsoft.com/en-us/library/ms151198.aspx

它只是谷歌,你會發現很多關於如何安裝和配置:

http://search.aim.com/search/search?&query=sql+server+2005+replication&invocationType=tb50fftrab

0

您可以安排一個bcp腳本來將數據複製到其他數據庫。

您還可以嘗試使用事務日誌傳送來更新只讀數據庫。

+0

謝謝。根據我的鏡像經驗,「鏡像」數據庫不可用於查詢。它始終處於「恢復」狀態。 – Charles 2010-01-12 17:28:06

+0

確實如此,因此鏡像不起作用。其他兩個選項可以工作。 – CraigF 2010-01-12 18:35:25

0

一般來說,所有集基於操作(包括更新索引)比非基於集合的操作更快

1,000插入將最有可能比插入的1,000記錄慢。

您可以批量更新到第二個數據庫。這將首先使索引更新更快,其次,平滑峯值。

1

事務複製可以做到這一點,因爲與發佈者相比,訂戶可以擁有多個aditional索引。但是您必須記住一個簡單的事實:所有插入/更新/刪除將在報告副本(訂閱者)處複製,並且aditional索引將會減慢複製速度。實際上可能會將複製速度放慢到無法跟上的速度,導致分佈數據庫的膨脹。但是,只有當您持續保持較高的更新率時纔會這樣。如果問題只發生在持續高峯時段,那麼分佈數據庫將作爲一個隊列來吸收峯值並在非高峯時段將其平穩化。

如果沒有絕對的,100%的證明證據證明這是額外的索引會減慢插入/更新/刪除,而沒有測試插入/更新/刪除實際上是否顯着沒有額外的索引更好。具體來說,確保罪魁禍首不是其他常見的嫌疑人:鎖爭奪。

0

不要忘記在創建兩個數據庫時調整填充因子。數據庫中頻率更新頻率應該較低,在「數據倉庫」/只讀數據庫中應該爲100。