SQL Server 2005/2008-여러 파일 / 파일 그룹-몇 개입니까? 왜?

저는 마음에 드는 개발자입니다. 그러나 때때로 고객은 이러한 문제를 처리 할 수있는 적절한 DBA를 가지고 있지 않으므로 결정을 요청했습니다 ....

합리적인 크기의 SQL Server 데이터베이스 (Northwind 또는 AdventureWorks보다 큰 것, 약 2-4GB의 데이터 + 인덱스 등)를 처리 할 때 전략 / 모범 사례는 무엇입니까?-여러 파일 / 파일 그룹을 사용합니까?

그렇다면 몇 개입니까? 그리고 왜?

"모든 것을위한 하나의 파일 그룹"접근 방식에서 벗어날 시점을 결정하기위한 기준은 무엇입니까?

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

여러 파일 그룹을 사용하는 경우 몇 개를 사용합니까? 데이터 하나, 인덱스 하나, 로그 하나? 데이터가 몇 개입니까? 선택한 이유는 무엇입니까? 왜 정확한 수의 파일 그룹을 사용합니까? :-)

힌트, 조언, 생각에 감사드립니다!

건배, 마크

경험의 기본 규칙은 경합을 피하기 위해 파일을 다른 볼륨으로 분리하는 것입니다. 그러나 얻을 수있는 성능 향상의 양은 I / O 하위 시스템 및 워크로드에 따라 크게 다릅니다. 예를 들어, 단일 물리적 스핀들의 여러 파일은 성능이 저하 될 때까지 빨라지지만 RAID 10 어레이의 수백 개의 드라이브가있는 SAN LUN에있는 볼륨과 동일한 배열은 괜찮을 수 있습니다. 디스크 대기열 길이 카운터는 I / O 병목 현상이 있는지 확인하는 가장 간단한 방법입니다.

데이터베이스에서 읽기 전용, 대부분 읽기, 쓰기, 쓰기, 쓰기 전용 등의 I / O 패턴을보고 있습니다. 또한 올바른 RAID 레벨을 선택하고 디스크 파티션 오프셋, RAID 스트라이프 크기 및 NTFS 할당 단위 크기가 올바르게 설정되어 있는지 확인하십시오. 어떤 사람들은 비 클러스터형 인덱스를 별도의 파일 그룹으로 나누기를 좋아하지만 여기서 설명한 성능 향상은 위에서 설명한 것처럼 다릅니다.

성능뿐만 아니라 관리 효율성과 복구 가능성도 고려해야합니다. 100GB 데이터베이스에 단일 단일 데이터 파일이 있으면 복원 단위가 해당 파일임을 의미합니다. 4 개의 25GB 파일 그룹으로 분할하면 부분 데이터베이스 가용성 및 단편 복원을 사용하여 파일이 손상된 경우 단일 파일 그룹 만 복원하면됩니다. 여러 파일 그룹에서 테이블과 인덱스를 분할하여 유지 관리 작업 (예 : 인덱스 조각화 제거)의 영향을받는 데이터베이스 부분을 제한 할 수도 있습니다.

Tempdb는 완전히 특별한 경우이며 tempdb를 분리하는 이유와 방법에 대한 모든 내용을 설명하는 블로그 게시물을 알려 드리겠습니다. 여기에 많은 오해가 있습니다.

여기에 '스위핑 일반화'권장 사항을 제공하지 않으면 서 읽을 수있는 여러 백서 및 블로그 게시물을 알려 드리겠습니다.

• 백서 : 물리적 데이터베이스 스토리지 디자인
• 백서 : 사전 배포 I / O 모범 사례
• 백서 : SQL Server 2005의 분할 된 테이블 및 인덱스

• 백서 : 부분 데이터베이스 가용성

• 블로그 게시물 : TF 1118에 대한 오해 (tempdb 레이아웃)

