版大遭遇的'靈異'現象, 其實是SQL Server的設定在搞鬼...
我也常把正式資料庫備份出來, 再還原成另一個資料庫名當做測試資料庫, 我曾經試過把資料庫還原到已存在的資料庫的檔案, 但系統會回應檔案被鎖定無法覆寫的錯誤訊息.
所以版大不會遇到覆蓋的問題, 確定是不同的資料庫檔案....
請看下圖..
我用紅框標示的'自動成長'...一般來講, SQL Server預設為10%, 當檔案空間不夠時, 會以當時資料庫檔案的大小乘上10%的容量來增加資料庫檔案的大小.
所以, 原來有100MB, 不夠用時會成長為110MB的資料庫檔案大小.
講這個幹嘛呢?!就是說, SQL Server資料庫檔案的大小不是隨資料的增加而隨時增加, 而一次先增加個一大塊空間來預留存放空間.
因此, 版大的問題的答案就是...上次備份前增加的空間還很夠, 一直沒有遇到需要再加空間的情況, 所以, 備份後再還的資料庫檔案就和原資料庫檔案的大小都一直保持一樣沒變.
版大可以檢查Table的大小, 就可以比較出不同了.
SQL Server這種做法有利有弊...
利: 提升效能...
弊: 硬碟空間不足時就會出問題...
另外, 或許您會看到我PO的圖中的LOG檔案也不小...這是我的過錯, 我應該要做點DBA的工作去管理一下LOG檔了....
就報告到這裏, 我該去處理LOG檔太大的問題了....下回再聊...
Log檔只能被壓縮..這個壓縮的意思, 其實是把Log中已經Commit到資料庫中的記錄刪掉...也就是把Checkpoint向前拉..然後把Check過的記錄由Log中刪掉...然後釋放沒用到的空間..
因為Log一定要預留空間來放交易記錄, 所以, Log檔案大小不會為零...這不是說不會清空...Log檔內容可以清空, 但Log檔一定會預留一定大小的空間來因應資料庫運作
我都是用...請先做一次完整備份再執行...
<pre class="c" name="code">BACKUP LOG MyDB WITH TRUNCATE_ONLY
DBCC SHRINKFILE ('MyDB_Log', 2) --- MyDB_Log請改成您的環境中Log檔名
SQL 2005應該不用BACKUP LOG .. with TRUNCATE ONLY..而是把Recovery Mode改成Simple(簡單), 然後做一次Full Backup...再執行SHRINKILE指令...
我執行完SHRINKFILE後, LOG檔就只有2MB大小了....
為什麼LOG檔會變麼大, 這和我家用的ERP系統的程式設計不好有關...
BACKUP LOG MyDB WITH TRUNCATE_ONLY ,此語法是什麼作用,第2行是執行壓縮了,是先備份完再壓縮,還壓縮完備份,我是請客服做,她和你一樣的方式,壓完變1024kb
wenchan提到:
壓完變1024kb
這應該是資料庫最早建立時的Log檔案大小規劃為1MB...SHRINKFILE指令會壓到盡量最小....
BACKUP LOG....TRUNCATE_ONLY指令是要備份LOG檔案但只做TRUNCATE的動作, TRUNCATE的意思就是把Checkpoint指到最近一次資料庫一致的地方...然後再用Shrinkfile指令把檔案清空...
但SQL 2005已經不這樣做了...所以, 我才說SQL 2005可以不用再執行BACKUP LOG指令..因為我是從SQL Server 6.5(10年前了)開始用的, 習慣養成要改也難...
還原時要修改目的資料庫檔名