SharePoint Server 팜의 SQL Server 모범 사례
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
SP1(서비스 팩 1), SQL Server 2016 또는 SQL Server 2017 RTM을 사용하여 SQL Server 2014에서 SharePoint Server 2016 및 2019 관계형 데이터베이스를 구성하고 유지 관리하는 경우 성능 및 보안을 높이는 옵션을 선택해야 합니다. 마찬가지로 SQL Server 2008 R2 서비스 팩 1(SP1), SQL Server 2012 및 SQL Server 2014에서 SharePoint Server 2013 관계형 데이터베이스를 구성하고 유지 관리할 때도 성능 및 보안을 향상시키는 옵션을 선택해야 합니다.
이 문서의 모범 사례들은 SQL Server의 설치 및 구성에서부터 SharePoint Server의 배포, 그런 다음 팜을 유지 관리하기까지 적용되는 순서에 따라 언급됩니다. 대부분의 사례는 모든 버전의 SQL Server에 적용됩니다. SQL Server 버전에만 고유한 사례는 별도의 섹션에서 언급됩니다.
참고
SharePoint Server 2016 팜에서 SQL Server Business Intelligence 구성 요소를 사용하려는 경우 SQL Server 2016 CTP 3.1 이상을 사용해야 합니다. 이제 SQL Server 2016 CTP 3.1 이상을 다운로드하여 SQL Server Power Pivot for SharePoint 추가 기능을 사용할 수 있습니다. SharePoint 통합 모드에서 SQL Server Reporting Services(SSRS)를 설치하고 SQL Server 설치 미디어에서 SSRS 프런트 엔드 추가 기능을 설치하여 Power View를 사용할 수도 있습니다.
자세한 내용은 새로운 SharePoint 2016에서 SQL Server 2016 PowerPivot 및 Power View 배포 백서를 다운로드하세요. 다중 서버 SharePoint Server 2016 팜에서 비즈니스 인텔리전스를 구성 및 배포하는 방법에 대한 자세한 내용은 다중 계층 SharePoint 2016 팜에서 SQL Server 2016 PowerPivot 및 Power View 배포를 다운로드하세요.
참고
SharePoint Server 2013 팜에서 SQL Server Business Intelligence 구성 요소를 사용하려는 경우 SQL Server 2012 서비스 팩 1(SP1) 또는 SQL Server 2014를 사용해야 합니다. SQL Server 2012 SP1 BI 및 SharePoint Server 2013에 대한 자세한 내용은 SharePoint 2013에서 SQL Server BI 기능 설치(SQL Server 2012 SP1)를 참조하세요. SQL Server 2014 및 SharePoint Server 2013에 대한 자세한 내용은 SQL Server 2014 Business Intelligence 기능 설치를 참조하세요.
중요
이 문서에 나오는 모범 사례는 SharePoint Server이 있는 SQL Server의 RDBMS(관계형 데이터베이스 관리 시스템)에 적용됩니다.
SQL Server에 대해 전용 서버 사용
팜 작업에 대한 최적의 성능을 보장하려면 다른 팜 역할을 실행하지 않고 다른 애플리케이션에 대한 데이터베이스를 호스트하지 않는 전용 서버에 SQL Server를 설치하는 것이 좋습니다. 유일한 예외는 개발 또는 테스트를 위한 독립 실행형 서버의 Single-Server 팜 역할 또는 SharePoint 2013에서 SharePoint Server 2016 또는 2019를 배포하는 것이며 프로덕션 용도에는 권장되지 않습니다. 자세한 내용은 SharePoint Server 2016 및 2019의 MinRole 및 관련 서비스에 대한 설명 및한 서버에 SharePoint Server 2016 또는 2019 설치를 참조하세요.
참고
가상화된 환경의 SQL Server 배포에도 관계형 데이터베이스용으로 전용 서버를 사용하는 것이 좋습니다.
SharePoint Server 배포 전에 특정 SQL Server 설정 구성
일관된 동작 및 성능을 유지하려면 SharePoint Server을 배포하기 전에 다음 옵션과 설정을 구성합니다.
여러 SQL 인스턴스 유지 관리와 관련된 잠재적인 성능 문제로 인해 배포된 데이터베이스 서버당 단일 SQL Server 인스턴스를 사용하는 것이 좋습니다.
SharePoint 콘텐츠 데이터베이스에 대해서는 통계 자동 작성을 사용하도록 설정하지 않습니다. SharePoint Server에서는 통계 자동 작성 사용이 지원되지 않습니다. SharePoint Server는 프로비전하고 업그레이드하는 동안 필요한 설정을 구성합니다. SharePoint 데이터베이스에서 수동으로 통계 자동 작성을 설정하면 쿼리 실행 계획을 크게 변경할 수 있습니다. SharePoint 데이터베이스는 통계(proc_UpdateStatistics)를 유지 관리하는 저장 프로시저를 사용하거나 SQL Server를 사용하여 이 작업을 수행합니다.
SharePoint Server 2013의 경우 유지 관리 계획은 SharePoint에서 관리합니다.
- SQL 통계는 proc_updatestatics 호출하는 상태 규칙 "SharePoint에서 사용하는 데이터베이스에 오래된 인덱스 통계가 있습니다"에 의해 관리됩니다.
- 콘텐츠 데이터베이스에 자동 업데이트 통계 속성이 False로 설정되어 있습니다.
SharePoint Server 2016 및 2019의 경우 SQL 관리자는 SharePoint 콘텐츠 데이터베이스에 대한 유지 관리 계획을 만들어야 합니다.
- SQL 통계는 "SharePoint에서 사용하는 데이터베이스에 오래된 인덱스 통계가 있습니다"라는 상태 규칙에 의해 관리되지 않습니다.
- 콘텐츠 데이터베이스에 자동 업데이트 통계 속성이 True로 설정되어 있습니다. `
단일 SQL Server 프로세스에서 각 요청을 처리하도록 SharePoint 데이터베이스를 호스트하는 SQL Server 인스턴스에 대해 MAXDOP(최대 병렬 처리 수준)를 1로 설정합니다.
중요
최대 병렬 처리 수준을 다른 수로 설정하면 사용될 쿼리 계획이 최적화되지 않아 SharePoint Server 성능이 저하하게 됩니다.
데이터베이스를 다른 서버로 좀 더 쉽게 이동하는 것과 같이 유지 관리를 쉽게 하려면 SQL Server의 모든 인스턴스에 대한 IP 주소를 가리키는 DNS 별칭을 만듭니다. DNS 또는 호스트 이름 별칭에 대한 자세한 내용은 SQL Server 인스턴스의 호스트 이름 별칭 추가 방법을 참조하세요.
이러한 SQL Server 설정 및 옵션에 대한 자세한 내용은 SQL Server 옵션 설정을 참조하세요.
SharePoint Server 배포 전에 데이터베이스 서버 강화
SharePoint Server을 배포하기 전에 데이터베이스 서버를 계획하고 강화하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.
성능과 가용성을 높일 수 있도록 데이터베이스 서버 구성
프런트 엔드 서버 및 애플리케이션 서버의 경우와 마찬가지로 데이터베이스 서버의 구성은 SharePoint Server의 성능에 영향을 줍니다. 일부 데이터베이스는 다른 데이터베이스와 동일한 서버에 있어야 합니다. 반대로 일부 데이터베이스는 다른 데이터베이스와 동일한 서버에 있을 수 없습니다. 자세한 내용은 SharePoint Server 2016 및 2019의 MinRole 및 관련 서비스 설명 및스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server)을 참조하세요.
미러링을 사용하며 항상 사용할 수 있는 데이터베이스에 대한 자세한 내용은 데이터베이스 미러링(SQL Server)을 참조하세요.
SQL Server 장애 조치(failover) 클러스터링 및 Always On 가용성 그룹
SQL Server 2012에는 Always On 가용성 그룹 기능이 도입되었습니다. 이 기능은 데이터베이스 미러링 및 로그 전달 솔루션을 대신하는 고가용성 및 재해 복구 솔루션입니다. Always On 가용성 그룹은 이제 최대 9개의 가용성 복제본을 지원합니다.
참고
데이터베이스 미러링은 향후 SQL Server 버전에서 더 이상 사용되지 않을 예정입니다. 따라서 Always On 가용성 그룹을 사용하는 것이 좋습니다.
Always On 가용성 그룹에는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 클러스터가 필요합니다. 만들어진 모든 가용성 그룹에 대해 WSFC 리소스 그룹이 만들어집니다. 자세한 내용은 다음 리소스를 참조하세요.
처리량과 관리 효율성을 최적화할 수 있도록 저장소 디자인
데이터베이스 서버의 여러 드라이브에 데이터를 분산시키고 데이터의 우선 순위를 지정하는 것이 좋습니다. tempdb 데이터베이스, 콘텐츠 데이터베이스, 사용 현황 데이터베이스, 검색 데이터베이스 및 트랜잭션 로그를 별도의 실제 하드 디스크에 배치하는 것이 이상적입니다. 다음 목록에서는 몇 가지 지침을 제공합니다. 자세한 내용은 데이터베이스 구성을 참조하세요.
공동 작업 또는 업데이트를 많이 수행하는 사이트의 경우 다음과 같은 순위로 저장소를 배분합니다.
가장 높은 순위 항목이 가장 빠른 드라이브에 있어야 합니다.
줄 항목 1 tempdb 데이터 파일 및 트랜잭션 로그 2 콘텐츠 데이터베이스 트랜잭션 로그 파일 3 검색 데이터베이스(검색 관리 데이터베이스는 제외) 4 콘텐츠 데이터베이스 데이터 파일 읽기 중심의 포털 사이트에서는 다음과 같이 트랜잭션 로그보다 데이터 및 검색 로그의 우선 순위를 더 높게 지정합니다.
가장 높은 순위 항목이 가장 빠른 드라이브에 있어야 합니다.
줄 항목 1 tempdb 데이터 파일 및 트랜잭션 로그 2 콘텐츠 데이터베이스 데이터 파일 3 검색 데이터베이스(검색 관리 데이터베이스는 제외) 4 콘텐츠 데이터베이스 트랜잭션 로그 파일 테스트 데이터 및 사용자 데이터의 경우 tempdb의 디스크 I/O가 부족하면 전체 팜 성능이 크게 저하될 수 있음을 보여 줍니다. 이 문제를 방지하려면 tempdb 데이터 파일을 저장하는 드라이브에 전용 디스크를 할당합니다.
최상의 성능을 유지하려면 tempdb 데이터 파일을 저장하는 드라이브에 RAID 10 배열을 사용합니다. tempdb 데이터 파일 수는 CPU 코어 수와 같아야 하며, 각 tempdb 데이터 파일은 같은 크기로 설정해야 합니다.
데이터베이스 데이터 및 트랜잭션 로그 파일을 여러 디스크에 분리합니다. 데이터와 로그 파일이 공간 제한으로 인해 디스크를 공유해야 하는 경우에는 사용 패턴이 서로 다른 여러 파일을 동일한 디스크에 배치하여 동시 액세스 요청을 최소화합니다.
사용량이 많은 콘텐츠 데이터베이스의 경우 여러 데이터 파일을 사용하고 각각 자체 디스크에 배치합니다.
관리 효율성을 높이려면 데이터베이스 크기를 제한하는 대신 필요한 만큼 모니터링하고 조정하여 콘텐츠 데이터베이스를 200GB 이하로 유지합니다.
참고
SQL Server에서 데이터베이스 크기를 수동으로 제한하면 용량이 초과할 때 예기치 않게 시스템이 중지할 수 있습니다.
SQL Server 시스템의 성능과 작업 효율성을 최적으로 유지하려면 I/O 하위 시스템을 적절하게 구성해야 합니다. 자세한 내용은 디스크 사용량 모니터링을 참조하세요.
팁
데이터 파일과 로그 파일 간에 디스크 속도를 측정하는 방법에는 여러 가지가 있습니다. 데이터베이스 데이터에 가장 빠른 드라이브가 로그 파일에도 가장 빠르지는 않을 수 있습니다. 사용 패턴, I/O 및 파일 크기를 고려합니다.
데이터 및 로그 파일의 증가를 사전에 관리
다음은 데이터 및 로그 파일의 증가를 사전에 관리하기 위한 권장 사항입니다.
가능한 경우 모든 데이터 파일 및 로그 파일을 예상되는 최종 크기까지 늘리거나, 설정된 기간(예: 매월 또는 6개월마다)에 정기적으로 늘리거나, 저장소를 많이 사용하는 새 사이트를 롤아웃하기 전에(예: 파일 마이그레이션 중에) 늘립니다.
Enable database autogrowth as a protective measure to make sure that you do not run out of space in data and log files. 다음과 같은 사항을 고려해야 합니다.
중요
자동 증가 사용과 관련된 성능 및 작동 문제를 고려해야 합니다. 자세한 내용은 SQL Server의 "자동 증가"와 "자동 축소" 설정을 위한 고려 사항을 참조하세요.
새 데이터베이스의 기본 설정은 1MB씩 늘리는 것입니다. 이 자동 증가 기본 설정이 데이터베이스의 크기를 늘리므로 기본 설정을 사용하지 않도록 합니다. 대신 SQL Server 옵션 설정에 나와있는 지침을 따르세요.
자동 증가 값을 백분율 대신 고정된 MB 값으로 설정합니다. 즉, 데이터베이스가 클수록 증분 값도 커집니다.
참고
SharePoint 데이터베이스의 자동 증가 기능을 설정할 때는 주의해야 합니다. 데이터베이스 자동 증가를 백분율, 예를 들어 10%로 설정하면 5GB인 데이터베이스는 데이터 파일을 확장해야 할 때마다 500MB씩 커집니다. 이러한 시나리오에서는 디스크의 공간이 부족할 수 있습니다.
예를 들어 콘텐츠가 100MB씩 증가하고 자동 증가가 10MB로 설정되는 시나리오를 생각해 보세요. 그런 다음 갑자기 새 문서 관리 사이트에는 초기 크기가 50GB인 매우 많은 양의 데이터 스토리지가 필요합니다. 이 큰 추가의 경우 500MB 증가는 10MB 증분보다 더 적합합니다.
관리되는 프로덕션 시스템의 경우 자동 증가는 예기치 않은 성장을 위한 비상일 뿐이라고 생각하세요. 자동 증가 옵션을 사용하여 데이터를 관리하고 매일 증가를 기록하지 마세요. 대신 1년 안에 대략적인 크기를 허용하도록 자동 증가를 설정한 다음 오류에 대해 20%의 여백을 추가합니다. 또한 데이터베이스가 공간이 부족하거나 최대 크기에 가까워지면 알림을 표시하도록 경고를 설정합니다.
증가 및 최대 사용 패턴을 허용하도록 드라이브에 최소한 25%의 사용 가능한 공간을 유지 관리합니다. 드라이브를 RAID 배열에 추가하거나 관리할 저장소를 더 많이 할당한 경우에는 공간이 부족해지는 것을 방지하기 위해 용량을 수시로 모니터링합니다.
지속적인 SQL Server 저장소 및 성능 모니터링
SQL Server 저장소 및 성능을 지속적으로 모니터링하여 각 프로덕션 데이터베이스 서버가 부하를 적절하게 처리하는지 확인합니다. 또한 지속적으로 모니터링하면 리소스를 계획하는 데 사용할 수 있는 벤치마크를 설정할 수도 있습니다.
광범위하게 리소스를 모니터링합니다. SQL Server와 관련된 리소스로 모니터링을 제한해서는 안 됩니다. SQL Server를 실행하는 컴퓨터의 CPU, 메모리, 캐시/적중률 및 I/O 하위 시스템과 같은 리소스를 추적하는 것도 마찬가지로 중요합니다.
하나 이상의 서버 리소스가 느려지거나 부하가 과도한 것처럼 보이면 현재 및 계획된 작업량을 기반으로 다음 성능 지침을 고려합니다.
백업 압축을 통해 백업 속도를 높이고 파일 크기 줄이기
백업 압축을 수행하면 SharePoint 백업 작업을 빠르게 진행할 수 있습니다. 이 기능은 SQL Server Standard 및 Enterprise Edition에서 사용할 수 있습니다. 백업 스크립트에서 압축 옵션을 설정하거나 기본적으로 압축하도록 SQL Server를 구성하면 데이터베이스 백업 및 전달된 로그의 크기를 크게 줄일 수 있습니다. 자세한 내용은 백업 압축(SQL Server) 및 데이터 압축이나 테이블 또는 인덱스에 압축 사용을 참조하세요.
도움 주신 분
SharePoint Server 콘텐츠 게시 팀에서는 이 문서 작성에 도움을 주신 다음 분들께 감사 드립니다.
Kay Unkroth(SQL Server 선임 프로그램 관리자)
Chuck Heinzelman(SQL Server 선임 프로그램 관리자)
참고 항목
개념
SharePoint Server 2016 및 2019 환경의 SQL Server 개요
저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server)