• 블로그 게시물 : 디스크 파티션 오프셋, RAID 스트라이프 크기 및 NTFS 할당 단위가 올바르게 설정되어 있습니까? (디스크 파티션 백서 링크 포함)

이것이 당신에게 도움이되기를 바랍니다!

다른 파일 그룹으로 데이터베이스를 분할하기로 한 결정은 현재 크기와 테이블의 향후 증가를 분석 한 후에 수행해야합니다. 내 생각으로는, 수백만 개의 행이있는 큰 데이터베이스 나 테이블이없는 한, 수정하는 것보다 더 많은 성능 문제가 발생할 수 있으므로 장단점을 신중하게 고려해야합니다.

특정 구내에서 흥미로운 시나리오가 있습니다.

• 2 개의 파일 그룹 : 데이터 및 색인
• 3 개의 파일 그룹 : 읽기 전용 테이블, 읽기 / 쓰기 테이블, 인덱스
• 다중 파일 그룹 : 읽기 전용, 읽기-쓰기, 색인, 키 테이블 1, 키 테이블 2, ...

파일 그룹이 SQL Server의 증가, 사용 및 성능 요구에 도움이되는지 결정하려면 환경을 분석해야합니다.

이 기사 에서 여러 파일 그룹으로 이동하는 몇 가지 주요 표시기 :

• 디스크 큐로 인해 응용 프로그램 및 사용자 경험 문제가 발생하는 경우
  • 이 경우 IO 집약적 테이블을 수용하는 새 파일 그룹으로 추가 디스크 드라이브 활용을 고려하십시오
• 특정 테이블이 데이터베이스의 10 % 이상인 경우
  • 이런 경우에는 특히 큰 테이블을 별도의 기본 디스크 드라이브에서 별도의 파일 그룹으로 옮기십시오.
  • 나머지 테이블에 비례하여 테이블 크기에 따라 개별 테이블에 대한 파일 그룹 작성을 고려하십시오.
• 큰 테이블에서 비 클러스터형 인덱스와 데이터 공간이 동일한 경우
  • 이 경우 비 클러스터형 인덱스에서 데이터와 클러스터형 인덱스를 분할하는 것이 좋습니다.
• 데이터베이스에 거의 동일한 비율의 읽기 전용 및 읽기 / 쓰기 데이터가 존재하는 경우
  • 이 경우 별도의 파일 그룹에서 읽기 전용 데이터를 읽기 / 쓰기 데이터로 분할하십시오.
• 데이터베이스 유지 보수를 수행 할 시간이 충분하지 않은 경우
  • 이 경우 큰 테이블을 다른 기본 디스크의 개별 파일 그룹으로 분할하고 병렬로 유지 관리를 수행하십시오
• 비즈니스 또는 응용 프로그램이 크게 변경되고 데이터가 훨씬 더 빠른 속도로 증가 할 때
  • 이 경우 잠재적 성장을 이해하기 위해 사용자와 협력하는 것이 좋습니다
• 보관 된 데이터가 프로덕션 데이터와 동일한 데이터베이스에있는 경우
  • 이 경우 별도의 파일 그룹 또는이 팁 (SQL Server에서 데이터 보관)의 기술 중 하나 이상을 고려하십시오.

파일 그룹이 데이터베이스 성능을 향상시킬 수있는 경우 프로덕션 서버에서 변경 사항을 구현하기 전에 스테이징 환경에서 코드를 작성하고 프로세스를 테스트하십시오. 변경 사항을 구현하기 전에 몇 가지 측정을 준비하고 전후에 비교하십시오. 이러한 프로세스는 매우 많은 자원과 시간이 소요될 수 있으므로 유지 관리 기간 동안 이러한 절차를 수행하십시오.

새 객체 (테이블 및 인덱스)를 생성 할 때 예상 성능을 보장하고 정기적으로 데이터베이스 객체가 올바른 파일 그룹에 있는지 확인하고 필요에 따라 올바른지 확인하기 위해 올바른 파일 그룹에서 객체를 생성해야합니다.