デタッチ/アタッチまたはオフライン/オンラインは、特定のデータベースのバッファキャッシュをクリアしますか？

私の友人は今日、SQL Serverをバウンスする代わりに、データベースをデタッチしてから再アタッチするだけで、このアクションにより、指定されたデータベースのページとプランをキャッシュからクリアできると私に言った。私は同意せず、以下の証拠を提供します。あなたが私に同意しない場合、またはより良い反論がある場合は、必ずそれを提供してください。

このバージョンのSQL ServerでAdventureWorks2012を使用しています。

SELECT @@ VERSION;
Microsoft SQL Server 2012-11.0.2100.60（X64）
Windows NT 6.1（Build 7601：Service Pack 1）上のDeveloper Edition（64ビット）

データベースをロードしたら、次のクエリを実行します。

まず、ここにあるJonathan KのAW肥大化スクリプトを実行します。

AW Get Fat

---------------------------
-ステップ1：Bpool Stuff？
---------------------------
USE [AdventureWorks2012];
行く

選択する
     OBJECT_NAME（p.object_id）AS [ObjectName]
   、p.object_id
   、p.index_id
   、COUNT（*）/ 128 AS [バッファサイズ（MB）]
   、COUNT（*）AS [buffer_count]
から
     sys.allocation_units AS a
     INNER JOIN sys.dm_os_buffer_descriptors AS b
           ON a.allocation_unit_id = b.allocation_unit_id
     INNER JOIN sys.partitions AS p
           ON a.container_id = p.hobt_id
どこ
     b.database_id = DB_ID（）
     AND p.object_id> 100
GROUP BY
     p.object_id
   、p.index_id
注文する
     buffer_count DESC;

結果は次のとおりです。

データベースを切断して再接続し、クエリを再実行します。

---------------------------
-ステップ2：デタッチ/アタッチ
---------------------------
-切り離す
USE [マスター]
行く
EXEC master.dbo.sp_detach_db @dbname = N'AdventureWorks2012 '
行く

-添付
USE [マスター];
行く

CREATE DATABASE [AdventureWorks2012]オン 
（ 
    FILENAME = N'C：\ sql server \ files \ AdventureWorks2012_Data.mdf ' 
）
    、
（ 
    FILENAME = N'C：\ sql server \ files \ AdventureWorks2012_Log.ldf ' 
）
 アタッチ用;
行く

現在、プールには何がありますか？

---------------------------
-ステップ3：Bpool Stuff？
---------------------------
USE [AdventureWorks2012];
行く

選択する
     OBJECT_NAME（p.object_id）AS [ObjectName]
   、p.object_id
   、p.index_id
   、COUNT（*）/ 128 AS [バッファサイズ（MB）]
   、COUNT（*）AS [buffer_count]
から
     sys.allocation_units AS a
     INNER JOIN sys.dm_os_buffer_descriptors AS b
           ON a.allocation_unit_id = b.allocation_unit_id
     INNER JOIN sys.partitions AS p
           ON a.container_id = p.hobt_id
どこ
     b.database_id = DB_ID（）
     AND p.object_id> 100
GROUP BY
     p.object_id
   、p.index_id
注文する
     buffer_count DESC;

そしてその結果：

この時点ですべての読み取りは論理的ですか？

--------------------------------
-ステップ4：論理読み取りのみ？
--------------------------------
USE [AdventureWorks2012];
行く

統計IOをオンに設定します。   
    SELECT * FROM DatabaseLog;
    行く
SET STATISTICS IO OFF;  

/ *
（1597行が影響を受けました）
テーブル 'DatabaseLog'。スキャンカウント1、論理読み取り782、物理読み取り0、先読み読み取り768、LOB論理読み取り94、LOB物理読み取り4、LOB先読み読み取り24。
* /  

そして、バッファープールがデタッチ/アタッチによって完全に吹き飛ばされていないことがわかります。私の相棒は間違っていたようです。誰かが同意しないか、より良い議論がありますか？

別のオプションは、データベースをオフラインにしてからオンラインにすることです。それを試してみましょう。

--------------------------------
-ステップ5：オフライン/オンライン？
--------------------------------
ALTER DATABASE [AdventureWorks2012] SET OFFLINE;
行く
ALTER DATABASE [AdventureWorks2012] SET ONLINE;
行く

---------------------------
-ステップ6：Bpool Stuff？
---------------------------
USE [AdventureWorks2012];
行く

選択する
     OBJECT_NAME（p.object_id）AS [ObjectName]
   、p.object_id
   、p.index_id
   、COUNT（*）/ 128 AS [バッファサイズ（MB）]
   、COUNT（*）AS [buffer_count]
から
     sys.allocation_units AS a
     INNER JOIN sys.dm_os_buffer_descriptors AS b
           ON a.allocation_unit_id = b.allocation_unit_id
     INNER JOIN sys.partitions AS p
           ON a.container_id = p.hobt_id
どこ
     b.database_id = DB_ID（）
     AND p.object_id> 100
GROUP BY
     p.object_id
   、p.index_id
注文する
     buffer_count DESC;

オフライン/オンライン操作の方がはるかにうまく機能しているようです。

最初はあなたがここで何かをしていると思っていました。作業の前提は、おそらくバッファプールがすぐにフラッシュされなかったということでした。そのためには、「いくらかの作業」が必要であり、メモリが必要になるまで煩わしいのです。だが...

テストに欠陥があります。

バッファープールに表示されるのは、データベースの再接続の結果として読み取られたページであり、データベースの以前のインスタンスの残りではありません。

そして、バッファープールがデタッチ/アタッチによって完全に吹き飛ばされていないことがわかります。私の相棒は間違っていたようです。誰かが同意しないか、より良い議論がありますか？

はい。physical reads 0物理的な読み取りがなかったという意味だと解釈している

テーブル 'DatabaseLog'。スキャンカウント1、論理読み取り782、物理読み取り0、先読み読み取り768、LOB論理読み取り94、LOB物理読み取り4、LOB先読み読み取り24。

Craig Freedmanのブログで説明されているように、シーケンシャルリードアヘッドメカニズムは、ページがクエリプロセッサによって要求される前にメモリ内にあることを確認しようとします。

SQL Serverが大きなテーブルの順次スキャンを実行すると、ストレージエンジンは先読みメカニズムを開始して、ページがメモリ内にあり、クエリプロセッサで必要になる前にスキャンの準備ができていることを確認します。先読みメカニズムは、500ページ前のスキャンを維持しようとします。

先読みでそこに配置されるまで、クエリを満たすために必要なページはメモリにありませんでした。

オンライン/オフラインで異なるバッファープールプロファイルが作成される理由については、アイドル調査がもう少し必要になります。@MarkSRasmussenは、彼が次に訪れるときに、私たちを助けることができるかもしれません。