機(jī)房在四月份改造中對(duì)數(shù)據(jù)庫的軟硬件進(jìn)行了升級(jí)，具體情況是：原先舊有的數(shù)據(jù)庫是采用主備兩臺(tái)1u的單機(jī)，在windows 2000的系統(tǒng)下分別安裝好sql server 2000后，在主數(shù)據(jù)庫上做一天一次的完整備份和每隔兩小時(shí)的差異備份，在完整備份的同時(shí)進(jìn)行發(fā)布；備數(shù)據(jù)庫則對(duì)主數(shù)據(jù)庫的完整備份進(jìn)行訂閱。改造后的配置則是使用了帶兩個(gè)節(jié)點(diǎn)sdb01和sdb02的群集，并使用sdb03進(jìn)行原先的備數(shù)據(jù)庫的訂閱工作。由于sdb01和sdb02兩臺(tái)機(jī)器上使用了windows 2003的系統(tǒng)，考慮到使用群集的情況，選用sql server 2005的兼容性會(huì)更好。于是就需要將sql2000上的數(shù)據(jù)庫遷移到sql2005，根據(jù)網(wǎng)上的方法在sql2000上進(jìn)行了數(shù)據(jù)庫備份，然后在sql2005上新建一個(gè)同名數(shù)據(jù)庫，并使用還原數(shù)據(jù)庫的方法覆蓋該數(shù)據(jù)庫，接著對(duì)還原后的數(shù)據(jù)庫用戶進(jìn)行必要的修改，一切看似遷移成功。

但隨著時(shí)間遷移，發(fā)現(xiàn)日志文件逐漸變大，三四個(gè)月后竟然達(dá)到10g之巨。期間有嘗試過處理，方法如下：

1.清空日志
DUMP TRANSACTION 庫名 WITH NO_LOG

2.截?cái)嗍聞?wù)日志：
BACKUP LOG 數(shù)據(jù)庫名 WITH NO_LOG

3.收縮數(shù)據(jù)庫文件（如果不壓縮,數(shù)據(jù)庫的文件不會(huì)減小）
同時(shí)也注意到將數(shù)據(jù)庫的恢復(fù)模式從“完整”改為“簡(jiǎn)單”。但是操作后的日志非但沒有減小，反而略有增大。也考慮到是否要使用分離數(shù)據(jù)庫的方法將日志文件刪除后，再附加數(shù)據(jù)庫。但這只是治標(biāo)不治本的方法，且對(duì)系統(tǒng)的運(yùn)行存在影響。

這時(shí)看到一篇文章介紹，用DBCC UPDATEUSAGE命令修復(fù)數(shù)據(jù)庫的行記錄數(shù)，修復(fù)了一些錯(cuò)誤，但是還是無法收縮。根據(jù)該文章的提示，使用了這樣一個(gè)函數(shù)：DBCC OPENTRAN(Db_Name)，顯示類似下面的信息：

已復(fù)制的事務(wù)信息:
最早的分布式 LSN : (0:0:0)
最早的非分布式 LSN : (1051867:2025:1)
DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。

而在其它正常的數(shù)據(jù)庫上運(yùn)行這個(gè)命令，則沒有前面三行東西。接著使用了exec sp_removedbreplication ‘Db_Name’,奇跡出現(xiàn)了，該數(shù)據(jù)庫日志文件立馬減少到了1兆多。

為什么會(huì)出現(xiàn)這樣的情況呢？sp_removedbreplication的msdn解釋是：該存儲(chǔ)過程在發(fā)布服務(wù)器的發(fā)布數(shù)據(jù)庫中或在訂閱服務(wù)器的訂閱數(shù)據(jù)庫中執(zhí)行。 該過程將從執(zhí)行它的數(shù)據(jù)庫中刪除所有復(fù)制對(duì)象，但它不會(huì)從其他數(shù)據(jù)庫（例如，分發(fā)數(shù)據(jù)庫）中刪除對(duì)象。非常的拗口，難于理解。下面這句話相信同樣不好理解：如果將數(shù)據(jù)庫附加到的服務(wù)器不是該數(shù)據(jù)庫從中分離的服務(wù)器，并且啟用了分離的數(shù)據(jù)庫以進(jìn)行復(fù)制，則應(yīng)該運(yùn)行 sp_removedbreplication 從數(shù)據(jù)庫刪除復(fù)制。

換言之，通常如果你設(shè)置過數(shù)據(jù)庫復(fù)制或發(fā)布，而后來設(shè)置失敗并沒有啟用，可能會(huì)導(dǎo)致這個(gè)問題，你看不到跟復(fù)制有關(guān)的內(nèi)容，但是在數(shù)據(jù)庫里卻存在這樣的東西，于是日志被它堵住了，這成了一個(gè)永遠(yuǎn)無法完成的命令，所以后續(xù)的日志都無法截?cái)唷?zhí)行了這個(gè)命令以后，強(qiáng)制清除了復(fù)制內(nèi)容。

因此我們的日志文件變得過大且無法正常截?cái)鄦栴}的根源可能在于：從sql2000升級(jí)到sql2005的過程中存在兼容性問題或者sql2005存在bug，因?yàn)樵谏?jí)過后群集的數(shù)據(jù)庫發(fā)布與sdb03的訂閱是正常的。

轉(zhuǎn)載于:https://www.cnblogs.com/y0umer/archive/2011/07/05/3839314.html

總結(jié)

以上是生活随笔為你收集整理的sql server 2005日志文件过大问题解决后分析--针对发布订阅产生的日志问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。