쿼리 저장소 사용 시나리오Query Store Usage Scenarios

이 항목은 다음에 적용됩니다. 예SQL Server(2016부터)예Azure SQL Database아니요Azure SQL Data Warehouse아니요병렬 데이터 웨어하우스 THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)yesAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

쿼리 저장소는 예측 가능한 워크로드 성능을 추적하고 보장하는 것이 중요한 광범위한 시나리오에서 사용될 수 있습니다.Query Store can be used in wide set of scenarios when tracking and ensuring predictable workload performance is critical. 다음은 고려할 수 있는 몇 가지 예입니다.Here are some examples you can consider:

  • 계획 선택 재발이 있는 쿼리 식별 및 수정Pinpoint and fix queries with plan choice regressions

  • 상위 리소스 소비 쿼리 식별 및 조정Identify and tune top resource consuming queries

  • A/B 테스트A/B testing

  • 최신 SQL ServerSQL Server로 업그레이드하는 동안 성능 안정성 유지Keep performance stability during the upgrade to newer SQL ServerSQL Server

  • 임시 워크로드 식별 및 개선Identify and improve ad-hoc workloads

계획 선택 재발이 있는 쿼리 식별 및 수정Pinpoint and fix queries with plan choice regressions

일반 쿼리 실행 중 데이터 카디널리티가 변경되거나, 인덱스가 생성, 변경 또는 삭제되거나, 통계가 업데이트되는 등 중요한 입력이 달라졌기 때문에 쿼리 최적화 프로그램에서 다른 계획을 사용하도록 결정하는 경우가 있을 수 있습니다. 선택하는 대부분의 새 계획은 이전에 사용된 것보다 더 낫거나 거의 동일합니다.During the regular query execution Query Optimizer may decide to take a different plan because important inputs became different: data cardinality has changed, indexes have been created, altered or dropped, statistics have been updated, etc. For the most part new plan it picks is better or about the same than one was used previously. 그러나 새 계획이 훨씬 나쁜 경우도 있습니다. 이러한 상황을 계획 선택 변경 재발이라고 합니다.However, there are cases when new plan is significantly worse - we refer to that situation as plan choice change regression. 쿼리 저장소 이전에는 SQL ServerSQL Server 에서 사용자가 시간이 지남에 따라 사용된 실행 계획을 확인할 수 있는 기본 제공 데이터 저장소를 제공하지 않았기 때문에 이는 식별하고 수정하기 매우 어려운 문제였습니다.Prior to Query Store, it was an issue very difficult to identify and fix as SQL ServerSQL Server didn’t provide built-in data store for users to look at for execution plans that were used over time.

쿼리 저장소를 사용하여 다음을 신속하게 수행할 수 있습니다.With the Query Store you can quickly:

  • 관심 기간(지난 시간, 일, 주 등) 동안 실행 메트릭이 저하된 모든 쿼리를 식별할 수 있습니다.Identify all queries which execution metrics have been degraded in the period of time of interest (last hour, day, week, etc.). 에서 재발된 쿼리 SQL Server Management StudioSQL Server Management Studio 를 사용하여 분석을 가속화할 수 있습니다.Use Regressed Queries in SQL Server Management StudioSQL Server Management Studio to speed up your analysis.

  • 재발된 쿼리 중에서 여러 계획이 있고 잘못된 계획 선택으로 인해 저하된 쿼리를 매우 쉽게 찾을 수 있습니다.Among the regressed queries it’s very easy to find those that had multiple plans and which degraded because of the bad plan choice. 재발된 쿼리 에서 계획 요약 창을 사용하여 재발된 쿼리에 대한 모든 계획과 시간에 따른 쿼리 성능을 시각화할 수 있습니다.Use Plan Summary pane in Regressed Queries to visualize all plans for a regressed query and their query performance over time.

  • 기록에서 이전 계획이 더 나은 것으로 증명된 경우 이를 적용합니다.Force the previous plan from the history if it proved to be better. 회귀된 쿼리계획 강제 적용 단추를 사용하여 쿼리에 대해 선택한 계획을 강제 적용합니다.Use Force Plan button in Regressed Queries to force selected plan for the query.

    query-store-usage-1query-store-usage-1

    이 시나리오에 대한 자세한 설명은 쿼리 저장소: 데이터베이스를 위한 항공 데이터 레코더 블로그를 참조하세요.For detailed description of the scenario refer to Query Store: A flight data recorder for your database blog.

