2010-12-14 66 views
1

我想寫一份報告建議移動事務日誌到一個單獨的物理驅動器,但我需要提供一些數字。我有一些上個月完成的配置文件查詢。我試圖確定持續時間的減少百分比。我知道它不可能100%準確,但非常接近的數字就足夠了。幫助搞清楚性能增益的數學公式

查詢1 讀取:325229284 寫入:85989 持續時間:840732

查詢2 讀取:558955611 寫入:87066 持續時間:1015697

查詢3 讀取:422966141 寫入:85087 持續時間:918225

當前讀取和寫入發生在同一個驅動器上。我想移動它們,所以讀取是一個驅動器,寫入是另一個。我試圖弄清楚,假設寫入速度比讀取速度慢20%,但在尋道時間中並不平均。我在7%-15%之間,但不知道這些數字是否正確。假設驅動器搜索時間是平均1ms。

+3

不要假設。儘可能精確地鏡像系統,並進行實際測試。反駁事實比假設更難。 – 2010-12-14 17:39:22

回答

4

思考:

  • 讀/寫相關性通常是無關的日誌。它的排序在tempdb中,線軸等

  • 您將需要每個數據庫LDF一個額外的音量:否則你仍然有巨大的頭部運動和許多數據庫寫入到一個卷

  • 如果你不使用SAN,那麼要做到這一點,每卷的磁盤就會少一些。

  • 將tempdb移動到不同的捲上會有什麼好處。 SQL Server的2005+真的一巴掌tempdb數據庫相比老版本(如觸發tempdb中使用,而不是日誌)

  • MDF/LDF分割往往是恢復:如果數據卷失敗

    你可以備份日誌尾部
  • 如果查詢有422,966,141個讀取,然後修復您的代碼和索引。單獨的日誌驅動器正在重新安排泰坦尼克號上的躺椅。

+0

我同意,但與350GB數據庫和195GB日誌文件和從單個驅動器運行的一切,我試圖讓他們分開日誌,tempdb和索引分開驅動器以及歸檔歷史數據。在這一點上,查詢優化不會有所幫助。這只是開始。 – 2010-12-14 18:15:34