SQL 2005：我應該推出自己的日誌傳送嗎？

Question

我正在研究使用日誌傳送進行災難恢復，並且我收到了關於是使用內置的東西還是滾動我自己的混合消息。你應該推薦哪一種，如果你喜歡自己推薦內置的東西有什麼問題？如果我要重新發明輪子，我不想犯同樣的錯誤！ （我們有工作組版）。提前致謝。

Answer 1

我試過內置的日誌傳送，發現一些真正的問題，所以我開發了我自己的。我在博客上寫了here。

PS：只是爲了記錄，您絕對會在Workgoup版本中獲得日誌傳送。我不知道這個企業唯一的事情在哪裏開始。

Answer 2

如果您決定推出自己的here's a nice guide。

我假設你要走這條路線，因爲企業版如此昂貴？

如果您不需要「實時備份」，但實際上只需要經常更新的備份，我認爲這種方法很有意義。

---

一件事：

請務必定期檢查您的備份策略的工作。

Answer 3

我很確定它在標準版中可用，因爲我們正在進行一些裝運，但我不確定工作組版 - 它相當簡單。

我總是贊成軟件包解決方案，但主要是因爲我相信整個MSFT開發團隊比我信任自己的團隊更多，但是這肯定會帶來價格。我想第二個你自己推出的任何解決方案都必須附帶一個滯後通知部分，以便您立即知道它是否無法正常工作 - 我們只發現多少次備份解決方案無法正常工作當有人需要備份？另外，誠實地思考一下您需要花多少時間來設計和推出自己的解決方案，包括錯誤修復和維護 - 您是否可以更廉價地做到這一點？也許你可以，但也許不可以。

此外，我們在Workgroup版中遇到的一個問題是，它一次只支持5個連接，並且如果您獲得的用戶數多於此值，似乎開始斷開連接，因此我們必須升級到Standard。我們遇到ASP.NET錯誤，如果我們的連接被關閉了幾秒鐘，我們的連接就會關閉，從而導致我們遇到各種問題。

Answer 4

我預計這將接近你想省下幾塊錢的最後一個地方，尤其是考慮到如果你搞砸的可能後果。你願意把你的工作放在線上嗎？我甚至不認爲我會承認，如果我覺得我有機會獲得這一個的權利？

你對此有什麼個人利益？

Answer 5

您是否考慮過鏡像？下面是一些documentation來確定，如果你能做到這一點，而不是

Answer 6

這確實兩個部分你的問題：

1. 原產日誌傳送不夠好？

2. 如果不是，我應該使用誰的日誌傳送？

這是我的兩分錢，但就像你已經發現，很多這是基於意見。

關於第一個問題 - 本地日誌傳送適用於小型實現 - 比如1-2臺服務器，少量數據庫和全職DBA。在這樣的環境中，本機日誌傳送缺乏監控，警報和管理不成問題。如果它打破了，你不會因爲修復相對容易而出現子彈。什麼時候會中斷？例如，如果某人在災難恢復服務器上恢復之前意外刪除了事務日誌備份文件。 （隨時都會使用自動化流程。）

當您超越幾臺服務器時，管理自動化的缺乏開始成爲問題。您希望獲得更好的自動電子郵件警報，日誌傳送時間超過X分鐘/小時時的警報，文件複製時間過長的警報，更容易處理多臺輔助服務器等。此時人們轉而採用備用解決方案。

關於第二個問題 - 我會這樣說。我爲LiteSpeed的製造商Quest Software工作，這是一款SQL Server備份恢復產品&。我經常與使用我們的產品和其他產品（如Idera SQLSafe和Red Gate SQL Backup）的數據庫管理員進行交流，以使他們的備份管理更加輕鬆。我們構建GUI工具來實現日誌傳送過程的自動化，爲您提供一個很好的圖形化儀表板，可以準確顯示瓶頸的位置，並幫助確保您的主要數據中心宕機時覆蓋您的屁股。我們出售許多許可證。 :-)

如果您推出自己的腳本 - 而且您當然可以 - 當您的數據中心宕機時，您將完全獨立。您將不需要支持熱線電話，您將不會有工具來幫助您，並且您無法告訴同事：「打開此GUI並單擊此處進行故障排除。」您將在災難中嘗試通過T-SQL腳本來引導他們。專家DBA有很多時間在他們手中有時更喜歡編寫他們自己的腳本，它確實給了你很多控制，但是你必須確保你有足夠的時間來構建它們並在你存入銀行之前測試它們就業。