상위 리소스 소비 쿼리 식별 및 조정Identify and tune top resource consuming queries

워크로드에서 수천 개의 쿼리를 생성할 수 있지만 일반적으로 그 중 소수의 쿼리만 대부분의 시스템 리소스를 사용하므로 주의가 필요합니다.Although your workload may generate thousands of queries, typically only a handful of them actually use the most of the system resources and therefore require your attention. 리소스를 많이 사용하는 상위 쿼리 중에서 추가 조정을 통해 개선할 수 있는 쿼리 또는 재발된 쿼리를 찾습니다.Among top resource consuming queries you will typically find those that are either regressed or those that can be improved with additional tuning.

탐색을 시작하는 가장 쉬운 방법은 에서 상위 리소스 소비 쿼리 Management StudioManagement Studio를 여는 것입니다.The easiest way to start exploration is to open Top Resource Consuming Queries in Management StudioManagement Studio. 사용자 인터페이스는 상위 리소스 소비 쿼리를 나타내는 막대 그래프(왼쪽), 선택한 쿼리에 대한 계획 요약(오른쪽) 및 선택한 계획에 대한 시각적 쿼리 계획(아래쪽), 이렇게 세 개의 창으로 구분되어 있습니다.User interface is separated into three panes: A histogram representing top resource consuming queries (left), a plan summary for selected query (right) and visual query plan for selected plan (bottom). 구성 을 클릭하여 분석할 쿼리 수 및 관심 있는 시간 간격을 제어할 수 있습니다.Click the Configure button to control how many queries you want to analyze and the time interval of interest. 또한 다양한 리소스 소비 차원(기간, CPU, 메모리, IO, 실행 횟수)과 기준선(평균, 최소값, 최대값, 합계, 표준 편차) 간에 선택할 수 있습니다.Additionally, you can choose between different resource consumption dimensions (duration, CPU, memory, IO, number of executions) and the baseline (Average, Min, Max, Total, Standard Deviation).

query-store-usage-2query-store-usage-2

오른쪽의 계획 요약을 보고 실행 기록을 분석한 후 다른 계획과 해당 런타임 통계에 대해 자세히 알아볼 수 있습니다.Look at the plan summary on the right to analyze the execution history and learn about the different plans and their runtime statistics. 아래쪽 창을 사용하여 다른 계획을 검사하거나 나란히 렌더링하여 시각적으로 비교(비교 단추 사용)할 수 있습니다.Use the bottom pane to examine the different plans or to compare them visually, rendered side by side (use the Compare button).

