MSSQL File사이즈 축소

초기에 계획을 잘 세워 구성을 하긴 했는데, 뭐 몇년을 운영하다 보니, 여러가지로 손볼께 생긴다.

특정 파일그룹에 부하가 좀 심해져서, 해당그룹의 파일을 좀 추가했더니만 정리할 필요가 생겼다.

처음엔 UserDataTr이란 파일그룹에 UserData_Tr1~4까지 30G씩 생성해서 사용을 했었는데, 한 2년쯤 지난 후에 부하가 좀 있어서 파일을 4개를 더 추가했다. 물론 다른 Disk에...그리고 또 하나를 생성하고 그래서 총 10개 파일로 구성이 되어 있었다. 실은 한달에 1번정도 빈도로 이상하게 Avg. Disk Queue Length값이 10정도로 한 5시간정도 지속되는 경우가 있었다. 이것 때문에 여러가지 조치를 취한 것들의 결과였다. 사실 이 현상은 전혀 다른 문제로 인한 것이 였지만...아무튼 결과가 파일들이 너저분하게 구성되는 결과를 가져왔다.

여하튼, 이 파일들을 좀 깨끗하게 정리하려고 한다.

우선 나중에 생성한 2개의 파일을 삭제한후, 1+0으로 구성된 추가한 디스크들에 해당 파일을 50G씩 4개를 생성하고, 나머지 8개를 삭제하려고 한다. 물론 DB를 내릴수가 없어서, 새벽시간에 조금씩 하려고 한다. 

우선, 해당 파일들의 이름과 사이즈, 사용사이즈를 보자

select   name 

        ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB

        ,size/128.0 as SizeMB

from sys.database_files

where   name like '파일명%'

order by 1;

그리고 DBCC ShrinkFile명령어로 특정파일을 완전히 비운담에 Remove를 한다.

DBCC ShrinkFile (Data_Tr1, EMPTYFILE);

ALTER DATABASE AdTargetsTV REMOVE FILE Data_Tr1;

이 작업이 의외로 시간이 많이 걸린다.

잘 돌아가는건지 궁금하기도 하고, 이때 아래 명령어로 확인해 보면된다.

-- 현재 진행중인 작업들

select session_id,start_time,command,status,percent_complete,wait_type,wait_time,reads,writes,logical_reads

from sys.dm_exec_requests

where   session_id >= 50

order by writes desc

아래처럼 결과가 나온다. 아웅....1시간돌았는데 아직 7.6%빡에 진행이 않됬다니. 물론 이 작업진행율이 정확한 건 아니다. 실제로 삭제할 파일을 디스크사용보고서로 확인해 보면, 파일사이즈가 줄어들고 있는것을 볼 수 있다. 파일을 비우면서 같은 파일그룹의 다른 파일들에 데이터를 이동시키고 있다.

101 2012-04-01  DbccFilesCompact suspended 7.667851 PAGEIOLATCH_EX 1171 289018 671312 6030382