請問一下 ms-sql之log檔要如何清除? 謝謝

把資料庫的復原模式設為簡單 ,就會 Truncate log on checkpoint

James兄 db預設之復原模式本為簡單 我的意思是DBrun了一段時間,log檔持續增長, 是否可清除? log檔的大小是否會影響sql? 謝

基本上如果復原模式是簡單時，那就會 Truncate log on checkpoint , 也就是說每次發生 checkpoint 的時候會把 Log 檔給清除 ( 但不會縮小 ) ,當需要紀錄 Log的時候他自然會去找可用的空間去使用 ,但如果您的 Log 檔會一直增加的話，建議您可以採用幾個步驟去處理 1. DBCC CheckDB 2. DBCC SHRINKDATABASE 如果做完以上兩個步驟都還不行的話 ,有一種暴力方式,就是先把資料庫 deattch , 把 Log刪除後再把資料庫 attach 上去 ,此時就會重建 Log 檔了。

引言: 基本上如果復原模式是簡單時，那就會 Truncate log on checkpoint , 也就是說每次發生 checkpoint 的時候會把 Log 檔給清除 ( 但不會縮小 ) ,當需要紀錄 Log的時候他自然會去找可用的空間去使用 ,但如果您的 Log 檔會一直增加的話，建議您可以採用幾個步驟去處理 1. DBCC CheckDB 2. DBCC SHRINKDATABASE 如果做完以上兩個步驟都還不行的話 ,有一種暴力方式,就是先把資料庫 deattch , 把 Log刪除後再把資料庫 attach 上去 ,此時就會重建 Log 檔了。

SORRY, 插花一下 我也是有這個狀況, 我的檔案 MDF 有 7G, 而 LDF(LOG檔)高達4.7G, 我花了所有的精力, 也花了兩週, 試過所有可能的方法全部無法將LOG清掉, 包含 資料庫設"簡易", 備份後回存--無效 重建資料庫, 設定LOG檔案大小, 回存資料或重新匯入 --無效, 如果使用重新匯入時, 一共有1200TABLE, 大約到400個TABLE 就出現 LOG檔已滿, 請備份LOG檔後, 釋放部份資源再做, 我必須變成一次一個的匯入(還不一定成功, 必要時得重開機), 回存時不將LOG掛入--無效 最後嘗試上面網友提供的方式, DEATTCH後刪除LOG檔, 重新ATTCH後, 資料庫根本無法附上, 因為會出現找不到 LOG...., 結果整個資料庫毀掉, 請問是否還有更安全, 更好的方法可以做呢? 我已經瘋掉了! 因為LOG檔無法清除, 我現在在新增欄位或資料時, 三不五時都會出現 LOG已滿的錯誤, 問題是我設定LOG是無限增長, 硬碟容量也確定足夠(80G*3, RAID5) 我用WIN2000 SQL2000, 難道 SQL發展到現在沒有對LOG有更人性化的處理方式?

引言: 請問一下 ms-sql之log檔要如何清除? 謝謝

最近也有客戶反應，試了之後可以用壓縮的方式解決，可能是異動太大，在SQL Server清掉Log後，空間沒釋放，壓縮後就得到釋放了，試試看吧！ 資料庫名稱按滑鼠右鍵→所有工作→壓縮資料庫→檔案→確定

人生有夢，逐夢而行。 人若為善，福雖未至，禍已遠離。 人若為惡，禍雖未至，福已遠離。 http://www.taconet.com.tw/jieshu/

引言: 最近也有客戶反應，試了之後可以用壓縮的方式解決，可能是異動太大，在SQL Server清掉Log後，空間沒釋放，壓縮後就得到釋放了，試試看吧！ 資料庫名稱按滑鼠右鍵→所有工作→壓縮資料庫→檔案→確定

