데이터베이스 스토리지 최적화

완료됨

데이터베이스 스토리지를 최적화하려면 비례 채우기 및 tempdb 구성을 고려해야 합니다.

I/O 성능 이해

I/O 성능은 데이터베이스 애플리케이션에 중요할 수 있습니다. Azure SQL은 물리적 파일 배치에서 사용자를 추상화하지만 필요한 I/O 성능을 얻을 수 있는 방법을 제공합니다.

애플리케이션에 IOPS(초당 입출력)가 중요할 수 있습니다. IOPS 요구에 적합한 서비스 계층 및 vCore를 선택해야 합니다. Azure로 마이그레이션하는 경우 온-프레미스에서 쿼리에 대한 IOPS를 측정하는 방법을 이해합니다. IOPS에 대한 제한이 있는 경우 I/O 대기 시간이 길어지는 것을 볼 수 있습니다. vCore 구매 모델에서는 IOPS가 충분하지 않은 경우 vCore를 스케일 업하거나 중요 비즈니스용 또는 하이퍼스케일 방식으로 전환할 수 있습니다. 프로덕션 워크로드의 경우 DTU를 사용할 때 프리미엄 계층으로 이동하는 것이 좋습니다.

I/O 대기 시간은 I/O 성능에 중요한 또 다른 구성 요소입니다. Azure SQL Database의 I/O 대기 시간을 단축하려면 중요 비즈니스용 또는 하이퍼스케일 방식을 사용하는 것이 좋습니다. SQL Managed Instance의 I/O 대기 시간을 단축하려면 중요 비즈니스용 방식으로 전환하거나 데이터베이스의 파일 크기 또는 파일 수를 늘립니다. 트랜잭션 로그 지연 시간을 줄이려면 여러 문장을 포함하는 트랜잭션을 사용해야 할 수 있습니다.

파일 및 파일 그룹

SQL Server 전문가는 파일 및 파일 그룹을 사용하여 실제 파일 배치를 통해 I/O 성능을 개선하는 경우가 많습니다. Azure SQL에서는 사용자가 특정 디스크 시스템에 파일을 저장할 수 없습니다. 그러나 Azure SQL에는 속도, IOPS 및 대기 시간에 대한 I/O 성능에 대한 리소스 약정이 있습니다. 이러한 방식으로 실제 파일 배치에서 사용자를 추상화하는 것이 유용할 수 있습니다.

Azure SQL Database에는 데이터베이스 파일이 하나뿐이며(일반적으로 하이퍼스케일에는 여러 개 있음) Azure 인터페이스를 통해 최대 크기가 구성됩니다. 더 많은 파일을 만드는 기능은 없습니다.

Azure SQL Managed Instance는 데이터베이스 파일 추가 및 크기 구성을 지원하지만 파일의 물리적 배치는 지원하지 않습니다. SQL Managed Instance의 파일 수와 파일 크기를 사용하여 I/O 성능을 개선시킬 수 있습니다. 또한 관리 목적으로 SQL Managed Instance에 대해 사용자 정의 파일 그룹이 지원됩니다.

비례 채우기 설명

두 개의 데이터 파일이 있는 SQL Server 데이터베이스에 1GB의 데이터를 삽입하는 경우 각 파일이 약 512MB 증가할 것으로 예상할 수 있습니다. 그러나 항상 그렇지는 않습니다. SQL Server는 각 파일의 크기에 따라 데이터를 배포합니다. 예를 들어 두 데이터 파일이 모두 2GB인 경우 데이터는 균등하게 분산됩니다. 그러나 한 파일이 10기가바이트이고 다른 파일이 1기가바이트인 경우 약 900MB는 더 큰 파일로, 100MB는 더 작은 파일로 이동합니다. 이 동작은 모든 데이터베이스에서 일반적이지만 쓰기 집약적 tempdb에서는 더 많은 쓰기를 처리하므로 균일하지 않은 쓰기 패턴이 가장 큰 파일에 병목 현상을 일으킬 수 있습니다.

SQL Server에서 Tempdb 구성

SQL Server는 설치 중에 사용 가능한 CPU 수를 검색하고 크기 조정을 통해 최대 8개까지 적절한 수의 파일을 구성합니다. 또한 추적 플래그 1117 및 1118의 동작은 데이터베이스 엔진에 통합되었지만, 이는 tempdb에만 적용됩니다. tempdb가 많은 워크로드의 경우 컴퓨터의 CPU 수와 일치하는 tempdb 파일 수를 8개 이상으로 늘리는 것이 도움이 될 수 있습니다.

SQL Server와 Azure SQL 모두에 대해 동일한 방식으로 tempdb를 사용합니다. 그러나 파일 배치, 파일 수 및 크기, tempdb 구성 옵션을 포함하여 tempdb를 구성하는 기능은 다릅니다.

