SAN 환경에서 SQL 인덱스 조각 모음을 수행하면 어떤 이점이 있습니까?

16

SQL 서버는 SAN에 있습니다. 여기에는 수십 개의 OLTP 데이터베이스가 포함되어 있으며 일부는 1m 이상의 레코드를 포함하는 여러 테이블이 있습니다.

우리는 매주 Ola Hallengren의 색인 유지 보수 스크립트를 실행 했으며 매시간 몇 시간 씩 실행됩니다. 조각화 임계 값에 따라 스크립트는 색인을 재구성하거나 다시 색인화합니다. 재 인덱싱하는 동안 로그 파일이 커져 로그 전달 중에 대역폭이 과도하게 소비되는 것으로 나타났습니다.

그런 다음 브렌트 오자 ( Brent Ozar)의 기사에서 SQL 인덱스에 대한 걱정을 멈추라 고 말합니다 .

하드 드라이브는 동시에 드라이브 요청을하는 다른 서버와 공유되므로 드라이브는 항상 데이터를 얻기 위해 모든 곳을 뛰어 넘습니다. 인덱스 조각 모음은 의미없는 작업입니다.

이 질문을 인터넷으로 연결하면 다양한 의견이 나오고, 대부분 너무 짧거나 약한 주장으로 뒷받침됩니다. 임시 계획은 유지 관리 스크립트에서 조각화 임계 값을 조정하여 다시 색인화하는 것보다 훨씬 자주 재구성되도록하는 것입니다.

최종 평결은 무엇입니까? 주간 유지 관리 작업 실행과 관련된 부담을 고려하여 SAN에서 SQL 인덱스를 조각 모음하는 것이 가치가 있습니까?

— dev_etter
소스

10

조각 모음 전략은 디스크 간 스캔 속도를 향상시키는 데 도움이 됩니다.

다양한 의견은 환경의 이상적인 조각 모음 전략이 여러 가지 요인에 의존해야하기 때문입니다. 또한 여러 개의 단편화 계층이 존재합니다.

데이터베이스가 SAN에 저장되어 있다고 말하는 것만으로는 충분하지 않습니다. 예를 들면 다음과 같습니다.

데이터베이스 파일이 별도의 물리적 RAID 그룹 또는 동일한 RAID 그룹에 저장되어 있습니까? 같은 장치에서 다른 프로세스가 활성화되어 있습니까? 백업 파일도 거기에 있습니까? 항상 투명한 것은 아니기 때문에 SAN 관리자에게이 정보를 요청해야 할 수도 있습니다.
데이터베이스의 액세스 패턴은 무엇입니까? OLTP는 일반적으로 임의 액세스이지만 때때로 응용 프로그램이 테이블 스캔에 만족하며 동작을 변경할 수 없습니다 (ISV 앱). 응용 프로그램이 대부분 읽거나 쓰거나 중간에 있습니까?
이 있습니까 플레이 성능의 SLA는 복구 / 장애 조치 기간 동안 ?

브렌트의 포스트는 하나의 거대한 스토리지 풀이 있고 모든 것이 공유한다고 가정합니다. 즉, 물리 디스크가 유휴 상태가 아니며 대부분의 액세스는 임의적입니다. 그것이 당신의 상황이라면, 조언이 적용되며, 나는 대부분 그것에 동의합니다. 이러한 유형의 전략은 관리하기가 훨씬 쉽지만 반드시 (a) 환경에있는 것 또는 (b) 환경에 가장 적합한 솔루션 인 것은 아닙니다.

인덱스 유지 관리에 부담이되는 경우, 적극적으로 수행하거나 일주일에 걸쳐 비용을 상각하십시오 (즉, 매주 한 번 유지 관리 대신 한 번 유지 관리를 한 번만 수행).

SortInTempdb사용자 데이터베이스에서 발생하는 로깅 양을 잠재적으로 줄이는 옵션을 설정할 수도 있습니다.

— 존 세이 겔
소스

와우, 철저한 대답. 모든 연구를 수행하는 데 다소 시간이 걸리 겠지만, 당신이 나를 올바른 길로 인도하고 있다는 것을 의심하지 않습니다. 우리의 현재 전략은 실제로 재구성과 재구성의 관점에서 유지 보수를 덜 적극적으로 실행하는 것입니다. 거기에서 나는 당신이 언급 한 나머지 요소들에 대해 더 많은 연구를 할 것입니다.

