SQL Serverは計画キャッシュと実行統計を定期的にクリアします

SQL Server 2014を2016にアップグレードした後、サーバーはキャッシュされた実行計画やdm*ビュー（などdm_exec_query_stats）を数時間ごとにリセットし続けます

誰かが手動で実行するかのように（誰も実行DBCC FREEPROCCACHEしない場合DBCC DROPCLEANBUFFERSを除き、自動的に実行されます）。

同じまさにデータベースがSQL Server 2014とWindows Server 2012で正常に機能し、SQL Server 2016（およびWindows server 2016）に移行した後、事態は南に進みました

私がチェックしたこと：データベースには「自動クローズ」フラグがありません。SQLサーバーはにad hoc optimized設定されていますtrue（私はそれが役立つと思ったが、そうではなかった）。「クエリストア」は「オフ」です。サーバーには16 GBのメモリがあります。

「SQL Serverログ」でも役に立たないものはありません。毎週のバックアップメッセージ...

また、この記事をチェックしましたhttps://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-set-options（下の「例」セクションまでスクロールします。それ）計画が自動的にクリアされる状況のリストがあります。それらのどれも当てはまりません。

更新：

残念ながら、どの提案も役に立たなかった。LPIM権限の付与、同じクエリに対して大量のプランを生成したパラメータ化されていないクエリの検出と修正、「最大サーバーメモリ」の削減...プランは数時間から5〜10分ごとにランダムにリセットされ続けます。サーバーが「メモリ不足」の場合、どうして同じバージョンのマシンでも2014バージョンは正常に機能していました。

要求されたsp_Blitzの出力は次のとおりです。

**Priority 10: Performance**:

- Query Store Disabled - The new SQL Server 2016 Query Store feature has not been enabled on this database.

    * xxx


**Priority 50: Server Info**:

- Instant File Initialization Not Enabled  - Consider enabling IFI for faster restores and data file growths.


**Priority 100: Performance**:

- Resource Governor Enabled  - Resource Governor is enabled.  Queries may be throttled.  Make sure you understand how the Classifier Function is configured.


**Priority 120: Query Plans**:

- Implicit Conversion Affecting Cardinality - One of the top resource-intensive queries has an implicit conversion that is affecting cardinality estimation.

    * 

- Missing Index - One of the top resource-intensive queries may be dramatically improved by adding an index.

    * 

- RID or Key Lookups - One of the top resource-intensive queries contains RID or Key Lookups. Try to avoid them by creating covering indexes.

    * 

**Priority 170: File Configuration**:

- System Database on C Drive
    * master - The master database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * model - The model database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * msdb - The msdb database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.


**Priority 200: Backup**:

- MSDB Backup History Not Purged msdb - Database backup history retained back to Jun 10 2017  9:47PM


**Priority 200: Informational**:

- Backup Compression Default Off  - Uncompressed full backups have happened recently, and backup compression is not turned on at the server level. Backup compression is included with SQL Server 2008R2 & newer, even in Standard Edition. We recommend turning backup compression on by default so that ad-hoc backups will get compressed.


**Priority 200: Non-Default Server Config**:

- Agent XPs  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- max server memory (MB)  - This sp_configure option has been changed.  Its default value is 2147483647 and it has been set to 15000.

- optimize for ad hoc workloads  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- show advanced options  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- xp_cmdshell  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.


**Priority 200: Performance**:

- Buffer Pool Extensions Enabled  - You have Buffer Pool Extensions enabled, and one lives here: Z:\sql_buffer_pool.BPE. It's currently 60.00000000000 GB. Did you know that BPEs only provide single threaded access 8KB (one page) at a time?

- cost threshold for parallelism  - Set to 5, its default value. Changing this sp_configure setting may reduce CXPACKET waits.

**Priority 240: Wait Stats**:

- No Significant Waits Detected  - This server might be just sitting around idle, or someone may have cleared wait stats recently.