최적 상태가 아닌 성능의 쿼리를 식별한 경우 수행할 작업은 문제의 성격에 따라 다릅니다.When you identify a query with sub-optimal performance, your action depends on the nature of the problem:

  1. 쿼리가 여러 계획으로 실행되고 마지막 계획이 이전 계획보다 훨씬 나쁜 경우 계획 적용 메커니즘을 사용하여 SQL ServerSQL Server 에서 향후 실행에 최적 계획을 사용하도록 할 수 있습니다.If the query was executed with multiple plans and the last plan is significantly worse than previous plan, you can use the plan forcing mechanism to ensure SQL ServerSQL Server will use the optimal plan for future executions

  2. 최적화 프로그램이 XML 계획에서 누락된 인덱스를 제안하는지 확인합니다.Check if the optimizer is suggesting any missing indexes in XML plan. 그런 경우 누락된 인덱스를 만든 다음 쿼리 저장소를 사용하여 쿼리 성능을 평가합니다.If yes, create the missing index and use the Query Store to evaluate query performance after the index creation

  3. 쿼리에 사용된 기본 테이블에 대한 통계가 최신 상태인지 확인합니다.Make sure that the statistics are up-to-date for the underlying tables used by the query.

  4. 쿼리에 사용된 인덱스가 조각 모음되었는지 확인합니다.Make sure that indexes used by the query are defragmented.

  5. 부담이 큰 쿼리는 다시 작성하는 것이 좋습니다.Consider rewriting expensive query. 예를 들어 쿼리 매개 변수화를 활용하고 동적 SQL의 사용을 줄입니다.For example, take advantages of query parameterization and reduce usage of dynamic SQL. 데이터를 읽을 때의 최적 논리를 구현합니다(응용 프로그램 쪽이 아니라 데이터베이스 쪽에서 데이터 필터링 적용).Implement optimal logic when read the data (apply data filtering on database side, not on application side).

A/B 테스트A/B testing

쿼리 저장소를 사용하여 예정된 응용 프로그램 변경 이전과 이후의 워크로드 성능을 비교할 수 있습니다.Use Query Store to compare workload performance before and after the application change you plan to introduce. 다음 목록에는 쿼리 저장소를 사용하여 환경 또는 응용 프로그램 변경이 워크로드 성능에 미치는 영향을 평가할 수 있는 몇 가지 예제가 포함되어 있습니다.The following list contains several examples where you can use Query Store to assess impact of the environment or application change to the workload performance:

  • 새 응용 프로그램 버전 출시Rolling out new application version.

  • 서버에 새 하드웨어 추가Adding new hardware to the server.

  • 부담이 큰 쿼리에서 참조하는 테이블에 누락된 인덱스 만들기Creating missing indexes on tables referenced by expensive queries.

  • 행 수준 보안을 위한 보안 정책 적용.Applying filtering policy for row-level security. 자세한 내용은 쿼리 저장소를 사용하여 행 수준 보안 최적화를 참조하세요.For more details see Optimizing Row Level Security with Query Store.

  • OLTP 응용 프로그램에서 자주 수정되는 테이블에 임시 시스템 버전 추가Adding temporal system-versioning to tables that are frequently modified by your OLTP applications.

    이러한 시나리오에서는 다음 워크플로를 적용합니다.In any of these scenarios apply the following workflow:

  1. 계획된 변경 전에 쿼리 저장소와 함께 워크로드를 실행하여 성능 기준선을 생성합니다.Run your workload with the Query Store before the planned change to generate performance baseline.

  2. 제어되는 시점에서 응용 프로그램 변경을 적용합니다.Apply application change at the controlled moment in time.

  3. 변경 후 시스템의 성능 이미지를 생성할 수 있는 충분한 시간 동안 워크로드를 계속 실행합니다.Continue running the workload long enough to generate performance image of the system after the change

  4. 1과 3의 결과를 비교합니다.Compare results from #1 and #3.

    1. 전체 데이터베이스 사용량을 열어 전체 데이터베이스에 대한 영향을 확인합니다.Open Overall Database Consumption to determine impact to the entire database.

    2. 상위 리소스 소비 쿼리 를 열거나 Transact-SQLTransact-SQL을 사용한 사용자 고유 분석을 실행하여 가장 중요한 쿼리에 미치는 변경의 영향을 분석합니다.Open Top Resource Consuming Queries (or run your own analysis using Transact-SQLTransact-SQL) to analyze impact of the change to the most important queries.

  5. 변경을 유지할지 또는 롤백(새로운 성능이 허용되지 않는 경우)을 수행할지 결정합니다.Decide whether to keep the change or perform roll back in case when new performance is unacceptable.

    다음 그림에서는 누락된 인덱스를 만드는 경우 쿼리 저장소 분석(4단계)을 보여 줍니다.The following illustration shows Query Store analysis (step 4) in case of missing index creation. 상위 리소스 소비 쿼리 /계획 요약 창을 열어 인덱스 만들기의 영향을 받는 쿼리에 대해 이 뷰를 가져옵니다.Open Top Resource Consuming Queries / Plan summary pane to get this view for the query that should be impacted by the index creation:

    query-store-usage-3query-store-usage-3

    또한 나란히 렌더링하여 인덱스 만들기 이전과 이후의 계획을 비교할 수 있습니다.Additionally, you can compare plans before and after index creation by rendering them side by side. 도구 모음에 빨간색 사각형으로 표시된 "별도 창에서 선택한 쿼리에 대한 계획 비교" 도구 모음 옵션을 사용합니다.(“Compare the plans for the selected query in a separate window” toolbar option which is marked with red square on the toolbar.)

    query-store-usage-4query-store-usage-4

    인덱스 만들기 이전 계획(plan_id = 1, 위)에 누락된 인덱스 힌트가 있으며, Clustered Index Scan이 쿼리에서 가장 부담이 큰 연산자였음을 검사할 수 있습니다(빨간색 사각형).Plan before index creation (plan_id = 1, above) has missing index hint and you can inspect that Clustered Index Scan was the most expensive operator in the query (red rectangle).

    이제 누락된 인덱스 만들기 이후 계획(plan_id = 15, 아래)에 전체 쿼리 비용을 줄이고 성능을 개선하는 Index Seek(비클러스터형)가 있습니다(녹색 사각형).Plan after missing index creation (plan_id = 15, below) now has Index Seek (Nonclustered) which reduces the overall cost of the query and improves it performance (green rectangle).

    분석에 따라, 쿼리 성능이 향상되었으므로 인덱스를 유지할 수 있습니다.Based on analysis you would likely keep the index as query performance has been improved.