可是版主! 我看過不少本的書提到, 如果執行壓縮資料庫, 如果以後資料在進行大量交易時會嚴重影響SQLserver的效能, 所以如果資料經常性的做大量交易時, 不建議使用壓縮方式, 另外我測試過(反正也耗了這麼多時間, 多一點也無所謂啦), 我在壓縮時也會產生log資料已滿, 要我做備份的錯誤, 或者是 primary檔案或檔案群組已無空間可以作業.... 等錯誤訊息, 這可真的把我搞死! 我最後是放棄所有的檔案, 拿原來的原始檔(dbf)一個一個重新匯入及建立資料表, 搞了四天總算全部加入, 然後看log檔只有不到1G大小, 我趕緊把LOG檔備份起來, 以後萬一增大時, 我再把LOG還原回來, 我想應該可以吧!

小弟提供個人的經驗給大家參考 儘量在沒有人使用資料庫時, 進行下列動作 truncat transcation log shink database 反覆作此一動作, 直到database size 不會再降下為止, 如此log檔的大小也會變小. 會有此現象, 小弟想可能是MSSQL對大量的log無法一次處理完畢, 批次處理所產生的狀況吧? 提供給大家參考.

引言: 可是版主! 我看過不少本的書提到, 如果執行壓縮資料庫, 如果以後資料在進行大量交易時會嚴重影響SQLserver的效能, 所以如果資料經常性的做大量交易時, 不建議使用壓縮方式, 另外我測試過(反正也耗了這麼多時間, 多一點也無所謂啦), 我在壓縮時也會產生log資料已滿, 要我做備份的錯誤, 或者是 primary檔案或檔案群組已無空間可以作業.... 等錯誤訊息, 這可真的把我搞死! 我最後是放棄所有的檔案, 拿原來的原始檔(dbf)一個一個重新匯入及建立資料表, 搞了四天總算全部加入, 然後看log檔只有不到1G大小, 我趕緊把LOG檔備份起來, 以後萬一增大時, 我再把LOG還原回來, 我想應該可以吧!

1.這是相對的，魚與熊掌不可兼得，但是你可以取一個平衡點，它也可設定壓縮到幾MB。 2.可能你的硬碟空間真的所剩無幾了，連做壓縮要用的暫存空間都不過。 3.Log還原不曉得會影響到什麼，這我不清楚，你可看線上叢書，K一下吧。

人生有夢，逐夢而行。 人若為善，福雖未至，禍已遠離。 人若為惡，禍雖未至，福已遠離。 http://www.taconet.com.tw/jieshu/

引言: 1.這是相對的，魚與熊掌不可兼得，但是你可以取一個平衡點，它也可設定壓縮到幾MB。

對SQL來說, 要取得平衡點不是我這樣的升斗小民可以決定計算得出來, 這似乎太困難了, 所以我還是捨棄壓縮!

引言: 2.可能你的硬碟空間真的所剩無幾了，連做壓縮要用的暫存空間都不過。

我的空間絕對沒有問題, RAID5格式每顆80G, 一共4顆, 240G, 我就不相信SQL會全部把我吃光光, 我至少還有(目前)200G

引言: 3.Log還原不曉得會影響到什麼，這我不清楚，你可看線上叢書，K一下吧。<

我手上有十來本書(包含原文), 似乎沒有看到那一本有提到將舊LOG還原到資料庫會產生何種情況與影響, 這可能要靠各位網友是否有實際的"慘痛"經驗可以分享, 我現在是不太敢去嘗試, 也還沒有足夠的記錄可以試試!

引言: 1.對SQL來說, 要取得平衡點不是我這樣的升斗小民可以決定計算得出來, 這似乎太困難了, 所以我還是捨棄壓縮! 2.我的空間絕對沒有問題, RAID5格式每顆80G, 一共4顆, 240G, 我就不相信SQL會全部把我吃光光, 我至少還有(目前)200G 3.我手上有十來本書(包含原文), 似乎沒有看到那一本有提到將舊LOG還原到資料庫會產生何種情況與影響, 這可能要靠各位網友是否有實際的"慘痛"經驗可以分享, 我現在是不太敢去嘗試, 也還沒有足夠的記錄可以試試!