**Priority 250: Informational**:

- SQL Server Agent is running under an NT Service account  - I'm running as NT Service\SQLSERVERAGENT. I wish I had an Active Directory service account instead.

- SQL Server is running under an NT Service account  - I'm running as NT Service\MSSQLSERVER. I wish I had an Active Directory service account instead.

**Priority 250: Server Info**:

- Default Trace Contents  - The default trace holds 125 hours of data between Aug 19 2017 11:55AM and Aug 24 2017  4:59PM. The default trace files are located in: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log

- Hardware  - Logical processors: 2. Physical memory: 15GB.

- Hardware - NUMA Config  - Node: 0 State: ONLINE Online schedulers: 2 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 29

- Locked Pages In Memory Enabled  - You currently have 12.02534484863 GB of pages locked in memory.

- Memory Model Unconventional  - Memory Model: LOCK_PAGES

- Server Last Restart  - Aug 20 2017 12:32PM

- Server Name  - xx

- Services
 - Service: SQL Full-text Filter Daemon Launcher (MSSQLSERVER) runs under service account NT Service\MSSQLFDLauncher. Last startup time: not shown.. Startup type: Manual, currently Running.

 - Service: SQL Server (MSSQLSERVER) runs under service account NT Service\MSSQLSERVER. Last startup time: Aug 20 2017 12:32PM. Startup type: Automatic, currently Running.

 - Service: SQL Server Agent (MSSQLSERVER) runs under service account NT Service\SQLSERVERAGENT. Last startup time: not shown.. Startup type: Automatic, currently Running.

- SQL Server Last Restart  - Aug 20 2017 12:33PM