최신 SQL ServerSQL Server로 업그레이드하는 동안 성능 안정성 유지 Keep performance stability during the upgrade to newer SQL ServerSQL Server

SQL Server 2014SQL Server 2014이전에는 사용자가 최신 플랫폼 버전으로 업그레이드하는 동안 성능 회귀 위험에 노출되었습니다.Prior to SQL Server 2014SQL Server 2014, users were exposed to the risk of performance regression during the upgrade to the latest platform version. 이러한 이유로 새 비트가 설치되는 즉시 최신 버전의 쿼리 최적화 프로그램이 활성화되었습니다.The reason for that was the fact that latest version of Query Optimizer became active immediately once new bits are installed.

SQL Server 2014SQL Server 2014부터는 쿼리 최적화 프로그램의 모든 변경 내용이 최신 데이터베이스 호환성 수준에 연결되므로 계획이 업그레이드 시점에 즉시 변경되지 않고 사용자가 COMPATIBILITY_LEVEL을 최신 상태로 변경할 때 변경됩니다.Starting with SQL Server 2014SQL Server 2014 all Query Optimizer changes are tied to the latest database compatibility level, so plans are not changed right at point of upgrade but rather when a user changes the COMPATIBILITY_LEVEL to the latest one. 이 기능은 쿼리 저장소와 함께 업그레이드 프로세스에서 쿼리 성능에 대한 뛰어난 제어 수준을 제공합니다.This capability, in combination with Query Store gives you a great level of control over the query performance in the upgrade process. 아래 그림에 권장 업그레이드 워크플로가 표시되어 있습니다.Recommended upgrade workflow is shown in the following picture:

