SQL Server 2019 temp table 사용한 워크로드에서 recompile 감소

 

·       Version : SQL Server 2019

 

SQL Server 2019에는 응용프로그램 코드에 필요한 변경을 최소화 하면서 성능을 향상시키는 가지 성능 최적화가 도입 되었다. 이번 포스트에서는 SQL Server 2019 성능 개선 사항 하나인 temp 테이블을 사용한 작업 부하에 대해 리컴파일 감소로 인한 성능 향상을 설명한다.

·       Intelligent query processing in SQL databases : https://docs.microsoft.com/en-us/sql/relational-databases/performance/intelligent-query-processing?view=sql-server-2017

 

개선 사항을 이해하기 위해 먼저 SQL Server 2017 이전의 동작을 살펴본다. DML (SELECT, INSERT, UPDATE, DELETE) 사용하여 임시 테이블을 참조할 임시 테이블이 외부 범위 배치에 의해 생성된 경우에는 실행 마다 DML 문을 다시 컴파일 힌다.

아래 스크립트는 실습를 사용하여 재현할 있다. OuterProc 프로시저에서는 아래와 같은 기능을 한다.

1. 임시테이블 만들기

2. InnerProc 저장 프로시저 호출

 

 

InnerProc 저장 프로시저의 경우 OuterProc에서 생성된 임시 테이블을 참조하는 개의 DML 문이 있다.

3. 임시 테이블에 행을 삽입

4. 임시 테이블에서 행을 리턴

 

 

우리는 임시 테이블을 DML문과 다른 범위로 만들었으며 기존 구현(SQL Server 2019 이전) 대해 임시 테이블 스키마가 실질적으로 변경되지 않음을 신뢰하지 않으므로 실행될 때마다 연관된 DML문이 추가 리컴파일 활동을 하여 CPU 사용률을 높이고 전체 워크로드 성능 처리량을 줄여 성능 저하로 이어질 있다.

 

SQL Server 2019 부터는 불필요한 리컴파일을 피하기 위해 추가 검사를 수행한다.

·       컴파일 타임에 임시 테이블을 생성하는데 사용된 외부 범위 모듈이 연속 실행에 사용된 것과 동일한지 확인한다.

·       초기 컴파일시 변경 DDL (Data Definition Language) 변경 사항을 추적하고 이를 연속 시행을 위한 DDL작업과 비교한다.

결과적으로 보증하지 않은 리컴파일 관련  CPU 오버헤드가 줄어든다.

 

아래 그림은 “OuterProc“ 저장 프로시저를 1,000 (in a loop) 실행하는 16개의 동시 스레드의 테스트 결과를 보여준다. Y축은 발생횟수를 나타내며 파란색 선은 Batch Requests/sec 나타내고 녹색 선은 SQL Re-Compilations/sec 나타낸다.

 

예제에서 기능이 활성화 되면 다음과 같은 결과가 나타난다.

·       Batch Requests/sec (파란색 , 번째 ) 표시되는 처리량 개선

·       전체 작업 시간 단축

·       SQL Re-Compilations/sec (녹색선) 표시되는 리컴파일 감소. ( 번째 테스트 시작시 약간의 증가가 발생하였음)

 

기능은 모든 데이터베이스 호환성 수준에서 SQL Server 2019에서 기본적으로 사용된다. 글을 쓰는 시점에서 기능은 데이터베이스 호환성 수준 150에서 Azure SQL Database에서도 사용할 있지만, 향후 다른 호환성 수준에서도 적용될 있다.

 

 

2019-09-24/ Sungwook Kang / http://sungwookkang.com

 

 

 

Azure SQL, SQL Server 2019, temp table, SQL Re-compilations, Batch Requests, Intelligent query processing in SQL databases

SQL Server 2019 Log Writer Workers

 

·       Version : SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL Server 2019

 

SQL Server 2017 숨겨진 스케줄러에서 최대 4개의 Log Writer Worker 활용하여 트랜잭션 로그 처리 활동을 지원한다.

 

SQL Server 2019 버전부터는 하드웨어 성능에 따라 최대 Log Writer Worker 수가  최대 8개까지 증가한다.

;with kgroups AS

(SELECT kgroup_count = COUNT(DISTINCT processor_group)

 FROM sys.dm_os_nodes osn)

SELECT SQLServer_version = SERVERPROPERTY('ProductVersion'), sinfo.scheduler_count,

       sinfo.cpu_count, sinfo.softnuma_configuration_desc, sinfo.socket_count,

    sinfo.numa_node_count, kgroups.kgroup_count

FROM sys.dm_os_sys_info sinfo

CROSS JOIN kgroups;

 

SELECT req.session_id, req.command, sch.scheduler_id, sched_status = sch.[status],

       sch.cpu_id, sch.parent_node_id, osn.memory_node_id, osn.processor_group

FROM sys.dm_exec_requests req

JOIN sys.dm_os_schedulers sch ON req.scheduler_id = sch.scheduler_id

JOIN sys.dm_os_nodes osn ON sch.parent_node_id = osn.node_id

WHERE req.command = 'LOG WRITER';

 

 

 SQL Server 서비스 시작시 시스템 리소스 상태에 따라 Log Writer Worker수를 결정하며  아래 그림은 SQL Server 2019 2Core CP, 2GM RAM에서 실행 하였을때, Log Writer Worker 수를 SQL Server Error Log에서 확인한 것이다.

 

 

여러 Log Writer Worker 허용되지 않는 경우 단일 Log Writer Worker 사용한다. 그렇지 않으면 아래 공식을 사용하여 Log Writer Worker 수를 계산한다.

·       NUMA 노드 X 2

·       NUMA 노드에서 사용사능한 CPU 계산 (affinity mask 설정에 따라 CPU 카운트에 영향을 있음)

 

MAX_LOG_WRITERS 허용에 따라 4 또는 8개가 할당 된다.

 

[참고자료]

·       https://blogs.msdn.microsoft.com/bobsql/2019/02/11/sql-server-log-writer-workers/

·       http://sql-sasquatch.blogspot.com/2019/06/sql-server-2019-ctp-30-max-number-of.html

 

 

 

2019-09-19/ Sungwook Kang / http://sungwookkang.com

 

 

SQL Server2017, SQL Server 2019, Log Writer Worker, 로그 쓰기 워커, NUMA, OS NODE

+ Recent posts