답변:
SQL 자체는 실제로 미리 알지 못하고 예측할 수 없기 때문에 재 구축에 걸리는 시간을 말하기는 정말 어렵습니다.
다음 쿼리를 사용하여 dm_exec_requests dmv를 사용하여 인덱스 재 구축 시간을보고 SQL에 실제로 예상치가 없는지 확인할 수 있습니다.
SELECT r.session_id,r.command,CONVERT(NUMERIC(6,2),r.percent_complete)
AS [Percent Complete],CONVERT(VARCHAR(20),DATEADD(ms,r.estimated_completion_time,GetDate()),20) AS [ETA Completion Time],
CONVERT(NUMERIC(10,2),r.total_elapsed_time/1000.0/60.0) AS [Elapsed Min],
CONVERT(NUMERIC(10,2),r.estimated_completion_time/1000.0/60.0) AS [ETA Min],
CONVERT(NUMERIC(10,2),r.estimated_completion_time/1000.0/60.0/60.0) AS [ETA Hours],
CONVERT(VARCHAR(1000),(SELECT SUBSTRING(text,r.statement_start_offset/2,
CASE WHEN r.statement_end_offset = -1 THEN 1000 ELSE (r.statement_end_offset-r.statement_start_offset)/2 END)
FROM sys.dm_exec_sql_text(sql_handle)))
FROM sys.dm_exec_requests r WHERE command IN ('Alter Index')
그러나 필요한 시간에 대한 실제 견적에 관해서 는 sqlmunkee 에서이 멋진 블로그 게시물 을 읽을 수 있습니다. sqlmunkee는 ".. 의존합니다."라고 말하여 요약합니다.
우리가 모두 같은 하드웨어에 있거나 동일한 소프트웨어를 사용하거나 동일한 데이터를보고있는 것은 아니기 때문에 대답은…
실망 스럽지만 사실은 슬프게도
나는 이 블로그 게시물 을 찾은 것으로 의심되는 작업을 수행하는 magick 스크립트 를 찾았 습니다. 실행중인 SQL Server 2014, 공유 잠금을 기다리는 쿼리 블록에서는 작동하지 않는 것 같습니다. 어쩌면 누군가가 유용하다고 생각하므로 여기에 그대로 두겠습니다.
;WITH cte AS
(
SELECT
object_id,
index_id,
partition_number,
rows,
ROW_NUMBER() OVER(PARTITION BY object_id, index_id, partition_number ORDER BY partition_id) as rn
FROM sys.partitions
)
SELECT
object_name(cur.object_id) as TableName,
cur.index_id,
cur.partition_number,
PrecentDone =
CASE
WHEN pre.rows = 0 THEN 0
ELSE
((cur.rows * 100.0) / pre.rows)
END,
pre.rows - cur.rows as MissingRows
FROM cte as cur
INNER JOIN cte as pre on (cur.object_id = pre.object_id) AND (cur.index_id = pre.index_id) AND (cur.partition_number = pre.partition_number) AND (cur.rn = pre.rn +1)
ORDER BY 4
위의 대답은 좋았지 만 중요한 것은 누락되었습니다. 명령 상태 (예 : 명령이 차단됨)
이 간단한 선택은 상태 전면 및 중앙을 보여줍니다.
SELECT percent_complete, *
FROM sys.dm_exec_requests
WHERE session_id = <session id of alter index>