在 SQL Server 中進行備份時出錯
前幾個月的 SQL 框已經崩潰。我們幾乎用一些工具返回了數據庫，並在其上順利執行應用程序。但是當我當時嘗試備份數據庫時，它會給出如下錯誤，
傳遞給數據庫“****”中的日誌掃描的日誌掃描編號 (3533468:412:0) 無效。此錯誤可能表示數據損壞或日誌文件 (.ldf) 與數據文件 (.mdf) 不匹配。如果在復製過程中發生此錯誤，請重新創建發布。否則，如果問題導致啟動期間出現故障，請從備份中恢復。（Microsoft SQL Server，錯誤：9003）
有人能幫我解決這個問題嗎？
我什至嘗試複製數據庫，但我失敗了。
提前致謝。
ALTER DATABASE dssp SET EMERGENCY ALTER DATABASE dssp REBUILD LOG ON (NAME=dssp_log, FILENAME=‘E:\MSSQL\DATA\dssp_log1.LDF’) DBCC CHECKDB (dssp) ALTER DATABASE dssp SET MULTI_USER
工作正常…感謝大家的寶貴意見… :)
首先，您為什麼使用這些工具而不是簡單地從備份中恢復？我的猜測是，您沒有備份，或者您沒有足夠新的可用備份。好的，我們稍後再處理。
與此同時，如果我處於你的位置，我會~~更新我的簡歷並在上面撒上仙塵，~~創建一個新的空數據庫，然後開始將你所有的表、對象、使用者和程式碼移到新數據庫中（很多其中可以使用 Management Studio 中內置的嚮導或使用 Red Gate 的 SQL 比較/SQL 數據比較等 3rd 方工具來完成。完成後，您可以刪除以某種方式設法執行的 Frankenstein 數據庫（不確定“某些工具”是否值得讚揚 - 我認為它們根本沒有給您帶來任何大的好處）。刪除後，您可以重命名新數據庫，一切都應該恢復正常。
雖然您可以解決目前數據庫遇到的任何問題，例如
DBCC CHECKDB ... WITH REPAIR_ALLOW_DATA_LOSS，但您收到的錯誤消息聽起來比一些糟糕的頁面更令人髮指。我會盡快從這些文件中取出您的數據。接下來，我的意思是下一步，建立一個合理的備份和恢復策略。這不僅僅意味著進行備份，而是進行備份並定期測試您是否可以恢復它們。這個問題不是關於損壞或從崩潰的數據庫中恢復，但那裡的答案肯定會詳細說明不同恢復模型的來龍去脈。通常，每晚或每週進行一次完整備份是不夠的 - 您需要在兩者之間進行差異備份或日誌備份，以最大程度地減少伺服器崩潰時數據失去的可能性。正如我所說，僅僅進行備份是不夠的——你需要驗證你正在做的備份可以在不同的硬體上恢復——你知道，如果你目前的硬體完全崩潰了。
之後，聯繫這些“工具”的供應商並要求退款。這不是恢復數據的方法，而且他們顯然對您的數據庫做了一些無法恢復的事情，這需要您進行更多的手動工作。很遺憾，您沒有詢問崩潰最初發生時該怎麼做的問題，因為這裡的人們肯定能夠指導您採用更可靠的恢復方法。我發現通常使用這些工具的人承諾完全恢復可疑或損壞的數據庫，而不知道你可能對它做了什麼，只是因為被誤導和/或恐慌的Google搜尋而嘗試它們。這些供應商在 SEO 方面表現出色，但在實際兌現他們牽強的承諾方面並不那麼出色。