非不得已還是不要用shrinkfile吧,沒什好處,但廠商要求就只能照做了,結果出乎意外地跑了好久,MDF不過500G,使用380G,壓成400G,結果花了快八小時!
--壓縮之前先確認有沒有足夠的可用空間可以移除
--壓縮之前先確認有沒有足夠的可用空間可以移除
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB FROM sys.database_files;
--shirk data file(MB)
DBCC SHRINKFILE (N'TestDB_log' , 1024)
--shirk log file(MB)
DBCC SHRINKFILE (N'TestDB' , 10)
關於Shrink的過程可參考下列連結
--因為實在太久了,找到以下可以看到進度及預估時間的命令
--但真的是估計,會一直變,會一直往遞延
--實際上完成時間往後遞延了一個多小時喔...@@
--但真的是估計,會一直變,會一直往遞延
--實際上完成時間往後遞延了一個多小時喔...@@
SELECT
session_id,
percent_complete,
DATEADD(MILLISECOND,estimated_completion_time,CURRENT_TIMESTAMP) Estimated_finish_time,
(total_elapsed_time/1000)/60 Total_Elapsed_Time_MINS ,
DB_NAME(Database_id) Database_Name ,command,sql_handle
FROM sys.dm_exec_requests
where command in ('DbccSpaceReclaim','DbccFilesCompact','DbccLOBCompact');
下面這篇有提到shirk的建議作法,也可參考
0 意見:
張貼留言