답변:
DB 시스템에서 가장 느린 부분은 디스크 드라이브입니다. 디스크 수준에서 병목 현상을 제거하면 성능이 향상됩니다. 데이터를 검색하고 색인을 사용하는 경우 색인을 먼저 검색 한 다음 해당 데이터를 가져옵니다. 인덱스와 데이터가 같은 디스크에 있으면 경합이 발생합니다. 반면에 데이터가 다른 (물리적) 디스크에 있으면 IO가 더 빨리 발생하여 성능이 향상됩니다. 주목할 부분은 데이터 또는 인덱스가 별도의 물리적 디스크 또는 LUN에 있다는 것입니다.
디스크가 있으면 시스템 성능을 향상시켜야하는 경우 이러한 시나리오를 사용합니다. 당신의 성능 모니터 카운터를 사용할 수의 경우 Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/sec이전 및 변경 사항의 비교 후이 있습니다.
서로 다른 드라이브간에 동시 I / O를 분산 시키면 성능이 향상 될 것입니다. 그것은 신화가 아닙니다. 신화는 두 번 수행하면 성능이 다시 향상된다는 것입니다.
당신이 경우 SAME , 두 개의 파티션으로 배열을 분할하고 다른 하나와 테이블에 인덱스를 넣는 것은 시간 낭비입니다.
데이터에서 인덱스를 별도의 파일 그룹으로 분리 = 성능 향상은 논란의 여지가 있습니다. 이를 지원할 기본 하드웨어가 있지만 다른 파일 그룹으로 분리해도 성능이 향상되지 않으면 성능이 향상 될 수 있습니다. 그리고 이것 때문에 perf boost를 측정하는 것은 쉽지 않습니다.
참조 : http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx
먼저 질문을해야합니다. 왜 이렇게해야합니까?
위의 목록에서 5 번의 필요성을 지원하기 위해이 작업을 살펴 보았지만 아직 조치를 취하지 않았지만 좋은 제안처럼 보입니다.
이 결정은 쉬운 일이 아니며 수행하려는 작업을 파악하고 지원할 하드웨어가 있는지 확인해야합니다. 테스트를 잘하지 않았고 성능이 크게 향상되지 않는 한 이런 식으로 변경하지 마십시오. 그렇지 않으면이 아이디어를 떨어 뜨릴 수 있습니다. 인덱스를 별도의 파일 그룹으로 분리하여 성능 향상을 기대한다면 가치가 없습니다.
이 항목에 대한 개인적인 경험을 알려 드리겠습니다. 클러스터되지 않은 인덱스는 현재 디스크 드라이브가 필요한 공간에 충분하지 않을 때 별도의 파일 그룹에 저장해야합니다 . 당신은 그것에 대해 웃을 수 있지만 ..
따라서 데이터 드라이브에 여유 공간이없는 상태에서 응급 상황을 해결하려면 여유 공간이있는 드라이브의 새 파일 그룹에서 클러스터되지 않은 모든 인덱스를 온라인으로 다시 작성하는 멋진 스크립트를 작성해야했습니다. 새 스토리지를 구입하는 것이 쉽고 빠르다고 생각할 수도 있지만 실제로는 그렇지 않습니다.
성능과 관련하여 우리는 이동 후 평범하지 않은 것을 보지 못했습니다. 그러나 모든 것이 함께 유지되는 큰 SAN 스토리지 박스입니다 :-).
일반적으로; 데이터와 인덱스를 유사한 성능을 갖는 별도의 디스크 로 분할 하면 해당 테이블에 대한 실질적인 쓰기 작업이나 해당 인덱스를 사용하는 대규모 읽기 작업의 성능이 향상 될 수 있습니다. 분할 된 테이블과 같은 다른 I / O 작업과 유사한 방법으로 여러 물리적 디스크에 분산됩니다.
그러나 그것은 또한 스토리지에 크게 의존합니다 . 예를 들어; 좋은 Fushion ioDrive (또는 비슷한 것)가있는 서버가 있고 개별 회전 디스크가있는 경우. 공간이 제한되지 않는 한 ioDrive에 모든 것을 유지하는 것이 더 유리할 수 있습니다. 고려해야 할 다른 사항도 있습니다-RAID 구성, 네트워크 스토리지 구성.
하드웨어가 비슷한 테스트 서버에서 또는 임시 데이터로 사용량이 적은 시간에 보조 서버가 옵션이 아닌 경우에만 벤치마킹을 수행하십시오. Sankar의 DBA-Monkey 링크는 생각하기에 좋은 음식입니다.