2012-03-29 57 views
0

我對大型多模式數據庫有一個有趣的問題和要求。在大型數據庫中歸檔/備份表和更改的最佳方法

- 數據庫大小約爲130Gb。

- 它是一個多模式數據庫,每個客戶都有一個模式。

- 我們目前在系統中有102247個表格。

- 微軟的SQL Server 2K8 R2

這是由於客戶的定製要求,所有使用單一定義前端。 我們遇到的問題是我們的數據庫備份成爲天文數據並且爲恢復丟失/丟失/不正確的數據而執行數據庫恢復是一場噩夢。最初的產品沒有定義審計跟蹤,我們沒有對存儲數據進行「更改」,我們只有1個版本的數據。

丟失數據返回基本上意味着恢復完整的130GB備份並加載差異/事務文件以獲取數據。

我們想爲每個模式中的每個重要表格引入一個'Changeset'。基本上保存一組數據,然後保存任何修改/不同的數據 - 每X分鐘數。這將最初是一個SQL工作,但我想知道什麼是最好的方法。

本質上,我會運行一個腳本,將'備份'表插入到我們希望保留備份的表的每個模式中。

然後每X分鐘運行一次作業以遍歷每個模式並插入當前數據 - 然後插入新數據/更改後的數據,因爲它會發現更改。 (基於該行的修改日期)然後它將在自我覆蓋之前保留這個更新日誌大約一個月。

我們仍然有我們較大的備份,但我們不需要保留較長的保留期。我的觀點是,檢查更改的數據並執行插入操作的最好和最有效的方法是什麼?

我的直覺是:

INSERT INTO BACKUP_table (UNIQUE ID, col1,col2,col3) 
select col1,col2,col3 from table where and ModifiedDate < DATEADD(mi,+90,Current_TimeStamp) 

*粗糙SQL

這必須是在一個循環要經過所有模式並運行此。許多表格不會改變數據。

這是一個很好的方法嗎?

SO想什麼?

回答

1

我的第一個迴應是考慮將每個客戶保留在他們自己的數據庫中,而不是將他們自己的模式保存在海量數據庫中。到這樣做的主要好處是:

元數據
  1. 更強調單個數據庫
  2. 您可以在任何時間表你喜歡
  3. 當某個客戶有你的高活性每個客戶執行備份可以輕鬆地將它們

我管理好幾年了這樣的系統,在我以前的工作和管理500個數據庫沒有複雜得多,管理10,和你的應用程序的唯一區別是連接字符串的數據庫部分(這實際上更容易使查詢適應比架構前綴)。

如果你真的致力於使每個人都在一個數據庫中,那麼你可以考慮做什麼是存儲自己的文件組中每個架構內的重要的表,並移動所有的東西主文件組中。現在,你可以備份獨立的文件組的基礎上,僅全主備份和個人文件組備份的段落還原,您可以在其他位置聯機只是客戶的模式,並獲取你後的數據(也許將其複製到使用導入/導出,BCP,或簡單的DML查詢),而不必完全恢復整個數據庫中的主數據庫。移動所有用戶數據從主文件組的最小化才能恢復初始備份,讓你到恢復客戶的具體文件組的時間。雖然這使得您的備份/恢復策略稍微複雜一些,但它確實能夠實現我相信的目標。

另一種選擇是使用自定義日誌傳送實現與有意延遲。我們通過將我們的日誌發送到報告服務器來做了一段時間,但是在應用之前等待了12個小時。這給了我們客戶的保護搬起石頭砸自己的腳,然後需要恢復 - 如果他們12小時自己的錯誤之內與我們聯繫,我們可能已經有了「前螺桿式」在線數據在報表服務器上,使得它瑣碎將其修復到主服務器上。對於查看12小時以前的數據的報告,它還作爲報告服務器的兩倍,從主服務器上帶走大量負載。

您也可以考慮change data capture,但您顯然需要測試性能以及對其餘工作負載的影響。此解決方案還取決於您使用的SQL Server版本,因爲它不適用於標準,Web,Workgroup等。

相關問題