답변:
이 질문에는 두 가지 부분이 있습니다. 새 FILEGROUP을 추가 할시기와 파일 그룹에 새 FILE을 추가 할시기입니다. 먼저 이론을 이야기합시다.
성능의 주된 이유에 대한 Mark의 권리.
두 번째 이유는 재해 복구입니다. SQL Server 2005 이상에서는 파일 그룹 복원을 수행 할 수 있습니다. 재해가 발생하면 먼저 기본 파일 그룹 만 복원하고 쿼리를 위해 데이터베이스를 부분적으로 온라인 상태로 만들 수 있습니다. 다른 파일 그룹을 복원하는 동안 사용자는 쿼리를 실행할 수 있습니다. 이는 즉시 필요하지 않은 대량의 히스토리 데이터가있는 데이터베이스 또는 액세스를 위해 히스토리 데이터가 없어도 현재 테이블에 데이터를로드해야하는 데이터웨어 하우스에 유용합니다.
또 다른 이유는 데이터 그룹의 읽기 / 쓰기 프로필입니다. 지속적으로 기록되는 일부 데이터와 많은 양의 읽기 작업을 수행하는 다른 데이터가있는 경우 해당 요구를 수용 할 수있는 다양한 유형의 스토리지를 구축 할 수 있습니다. 대량 쓰기 작업을 레이드 10에 배치하고 읽기 편향 작업을 저렴한 레이드 5에 배치 할 수 있습니다.
이제 파일과 파일 그룹을 이야기 해 봅시다. SQL Server에 개체를 배치 할 때는 파일 그룹 수준에 개체를 배치해야합니다. 파일 그룹에 테이블 또는 인덱스를 랜딩 할 수 있지만 특정 파일을 선택할 수는 없습니다. 지금까지 논의한 모든 내용은 파일 그룹을 추가 할시기에 관한 것이지만 언제 파일을 추가합니까?
스토리지를 설계하고 있고 80 개의 하드 드라이브가있는 경우이를 분리 할 수있는 몇 가지 방법이 있습니다.
스토리지 서브 시스템마다 성능 프로파일이 다릅니다. 12-16 개의 드라이브 어레이에서 가장 잘 수행 된 일부 SAN에서 작업했으며 그보다 큰 것은 성능 향상이 없었습니다. 다른 예는 다중 경로가있는 SAN입니다. 서버를 스토리지에 연결하는 여러 HBA가 있고 다중 경로 소프트웨어가 실제 활성 / 활성이 아닌 경우로드를 분산하기 위해 경로당 하나의 어레이가 필요할 수 있습니다. 4 개의 경로, 4 개의 드라이브 풀은 이러한 유형의 드라이브에서 성능이 향상됩니다.
이 경우 Windows에서 4 개의 다른 배열, 4 개의 다른 드라이브 (마운트 지점을 사용하지 않고 폴더가 다른 경우가 아니라면)로 끝나고 SQL Server에 4 개의 별도 파일이 필요합니다. 이러한 개별 파일은 동일한 파일 그룹에있을 수 있습니다.
주된 이유는 성능입니다. 기본 파일 그룹 디스크 드라이브에서 IOPS 용량이 부족한 경우 스토리지 구성에 따라 IOPS를 여러 디스크 / LUN으로 분할하려면 두 번째 파일 그룹으로 확장해야합니다.
편집 : 브래드 윌슨은 SSD에 대해 좋은 의견을 남겼습니다. 복합 SSD / SATA / FC 스토리지 시스템을 사용하는 경우 다른 유형의 스토리지에 다른 파일 그룹을 원할 수 있습니다. 그런 다음 극한 IOPS 요구 사항 테이블을 SSD 파일 그룹에 배치 할 수 있지만 기록 / 통계 테이블은 저렴한 SATA 파일 그룹에 저장할 수 있습니다.
또한이 질문에도 복구 가능 / 데이터 가용성 측면이 있음을 지적합니다. 여러 파일 그룹을 사용하고 기본 파일 그룹에 사용자 정의 오브젝트를 배치하지 않으면 온라인 복원을보다 유연하게 사용할 수 있습니다. 이것은 파일 그룹 레벨에서 단편 복원을 허용합니다.
2005 년 이후의 SQL Server Enterprise 및 Developer 버전에서 온라인 복원을 사용할 수 있습니다.
염두에 두어야 할 또 다른 생각은 읽기 전용 정적 참조 데이터를 트랜잭션 데이터와 분리하는 것입니다. 더 큰 데이터베이스의 경우 백업을 수행하는 데 필요한 시간 및 / 또는 공간이 줄어 듭니다.