以 SQL server 的 IMAGE 資料類型存放圖片 儲存前已轉成 jpg 格式, (原本用 bmp, 但已逐筆轉成 jpg 再回存, 空間已經縮了一次) 把 2000 筆資料的 image 欄位擷取出來存檔, 只佔了 30 MB (因為其中只有 500 筆有實際存圖片, 所以只有 500 張) 但是, 資料庫檔卻需要佔用 500 MB (完整的資料達 18000 筆, 以 bmp 儲存用掉 27GB, 轉成 JPG 後縮成 15GB) 欄位數並不多, 只有 image 欄位比較特別而已 這樣子合理嗎? 還是有些什麼設定的技巧呢?

若是資料筆數不大的狀況下, 使用 db 存圖片資料還 ok. 但你的圖片這麼大, 弟建議你的圖片不要存入資料庫, 改用實體檔案的方式來存, 並在資料庫中記錄位置即可, 以避免不必要的資料庫空間浪費及效能增進!!

擷取出來的 JPG 檔, 每個的大小也才 70K 70K * 500 = 35MB 我的問題其實比較傾向 "SQL Server 的 IMAGE 欄位是不是佔用的空間, 比實際 BLOB 內容大" 或是 "SQL Server 的 IMAGE 欄位的原理" 剛剛試著把圖片清掉 --> TBlobField().Clear 資料庫壓縮 結果空間還是釋放不回來 問題來了 : 如何清除 Image 欄位佔用的空間??

或是把這個欄位給drop掉

DROP 掉看來並不是解決之道 因為要解決的是 "把 BLOB 欄位內容 CLEAR 掉後, 怎麼把空間挪出來" 有可能只是需要把某些筆資料的 BLOB 內容清掉而已 其他筆資料還要用啊 不過這個倒啟發我做了個實驗 "把 IMAGE FIELD DROP 掉" 結果ㄋ, 還是一樣.... 490MB, 沒有效

hi, 你用 sql query analyzer 在該 database 下使用 sp_spaceused 看一下, database_size 是多少 mb, unallocated_space 是多少 mb. 若是 database_size 有降下來, 變為30多mb, 但 unallocated_space 很大的話, 可以使用 DBCC SHRINKDATABASE (database_name) 注意 database_name 不要加引號, 這樣可以將未使用的空間還給 filesystem, 也就是減少該 mdf 的檔案大小!! 詳情可以參考 help 內的說明!

shrink 這個動作我也都有做 欄位刪除後做 Shrink 的確是可以把空間弄回來 但是這不是根本解，畢竟欄位還要使用 我歸納一下這幾天各位給的建議和我的嘗試 根本的問題如下 ＂曾經有儲存過資料的 image 欄位所佔用掉的空間 使用 TBlobField.Clear 後， 就算做了 Shrink 還是沒有辦法歸還給檔案系統 除了刪除該筆資料紀錄或刪除整個 image 欄位 難道沒有別的方式可以弄回來嗎？＂

請問你試過了 sp_spaceused 了嗎? 有看出來 unallocated_space 嗎?    基本上, 資料庫的資料檔, 由於效能及服務使用考量, 會依照使用量來調整並增大, 以期能放入更多的資料, 當資料被刪除時, 會將空間釋放回 unallocated_space, 但並不會還給 os, 考量有可能再度使用到這麼大的資料空間, 所以並不主動釋放回 os, 並且這些空間會因為後續資料的增加, 會再度使用到, 直到 unallocated_space 少於某一設定比例時, 服務將會再向 os 索取更多的空間來使用, 這是 mdf, ldf 的工作模式. 若你覺得你有這樣的需求(希望 unallocated_space 不要太大), 大量的資料新增, 刪除時, 建議你將維護資料庫空間的指令排入定期的 job 維護, 或是使用 alert performance 來定期調整 mdf 檔的使用空間!!

