ms-sql之log檔? |
|
bear
一般會員 發表:8 回覆:6 積分:2 註冊:2002-07-19 發送簡訊給我 |
|||
James
高階會員 發表:10 回覆:290 積分:220 註冊:2002-07-25 發送簡訊給我 |
|||
bear
一般會員 發表:8 回覆:6 積分:2 註冊:2002-07-19 發送簡訊給我 |
|||
James
高階會員 發表:10 回覆:290 積分:220 註冊:2002-07-25 發送簡訊給我 |
基本上如果復原模式是簡單時,那就會 Truncate log on checkpoint ,
也就是說每次發生 checkpoint 的時候會把 Log 檔給清除 ( 但不會縮小 )
,當需要紀錄 Log的時候他自然會去找可用的空間去使用 ,但如果您的 Log
檔會一直增加的話,建議您可以採用幾個步驟去處理
1. DBCC CheckDB
2. DBCC SHRINKDATABASE 如果做完以上兩個步驟都還不行的話 ,有一種暴力方式,就是先把資料庫
deattch , 把 Log刪除後再把資料庫 attach 上去 ,此時就會重建 Log
檔了。
|
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 基本上如果復原模式是簡單時,那就會 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有更人性化的處理方式? |
||
jieshu
版主 發表:42 回覆:894 積分:745 註冊:2002-04-15 發送簡訊給我 |
引言: 請問一下 ms-sql之log檔要如何清除? 謝謝最近也有客戶反應,試了之後可以用壓縮的方式解決,可能是異動太大,在SQL Server清掉Log後,空間沒釋放,壓縮後就得到釋放了,試試看吧! 資料庫名稱按滑鼠右鍵→所有工作→壓縮資料庫→檔案→確定
------
人生有夢,逐夢而行 人若為善,福雖未至,禍已遠離 人若為惡,禍雖未至,福已遠離 http://www.taconet.com.tw/jieshu/ |
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 最近也有客戶反應,試了之後可以用壓縮的方式解決,可能是異動太大,在SQL Server清掉Log後,空間沒釋放,壓縮後就得到釋放了,試試看吧! 資料庫名稱按滑鼠右鍵→所有工作→壓縮資料庫→檔案→確定可是版主! 我看過不少本的書提到, 如果執行壓縮資料庫, 如果以後資料在進行大量交易時會嚴重影響SQLserver的效能, 所以如果資料經常性的做大量交易時, 不建議使用壓縮方式, 另外我測試過(反正也耗了這麼多時間, 多一點也無所謂啦), 我在壓縮時也會產生log資料已滿, 要我做備份的錯誤, 或者是 primary檔案或檔案群組已無空間可以作業.... 等錯誤訊息, 這可真的把我搞死! 我最後是放棄所有的檔案, 拿原來的原始檔(dbf)一個一個重新匯入及建立資料表, 搞了四天總算全部加入, 然後看log檔只有不到1G大小, 我趕緊把LOG檔備份起來, 以後萬一增大時, 我再把LOG還原回來, 我想應該可以吧! |
||
Wesly
中階會員 發表:14 回覆:103 積分:53 註冊:2002-05-31 發送簡訊給我 |
|||
jieshu
版主 發表:42 回覆:894 積分:745 註冊:2002-04-15 發送簡訊給我 |
引言: 可是版主! 我看過不少本的書提到, 如果執行壓縮資料庫, 如果以後資料在進行大量交易時會嚴重影響SQLserver的效能, 所以如果資料經常性的做大量交易時, 不建議使用壓縮方式, 另外我測試過(反正也耗了這麼多時間, 多一點也無所謂啦), 我在壓縮時也會產生log資料已滿, 要我做備份的錯誤, 或者是 primary檔案或檔案群組已無空間可以作業.... 等錯誤訊息, 這可真的把我搞死! 我最後是放棄所有的檔案, 拿原來的原始檔(dbf)一個一個重新匯入及建立資料表, 搞了四天總算全部加入, 然後看log檔只有不到1G大小, 我趕緊把LOG檔備份起來, 以後萬一增大時, 我再把LOG還原回來, 我想應該可以吧!1.這是相對的,魚與熊掌不可兼得,但是你可以取一個平衡點,它也可設定壓縮到幾MB。 2.可能你的硬碟空間真的所剩無幾了,連做壓縮要用的暫存空間都不過。 3.Log還原不曉得會影響到什麼,這我不清楚,你可看線上叢書,K一下吧。
------
人生有夢,逐夢而行 人若為善,福雖未至,禍已遠離 人若為惡,禍雖未至,福已遠離 http://www.taconet.com.tw/jieshu/ |
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 1.這是相對的,魚與熊掌不可兼得,但是你可以取一個平衡點,它也可設定壓縮到幾MB。對SQL來說, 要取得平衡點不是我這樣的升斗小民可以決定計算得出來, 這似乎太困難了, 所以我還是捨棄壓縮! 引言: 2.可能你的硬碟空間真的所剩無幾了,連做壓縮要用的暫存空間都不過。我的空間絕對沒有問題, RAID5格式每顆80G, 一共4顆, 240G, 我就不相信SQL會全部把我吃光光, 我至少還有(目前)200G 引言: 3.Log還原不曉得會影響到什麼,這我不清楚,你可看線上叢書,K一下吧。<我手上有十來本書(包含原文), 似乎沒有看到那一本有提到將舊LOG還原到資料庫會產生何種情況與影響, 這可能要靠各位網友是否有實際的"慘痛"經驗可以分享, 我現在是不太敢去嘗試, 也還沒有足夠的記錄可以試試! |
||
jieshu
版主 發表:42 回覆:894 積分:745 註冊:2002-04-15 發送簡訊給我 |
引言: 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/ |
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 3.我只有一本SQL6.5的書(真是太混了),都是靠線上叢書維生,據了解Log檔是異動紀錄,在OnLineBook上看到好像可以有第一次的備份,就可將資料回復到某一時間點(當然在後來的MDF和LOG檔都要完整才行),所以還原舊的LOG檔應該和Truncate log差不多,就是無法做還原到Truncate log前的狀態,當然這種只有在不得已的情況下才會用到,如果不Care的話就沒關係。 以上僅是個人認知,並不保證一定是對的,僅供網友參考![/green]哦, 一本書不代表混, 有的人喜歡使用onlinehelp, 而我自己很不喜歡onlinehelp, 覺得要查一個東西很麻煩, 所以我才會不斷的去買書來看, 而且看多別人寫的書還可以參照各家寫法, 從中可能會發現一些不為人知的東東! 其實SQL的 log 並無太大作用, 因為好像我也無法看到 log 內容, 所以我在建資料庫時, 根本就不想要, 只要SQL強迫每一個資料庫一定要掛一個, 不知道為什麼? 不知各位網友是否有SQL方面有關 log 的經驗或可以公開的技術分享? |
||
領航天使
站長 發表:12216 回覆:4186 積分:4084 註冊:2001-07-25 發送簡訊給我 |
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討論區站長~~~ |
||
James
高階會員 發表:10 回覆:290 積分:220 註冊:2002-07-25 發送簡訊給我 |
容小弟插嘴一下 ,看到站長介紹的那個產品 ,小弟我倒是覺得那個有點像是
進階的 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 並不是可有可無的 ,
套句廣告詞 "這是一定要的啦"
|
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 容小弟插嘴一下 ,看到站長介紹的那個產品 ,小弟我倒是覺得那個有點像是 進階的 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 具有這麼大的角色! 真是孤陋寡聞, 謝謝各位網友指教! |
||
領航天使
站長 發表:12216 回覆:4186 積分:4084 註冊:2001-07-25 發送簡訊給我 |
|||
James
高階會員 發表:10 回覆:290 積分:220 註冊:2002-07-25 發送簡訊給我 |
|||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
引言: 期待站長您的測試結果了 ,如果真的可以讀取 Log 檔案的話 ,那看來 MS 就 有提供 API 或者是其他之類的方式去讀取了.....嗨, 我又來了, 以下做一些我實作報告 1.原先我提到將第一次的LOG檔備份, 留到日後萬一LOG檔太大時可以還原, 結果實測不可行, 因為會發生無法還原的錯誤 2.站長提到的那個軟體, 我測試過(向該公司申請), 另也請問該公司的技術支援, 該套無法對LOG記錄做任何廋身的行為, 只能對LOG記錄做還原或備份, 日後也沒有對LOG做這類功能的打算 3.利用簡易模式或備份或壓縮方式對LOG瘦身, 效能很不好, 甚至沒有用, 我用壓縮方式對 4.7G的LOG進行, 做了三個小時仍無效, 而且做到一半會出現"資料庫XXXX 記錄檔案已滿, 請備份記錄的交易記錄來釋放部份的記錄檔空間", 問題是我做了備份, LOG檔並沒有減少的情況, 所以我快瘋了! 是不是還有其他網友對SQL管理有更深的研究可以幫幫小弟吧! 謝謝! |
||
天外來客
初階會員 發表:22 回覆:199 積分:44 註冊:2001-11-27 發送簡訊給我 |
|||
James
高階會員 發表:10 回覆:290 積分:220 註冊:2002-07-25 發送簡訊給我 |
引言: 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] |
||
P.D.
版主 發表:603 回覆:4038 積分:3874 註冊:2006-10-31 發送簡訊給我 |
|||
azi
一般會員 發表:10 回覆:39 積分:9 註冊:2002-05-27 發送簡訊給我 |
|||
luowy651
高階會員 發表:257 回覆:313 積分:114 註冊:2003-04-09 發送簡訊給我 |
|||
tpchen
一般會員 發表:3 回覆:7 積分:2 註冊:2003-08-24 發送簡訊給我 |
我也遇到同樣的問題,這是用google找到的原文詳見下方URL位置
http://forum.tpc.edu.tw/ShowPost.aspx?PostID=3172
我依照下列方法很輕易的清除Log檔過大的問題。
我清除的資料庫是SQL SERVER 2000 摘錄部分資訊如下:
SQLserver 資料庫的LOG檔大的跟牛一樣,請問該怎麼辦?
可以利用以下的方法比較快: 1. 先將 Transaction Log 清掉
BACKUP LOG
|
||
silence
一般會員 發表:9 回覆:17 積分:10 註冊:2003-06-04 發送簡訊給我 |
因為 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指令), 動到太多筆資料
●當然還有其他我不知道的.. 儘量減少上述情況發生
然後常做
|
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |