답변:
내 대답에서 너무 일반적 일 위험이 있기 때문에 정기적으로 인덱스 유지 관리 프로세스를 실행해야한다고 말할 것입니다. 그러나 인덱스 유지 관리 프로세스는 인덱스가 필요한 인덱스 만 다시 작성 / 재구성해야합니다.
이것은 언제 인덱스를 재 구축하거나 재구성해야합니까? 롤란도는이 부분을 잘 다루었습니다. 다시 말하지만, 나는 매우 광범위 할 위험이 있습니다. 조각화 수준이 성능에 부정적인 영향을 줄 때 인덱스를 유지 관리해야합니다. 이 조각화 수준은 색인의 크기와 구성에 따라 달라질 수 있습니다.
SQL Server와 관련하여 인덱스 유지 관리를 시작하는 시점에서 인덱스 크기와 인덱스 조각화 수준을 선택하는 경향이 있습니다. 색인에 100 페이지 미만이 포함되어 있으면 유지 관리를 수행하지 않습니다.
인덱스가 10 %에서 30 % 사이 인 경우 REORGANIZE인덱스와 UPDATE통계를 사용합니다. 인덱스가 30 % 이상 조각난 REBUILD경우 인덱스 UPDATE STATISTICS에 의해 처리 되므로 인덱스가 없습니다 REBUILD. 재 구축은 인덱스와 직접 연결된 통계 개체 만 업데이트합니다. 다른 열 통계는 별도로 유지 관리해야합니다.
이 답변은 실제로 말하기에 먼 길입니다. 예, 정기적 인 인덱스 유지 관리를 수행해야하지만 필요한 인덱스에서만 수행해야합니다.
관계형 데이터베이스 (예 : SQL Server)에서 인덱스를 언제 다시 작성해야합니까?
특수 이벤트로 인해 인덱스가 많이 조각화되면 인덱스를 다시 작성해야합니다. 예를 들어, 인덱스 된 테이블에 대량의 대량 데이터로드를 수행합니다.
정기적으로 인덱스를 다시 작성하는 경우가 있습니까?
규칙적인 활동으로 인해 인덱스가 정기적으로 조각화되면 어떻게 될까요? 정기적 인 재 구축을 예약해야합니까? 그들은 얼마나 자주 달려야합니까?
이 고전적인 Ask Tom 스레드 에서 Tom Kyte 는 다음을 권장합니다.
인덱스 재 구축 사이의 시간 지연은 거의 영구적이어야합니다.
...
더 잘 말하는 법을 모른다. 지수는 여분의 공간으로 크고 뚱뚱하고 싶다. 업데이트하는 열에 있으며 인덱스 항목을 인덱스에서 다른 곳으로 옮깁니다. 어느 날 행에는 "A"코드가 있고 다음 날에는 "G", "Z", "H"등이 있습니다. 따라서 행에 대한 색인 항목이 색인에서 한 위치로 이동합니다. 따라서 공간이 필요합니다. 공간이 없으면 블록을 두 개로 나누고 공간을 만듭니다. 이제 지수는 뚱뚱해지고 있습니다. 시간이 지남에 따라 인덱스는 시작했을 때의 크기의 2-3 배이며 "반 이상 비어 있습니다"그러나 행을 이동하기 때문에 괜찮습니다. 이제 행을 움직일 때 더 이상 방을 만들기 위해 블록을 나눌 필요가 없습니다. 방이 이미 사용 가능합니다.
그런 다음 인덱스를 다시 작성하거나 삭제하고 다시 작성합니다. 동일한 효과를 가진-재 구축은 "새퍼"입니다. 인덱스를 잃을 가능성이 없으며 인덱스를 다시 작성할 수 있으므로 더 빠릅니다. 테이블을 스캔하는 대신 기존 인덱스를 스캔하고 새로운 인덱스를 정렬 및 빌드하는 것). 이 멋진 공간은 모두 사라졌습니다. 우리는 블록을 다시 분할하는 과정을 시작하여 시작한 곳으로 바로 돌아갑니다.
공간을 절약했습니다.
지수는 그 당시의 모습과 똑같습니다.
이 악순환이 스스로 반복되도록 다시 시간을 낭비하고 싶을 것입니다.
여기의 논리는 소리이지만 읽기 무거운로드 프로파일에 대해 바이어스됩니다.
"뚱뚱한"인덱스 (즉, 공백이 많은 인덱스)는 실제로 새로운 행과 이동 된 행을위한 충분한 공간을 유지하므로 페이지 분할을 줄이고 쓰기 속도를 유지합니다. 그러나 해당 지방 지수를 읽을 때 더 많은 빈 페이지를 조사하기 때문에 더 많은 페이지를 읽어야 동일한 데이터를 얻을 수 있습니다. 읽기 속도가 느려집니다.
따라서 읽기가 많은 데이터베이스에서는 정기적으로 인덱스를 다시 작성하거나 재구성하려고합니다. (Mat M은 이미이 질문에 대한 구체적인 대답 을 가지고 있습니다.) 대략 동등한 읽기 및 쓰기 활동을 경험하는 데이터베이스 또는 쓰기가 많은 데이터베이스에서는 인덱스를 다시 작성하여 데이터베이스 성능을 저하시킬 수 있습니다. 정기적으로.
대부분의 사람들은 정기적으로 재건하여 조각난 일이 없도록합니다. 재 구축해야하는시기는 얼마나 빨리 조각화되는지에 따라 결정됩니다. 일부 인덱스는 자주 다시 작성해야하며 다른 인덱스는 기본적으로 절대 다시 작성하지 않아야합니다. SQLFool 이 함께 제공하는 스크립트를 확인 하여 많은 정보를 처리하십시오.
Matt M의 승인 된 답변에서 언급했듯이 일반적인 경험상 30 %가 넘는 조각을 다시 작성해야합니다.
이 쿼리는 30 % 이상 조각화 된 인덱스 수를 찾는 데 도움이됩니다 (일부 인덱스가 있으면 다시 작성해야 함).
SELECT DB_NAME() AS DBName,
OBJECT_NAME(ind.object_id) AS TableName,
ind.name AS IndexName,
indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages,
SUM(p.rows) AS Rows
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.indexes AS ind ON ( ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id)
INNER JOIN sys.partitions AS p ON ( ind.object_id = p.object_id
AND ind.index_id = p.index_id)
WHERE indexstats.avg_fragmentation_in_percent > 30
GROUP BY
OBJECT_NAME(ind.object_id),
ind.name,
indexstats.index_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages
ORDER BY indexstats.avg_fragmentation_in_percent DESC언제 인덱스를 다시 작성해야합니까?
인덱스 조각화 비율이 30 %를 초과하는 경우
정기적으로 인덱스를 다시 작성하는 경우가 있습니까?
그러한 경우는 없지만 일반적으로 일주일에 한 번 인덱스 유지 관리를 수행하면 주말 동안 환경을 안정적으로 유지하는 것이 가장 좋습니다.
Ola Hallengren의 유지 관리 스크립트 (최고의 유지 관리 스크립트)를 사용하고 환경에 따라 스크립트를 사용자 지정하고 주말에 실행되도록 예약하는 것이 좋습니다.
참고 : 인덱스 재 구축이 모든 통계를 업데이트하지는 않으므로 인덱스를 재 구축 한 후 통계를 업데이트하는 것을 잊지 마십시오.
IT의 대부분의 경우와 마찬가지로 다릅니다. 인덱스를 다시 작성하여 어떤 문제를 해결하려고합니까? 실제로 문제가 해결되었음을 보여줄 수 있습니까? 그렇다면 문제를 해결하기 위해 유지 관리해야 할 최소한의 양을 찾을 때까지 숫자를 조정하십시오.
문제가 해결되지 않거나 수행하는 이유는 더 나은 결과를 얻을 수 있기 때문에 모니터링하는 일부 메트릭을 완화하는 것이므로 CPU와 IO를 태우고 문제를 악화시킬 수 있습니다.
조각화를 수정해도 서버에 아무런 영향을 미치지 않는다는 주장이 있습니다. 따라서 정기적으로 수행하는 것이 가치가 있습니까?
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/