五餅二魚工作室

就在準備收拾東西準備要下班時， Skype 忽然彈出一個訊息，一個同事詢問客戶端資料庫無法正常備份的狀況，只好先放在背包，看了一下傳來的圖片，從片段的訊息中實在很難想像那裡出了問題了。

因此決定透過遠端連線處理，直接下備份指令來查看一下問題發生的真正錯誤訊息，看看對問題是否有幫助，為了避免備份浪費時間和空間，因此我利用 BACKUP 到 NULL 裝置的方式來查看錯誤

BACKUP DATABASE [資料庫名稱]  TO DISK = 'NUL'

透過 SSMS 下指令之後，看起來問題似乎比較明顯一點了，有比較多的訊息可以參考。從錯誤訊息中似乎要我們用 DBCC CHECKDB 或者是 BACKUP LOG 的方式來處理，因此當下我們就直接使用 DBCC CHECKDB 來做檢查，但檢查的結果看起來一點問題也都沒有，看起來問題似乎比想像中的還要複雜了一些。

因此我決定用 SSMS 來針對這個有問題的資料庫，來檢查看看有沒有甚麼特殊的設定，造成中繼資料有不一致的狀況。此時我按照資料庫的屬性一個一個檢查，似乎全部都是採用預設值，沒有看到甚麼特別的地方；接著也針對資料庫下的物件也一個一個查看，就在要放棄之際，忽然發現一個很特殊的東西「全文檢索目錄」，似乎跟其他的資料庫不一樣，多了一個 Attach 的目錄 ?!

在印象中應該在我們系統內並沒有使用到全文檢索，但怎麼會有全文檢索目錄呢 ? 而當我們要刪除的時候，SSMS 也會顯示因為該資料庫並沒有設定全文檢索，因此也不能刪除全文檢索目錄。因此我們採用重新設定的方式來做處理。

-- 重新設定啟動全文檢索
EXEC [dbo].[sp_fulltext_database] @action = 'enable'
GO
 
-- 關閉全文檢索
EXEC [dbo].[sp_fulltext_database] @action = 'disable'
GO

很順利的，當重新設定 enable 再設定為 disable 之後，原本在 SSMS 上面顯示的全文檢索目錄 Attach 已經消失了。此時再重新使用  BACKUP NULL 的方式再做一次，果然就正常了。這時我們將原本有異常的排程手動去執行一次，也很順利的可以執行完畢，總算讓我完成這個「簡單任務」，看來這下可以順利回家去吃晚餐了。