1.這就是為什麼會有資料庫管理師的出現，身為程式設計師的我們，只能作簡單的操作，沒有時間深入了解，在此僅提供個人經驗參考。 2.那會不會是SQL本身的問題，有沒有Update到sp2，我操作的時候並不會出現錯誤。 3.我只有一本SQL6.5的書(真是太混了)，都是靠線上叢書維生，據了解Log檔是異動紀錄，在OnLineBook上看到好像可以有第一次的備份，就可將資料回復到某一時間點(當然在後來的MDF和LOG檔都要完整才行)，所以還原舊的LOG檔應該和Truncate log差不多，就是無法做還原到Truncate log前的狀態，當然這種只有在不得已的情況下才會用到，如果不Care的話就沒關係。 以上僅是個人認知，並不保證一定是對的，僅供網友參考！

人生有夢，逐夢而行。 人若為善，福雖未至，禍已遠離。 人若為惡，禍雖未至，福已遠離。 http://www.taconet.com.tw/jieshu/

引言: 3.我只有一本SQL6.5的書(真是太混了)，都是靠線上叢書維生，據了解Log檔是異動紀錄，在OnLineBook上看到好像可以有第一次的備份，就可將資料回復到某一時間點(當然在後來的MDF和LOG檔都要完整才行)，所以還原舊的LOG檔應該和Truncate log差不多，就是無法做還原到Truncate log前的狀態，當然這種只有在不得已的情況下才會用到，如果不Care的話就沒關係。 以上僅是個人認知，並不保證一定是對的，僅供網友參考！[/green]

哦, 一本書不代表混, 有的人喜歡使用onlinehelp, 而我自己很不喜歡onlinehelp, 覺得要查一個東西很麻煩, 所以我才會不斷的去買書來看, 而且看多別人寫的書還可以參照各家寫法, 從中可能會發現一些不為人知的東東! 其實SQL的 log 並無太大作用, 因為好像我也無法看到 log 內容, 所以我在建資料庫時, 根本就不想要, 只要SQL強迫每一個資料庫一定要掛一個, 不知道為什麼? 不知各位網友是否有SQL方面有關 log 的經驗或可以公開的技術分享?

MS-SQL的Log File記錄著每一筆異動的交易,包括Insert/Update/Delete的過程,您可以使用Enterprise管理工具內的提供的壓縮功能來讓Log File變小,但時間一久Log File又會變大,若覺得經常性的壓縮很麻煩,可以在Enterprise管理工具內的排程設定為自動定時壓縮,就可以解決Log File一直長大的問題!    還有Log File雖然很大很討厭,有時甚至比資料庫主檔還大,但它還是有優點的,站長剛好看到一套軟體可以View Log File,也可以從Log File中還原某一筆記錄,或還原某一個Table,甚至還原整個資料庫,這套軟體叫作Log Explore For MS SQL Server,相關資料請見http://www.openpath.com.tw/,列出該軟體的圖片: ～～～Delphi K.Top討論區站長～～～

------
～～～Delphi K.Top討論區站長～～～

容小弟插嘴一下 ,看到站長介紹的那個產品 ,小弟我倒是覺得那個有點像是 進階的 SQL Profiler,或許跟Trancion Log沒有太大的關聯 ,一般來說 ,Log 檔的用途是看不到的 ,但可以從幾個地方看到他的重要性... 1.不正常斷線或是當機時，當下次重新啟動時 ,您可以從 SQL Server 的 Eventlog 中看到一些有關於 Roll Back or Roll Forward 的處理 ,確保 資料的一致性 ,這就是 Log 很重要的功能之一 2.資料庫的 Backup Tranction Log & Backup File or Filegroup 的時候 , Log 檔也扮演重要的角色。 3.Standby Server 的架構也是透過 Log 處理的機制才能達到的... 小弟想了以上三點 ,我想還有其他的地方可以來說明 ,Log 並不是可有可無的 , 套句廣告詞 "這是一定要的啦"