query-store-usage-5query-store-usage-5

  1. 데이터베이스 호환성 수준을 변경하지 않고 SQL ServerSQL Server를 업그레이드합니다.Upgrade SQL ServerSQL Server without changing the database compatibility level. 최신 쿼리 최적화 프로그램 변경 내용을 노출하지 않고 쿼리 저장소를 포함하는 최신 SQL ServerSQL Server 기능을 제공합니다.It doesn’t expose the latest Query Optimizer changes but still provides newer SQL ServerSQL Server features including Query Store.

  2. 쿼리 저장소를 사용하도록 설정합니다.Enable Query Store. 이 항목에 대한 자세한 내용은 쿼리 저장소를 워크로드에 맞게 조정된 상태로 유지를 참조하세요.For more information on this topic, see Keep Query Store adjusted to your workload.

  3. 쿼리 저장소가 쿼리 및 계획을 캡처할 수 있도록 하고 원본/이전 데이터베이스 호환성 수준으로 성능 기준선을 설정합니다.Allow Query Store to capture queries and plans, and establishes a performance baseline with the source/previous database compatibility level. 모든 계획을 캡처하고 안정적인 기준선을 얻을 때까지 이 단계를 계속 유지합니다.Stay at this step long enough to capture all plans and get a stable baseline. 프로덕션 워크로드에 대한 일반적인 비즈니스 주기 기간일 수 있습니다.This can be the duration of an usual business cycle for a production workload.

  4. 최신 데이터베이스 호환성 수준으로 이동: 워크로드를 최신 쿼리 최적화 프로그램 변경 내용에 노출하여 잠재적으로 새 계획을 만들 수 있도록 합니다.Move to latest database compatibility level: get your workload exposed to the latest Query Optimizer changes and let it potentially create new plans.

  5. 분석 및 회귀 수정에 쿼리 저장소 사용: 대부분의 경우 새 쿼리 최적화 프로그램 변경 내용은 향상된 계획을 생성합니다.Use Query Store for analysis and regression fixes: for the most part, the new Query Optimizer changes should produce better plans. 그러나 쿼리 저장소는 계획 선택 회귀를 식별하고 계획 강제 적용 메커니즘을 사용하여 수정하는 간편한 방법을 제공합니다.However, Query Store will provide an easy way to identify plan choice regressions and fix them using a plan forcing mechanism.

임시 워크로드 식별 및 개선Identify and improve ad-hoc workloads

일부 워크로드에는 전체 응용 프로그램 성능을 개선하기 위해 조정할 수 있는 주요 쿼리가 없습니다.Some workloads do not have dominant queries that you can tune to improve overall application performance. 이러한 워크로드는 일반적으로 각각 시스템 리소스의 일부를 사용하는 비교적 다수의 쿼리가 있는 것이 특징입니다.Those workloads are typically characterized with relatively large number of different queries each of them consuming portion of system resources. 이러한 쿼리는 거의 실행되지 않으므로(일반적으로 한 번만 실행되므로 임시 쿼리라고 함) 해당 런타임 소비는 중요하지 않습니다.Being unique, those queries are executed very rarely (usually only once, thus name ad hoc), so their runtime consumption is not critical. 반면, 응용 프로그램이 항상 완전히 새로운 쿼리를 생성하는 경우에는 시스템 리소스의 상당 부분이 최적화되지 않은 쿼리 컴파일에 소비됩니다.On the other hand, given that application is generating net new queries all the time, significant portion of system resources is spent on query compilation which is not optimal. 이는 많은 수의 쿼리와 계획이 예약된 공간을 차지하는 경우 쿼리 저장소에 이상적인 상황이 아닙니다. 즉, 쿼리 저장소가 매우 빠르게 읽기 전용 모드로 전환될 수 있습니다.This is not ideal situation for Query Store either given that large number of queries and plans flood the space you have reserved which means that Query Store will likely end up in the read-only mode very quickly. 크기 기반 정리 정책 (쿼리 저장소를 항상 실행되도록 유지하는 데매우 권장됨 )을 활성화한 경우 백그라운드 프로세스에서 쿼리 저장소 구조를 정리하므로 대부분의 시간 동안 상당한 시스템 리소스가 소비됩니다.If you activated Size Based Cleanup Policy (highly recommended to keep Query Store always up and running), then background process will be cleaning Query Store structures most of the time also taking significant system resources.