- SQL Server Service  - Version: 13.0.4446.0. Patch Level: SP1. Edition: Enterprise Edition (64-bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

- Virtual Server  - Type: (HYPERVISOR)

- Windows Version  - You're running a pretty modern version of Windows: Server 2012R2 era, version 6.3


**Priority 254: Rundate**:

 - Captain's log: stardate something and something...

まず、プランキャッシュがクリアされている正確な時間を取得します。最も簡単な方法は次のとおりです。ほとんどすぐに実行され、誰もブロックしません。

SELECT TOP 1 creation_time
FROM sys.dm_exec_query_stats WITH (NOLOCK)
ORDER BY creation_time;

その日付/時刻が予想よりも古いと思われる場合は、プランキャッシュの一部のみがクリアされています。たとえば、影響を受ける特定のオブジェクトのプランキャッシュをフラッシュしますが、他のオブジェクトはそのまま残ります。これは、システムクエリ（DMVクエリなど）が続く場合によく見られますが、ユーザーデータベースの計画は明確です。

その日付/時刻が特定の間隔で更新される場合、たとえば2時間ごとに6：00、8：00、10：00などと更新されるように見える場合、おそらく誰かがプランキャッシュを引き起こすジョブまたはクエリを実行しています空にする。正確な頻度がわかったら、次のことができます。

• ジョブスケジュールを見て、その間隔で実行される内容を確認します
• その期間中にプロファイラートレースまたは拡張イベントトレースを実行して謎を解明します（私は通常、実稼働環境でトレースするのが好きではありませんが、キラーが攻撃を開始するタイミングを正確に把握していれば、安易に攻撃を開始できます-実行中のオーバーヘッドサンプル）
• sp_WhoIsActiveその時間中にテーブルにログを記録します（最も簡単な方法ですが、それを引き起こす正確なクエリに絞り込む可能性は最も低いです）

クエリを実行するたびにその日付/時刻が変化し続ける場合、サーバーはおそらくメモリ不足に陥っています。これを実行して基本的なヘルスチェック情報を生成し、それをStack質問にコピーして貼り付けて診断できるようにします。

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1, @CheckUserDatabaseObjects = 1

（開示：私はの著者の一人ですsp_Blitz。）

sp_Blitzデータで2017/08/25を更新しました-sp_Blitzを実行して質問に追加していただき、ありがとうございます。これはいくつかのことを示すのに役立ちます。2つのコアと16GBのRAMを搭載したVM上でSQL Server 2016 Enterprise Editionを実行しています。まず、ライセンスに関する簡単なメモ：ゲストによるライセンスを取得している場合、最小購入要件は2ではなく4コアです（SQL Serverライセンスガイドを参照してください）を参照してください）。EnterpriseEditionの4コアは約28,000米ドルです、そしてわずか16GBのRAMに多くのライセンス費用が費やされているのを見るのはかなり珍しいことです。ただし、ホストレベルでSQL Server Enterprise Editionのライセンスを取得している場合は、それを無視して小さなVMを実行できます。

SQL Serverが外部メモリのプレッシャーにさらされているようです。16GBのRAMがあり、最大サーバーメモリを15GBに設定しました。残念ながら、オペレーティングシステム用に1GBだけでは十分ではありません（さらに、バックアップソフトウェアやSSMSなど、そこで実行するものは何でも）。より大きい-あなたの場合、それは4GBになるので、最大サーバーメモリ設定は15GBではなく12GBにする必要があります。

現在のメモリ割り当てには、より多くの証拠が現れます。メモリ内のロックされたページ（LPIM）はオンになっていますが、メモリ内にロックされているページは12.02GBのみです。その可能性が高い（ただし保証されていない）ことは、他のアプリケーションがメモリを必要としているため、Windowsがメモリプレッシャー通知を送信し、SQL Serverが他の3GBのメモリを放棄して他のアプリに処理を行わせることを意味します。これは、15GBの最大メモリを実際に使用できないことを証明しています。他のものにはメモリが必要です。

SQL Serverが外部メモリのプレッシャーにさらされ、他のアプリ用にメモリを解放する必要がある場合、プランキャッシュが低下します。

そのため、いくつかのオプションがあります。

• 最大メモリを適切に設定します -たとえば、12GB（またはサーバーで他のアプリを実行する場合はさらに低くします）アプリには2〜3 GBのRAMが必要です-既に利用可能です
• サーバー上で他のアプリの実行を停止します -ただし、他のシステム管理者がリモートデスクトップを実行し、SSMSのようなものを実行している場合、これは難しい場合があります。開いているRDPセッションの数に対してPerfmonカウンターアラームを設定し、0以外の場合にアラートを出しました。これにより、犯人を実際に捕らえることができます。
• VMにメモリを追加します -しかし、実際には必要ないと思います。「重大な待機は検出されなかった」というsp_Blitzレポートによって、いくつかの証拠が示されています。頻繁にメモリが圧迫されているとは思わない。特にそれはたまにしか起きないと報告しているからだ。これは最も費用対効果の低いオプションです。

わかりました、ここで、SQL Server 2016を最新バージョンに更新することで、この問題をようやく修正しました。私が持っていたSP1し、昨日私がインストールさCumulative Update 6。

ブレントの答えが示唆するように、「最大メモリ」も適切に設定します。ところで、素晴らしい答えです。私は皆にそれを支持することを勧めます。

36時間経過しており、計画はリセットされていません。

Brent Ozarには、https：//sqlserverupdates.com/という非常に優れたWebサイトもあり、必要な更新を判断するのに役立ちます。

助けとなったもう1つのことは、「信頼できない外部キー」の問題を検出して解決することでした。ブレントには、それを解決する方法についての非常に素晴らしい記事があります（ハハ、ええ、ブレント、私は正しいことを知っています）、ただグーグル、彼は＃1の結果です

ホームテストボックスでこの問題が発生し、「メモリ内のページのロック」権限をSQL Serverサービスアカウントに追加することで問題が解決することがわかりましたが、これが最善のアドバイスであるかどうかはわかりません。

「メモリ内のページのロックオプションを有効にする（Windows）」を参照してください。