引言: 容小弟插嘴一下 ,看到站長介紹的那個產品 ,小弟我倒是覺得那個有點像是 進階的 SQL Profiler,或許跟Trancion Log沒有太大的關聯 ,一般來說 ,Log 檔的用途是看不到的 ,但可以從幾個地方看到他的重要性... 1.不正常斷線或是當機時，當下次重新啟動時 ,您可以從 SQL Server 的 Eventlog 中看到一些有關於 Roll Back or Roll Forward 的處理 ,確保 資料的一致性 ,這就是 Log 很重要的功能之一 2.資料庫的 Backup Tranction Log & Backup File or Filegroup 的時候 , Log 檔也扮演重要的角色。 3.Standby Server 的架構也是透過 Log 處理的機制才能達到的... 小弟想了以上三點 ,我想還有其他的地方可以來說明 ,Log 並不是可有可無的 , 套句廣告詞 "這是一定要的啦"

原來 log 具有這麼大的角色! 真是孤陋寡聞, 謝謝各位網友指教!

引言: 看到站長介紹的那個產品 ,小弟我倒是覺得那個有點像是 進階的 SQL Profiler,或許跟Trancion Log沒有太大的關聯 ,一般來說 ,Log 檔的用途是看不到的...

等站長申請到試用版,真正使用過後,再向各位報告使用心得! ～～～Delphi K.Top討論區站長～～～

期待站長您的測試結果了 ,如果真的可以讀取 Log 檔案的話 ,那看來 MS 就 有提供 API 或者是其他之類的方式去讀取了.....

引言: 期待站長您的測試結果了 ,如果真的可以讀取 Log 檔案的話 ,那看來 MS 就 有提供 API 或者是其他之類的方式去讀取了.....

嗨, 我又來了, 以下做一些我實作報告 1.原先我提到將第一次的LOG檔備份, 留到日後萬一LOG檔太大時可以還原, 結果實測不可行, 因為會發生無法還原的錯誤 2.站長提到的那個軟體, 我測試過(向該公司申請), 另也請問該公司的技術支援, 該套無法對LOG記錄做任何廋身的行為, 只能對LOG記錄做還原或備份, 日後也沒有對LOG做這類功能的打算 3.利用簡易模式或備份或壓縮方式對LOG瘦身, 效能很不好, 甚至沒有用, 我用壓縮方式對 4.7G的LOG進行, 做了三個小時仍無效, 而且做到一半會出現"資料庫XXXX 記錄檔案已滿, 請備份記錄的交易記錄來釋放部份的記錄檔空間", 問題是我做了備份, LOG檔並沒有減少的情況, 所以我快瘋了! 是不是還有其他網友對SQL管理有更深的研究可以幫幫小弟吧! 謝謝!

online help 對log檔主要的用途就如同 James兄所言。 要是一部 server 常常當，大概也會要老板買新的吧！ 所以有必要讓 log 檔無限制的增長嗎？ 個人無法相信使用者還會去對2年前的資料做rollback. 一般資料不正確，是不是求助資管人員或程式設計人員直接修改資料庫中的資料，才是正解呢？ 以上純屬個人看法。

引言: 1.原先我提到將第一次的LOG檔備份, 留到日後萬一LOG檔太大時可以還原, 結果實測不可行, 因為會發生無法還原的錯誤

當然不行囉 ,因為時間點已經不相符了啊...

引言: 2.站長提到的那個軟體, 我測試過(向該公司申請), 另也請問該公司的技術支援, 該套無法對LOG記錄做任何廋身的行為, 只能對LOG記錄做還原或備份, 日後也沒有對LOG做這類功能的打算 3.利用簡易模式或備份或壓縮方式對LOG瘦身, 效能很不好, 甚至沒有用, 我用壓縮方式對 4.7G的LOG進行, 做了三個小時仍無效, 而且做到一半會出現"資料庫XXXX 記錄檔案已滿, 請備份記錄的交易記錄來釋放部份的記錄檔空間", 問題是我做了備份, LOG檔並沒有減少的情況, 所以我快瘋了! 是不是還有其他網友對SQL管理有更深的研究可以幫幫小弟吧! 謝謝!

