“DbccFilesCompact”상태가“Suspended”인 이유는 무엇입니까?

600G 데이터 파일에서 SHRINK 파일을 실행하고 있습니다.

현재 상태가 "중지"로 및보고 sys.dm_exec_requests.percent_complete를 위해 DbccFilesCompact이 실행 (하지만 매우 느리게) 것을 명령 보고서

일시 중단 된 이유와 원활하게 실행하는 방법을 확인할 수있는 방법이 있습니까?

FYI- 상태 확인을위한 SQL 쿼리

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

아니요, 왜 느리게 실행되는지 확인할 수는 없지만 힌트를 줄 수는 있습니다.

1) SQL 2005에서 비 클러스터형 인덱스 관리는 스토리지 엔진 (팀)에서 쿼리 프로세서로 변경되었습니다. 여기에는 많은 부작용이 있으며 그 중 하나는 축소로 힙 데이터 페이지를 이동할 수있는 속도입니다. 모든 비 클러스터형 인덱스 레코드는 인덱싱중인 데이터 레코드에 대한 백 링크를 포함합니다. 힙의 경우 특정 데이터 페이지의 레코드 번호에 대한 물리적 링크입니다. 힙 데이터 페이지를 축소하여 이동하면 해당 페이지의 레코드로 백 링크되는 모든 비 클러스터형 인덱스 레코드를 페이지의 새 위치로 업데이트해야합니다. 2000 년에 이것은 저장소 엔진 자체에 의해 매우 효율적으로 수행되었습니다. 2005 년 이후에는 비 클러스터형 인덱스 레코드를 업데이트하기 위해 쿼리 프로세서를 호출하여이 작업을 수행해야합니다. 때로는 2000 년보다 최대 100 배 느립니다.

2) 행 외부 LOB 값 (실제 LOB 데이터 유형 또는 행 오버 플로우 데이터)에는 해당 데이터 또는 인덱스 레코드에 대한 백 링크가 포함되지 않습니다. LOB 레코드의 페이지가 이동 될 때, 어떤 데이터 / 인덱스 레코드가 자신을 가리키는 지 알아 내기 위해 이들이 속한 전체 테이블 또는 인덱스를 스캔하여 새 위치로 업데이트 할 수 있습니다. 이것은 또한 매우 느립니다.

3) 데이터베이스를 사용하는 다른 프로세스에서 축소가 페이지를 이동해야하는 잠금을 기다리는 것을 막을 수 있습니다.

4) 스냅 샷 격리를 사용하도록 설정했을 수 있으며 이전 버전이 필요한 트랜잭션이 완료 될 때까지 축소를 통해 버전 저장소 링크가있는 페이지를 이동할 수 없습니다.

5) I / O 하위 시스템에 전원이 부족할 수 있습니다. 낮은 한 자리수보다 높은 디스크 큐 길이는 병목 현상이 발생하는 I / O 하위 시스템을 의미합니다.

이들 중 일부 또는 전부가 런타임의 축소 속도 저하에 기여할 수 있습니다.

그러나 일반적으로 축소를 실행하고 싶지 않습니다. 자세한 내용은이 블로그 게시물을 참조하십시오. 데이터 파일을 축소해서는 안되는 이유 .

도움이 되었기를 바랍니다!

이 스크립트를 실행하여 완료율을 확인할 수 있습니다!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

SQL Server 2008 SP1에서 데이터베이스를 축소하고 있으며 수축 명령의 진행률을 sp_lock spid를 실행하여 알 수있는 한 가지 방법은 대부분 파일 1에 잠금을 설정 한 다음 완료되면 파일 ID 2를 잠그십시오. 이렇게하면 마지막 파일 ID에서 작업하는 시점을 알 수 있으며 이것은 거의 완료되었음을 나타냅니다.

감사,

알렉스 아길라

나는 문제가 무엇인지 발견했고 (내 경우에는) 여기에 내가 사용한 솔루션을 제공합니다.

데이터베이스를 사용하는 것이 없으며 master는 내 세션의 기본 데이터베이스였으며 sp_who2를 사용하고 있음을 확인했습니다. 그런 다음 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 "작업"을 선택한 다음 "축소"와 "확인"을 차례로 클릭합니다. sp_who2를 다시 사용하면 몇 분 동안 상태가 "일시 중단"되고 그 이후 "배타적 잠금을 얻을 수 없음"으로 인해 중단됩니다. 자신을 추측하지만 대화 자체가 그 원인이 될 것이라고 확신합니다.

그래서 나는 다음을 사용하여 명령 줄을 통과하기로 결정했습니다.

DBCC SHRINKDATABASE (myDataBase)

(마녀는 어디에나 기록되어있다) 그리고 수축은 몇 초 밖에 걸리지 않았다.