상위 리소스 소비 쿼리 뷰는 워크로드의 임시 특성에 대한 첫 번째 표시를 제공합니다.Top Resource Consuming Queries view will give you first indication of the ad-hoc nature of your workload:

query-store-usage-6query-store-usage-6

실행 수 메트릭을 사용하여 상위 쿼리가 임시 쿼리인지 분석합니다( QUERY_CAPTURE_MODE = ALL을 사용하여 쿼리 저장소를 실행해야 함).Use Execution Count metric to analyze whether your top queries are ad hoc (this requires you to run Query Store with QUERY_CAPTURE_MODE = ALL). 위 다이어그램에서는 상위 리소스 소비 쿼리 의 90%가 한 번만 실행되는 것을 볼 수 있습니다.From diagram above you can see that 90% of your Top Resource Consuming Queries are executed only once.

또는 Transact-SQLTransact-SQL 스크립트를 실행하여 시스템의 총 쿼리 텍스트 수, 쿼리 수 및 계획 수를 파악하고 query_hash와 plan_hash를 비교하여 차이점을 확인할 수 있습니다.Alternatively, you can run Transact-SQLTransact-SQL script to get total number of query texts, queries and plans in the system and determine how different they are by comparing their query_hash and plan_hash:

/*Do cardinality analysis when suspect on ad-hoc workloads*/  
SELECT COUNT(*) AS CountQueryTextRows FROM sys.query_store_query_text;  
SELECT COUNT(*) AS CountQueryRows FROM sys.query_store_query;  
SELECT COUNT(DISTINCT query_hash) AS CountDifferentQueryRows FROM  sys.query_store_query;  
SELECT COUNT(*) AS CountPlanRows FROM sys.query_store_plan;  
SELECT COUNT(DISTINCT query_plan_hash) AS  CountDifferentPlanRows FROM  sys.query_store_plan;  

이것은 임시 쿼리가 있는 워크로드에서 얻을 수 있는 하나의 잠재적 결과입니다.This is one potential result you can get in case of workload with ad-hoc queries:

query-store-usage-7query-store-usage-7

쿼리 결과는 쿼리 저장소에 많은 수의 쿼리와 계획이 있음에도 불구하고 해당 query_hash와 plan_hash가 실제로 다르지 않음을 보여 줍니다.Query result shows that despite the large number of queries and plans in the Query Store their query_hash and plan_hash are actually not different. 고유한 쿼리 텍스트와 고유한 query_hash 간의 비율(1보다 훨씬 큼)은 워크로드가 매개 변수화하기 적절한 후보임을 나타냅니다. 쿼리 간에 쿼리 텍스트의 일부로 제공된 문자열 상수(매개 변수)만 다를 뿐이기 때문입니다.Ratio between unique query texts and unique query_hash which is much bigger than 1 is an indication that workload is a good candidate for parameterization as the only difference between the queries is literal constant (parameter) provided as part of the query text.

일반적으로 이러한 상황은 응용 프로그램에서 쿼리를 생성(저장 프로시저 또는 매개 변수화된 쿼리를 호출하는 대신)하는 경우 또는 응용 프로그램이 기본적으로 쿼리를 생성하는 개체-관계형 매핑 프레임워크에 의존하는 경우에 발생합니다.Usually, this situation happens if your application generates queries (instead of invoking stored procedures or parameterized queries) or if it relies on object-relational mapping frameworks that generate queries by default.

응용 프로그램 코드에 대한 제어 권한이 있는 경우 저장 프로시저 또는 매개 변수화된 쿼리를 활용하도록 데이터 액세스 계층을 다시 작성하는 것이 좋습니다.If you are in control of the application code you may consider rewriting of the data access layer to utilize stored procedures or parameterized queries. 그러나 전체 데이터베이스(모든 쿼리) 또는 query_hash가 동일한 개별 쿼리 템플릿에 대해 쿼리 매개 변수화를 적용하여 응용 프로그램을 변경하지 않고 이 상황을 크게 개선할 수도 있습니다.However, this situation can be also significantly improved without application changes by forcing query parameterization for the entire database (all queries) or for the individual query templates with the same query_hash.

