web-dev-qa-db-ja.com

NCCIでのLob論理読み取りおよびLOB先読み読み取り

次の構造のテストテーブルがあります。

CREATE TABLE [dbo].[DW_test](
[ID] [bigint] IDENTITY(1,1) NOT NULL,
[CourtCaseID] [int] NOT NULL,
[ActionID] [int] NOT NULL,
PRIMARY KEY CLUSTERED([ID] ASC)

次に、次のスクリプトを使用して、約4億7千万のレコードをテーブルに入力しました。

insert into DW_test
--select count(*)
--from (
select top 1000000 abs(checksum(newid())) % 100000 + 1 a, abs(checksum(newid())) % 10 + 1 b
from sys.all_objects
cross join sys.all_objects a
cross join sys.all_objects b
cross join sys.all_objects c
cross join sys.all_objects d
cross join sys.all_objects e
cross join sys.all_objects f
cross join sys.all_objects g
--) t
GO

スクリプトは約470回実行され、テーブルに4億7千万のレコードが生成され、そのテーブルにNCCIが作成されました。

CREATE NONCLUSTERED COLUMNSTORE INDEX [IX_test1] ON [dbo].[DW_test]
(
    [CourtCaseID],
    [ActionID]
)

次に、単純なクエリをテストして、テーブル内のレコードをカウントします。

DBCC DROPCLEANBUFFERS
GO
select COUNT_BIG(*)
from DW_test

SET STATISTICS IO ON次の結果が得られます

コールドキャッシュあり

テーブル「DW_test」。スキャンカウント25、論理読み取り3、物理読み取り0、先読み読み取り0、LOB論理読み取り469697、LOB物理読み取り1、LOB先読み読み取り1877324

テーブル「DW_test」。セグメントは453を読み取り、セグメントは0をスキップしました。

テーブル「ワークテーブル」。スキャンカウント0、論理読み取り0、物理読み取り0、先読み読み取り0、LOB論理読み取り0、LOB物理読み取り0、LOB先読み読み取り0。

ウォームキャッシュ

テーブル「DW_test」。スキャンカウント25、論理読み取り3、物理読み取り0、先読み読み取り0、lob論理読み取り229248、lob物理読み取り0、lob先読み読み取り0

テーブル「DW_test」。セグメントは453を読み取り、セグメントは0をスキップしました。

テーブル「ワークテーブル」。スキャンカウント0、論理読み取り0、物理読み取り0、先読み読み取り0、LOB論理読み取り0、LOB物理読み取り0、LOB先読み読み取り0。

1つの論理読み取りはクエリ実行中にバッファプールから読み取られる単一のデータページであり、1つの物理読み取りはディスクから読み取られる単一のデータページであることを知っています。 RedGateが教えてくれます 先読みは次のとおりです：

この数は、SQL Serverの「先読み」メカニズムによって満たされた物理読み取りの数を示します。これは物理的な読み取りに直接関連しているため、物理的な読み取りがない場合、先読み読み取りは0になります。

私の場合、私はlobの論理的、物理的、および先読み読み取りを扱っています。この数字が私の特定のケースで何を意味するのかを理解したいと思います。

テーブルに約4億7000万のレコードがある場合、コールドキャッシュを使用して1 LOBの物理読み取りを1つだけにすることはどのように可能ですか？

LOBページの総数がコールドキャッシュの約230万からウォームキャッシュの約220kに減少したのはなぜですか？

sql-serversql-server-2017columnstore
8
Artashes Khachatryan

テーブルに約4億7000万のレコードがある場合、コールドキャッシュを使用して1 LOBの物理読み取りを1つだけにすることはどのように可能ですか？

LOB物理読み取りが1回、先読みが1,877,324回あります。先読みはまだ物理的な読み取りであり、事前に実行されるだけです（プリフェッチ）。 Redgateからの引用は正しくありません。

LOBページの総数がコールドキャッシュの約230万からウォームキャッシュの約220kに減少したのはなぜですか？

論理読み取りは、メモリ内のページがタッチされた回数をカウントします。 469,697（コールドキャッシュ）から229,248（ウォーム）に削減されます。これについての完全な説明はありませんが、列ストアデータが一般的なページサイズのバッファープールではなく、別の列ストアオブジェクトプールに連続してキャッシュされるため、それは一部かもしれません。

先読みは、Bツリーの上位レベルからページを読み取って、スキャンの前に読み取るページを識別します。これにより、タイミングとストレージシステムの特性に応じて、「余分な」論理読み取りの数が変化する可能性もあります。 。列ストアインデックスは、永続ストレージにBツリー構造を持っています。

別の要因は並列処理です（テストはDOP 24で実行されたようです）。異なるスレッドからの要求が重複すると、追加の論理読み取りが発生する可能性があるためです。 OPTION (MAXDOP 1)を使用して実行すると、過剰な論理読み取りが多少減少する場合があります。

Columnstoreの内部ストレージの詳細は十分に文書化されておらず、通常のDMVで完全にサポートされていません。この段階で、コールドキャッシュケースとウォームキャッシュケースの間の読み取りの削減についての最良の説明は、ディスク上のストレージとメモリ内の（キャッシュされた）ストレージの違いです。

列ストアデータ（ディクショナリとセグメント）はディスク上のLOBに格納されますが、パフォーマンス上の理由から、同じ形式でメモリに保持されません。これらは異なるものであるため、物理的な読み取りに論理的な読み取りを追加するだけでは、意味のある結果を得ることができません。

13
Paul White 9

「テーブルに約4億7千万のレコードがある場合、コールドキャッシュを使用して物理的に1 LOBのみを読み取ることができるのはなぜですか？」

他の物理的な読み取りは先読み（LOBタイプ）によって提供されていたためです。おそらくRedGateの記事で混乱したかもしれませんが、エクステント（たとえば）を先読み（RA）として提供している場合、物理的な読み取りは行われません。物理読み取りの統計を収集するスレッドは、キャッシュ内でそれらのページを見つけたため、物理読み取りカウンターに蓄積されませんでした。

これが発生する別の状況は、古典的なバッファキャッシュヒット率のperfmonカウンタです。 RA読み取りはこの値に影響しますnotこのため、負荷と物理I/Oの負荷が発生する可能性がありますが、それでもBCHRで100に近くなります。

「ロブページの総数がコールドキャッシュの約230万からウォームキャッシュの約220kに減少したのはなぜですか？」

私の推測では、最初のものは自動作成統計を開始しました。

2
Tibor Karaszi