검사 목록: SQL Server 구성
BizTalk Server 프로덕션 환경에서 사용할 SQL Server 준비할 때 수행할 단계입니다.
SQL Server 구성
단계 | 참조 |
---|---|
BizTalk Server 데이터베이스 파일 디스크 I/O 경합을 모니터링하고 줄입니다. | - 데이터 및 트랜잭션 로그 파일을 보관하는 디스크의 디스크 I/O 사용량을 사전에 모니터링하는 것이 좋습니다. - 디스크 I/O 경합이 문제가 될 가능성을 줄이기 위해 이들 각각에 대한 데이터 파일 및 트랜잭션 로그 파일을 전용 드라이브에 배치하는 것이 좋습니다. - MessageBox 및 추적(DTA) 데이터베이스를 분리하고 다른 실제 디스크에서 데이터베이스 파일과 트랜잭션 로그 파일을 분리하여 디스크 I/O 경합을 줄일 수 있습니다. 자세한 내용은 데이터베이스 IO 경합 모니터링 및 감소를 참조하세요. |
SQL Server 올바르게 정렬된 디스크 파티션에 구성되어 있는지 확인합니다. | 디스크 파티션이 올바르게 정렬되면 대기 시간이 크게 감소하여 SQL Server 성능이 향상되어 BizTalk Server 성능이 향상될 수 있습니다. 반대로, 정렬되지 않은 디스크 파티션은 I/O 성능에 부정적인 영향을 줄 수 있으므로 SQL Server 저하되고 성능이 BizTalk Server. 올바르게 정렬된 디스크 파티션이 성능에 긍정적인 영향을 줄 수 있는 방법에 대한 자세한 내용은 SQL Server 대한 디스크 파티션 맞춤 모범 사례를 참조하세요. |
SQL Server Profiler 사용하여 모니터링하는 이벤트를 유지합니다. | SQL Server Profiler 를 사용하여 필요한 이벤트만 모니터링할 수 있습니다. 추적이 너무 커지면 원하는 정보에 따라 필터링하여 이벤트 데이터의 하위 집합만 수집할 수 있습니다. 너무 많은 이벤트를 모니터링하면 서버와 모니터링 프로세스에 오버헤드가 추가되어 특히 장기간 동안 모니터링할 때는 추적 파일이나 추적 테이블이 너무 커질 수가 있습니다. |
DTC 로그 파일 디스크 I/O 경합을 모니터링하고 줄입니다. | DTC 로그 파일 디스크 IO 경합 모니터링 및 감소 |
SQL Server 데이터베이스에 고가용성을 제공합니다. | 데이터베이스 가용성 계획 |
장애 조치(failover) 시나리오에 대한 활성/활성 SQL Server 클러스터 구성을 검토합니다. | 장애 조치 시나리오에 대한 SQL Server 클러스터 구성 검토 및 테스트 |
다음을 위해 기본 구성 설정을 사용합니다. - MDOP(최대 병렬 처리 수준). - BizTalk Server MessageBox 데이터베이스에 대한 통계를 SQL Server. - SQL Server 데이터베이스 인덱스가 다시 빌드되고 조각 모음됩니다. |
변경할 수 없는 SQL Server 설정 |
추적 플래그 1118(TF1118)을 SQL Server 모든 인스턴스에 대한 시작 매개 변수로 사용하도록 설정합니다. | TF1118을 구현하면 거의 모든 단일 페이지 할당을 제거하여 SQL Server 인스턴스에서 경합을 줄일 수 있습니다. 자세한 내용은 tempdb 데이터베이스에 대한 Microsoft 기술 자료 문서 동시성 향상을 참조하세요. 참고: TF1118에 대한 자세한 내용은 TF1118에 대한 오해를 참조하세요. 이 링크의 콘텐츠는 Microsoft에서 소유하지 않으며 Microsoft는 콘텐츠의 정확도를 보장하지 않습니다. |
tempdb 데이터베이스를 BizTalk Server 사용하는 각 SQL Server instance 크기가 같은 여러 데이터 파일로 분할합니다. | tempdb에 사용되는 데이터 파일의 크기가 같은지 확인합니다. SQL Server 사용하는 비례 채우기 알고리즘은 데이터 파일의 크기를 기반으로 하므로 이는 매우 중요합니다. 데이터 파일이 같지 않은 크기로 만들어지면 비례 채우기 알고리즘은 모든 파일 간에 할당을 분산하는 대신 GAM(전역 할당 맵) 할당에 가장 큰 파일을 더 많이 사용하므로 여러 데이터 파일을 만드는 목적이 무효화됩니다. 일반적인 지침으로 서버의 각 CPU에 대해 하나의 데이터 파일을 만든 다음 필요에 따라 파일 수를 위아래로 조정합니다. 이중 코어 CPU는 두 개의 CPU로 간주됩니다. 어떤 경우에도 컴퓨터에서 사용할 수 있는 추가 코어 수에 관계없이 데이터 파일 수는 8보다 커서는 안 됩니다. tempdb 파일에 대한 자세한 내용은 tempdb 성능 최적화를 참조하세요. |
최소 및 최대 서버 메모리를 BizTalk Server 데이터베이스를 호스트하는 SQL Server instance 동일한 값으로 설정합니다. | BizTalk Server 데이터베이스를 호스트하는 SQL Server 실행하는 컴퓨터는 실행 중인 SQL Server 전용이어야 합니다. BizTalk Server 데이터베이스를 호스트하는 SQL Server 실행 중인 컴퓨터가 실행 중인 SQL Server 전용인 경우 각 SQL Server instance '최소 서버 메모리' 및 '최대 서버 메모리' 옵션을 설정하여 할당할 고정 메모리 양을 지정하는 것이 좋습니다. SQL Server. 이 경우 'min server memory' 및 'max server memory'를 동일한 값(SQL Server 사용할 최대 실제 메모리 양과 같음)으로 설정해야 합니다. 이렇게 하면 이러한 값을 동적으로 관리하는 SQL Server 사용되는 오버헤드가 줄어듭니다. SQL Server 실행하는 각 컴퓨터에서 다음 T-SQL 명령을 실행하여 SQL Server 할당할 고정 메모리 양을 지정합니다. sp_configure '최대 서버 메모리(MB)',(MB의 최대 크기)sp_configure '최소 서버 메모리(MB)',(MB의 최소 크기) SQL Server 메모리 양을 설정하기 전에 총 실제 메모리에서 Windows Server에 필요한 메모리를 빼서 적절한 메모리 설정을 결정합니다. 이는 SQL Server 할당할 수 있는 최대 메모리 양입니다. 참고: BizTalk Server 데이터베이스를 호스트하는 SQL Server 실행 중인 컴퓨터가 마스터 비밀 서버 클러스터링 항목에 설명된 대로 Enterprise 단일 Sign-On master 비밀을 호스트하는 경우 Enterprise Single Sign-On Service를 실행할 수 있는 메모리가 충분한지 확인하기 위해 이 값을 조정해야 할 수 있습니다. |
BizTalk 추적 데이터베이스의 크기를 고려합니다. | - BizTalk Tracking(DTA) 데이터베이스에서 메시지 크기를 결정할 때 메시지 크기에 비해 중요한 경우 메시지 컨텍스트의 평균 크기를 메시지 크기에 추가합니다. - BizTalk 추적 데이터베이스의 메시지 크기를 제한하려면 승격하는 속성 수를 제한합니다. - 오케스트레이션 디버거 옵션을 사용하는 경우 오케스트레이션에 있는 각 셰이프의 상태 BizTalk 추적 데이터베이스에 저장된다는 점을 고려합니다. |
SQL Server 유지 관리 절차 수행
단계 | 참조 |
---|---|
BizTalk Server 데이터베이스에 대한 자동 증가 설정을 정의합니다. | - 데이터베이스 자동 증가는 특히 MessageBox 및 추적 데이터베이스의 경우 백분율 대신 고정된 수의 메가바이트로 설정해야 합니다. BizTalk Server 애플리케이션 및 처리량에 따라 MessageBox 및 추적 데이터베이스가 상당히 커질 수 있습니다. 자동 증가가 백분율로 설정된 경우 자동 증가도 상당할 수 있습니다. - 즉시 파일 초기화는 파일 증가 작업의 성능 영향을 크게 줄일 수 있습니다. - 이상적으로 파일 그룹을 지원하는 파일의 크기는 미리 할당되어야 하며 가능하면 정적 크기로 설정해야 합니다. 자세한 내용은 데이터베이스에 대한 자동 증가 설정 정의를 참조하세요. |
BizTalk Server 데이터베이스 백업 | - BizTalk Server 데이터베이스 트랜잭션 로그가 바인딩되지 않은 방식으로 증가하지 않도록 BizTalk Server 백업 작업을 실행하는 것이 좋습니다. - 전체 BizTalk Server 환경을 정기적으로 복원해야 하며 프로세스를 신중하게 문서화해야 합니다. - 이전 백업 파일을 보관하는 것이 좋습니다. 자세한 내용은 데이터베이스 백업을 참조하세요. |
BizTalk Server SQL 에이전트 작업을 모니터링합니다. | 이러한 작업의 상태를 모니터링하고 오류 없이 실행 중인지 확인합니다. 자세한 내용은 SQL Server 에이전트 작업 모니터링을 참조하세요. |
BizTalk Server 추적 및 보관 사용 | "DTA 제거 및 보관" SQL 에이전트 작업은 BizTalk 추적 데이터베이스에서 이전 데이터를 보관하고 제거하므로 제어할 수 없습니다. 이는 건강한 BizTalk Server 시스템에 필수적입니다. 자세한 내용은 추적 데이터 제거 및 보관을 참조하세요. |
BizTalk Server 데이터베이스 백업
단계 | 참조 |
---|---|
백업 BizTalk Server SQL 에이전트 작업이 구성되어 있는지 확인합니다. | Backup BizTalk Server 작업 구성을 참조하세요. |
변수에서 지정 @DaysToKeep 한 일 수보다 오래된 백업 파일을 삭제하도록 백업 BizTalk Server SQL 에이전트 작업을 구성합니다. 백업 파일이 삭제되지 않으면 시간이 지남에 따라 무제한으로 증가하여 백업 파일이 포함된 디스크를 채우고 제한된 디스크 공간과 관련된 문제를 일으킬 수 있습니다. | Backup BizTalk Server 작업 구성을 참조하세요. |
백업 BizTalk Server SQL 에이전트 작업이 사용하도록 설정되고 실행되고 있는지 확인합니다. | SQL Server 에이전트 작업 모니터링 |
재해 복구에 SQL Server 로그 전달 사용
단계 | 참조 |
---|---|
재해 복구 서버에 프로덕션 부하를 처리할 수 있는 용량이 있는지 확인합니다. | 재해 복구에 BizTalk Server 로그 전달 사용을 참조하세요. |
재해 복구 루틴의 세부 사항이 잘 문서화되어 있는지 확인합니다. | 재해 복구에 BizTalk Server 로그 전달 사용을 참조하세요. |
정기적인 테스트의 일환으로, 특히 새 BizTalk 애플리케이션이 프로덕션 환경에 배치됨에 따라 재해 복구 사이트로 장애 조치(failover)를 연습합니다. | 재해 복구에 BizTalk Server 로그 전달 사용을 참조하세요. |
SQL 에이전트 작업 BizTalk Server 모니터링
단계 | 참조 |
---|---|
SQL Server 에이전트 서비스가 실행 중인지 확인합니다. | SQL Server 에이전트 작업 모니터링을 참조하세요. |
BizTalk Server 설치한 SQL Server 에이전트 작업이 사용하도록 설정되고 성공적으로 실행되고 있는지 확인합니다. | SQL Server 에이전트 작업 모니터링을 참조하세요. |
BizTalk Server SQL 에이전트 작업이 적시에 완료되는지 확인합니다. | SQL Server 에이전트 작업 모니터링을 참조하세요. |
추적 데이터 보관 및 제거
단계 | 참조 |
---|---|
SQL 에이전트 작업 "DTA 제거 및 보관"이 제대로 구성되고 사용하도록 설정되었으며 성공적으로 완료되었는지 확인합니다. | DTA 제거 및 보관 작업 구성을 참조하세요. |
들어오는 추적 데이터가 생성되는 즉시 작업에서 추적 데이터를 제거할 수 있는지 확인합니다. | 지속 가능한 최대 추적 처리량 측정을 참조하세요. |
소프트 제거 및 하드 제거 매개 변수를 검토하여 최적의 시간 동안 데이터를 유지하고 있는지 확인합니다. | BizTalk 추적 데이터베이스 보관 및 제거를 참조하세요. |
이전 데이터만 제거해야 하고 먼저 보관할 필요가 없는 경우 저장 프로시저를 "dtasp_PurgeTrackingDatabase"이라고 호출하도록 SQL 에이전트 작업을 변경합니다. | BizTalk 추적 데이터베이스에서 데이터 제거를 참조하세요. |