추적 플래그 4199-전역 적으로 사용 하시겠습니까?

이것은 의견 범주에 속할 수 있지만 사람들이 4199 추적 플래그 를 SQL Server의 시작 매개 변수로 사용하고 있는지 궁금합니다 . 그것을 사용한 사람들에게는 어떤 상황에서 쿼리 회귀가 발생 했습니까?

그것은 전반적으로 잠재적 인 성능상의 이점처럼 보입니다. 저는 비 프로덕션 환경에서 전 세계적으로 활성화하고 몇 달 동안 문제를 해결할 수 있도록 고려하고 있습니다.

2014 년 (또는 2016 년)에 기본적으로 4199의 수정 사항이 옵티 마이저에 롤링됩니까? 예기치 않은 계획 변경 사항을 도입하지 않은 경우를 이해하지만 버전간에 이러한 수정 사항을 모두 숨기는 것이 이상합니다.

우리는 2008, 2008R2 및 대부분 2012를 사용하고 있습니다.

개인적으로 새 프로젝트를 위해 새 서버를 만들 때마다 항상 TF4199를 전 세계적으로 활성화합니다. 기존 인스턴스를 최신 버전으로 업그레이드 할 때도 마찬가지입니다.

TF를 사용하면 응용 프로그램의 동작에 영향을 줄 수있는 새로운 수정 프로그램을 사용할 수 있지만 새 프로젝트의 경우 회귀 위험이 문제가되지 않습니다. 이전 버전에서 업그레이드 된 인스턴스의 경우 이전 버전과 새 버전의 차이점이 자체적으로 문제이므로 계획 회귀를 처리해야 할 것으로 예상되므로 TF4199를 사용하여 싸우는 것을 선호합니다.

기존 데이터베이스에 관한 한, 알 수있는 방법은 테스트입니다. 기존 설정에서 워크로드를 캡처하고 플래그를 활성화 한 후 재생할 수 있습니다. 이 답변에 설명 된대로 RML 유틸리티를 사용하면 프로세스를 자동화 할 수 있습니다 .

분명히 플래그는 전체 인스턴스에 영향을 미치므로 거기에있는 모든 데이터베이스를 테스트해야합니다.

주제에 대한 검색으로 인해 여기에 왔으므로 주제에 대한 최근 경험을 공유하고 싶습니다.

나는 SQL 2014를 실행하고 있었으므로 4199에 대해 조금 신경 써야하는 것이 안전하다고 생각했습니다 ... 그러나 그것은 사실이 아닙니다 ...

4199가 필요한 경우 진단하는 방법

쿼리 가 제대로 실행 되지 않는 것처럼 보이는 경우 ( 특히, 그렇지 않아야한다고 생각 될 때) 다음을 추가하여 모든 문제를 해결하는지 확인하십시오. 4199 ( "Query Optimizer 수정 프로그램 사용") )

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

내 상황에서, 나는 잘 작동하지 않는 쿼리를 날려 버린 상위 10 개의 조항을 가지고 있었는데, 이는 비린내가 일어나고 있다고 생각하게하고 4199가 도움이 될 수 있다고 생각했습니다.

약 4199

새로운 주 버전 릴리스 이후에 생성 된 모든 SQL Server 쿼리 최적화 프로그램 버그 / 성능 수정은 실제로 숨겨져 차단됩니다. 이것은 이론적으로 완벽하게 최적화 된 다른 프로그램에 실제로 해를 끼칠 수있는 경우입니다. 따라서 업데이트를 설치하십시오. 실제 쿼리 최적화 프로그램 변경 사항은 기본적으로 사용되지 않습니다. 따라서 단일 수정 또는 개선이 완료되면 4199를 활용해야합니다. 많은 수정 프로그램이 표시되면 결국 수정 사항 중 하나가 사용자에게 영향을 줄 때이 기능을 켜게됩니다. 이러한 수정 프로그램은 일반적으로 자체 추적 플래그에 연결되어 있지만 "모든 수정 프로그램 설정"마스터로 4199가 사용됩니다.

필요한 수정 프로그램을 알고 있으면 4199를 사용하지 않고 부분 식사를 사용할 수 있습니다. 모든 수정 프로그램을 사용하려면 4199를 사용하십시오.

자, 전 세계적으로 4199를 원합니다 ...