SQL Server는 사용자 정의 임시 테이블을 저장하는 것 외에 다양한 작업에 tempdb를 사용합니다. 중간 쿼리 결과, 정렬 작업 및 행 버전 관리용 버전 저장소를 저장하는 작업 테이블에 사용됩니다. 이 광범위한 사용률로 인해 tempdb를 사용 가능한 가장 낮은 대기 시간 스토리지에 배치하고 데이터 파일을 올바르게 구성하는 것이 중요합니다.

tempdb의 데이터베이스 파일은 항상 로컬 SSD 드라이브에 자동으로 저장되므로 I/O 성능은 문제가 되지 않습니다.

SQL Server 전문가는 둘 이상의 데이터베이스 파일을 사용하여 tempdb 테이블의 할당을 분할하는 경우가 많습니다. Azure SQL Database의 경우 파일 수는 최대 16개인 vCore 수(예: vCore 2개는 4개 파일과 같음)로 크기가 조정됩니다. 파일 수는 tempdb에 대해 T-SQL을 통해 구성할 수 없지만 배포 옵션을 변경하여 구성할 수 있습니다. tempdb의 최대 크기는 vCore 수에 따라 조정됩니다. vCore와는 별개로 SQL Managed Instance를 통해 12개 파일을 얻습니다.

데이터베이스 옵션 MIXED_PAGE_ALLOCATIONOFF로 설정되고 AUTOGROW_ALL_FILESON으로 설정됩니다. 이를 구성할 수는 없지만 SQL Server와 마찬가지로 이것이 권장되는 기본값입니다.

과도한 래치 경합을 완화할 수 있는 SQL Server 2019에 도입된 tempdb 메타데이터 최적화 기능은 현재 Azure SQL Database 또는 Azure SQL Managed Instance에서 사용할 수 없습니다.

데이터베이스 구성

일반적으로 T-SQL ALTER DATABASEALTER DATABASE SCOPED CONFIGURATION 문을 사용하여 데이터베이스를 구성합니다. Azure SQL에는 성능을 위해 많은 구성 옵션을 사용할 수 있습니다. SQL Server, Azure SQL Database 및 Azure SQL Managed Instance 간의 차이에 대해서는 ALTER DATABASEALTER DATABASE SCOPED CONFIGURATION T-SQL 참조를 참조하세요.

Azure SQL Database에서 기본 복구 모델은 전체 복구로, 데이터베이스가 Azure SLA(서비스 수준 계약)를 충족할 수 있도록 합니다. 즉, 최소 로깅이 허용되는 경우를 제외하고는 tempdb대량 작업에 대한 최소 로깅이 지원되지 않습니다.

MAXDOP 구성

MAXDOP(최대 병렬 처리 수준)는 개별 쿼리의 성능에 영향을 미칠 수 있습니다. SQL Server 및 Azure SQL은 동일한 방식으로 처리 MAXDOP 됩니다. 더 높은 값으로 설정하면 MAXDOP 쿼리당 더 많은 병렬 스레드가 사용되므로 쿼리 실행 속도가 향상될 수 있습니다. 그러나 이러한 병렬 처리가 증가하려면 메모리 리소스가 추가로 필요하므로 메모리가 부족하고 스토리지 성능에 영향을 줄 수 있습니다. 예를 들어 행 그룹을 columnstore로 압축할 때 병렬 처리에는 메모리가 더 많이 필요하므로 메모리 압력과 행 그룹 트리밍이 발생할 수 있습니다.

반대로 MAXDOP를 더 낮은 값으로 설정하면 메모리 압력을 줄여 스토리지 시스템이 보다 효율적으로 수행할 수 있습니다. 이는 메모리 리소스가 제한되거나 스토리지 요구가 높은 환경에서 중요합니다. MAXDOP를 신중하게 구성하면 쿼리 성능과 스토리지 효율성의 균형을 유지하여 CPU 및 스토리지 리소스를 최적으로 사용할 수 있습니다.

다음 기술을 사용하여 Azure SQL에서도 SQL Server와 유사하게 MAXDOP를 구성할 수 있습니다.

  • Azure SQL에 ALTER DATABASE SCOPED CONFIGURATION이 지원되도록 구성하려면 MAXDOP 사용
  • "최대 병렬 처리 수준"에 대한 저장 프로시저 sp_configure 는 SQL Managed Instance에 대해 지원됩니다.
  • MAXDOP 쿼리 힌트는 완전히 지원됩니다.
  • 리소스 관리자를 사용하여 구성하는 MAXDOP 것은 SQL Managed Instance에 대해 지원됩니다.