— dev_etter

1

@dev_etter : 몇 가지 요소 만 나열했습니다. 더 많은 것이 있습니다. 요점은 첫 번째 문장입니다. 당신이 당신의 환경을 생각할 때 그것을 명심한다면, 그것은 당신의 결정을 올바르게 지시 할 것입니다. 모든 것은 그것에서 비롯됩니다. (또한이 모든 것은 SSD가 포함되어 있지 않다고 가정합니다.)

— Jon Seigel

FWIW, 나는 무언가를 완전히 간과했습니다. 작업 단계 (소스가 아닌)의 실제 스크립트는 최소 조각화 비율이 1 인 모든 인덱스를 처리하도록 구성되었습니다. 최대 15 개를 높이고 30에서 다시 빌드 임계 값을 높였습니다. 작업이 이제 8이 아닌 3 시간이 조금 넘게 실행됩니다. 덜 공격적인 제안은 맞습니다. 내 잘못은 그 일이 이미 덜 공격적이라고 생각되었다는 사실에 거짓말을했다. 이 접근법은 아마도 우리에게 가장 좋을 것입니다. 여전히 손을 대고 가고 있지만 이미 약간의 고통을 완화했습니다.

— dev_etter

@ JonSeigel 나는이 답변에 전적으로 동의합니다. 여행 중에는 대부분의 DBA가 단일 풀 또는 최소한 같은 RAID 레벨의 어레이를 공유하는 것을 볼 수 있습니다. 나는 100 + TB 데이터베이스의 개별 파일 그룹을 조각 모음하기 위해 3AM 24x7에 DBA를 설치했습니다 ... 그리고 정확히 무엇입니까? 디스크에서 완전히 임의의 IO가 있었고 대기 시간은 15ms였습니다. 그 시점에서 나는 단지 15ms를 가리키고 개발자에게 나를 내버려 두라고 지시해야합니다.

— ooutwire

2

이상적으로는주의가 필요한 인덱스에 대해서만 재구성 / 인덱싱을 수행해야합니다. 그렇지 않으면 리소스를 낭비하고 잠재적으로 다른 문제를 일으킬 수 있습니다.

성능 기준을 설정해야하며 변경을 수행 할 때마다 성능 변경을 기준과 비교하여 변경 사항을 구현할 가치가 있는지 확인하십시오.

— 짐보
소스

우리의 즉각적인 전략은 단지 그렇게 할 것입니다 - 우리는이 스크립트에서 minFragmentation 및 rebuildThreshold 변수에 대한 설정을 조정할 예정 : sqlfool.com/2011/06/index-defrag-script-v4-1

— dev_etter

0

문제는 파일 또는 파일 세트의 구성 인 데이터베이스 인덱스에 관한 질문입니다. 위의 답변을 읽으면 파일 내부의 인덱스가 아닌 디스크 수준의 조각화에 대해 이야기하고 있다고 믿을 수 있습니다. 이것들은 완전히 별개의 주제입니다.

여기서 근시 접근 방식은 인덱스를 조각 모음하거나 다시 작성하면 OLTP 데이터베이스 내에서 데이터를 검색하고 OLTP 데이터베이스를 개선 할 때 성능이 향상됩니다. 대답은 '예'입니다. 그러나 디스크 조각화도 중요한 요소입니다.

전반적으로 가장 낮은 "비용"? 데이터베이스 유지 관리를 수행하십시오. 두 번째로 저렴한 비용으로 데이터베이스를 분리하고 다른 곳으로 이동 한 다음 디스크를 다시 포맷하고 디스크 파티션 정렬에 대한 모범 사례를 따르십시오 http://msdn.microsoft.com/en-us/library/dd758814.aspx . 마지막으로 Diskkeeper와 같은 타사 고급 조각 모음을 사용하십시오.

이는 NTFS 유형 스토리지 (예 : Windows OS)에만 권장되며 이는 제품을 보증하지 않으며 Condusiv Technologies 또는 그 자회사와 관련이 없습니다.

— 아이리
소스

2

아마도 "답은 YES입니다!"라는 말을 피하고 싶을 것입니다. 다른 포스터에 의해 오랫동안 논의 된 문제 공간에. 브렌트 오자 (Brent Ozar)가 자신의 블로그 게시물에 표시 한 것처럼 때로는 "예"라고 대답하는 것이 사실 일 수도 있지만, 항상 그런 것은 아닙니다.

— Max Vernon