タグ付けされた質問 「execution-plan」

クエリを処理するためにクエリオプティマイザーによって選択された戦略。

1
SQL Serverのすべての接続でARITHABORTをONに設定すると、どのような影響がありますか？
そのため、SQL Serverの不安定な動作は.Net SqlClientデータプロバイダーのデフォルト設定が原因であると判断しましたSET ARITHABORT OFF。そうは言っても、これを実装する最良の方法を議論するさまざまな記事を読んだことがあります。私にとっては、SQL Serverに問題があり、クエリのチューニングがアプリ全体で完全に超えていない（そして明らかにSETsp に追加しても機能しない）ため、簡単な方法が欲しいだけです。 Erland Sommarskogのこのトピックに関する素晴らしい記事では、基本的にアプリを変更SET ARITHABORT ONして接続用に発行することで安全なアプローチを取ることを提案しています。ただし、dba.stackexchange 質問からのこの回答では、Solomon Rutzkyがインスタンス全体とデータベース全体の両方のアプローチを提供しています。 これをインスタンス全体に設定すると、どのような影響がありますか？私が見ているように... SSMSにはONデフォルトでこれが設定されているONため、すべての接続に対してサーバー全体に設定しても問題はありません。結局のところ、何よりもこのSQL Serverを実行する必要があるだけです。
1
結合消去がsys.query_store_planで機能しないのはなぜですか？
以下は、クエリストアで発生するパフォーマンスの問題の簡略化です。 CREATE TABLE #tears ( plan_id bigint NOT NULL ); INSERT #tears (plan_id) VALUES (1); SELECT T.plan_id FROM #tears AS T LEFT JOIN sys.query_store_plan AS QSP ON QSP.plan_id = T.plan_id; plan_id列は、主キーとして文書化されているsys.query_store_planが、実行計画は使用されません撤廃への参加が期待されるように： DMVから投影される属性はありません。 DMV主キーplan_idは一時テーブルの行を複製できません A LEFT JOINが使用されているため、から行をT削除できません。 実行計画 これはなぜですか、ここで参加の削除を取得するにはどうすればよいですか？
1
報告されたインデックスサイズと実行プランのバッファ数の大きな不一致
問題 次のようなクエリがあります SELECT COUNT(1) FROM article JOIN reservation ON a_id = r_article_id WHERE r_last_modified < now() - '8 weeks'::interval AND r_group_id = 1 AND r_status = 'OPEN'; （10分後に）タイムアウトになることが多いため、この問題を調査することにしました。 EXPLAIN (ANALYZE, BUFFERS)出力は次のようになります。 Aggregate (cost=264775.48..264775.49 rows=1 width=0) (actual time=238960.290..238960.291 rows=1 loops=1) Buffers: shared hit=200483 read=64361 dirtied=666 written=8, temp read=3631 written=3617 I/O Timings: …
1
このクエリで主（クラスター）キーが使用されないのはなぜですか？
スキーマ構造が次のようなSQL Server 2008 R2テーブルがあります。 CREATE TABLE [dbo].[CDSIM_BE] ( [ID] [bigint] NOT NULL, [EquipmentID] [varchar](50) NOT NULL, [SerialNumber] [varchar](50) NULL, [PyrID] [varchar](50) NULL, [MeasMode] [varchar](50) NULL, [ReadTime] [datetime] NOT NULL, [SubID] [varchar](15) NULL, [ProbePosition] [float] NULL, [DataPoint] [int] NULL, CONSTRAINT [PK_CDSIM_BE] PRIMARY KEY CLUSTERED ([ID] ASC, [EquipmentID] ASC, [ReadTime] ASC) WITH …
1
SQL Server 2014でクエリプランがパフォーマンスを悪化させる
最近、サーバーをSQL Server 2008R2からSQL Server 2014にアップグレードしました。2008R2で正常に実行されたクエリがありますが、2014年には実行が非常に遅くなり、実行計画が不良です。 私はいくつかのテストを行いました... 2014 DBを2008/2012互換モードに切り替えます。 ページネーションを使用してクエリをテストします。 これらの両方により、クエリはSQL Server 2008R2と同じように高速で実行されました。 SQL Server 2014で計画がなぜそれほどひどく、クエリが長く実行されるのですか？ この画像は2つのクエリを示しており、1つは2008R2での実行方法と同じように行番号を使用しており、2つ目は改ページ調整による修正です。どちらも2014年に実行されましたが、どちらも非常に異なりますが、2008年には、2014年に改ページ調整を使用した場合と同じパフォーマンスが得られます。
2
行の見積もりが大幅に不正確であるため、フルテキスト検索が遅い
このデータベースに対するフルテキストクエリ（RT（リクエストトラッカー）チケットを格納する）は、実行に非常に長い時間がかかるようです。添付ファイルテーブル（フルテキストデータを含む）は約15GBです。 データベーススキーマは次のとおりで、約200万行です。 rt4 =＃\ d +添付ファイル テーブル "public.attachments" コラム| タイプ| 修飾子| ストレージ| 説明文 ----------------- + ----------------------------- +- -------------------------------------------------- ------ + ---------- + ------------- id | 整数| nullではないデフォルトのnextval（ 'attachments_id_seq' :: regclass）| プレーン| transactionid | 整数| nullではない| プレーン| 親| 整数| nullではないデフォルト0 | プレーン| メッセージID | キャラクター変化（160）| | 拡張| 件名| 文字の変化（255）| | 拡張| …
1
SQLHANDLEの無限再コンパイルの可能性が検出されました
私はSQLエラーログで奇妙なエラーメッセージを見つけてきました： Bocss：1時間ごとに同じデッドロックが発生–調査が必要 また、次の例のように、他のSPIDのエラーログに多くの再コンパイルがリストされます。 2015年9月4日14：30：10、spid64、Unknown、SQLHANDLE 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600200000010000000000000000000000000000000000000000000000000000000開始オフセット600400000009000000 、spid150、Unknown、SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000開始オフセット998、最後のオフセット252015終了オフセット2.9 09終了オフセット25209 09終了オフセット25209 09終了オフセット2509 0930：09、spid163、不明、可能無限の再コンパイルがSQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle検出された可能無限の再コンパイルは、最後の再コンパイルの理由2. 2015年9月4日14れた2652終了オフセット1064オフセット開始SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000検出されました0x06000400E7C7BF0EF0EB68A52C00000001000000000000000000000000000000000000000000000000000000開始オフセット1028終了オフセット2580。最後の再コンパイル理由は2でした。 何が原因でしょうか？ キャッシュにプランがもうないようです。 この投稿のアドバイスに従って http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx 次に、安全対策によりフルテキストカタログが無効にされたため、これには違いがなかったため、変更を完全にロールバックしました（新しいオブジェクトをドロップしたなど）。これでも違いはありませんでした。結局、SQLインスタンスの再起動がそれを止めるように見えた唯一の事柄であり、これが問題を即座に解決しました。 これも私を整理しました、しかし、私はまだ最初にこの混乱を引き起こした原因を見つける必要がありますか？
2
単一の行をアンピボットするときに、役に立たない並列分岐をどのようにして取り除くことができますか？
少数のスカラー集計をアンピボットする次のクエリを考えてみます。 SELECT A, B FROM ( SELECT MAX(CASE WHEN ID = 1 THEN 1 ELSE 0 END) VAL1 , MAX(CASE WHEN ID = 2 THEN 1 ELSE 0 END) VAL2 , MAX(CASE WHEN ID = 3 THEN 1 ELSE 0 END) VAL3 , MAX(CASE WHEN ID = 4 THEN 1 …
1
欠落している非クラスター化インデックスは既にクラスター化インデックスの一部です
実行速度の遅いクエリをデバッグしています。実行プランでは、非クラスタ化インデックスが推奨され、51.6648の影響があります。ただし、非クラスター化インデックスには、主キー（PK）複合クラスター化インデックスに既に含まれている列のみが含まれます。 これは、インデックス内の列の順序が原因である可能性がありますか？つまり、クラスター化インデックスの列の選択性が最も高いものから低いものへの順序ではない場合、非クラスター化インデックスがパフォーマンスを向上させる可能性はありますか？ さらに、非クラスター化インデックスには3つのPK列のうち2つだけが含まれ、3番目の列は包含列として追加されます。あるinclude非クラスタ化インデックスの使用がより最適かもしれないもう一つの理由？ 以下は、私が使用しているテーブル構造の例です。 テーブル- Retailers ( RetailerID int PK, name ...) Retailer_Relation_Types ( RelationType smallint PK, Description nvarchar(50) ...) Retailer_Relations ( RetailerID int PK FK, RelatedRetailerID int PK FK, RelationType smallint PK FK, CreatedOn datetime ...) テーブルにRetailer_Relationsは、次の複合PKインデックスと推奨インデックスがあります。 CONSTRAINT PK_Retailer_Relations PRIMARY KEY CLUSTERED ( RetailerID ASC, RelatedRetailerID ASC, RelationType ASC …
1
インデックスシークオペレーターのコスト
以下のAdventureWorksサンプルデータベースクエリの場合： SELECT P.ProductID, CA.TransactionID FROM Production.Product AS P CROSS APPLY ( SELECT TOP (1) TH.TransactionID FROM Production.TransactionHistory AS TH WHERE TH.ProductID = P.ProductID ORDER BY TH.TransactionID DESC ) AS CA; 実行計画ショー推定オペレータコストの0.0850383ため（93％）インデックスシーク： コストは、使用中のカーディナリティ推定モデルとは無関係です。 Estimated CPU CostとEstimated I / O Costを単純に追加したものではありません。また、インデックスシークの 1回の実行のコストに推定実行回数を掛けたものでもありません。 このコスト数はどのようにして得られたのですか？
1
マスター/詳細テーブル間のハッシュ結合により、カーディナリティの見積もりが低すぎる
マスターテーブルを詳細テーブルに結合するときに、SQL Server 2014が大きい（詳細）テーブルの基数推定を結合出力の基数推定として使用するようにするにはどうすればよいですか？ たとえば、10Kのマスター行を100Kの詳細行に結合する場合、SQL Serverで結合を100K行で推定します-詳細行の推定数と同じです。すべての詳細行に常に対応するマスター行があるという事実をSQL Serverの推定器が活用できるようにするには、クエリやテーブル、インデックス、あるいはその両方をどのように構成すればよいですか？（それらの間の結合は、カーディナリティの推定値を決して減らすべきではないという意味です。） 詳細はこちらです。このデータベースには、マスター/詳細のテーブルのペアがありVisitTargetます。販売トランザクションごとに1つの行があり、トランザクションVisitSaleごとに製品ごとに1つの行があります。これは1対多の関係です。VisitTargetの行が1つで、平均で10件のVisitSale行があります。 テーブルは次のようになります（この質問に関連する列のみを簡略化しています）。 -- "master" table CREATE TABLE VisitTarget ( VisitTargetId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, SaleDate date NOT NULL, StoreId int NOT NULL -- other columns omitted for clarity ); -- covering index for date-scoped queries CREATE NONCLUSTERED INDEX IX_VisitTarget_SaleDate ON VisitTarget …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.