개별 쿼리 템플릿을 사용하는 접근 방식에서는 계획 지침을 만들어야 합니다.Approach with individual query templates requires plan guide creation:

/*Apply plan guide for the selected query template*/  
DECLARE @stmt nvarchar(max);  
DECLARE @params nvarchar(max);  
EXEC sp_get_query_template   
    N'<your query text goes here>',  
    @stmt OUTPUT,   
    @params OUTPUT;  

EXEC sp_create_plan_guide   
    N'TemplateGuide1',   
    @stmt,   
    N'TEMPLATE',   
    NULL,   
    @params,   
    N'OPTION (PARAMETERIZATION FORCED)';  

계획 지침이 있는 솔루션이 더 정확하지만 여기에는 추가 작업이 필요합니다.Solution with plan guides is more precise but it requires more work.

모든 쿼리(또는 대부분의 쿼리)가 자동 매개 변수화에 적합한 경우 전체 데이터베이스에 대해 FORCED PARAMETERIZATION 을 변경하는 것이 더 나은 옵션일 수 있습니다.If all your queries (or majority of them) are candidates for auto-parameterization than changing FORCED PARAMETERIZATION for the entire database may be a better option:

/*Apply forced parameterization for entire database*/  
ALTER DATABASE <database name> SET PARAMETERIZATION  FORCED;  
참고

이 항목에 대한 자세한 내용은 강제 매개 변수화 사용 지침을 참조하세요.For more information on this topic, see Guidelines for Using Forced Parameterization.

이 단계 중 하나를 적용하면 상위 리소스 소비 쿼리 에 워크로드의 다른 그림이 표시됩니다.After you apply any of these steps, Top Resource Consuming Queries will show you different picture of your workload.

query-store-usage-8query-store-usage-8

경우에 따라 응용 프로그램이 자동 매개 변수화에 적합하지 않은 많은 쿼리를 생성할 수 있습니다.In some cases your application may generate lots of different queries which are not good candidates for auto-parameterization. 이 경우 시스템에 많은 쿼리가 표시되지만 고유한 쿼리와 고유한 query_hash 간의 비율은 1에 가까울 수 있습니다.In that case you will see large number of queries in the system but the ratio between unique queries and unique query_hash is likely close to 1.

이 경우 임시 작업을 위해 최적화 서버 옵션을 설정하여 다시 실행될 가능성이 낮은 쿼리에서 캐시 메모리가 낭비되는 것을 방지하는 것이 좋습니다.In that case you may want to enable the Optimize for Ad Hoc Workloads server option to prevent wasting cache memory on queries that won’t likely be executed again. 쿼리 저장소에서 이러한 쿼리의 캡처를 방지하려면 QUERY_CAPTURE_MODEAUTO로 설정합니다.To prevent capture of those queries in the Query Store, set QUERY_CAPTURE_MODE to AUTO.

sp_configure 'show advanced options', 1;  
GO  
RECONFIGURE;  
GO  

sp_configure 'optimize for ad hoc workloads', 1;  
GO  
RECONFIGURE;  
GO  

ALTER DATABASE  [QueryStoreTest] SET QUERY_STORE CLEAR;  
ALTER DATABASE  [QueryStoreTest] SET QUERY_STORE = ON   
    (OPERATION_MODE = READ_WRITE, QUERY_CAPTURE_MODE = AUTO);  

참고 항목See Also

쿼리 저장소를 사용하여 성능 모니터링 Monitoring Performance By Using the Query Store
쿼리 저장소에 대한 모범 사례Best Practice with the Query Store