當然啦 ,Log 不可能因為那些軟體而有些改變 ,除非他改變 MSSQL 的行為 ,但 是想請問 PD 兄 ,我真的很好奇為什麼你所謂 "利用簡易模式或備份或壓縮方 式對LOG瘦身, 效能很不好" ,我試過了好幾次都沒有遇過您所謂的問題 , 或許 你要不是要試試看一個方式 , 1.先建立一個資料庫 ,設定資料庫的復原模式為簡易 。 2.把資料庫利用 DTS 把原來的資料庫轉到新的資料庫上。 3.在檢查看看是否新的資料庫還有類似的情況。 4.如果沒有問題的話 ,把原本的資料庫改成 , 把新的資料庫rename成為舊的。 [/quote]

不知道這篇文章如何又被翻出來判讀, 不過我記得之前有一位網友提點一個 做法, 而且我做過的確效果很好, 提供給大家參考 萬一 log 過大的懶人做法 1.卸離該資料庫 2.直接刪除該 ldf 檔 (log) 3.重新附加回來, 系統就會自動建立新的log, 而且只有不到 1M 當然如果你想保留 log 內的異動狀況, 以上方法完全不適用~

引言: online help 對log檔主要的用途就如同 James兄所言。 要是一部 server 常常當，大概也會要老板買新的吧！ 所以有必要讓 log 檔無限制的增長嗎？ 個人無法相信使用者還會去對2年前的資料做rollback. 一般資料不正確，是不是求助資管人員或程式設計人員直接修改資料庫中的資料，才是正解呢？ 以上純屬個人看法。

我也有同樣的困擾。 如果限制log的大小，不就會遇到log空間已滿的訊息嗎? --- Azi

我是这样解决的： 1.确认log文档已太大了； 2.detach 此database; 3.del log文档 4.attach 此database后,会自动生成一个很小的log文档 其实p.d.大大已经说得很清楚了. 發表人 - luowy651 於 2004/01/19 17:18:50

我也遇到同樣的問題，這是用google找到的原文詳見下方URL位置 http://forum.tpc.edu.tw/ShowPost.aspx?PostID=3172 我依照下列方法很輕易的清除Log檔過大的問題。 我清除的資料庫是SQL SERVER 2000 摘錄部分資訊如下： SQLserver 資料庫的LOG檔大的跟牛一樣,請問該怎麼辦? 可以利用以下的方法比較快： 1. 先將 Transaction Log 清掉 BACKUP LOG WITH NO_LOG 2. 利用 sp_helpdb 找出 DB 的 log file 的 logical name 一般預設的名稱是 _log 3. 將 Logfile 檔案變成指定大小的 size DBCC SHRINKFILE ( , ) ex. DBCC SHRINKFILE(ABC_log,3) 這樣就可以不須要停掉 DB 伺服器 至於要自動覆蓋記錄檔？這個 SQL Server 2000 並不支援，不過您可以利用 BACKUP LOG WITH NO_LOG 的指令，定期清除記錄檔，或是是將復原模式改成 simply 或是 Bulk-Logged 如果交易記錄檔對您的復原並不重要

因為 log 真的很少用到 就乾脆設定 AutoClose, trunc. log, autoshrink 都開 True rollback 也是用 "簡單"    SQL 語法如下 exec sp_dboption N'aDATEBASE', N'autoclose', N'true' exec sp_dboption N'aDATEBASE', N'trunc. log', N'true' exec sp_dboption N'aDATEBASE', N'autoshrink', N'true'    在我這樣的設定下, 只有以下情況 log 會暴大 ●修改 table 欄位等等 ●Delete 大量 Record ●單一批次的交易(也就是一次SQL指令), 動到太多筆資料 ●當然還有其他我不知道的.. 儘量減少上述情況發生 然後常做