タグ付けされた質問 「columnstore」

1
クラスター化された列ストアからのこの削除には、熱心なスプール演算子が役立ちますか？
クラスター化された列ストアインデックスからのデータの削除をテストしています。 実行計画に大きな熱心なスプールオペレーターがいることに気付きました。 これは、次の特性で完了します。 6,000万行が削除されました 1.9 GiB TempDBを使用 実行時間14分 シリアルプラン 1スプールで再バインド スキャンの推定コスト：364.821 見積もりツールをだまして過小評価するようにすると、TempDBの使用を回避するより高速なプランが得られます。 推定スキャンコスト：56.901 （これは推定プランですが、コメントの数値は正しいものです。） 興味深いことに、次を実行してデルタストアをフラッシュすると、スプールは再び消えます。 ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON); スプールは、デルタストアにページのしきい値を超えるしきい値がある場合にのみ導入されるようです。 デルタストアのサイズを確認するには、次のクエリを実行して、テーブルの行内ページを確認します。 SELECT SUM([in_row_used_page_count]) AS in_row_used_pages, SUM(in_row_data_page_count) AS in_row_data_pages FROM sys.[dm_db_partition_stats] as pstats JOIN sys.partitions AS p ON pstats.partition_id = p.partition_id WHERE p.[object_id] = OBJECT_ID('Fact.RecordedMetricsDetail'); …
1
SQL Server 2014はバッチモードで正確に何を実行できますか？
クエリで列ストアインデックスが使用されている場合、SQL Serverはバッチモードを使用できます。ドキュメントは、バッチモードで実行できるものとできないものについては薄い。バッチモード（緑色）で驚くほど多くのことが実行される、次の（動機付けの）クエリプランをご覧ください。 （これは推定プランです。実際のプランを使用して、実際の実行モードが実際にバッチであることを確認しました。） T1のビルド側のみが列ストアインデックスを使用することに注意してください。すべてのプローブ入力（T2およびT3）は行ストアです。彼らのデータはバッチモードに移行しているようです。プローブ側のみで実行されるデータストリームにはバッチモードが使用されていると常に考えていました。 列ストアインデックスに由来しない場合でも、データはバッチモードに移行できるようです。それは疑問を提起します：なぜSQL Serverは行ストアのみのクエリにもバッチモードを使用しないのですか？それらのいくつかのために有益である可能性があります。列ストアインデックスの使用は、SQL Serverでバッチモードを考慮するために必要な正式な要件ですか？列ストアインデックスを持つゼロ行のダミーテーブルを追加して、バッチモードを導入し、パフォーマンスの向上を実現できますか？ SQL Server 2014の時点でバッチモードで正確に実行できるものは何ですか？
3
単純なCCI行グループを作成するのに最大30秒かかるのはなぜですか？
挿入物の一部が予想よりも長くかかっていることに気付いたとき、CCIを含むデモに取り組んでいました。再現するテーブル定義： DROP TABLE IF EXISTS dbo.STG_1048576; CREATE TABLE dbo.STG_1048576 (ID BIGINT NOT NULL); INSERT INTO dbo.STG_1048576 SELECT TOP (1048576) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN FROM master..spt_values t1 CROSS JOIN master..spt_values t2; DROP TABLE IF EXISTS dbo.CCI_BIGINT; CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE); テストでは、ステージングテーブルから1048576行すべてを挿入しています。何らかの理由でトリミングされない限り、圧縮された行グループを1つだけ埋めるのに十分です。 …
1
列ストアインデックスの構造は何ですか？
コードネームDenaliが付けられたSQL Server 2012の新機能の1つに、Columnstoreインデックスがあります。 Bツリー構造、リーフレベルとBツリーページのストレージの違い、含まれているフィールドの影響、それらを使用するための最適化、キーの順序など、通常の古い行ストアインデックスについてかなり知っています。 列ストアインデックスの内部情報を得るのに苦労しています。 どのように構成されていますか？ Bツリーはありますか？その他の構造はありますか？ データはどのように編成されていますか？ どの種類の特定の演算子を使用するのが最適ですか？ 他のアンチパターンを使用する際に避けるべきものはありますか？ それらについて私が知ることができるものの多くは、基本的に「通常の」インデックスの正反対です。つまり、キーの順序付け、含まれるフィールド、非クラスタ化のみです。 どんな洞察も大歓迎です。
3
クラスター化された列ストアインデックスと外部キー
インデックスを使用してデータウェアハウスのパフォーマンスをチューニングしています。私はSQL Server 2014を初めて使用します。Microsoftは次のように説明しています。 「クラスター化された列ストアインデックスは、大規模なデータウェアハウジングファクトテーブルを格納するための標準であり、ほとんどのデータウェアハウジングシナリオで使用されることを期待しています。操作を削除します。」 http://msdn.microsoft.com/en-us/library/gg492088.aspx ただし、ドキュメントをさらに読むと、制限と制限があります。 「一意の制約、主キーの制約、または外部キーの制約を持つことはできません。」 これは私をとても混乱させます！さまざまな理由（データの整合性、セマンティックレイヤーに表示される関係など）のために、データウェアハウスに外部キーを配置することをお勧めします（必須ではありません）。 そのため、Microsoftはデータウェアハウスシナリオのクラスター化列ストアインデックスを推奨しています。ただし、外部キー関係を処理できませんか？！ これは正しいですか？他にどのアプローチをお勧めしますか？過去には、データウェアハウスのシナリオで、クラスター化されていない列ストアインデックスを使用して、データロードのドロップと再構築を行いました。しかし、SQL Server 2014はデータウェアハウスに新しい価値を追加しませんか？
1
クラスター化列ストアの非クラスター化インデックスストレージ
SQL Serverでは、行ストアテーブルの一意でない非クラスター化インデックスに、非クラスター化インデックス構造のすべてのレベルでベースオブジェクトのブックマーク（RIDまたはクラスター化キー）が組み込まれます。ブックマークは、すべてのインデックスレベルで非クラスター化インデックスキーの一部として保存されます。 一方、非クラスター化インデックスが一意である場合、ブックマークはキーの一部としてではなく、インデックスのリーフレベルにのみ存在します（実際には、ブックマークは1つ以上の含まれる列として存在します）。 SQL Server 2016では、列指向のテーブル（クラスター化された列ストアインデックスを持つテーブル）に非クラスター化Bツリーインデックスを構築できます。 クラスター化された列ストアテーブルの非クラスター化Bツリーインデックスに使用される「ブックマーク」とは何ですか？ 上記の一意および非一意の非クラスタ化インデックスの違いは引き続き適用されますか？
2
read_onlyファイルグループの列ストアインデックスによりCheckDBが妨げられる
ファイルグループに列ストアインデックスが含まれている場合、データベース全体をread_only防止するようdbcc checkdbにファイルグループを設定しているようです。実行しようとするcheckdbかcheckfilegroup（のための任意の読み書きセカンダリとを含め、データベース内のファイルグループ[PRIMARY]）、以下のエラーが返されます... Msg 8921, Level 16, State 1, Line 24 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. 読み取り専用のファイルグループに列ストアデータを保持するためのサポートされている方法はありますか？または、このシナリオの整合性チェックから除外されますか？ 再現 create database check_fg_ro go use check_fg_ro go exec sp_changedbowner 'sa'; go alter database check_fg_ro add …
1
UNPIVOT（ループ結合）でバッチモードを使用する方法は？
次の形式のクエリがあります。 SELECT ... FROM ColumnstoreTable cs CROSS APPLY ( SELECT * FROM (VALUES ('A', cs.DataA) , ('B', cs.DataB) , ('C', cs.DataC) ) x(Col0, Col1) ) someValues これは、Columnstore-backedサブクエリ（ColumnstoreTable）からすべての行を取得し、それらの行を乗算します。これは本質的にUNPIVOTです。実際のクエリはこれよりも大きくなります。クエリのこの部分は、他の処理に送られます。 ここでの問題は、これCROSS APPLYが合理的な選択であるループ結合として実装されていることです。残念ながら、ループ結合はバッチモードをサポートしていません。 クエリのこの部分はパフォーマンスが非常に重要であり、バッチモードで実行するとパフォーマンスに非常に有益であると思われます。 バッチモードから移行しないように、このクエリを書き換えるにはどうすればよいですか？ の代わりに一時テーブルを使用してみましたVALUESが、ハッシュ結合に等価結合条件がないという事実は変わりませんでした。
1
バッチモードのウィンドウ集計で算術オーバーフローが発生するのはなぜですか？
次のクエリは、SUM列ストアテーブルに対してウィンドウ処理を実行します1500 total rows。それぞれの値は0または1であり、INTデータ型をオーバーフローします。なんでこんなことが起こっているの？ SELECT a, p, s, v, m, n, SUM(CASE WHEN n IS NULL THEN 0 ELSE 1 END) OVER (PARTITION BY s, v, a ORDER BY p) AS lastNonNullPartition FROM ( SELECT a, p, s, v, m, n, RANK() OVER (PARTITION BY v, s, a, p ORDER BY …
3
フィルター条件がクラスター化列ストアインデックスに正しく適用されない
以下の例を使用すると、述語は同じですが、上のステートメントは（正しく）0行を返し、下のステートメントは1を返します-述語が一致しない場合でも： declare @barcode nchar(22)=N'RECB012ZUKI449M1VBJZ' declare @tableId int = null declare @total decimal(10, 2) = 5.17 SELECT 1 FROM [dbo].[transaction] WITH (INDEX([IX_Transaction_TransactionID_PaymentStatus_DeviceID_DateTime_All])) WHERE Barcode = @barcode AND StatusID = 1 AND TableID = @tableID AND @total <= Total SELECT 1 FROM [dbo].[transaction] WHERE Barcode = @barcode AND StatusID = 1 AND …
2
SELECTでパーティション化された列ストアのデッドロックを防ぐ方法
SQL Server 2016に3つのクラスター化列ストアインデックス（CCI）テーブルがあります。これらのCCIはすべて、テナントIDに基づいて同じパーティションスキームにあります。最近、一貫性のない方法で、結合からこれらのテーブルへの単純な選択ステートメントでデッドロックが発生しています。デッドロックするクエリの例： SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 エラーメッセージ： トランザクション（プロセスID 56）は、別のプロセスで汎用の待機可能なオブジェクトリソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。 手がかり： クエリがCCI以外の別のインデックスを使用する場合、デッドロックは発生しません。 3つのテナントフィルターのうち2つを削除しても、デッドロックしません。 トップ32以下を選択しても、デッドロックは発生しません。 OPTION（MAXDOP 1）を追加しても、デッドロックは発生しません。 スクランブルされたPRODレプリカ、PROD読み取り専用セカンダリ、およびPROD自体でこれを再現できます。 この動作をDEVまたはINTで再現できません。 3つのテーブル結合すべてにWITH（NOLOCK）を追加すると、依然としてデッドロックが発生します クエリ自体がデッドロックします。他にアクティブなプロセスがない場合はデッドロックします。 並列処理のないクエリプランはデッドロックしない デッドロックxmlはこちら PRODバージョン： …
2
列ストアインデックスのID列
非常に大きなテーブルIMO（約1億3700万行）があり、繰り返しデータやNULL列がたくさんあります。 を含むテーブルを使用してこれを検討することを検討しCOLUMNSTORE INDEXていIDENTITYます。元のテーブルに列があります。これは、すべての行が一意である唯一の列です。 この列を省略するか、含める必要がありますか？テーブルのすべての行をに含めたいとCOLUMNSTORE INDEX読んだことがありますが、最適な候補は、一意でない行がたくさんある列であることも読みました。 これは単に悪い候補COLUMNSTORE INDEXですか？ SQL Server 2012を使用しているため、非クラスター化列ストアです。私はこのデータを格納するための可能なより良い方法を探っているところです。更新は存在しませんが、ELTプロセスによって新しい行が定期的に追加されるため、そこで作業が行われると想定しています。一部の人々はこのデータをマイニングして膨大なレポートを生成し、多くの行をスキャンして、サーバーをクロールさせて、コピーを毎日セカンダリサーバーにオフロードすることを余儀なくさせています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.