추적 플래그를 전역 적으로 사용하려면 매일 아침 다음 라인으로 실행되는 SQL 에이전트 작업을 작성하십시오. 이렇게하면 누군가 전원을 끄거나 다시 켜도됩니다. 이 작업 단계에는 매우 간단한 SQL이 있습니다.

DBCC TRACEON (4199, -1);

여기서 -1은 DBCC TRACEON에서 전역 부분을 지정합니다. 자세한 내용은 다음을 참조하십시오.

https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396

"재 컴파일"쿼리 계획

가장 최근의 시도에서 나는 전 세계적으로 4199를 활성화 하고 기존의 캐시 된 쿼리 계획을 제거해야했습니다 .

sp_recompile 'dbo.SomeTable'

https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396

다시 컴파일 저장 프로 시저가 데이터베이스 개체 (예 : 테이블)와 관련된 쿼리 계획을 찾아 해당 쿼리 계획을 삭제하면 다음에 비슷한 쿼리를 실행하여 컴파일해야합니다.

따라서 필자의 경우 4199는 잘못된 쿼리 계획이 생성되지 않도록했지만 sp_recompile을 통해 여전히 캐시 된 계획을 제거해야했습니다. 영향을받는 알려진 쿼리에서 테이블을 선택하십시오. 이제 전 세계적으로 4199를 사용 가능하게하고 문제가있는 캐시 된 쿼리 계획을 지운다 고 가정하면 해당 쿼리를 다시 시도하는 것이 좋습니다.

4199에 대한 결론

인덱스를 사용할 때 스마트 인덱스 계획 최적화는 실제로 해당 인덱스를 지능적으로 사용하는 데 중요 해지고 시간이 지남에 따라 쿼리 최적화 프로세스에 대한 일부 수정 사항이 릴리스된다고 가정하면 일반적으로 전 세계적으로 4199를 사용하여 안전하게 실행할 수 있습니다. 새로운 수정 사항이 실제로 이전 수정 사항 이전에 최적화 된 고도로 최적화 된 데이터베이스에서 제대로 작동하지 않을 수 있다는 것을 알고있는 한. 그러나 4199의 기능은 무엇입니까? 그것은 단지 모든 수정을 가능하게합니다.

추적 플래그 4199와 경험을 공유하고 싶었습니다.

SQL Server 2012 SP3을 실행하는 고객 시스템에서 성능 문제 진단을 마쳤습니다. 고객은보고 데이터베이스를 프로덕션 OLTP 서버에서 새 서버로 옮기고있었습니다. 고객의 목표는 OLTP 쿼리로 리소스 경쟁을 제거하는 것이 었습니다. 불행히도 고객은 새로운보고 서버가 매우 느리다고 말했다.

OLTP 시스템에서 실행되는 샘플 쿼리는 1.6 초 안에 완료되었습니다. 쿼리 계획은 뷰의 일부인 ~ 2 억 ~ 행 테이블에 대한 인덱스 탐색을 수행했습니다.

새 서버에서 동일한 쿼리가 10 분 44 초 안에 완료되었습니다. 동일한 ~ 2 억 개의 행 테이블에서 인덱스 스캔을 수행했습니다.

보고 서버 데이터는 OLTP 데이터의 복사본이므로 데이터에 차이가있는 것으로 보이지 않았습니다.

OLTP 시스템을 실행하는 소프트웨어가 시작시 일부 추적 플래그를 활성화했음을 상기 할 때까지 나는 혼란에 빠졌습니다. 그중 하나 인 4199는 쿼리 옵티 마이저 수정이었습니다.

고객의 새보고 서버에서 추적 플래그 4199를 사용하도록 설정 한 결과보고 쿼리가 0.6 초 안에 완료되었습니다. (Wow!) 추적 플래그를 비활성화하고 쿼리가 10 분 44 초 후에 다시 완료되었습니다. 플래그를 활성화했습니다 : 0.6 초로 돌아갑니다. 분명히 추적 플래그를 사용하면 옵티마이 저가 2 억 행 테이블의 인덱스 탐색을 사용할 수있었습니다.

이 경우 추적 플래그 4199로 활성화 된 쿼리 최적화는 큰 차이를 만들었습니다. 당신의 경험은 다를 수 있습니다. 그러나이 경험을 바탕으로 분명히 나를 가능하게 할 가치가있는 것 같습니다.