是的 這些都有做過了 據了解 unallocated 的值就是 [壓縮]或是[資料庫內容] 裡面可以查得到的 [可用空間] 的值 刪除 record 或 field ，是會回復 [可用空間] , 有 [可用空間] 才能做 shrink(壓縮) / 資料庫維護計畫-最佳化或是 Auto-Shrink ，把空間歸還給 os， 但其實基本上不管縮幾次，還是會有 1~2% 的 [可用空間] ， 這是因為分頁大小的規劃的關係(以 MB 為單位)    但是 ＂清空 Image field 的內容， 或是把資料內容縮小 (例如原本實際用 900K, 縮成實際只使用 50K)， 並不會增加 [可用空間]，所以也沒有辦法還給 os ＂

Hi, 弟根據你的狀況做了實驗, 確實在該欄位 clear 後會釋放空間回 unallocated_space, 並不會特別吃掉額外的空間. 弟測試用的資料庫為 MSSQL 2000 Delphi 7 使用 ado 存取資料庫. 你也可以使用 sp_spaceused 'table_name' 來觀察該空間的使用狀況!

我是用 SQL 2000 delphi 6 Clear 並沒有增加 anyway 只好用土法煉鋼 將原本的 table 資料轉入新的 table, blob 一並轉換成 jpg 存入 再切換 table name, 再把整個舊 table drop 掉

引言: anyway 只好用土法煉鋼 將原本的 table 資料轉入新的 table, blob 一並轉換成 jpg 存入 再切換 table name, 再把整個舊 table drop 掉

若是依你說的做, 這樣進行可以將空間還原嗎? 另外也請試試使用 update 語法, 將該 image 欄位設為 null 試試看, 稍早弟在測試時, 使用這種方式也可以順利還給 unallocated_space!!

沒錯 從前幾次的試驗, 我認為 drop Field / Table 會把該 Field / Table 佔用的空間 release 掉/red] Table 之間空間是獨立的, record 一條一條存在 page 裡 drop Table 是把那塊空間整個釋放出來 因為根本上, Table 已經消失, 所用的空間不會需要再用到 drop Field 也一樣 刪除或更動任何 Field 的 type/size/sequence 都會重組 table 的空間分布 但是我不確定 [red]"若 image 欄位在更動後還有存在, image 欄位佔用的空間會不會被重組" 因為 image 欄位其實只存 "指標", 指向另一個分開的空間, 和同 table 內的 data field 的空間是不同的 其他欄位更動理論上都不會去動到 "指標" 指向的地方 "指標" 也沒有縮小的問題 指向的地方的 "內容" 所佔用的位置才是重點 所以當初在問 TBlobField.Clear / Update xxx Set BLOB=NULL 是不是真的有把空間還回來 是因為有點懷疑這兩個動作是不是只把 "指標" 弄成 null 而已 SQL server 應該有這樣的機制就是 "保留空間以便資料變大所需 －(某Ａ機制 for record 數變多/ 某Ｂ機制 for image field 變大) " 我確定有 "就算 record 被刪除掉, 原本佔用的空間會先保留起來" 的機制 但是 "把 image 內容從 900K update 成剩下 50K 時, 還是保留 900K 空間?" 是不是有這樣的機制？ 所以一開始才會問是不是有什麼設定技巧是我沒有做的 可以將這些個 size down 下來 而引申的問題 "SQL Server 的 IMAGE 欄位的原理" 是想了解 "image 欄位的分頁大小", 是不是這個影響到 "已經從 900K 縮成 50K, 但 total 整個 mdf 檔並沒有等比例縮小" SQL server on line help 都沒有講到這些, 而且常常文不達意 個人又不喜歡去做 M$ 的認證或上課, 所以只有網上請教囉 最後分享一下結果 原本整個資料庫用掉 27G (扣掉雜七雜八的資料, 19000 筆 record (BMP image) 估算約佔 23G) 第一次縮成 JPG 後, 整個資料庫剩 15G 最後土法煉鋼之後, 目前只使用 6G 其中把 19000 筆資料轉出來, 其實只有 650mb (雜七雜八的資料大概4~5G)