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

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

1
クエリストアの強制計画機能が機能しない
クエリストアフォースプラン機能がプランを適用していないようです。 クエリストアを知っています-強制は常に強制を意味するわけではありません。ただし、私の計画はさほど変わらない場合がありますが、クエリオプティマイザーは引き続き不適切なインデックスやループの選択などを選択する可能性があります。 基本的に:それは私の強制的な計画の選択を尊重しません。私は多くの計画を強制しましたが、それはうまくいきません。 私が見たとき、0の失敗数または理由がありますsys.query_store_plan force_failure_count。 拡張イベントquery_store_plan_forcing_failedは何も生成しません。0イベント。 たとえば、20.09に強制された計画。たまたま強制計画を使用したコンパイルは1つだけです。 計画は大きく異なります。1つはINDEX 1でハッシュ一致結合を使用し、もう1つはINDEX 2でループ結合を使用します。 バージョン:Microsoft SQL Server 2016(SP1-GDR)(KB3210089)-13.0.4202.2(X64) ここで何が欠けていますか?

3
BULK INSERTステートメントのパフォーマンスをどのように調査しますか?
私は主にEntity Framework ORMを使用する.NET開発者です。ただし、ORMの使用に失敗したくないので、データレイヤー(データベース)内で何が起こるかを理解しようとしています。基本的に、開発中にプロファイラを起動し、クエリの観点からコードの一部が生成するものを確認します。 非常に複雑なもの(ORMが注意深く書かれていなければ、かなり単純なLINQステートメントからでもひどいクエリを生成する可能性があります)や重いもの(持続時間、CPU、ページの読み取り)を見つけた場合は、それをSSMSで受け取り、その実行計画を確認します。 私のデータベースの知識レベルでは問題なく動作します。ただし、BULK INSERTはSHOWPLANを生成しないように見えるため、特別な生物のようです。 非常に単純な例を示します。 テーブル定義 CREATE TABLE dbo.ImportingSystemFileLoadInfo ( ImportingSystemFileLoadInfoId INT NOT NULL IDENTITY(1, 1) CONSTRAINT PK_ImportingSystemFileLoadInfo PRIMARY KEY CLUSTERED, EnvironmentId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo REFERENCES dbo.Environment, ImportingSystemId INT NOT NULL CONSTRAINT FK_ImportingSystemFileLoadInfo_ImportingSystem REFERENCES dbo.ImportingSystem, FileName NVARCHAR(64) NOT NULL, FileImportTime DATETIME2 NOT NULL, CONSTRAINT UQ_ImportingSystemImportInfo_EnvXIs_TableName UNIQUE …

1
シーク述語と述語の違い
SQL Server 2014 Enterpriseにあるクエリのパフォーマンスを調整しようとしています。 私はSQL Sentryのプランエクスプローラで、実際のクエリプランを開いていて、私はそれがいることを一つのノード上で見ることができる述語をシークしても述語 Seek PredicateとPredicateの違いは何ですか? 注:このノードには多くの問題(たとえば、推定行と実際の行、残りのIO)があることがわかりますが、質問はそれとは関係ありません。

2
DELETEクエリが別のフォーマットよりもはるかに長いフォーマットで実行されるのはなぜですか?
一部の重複を削除しようとする特定のクリーンアップコードがあります。 これは多くの顧客サイトで完全に実行されます。ログから、このクエリでは少なくとも1秒から45秒が消費されていることがわかります。 DELETE FROM [tbl] WHERE [Id] NOT IN ( SELECT MIN([Id]) FROM [tbl] GROUP BY [IdProject], [IdRepresentative], [TimeStart] ) しかし、私はこのクエリを4時間以上(現在までで、終了しない)実行している顧客がいます!私はDBをチェックしました(DBCC CHECKDB)、統計情報を更新しました(sp_updatestats)もUPDATE STATISTICS [tbl] WITH FULLSCAN変更を示していません。 お客様からDBの元のバックアップがあります。SQL Server 14.0.2002.14で実行しています。Standard Editionを持っていますが、お客様はExpress Editionを使用しています。 他の誰もDBを使用していないことをアクティビティモニターで確認できます。待機時間はなく、CPUは25%使用されています(4つのCPUのうちの1つのみ)。また、この私のテストケースでは、他の誰もDBを使用していません。 私はクエリを再構成し、このステートメントをチェックしました: DELETE FROM [tbl] FROM [tbl] AS t LEFT OUTER JOIN ( SELECT MIN([Id]) AS [IdMin] FROM [tbl] …

2
Int / SmallintからVarcharへの暗黙の変換が発生するのはなぜですか?それは本当にカーディナリティの見積もりに影響を与えますか?
実際の実行プランでプラン表示分析(SSMS)を使用して、パフォーマンスの遅いクエリをトラブルシューティングしようとしています。分析ツールは、行数の見積もりが計画のいくつかの場所で返された結果からずれていることを指摘し、さらにいくつかの暗黙の変換警告を与えます。 これらのintからVarcharへの暗黙的な変換を理解できません-参照されるフィールドはクエリのパラメーター/フィルターの一部ではなく、関係するすべてのテーブルで列のデータ型は同じです: 以下のCardinalityEstimate警告が表示されます。 式の型変換(CONVERT_IMPLICIT(varchar(12)、[ccd]。[profileid]、0))は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDB内のすべての整数です 式の型変換(CONVERT_IMPLICIT(varchar(6)、[ccd]。[nodeid]、0))は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDBのあらゆる場所でsmallintです 式の型変換(CONVERT_IMPLICIT(varchar(6)、[ccd]。[sessionseqnum]、0))は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、DB内のあらゆる場所で小さな整数です 式の型変換(CONVERT_IMPLICIT(varchar(41)、[ccd]。[sessionid]、0))は、クエリプランの選択で "CardinalityEstimate"に影響する可能性があります-このフィールドは、DBのすべての場所で10進数です [編集]参照用のクエリと実際の実行計画は次の とおりですhttps://www.brentozar.com/pastetheplan/?id=SysYt0NzN そして、テーブルの定義。 /****** Object: Table [dbo].[agentconnectiondetail] Script Date: 1/10/2019 9:10:04 AM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[agentconnectiondetail]( [sessionid] [decimal](18, 0) NOT NULL, [sessionseqnum] [smallint] NOT NULL, [nodeid] [smallint] NOT NULL, [profileid] [int] …

1
SQL ServerクエリプランXML:QueryPlanHashの長さ
更新:これは間違いなくバグです。詳細については、こちらの接続アイテムをご覧ください。 sp_BlitzCacheへのいくつかの変更(完全な開示、私は作成者の1人)をテストしているときに、コードのバグだと思ったものに遭遇しました。 ある時点で、クエリコストを取得するためにクエリプランハッシュを照合しています。私たちはそのようにしています: statement.value('sum(/p:StmtSimple[xs:hexBinary(substring(@QueryHash, 3)) = xs:hexBinary(sql:column("b.QueryHash"))]/@StatementSubTreeCost)', 'float') これは、私が見た限りではうまくいきました。ただし、奇妙なケースの1つとして、XMLの部分文字列がNULL値をスローし、プランのコストはかなり高いにもかかわらず、コストが0でした。 掘り下げる実行計画(フル開示は、ホストが計画を貼り付けていること、会社のための私の仕事は)、私は、クエリプランハッシュは一つの問題ハッシュのための残りが18ここである例でありながら、17文字の長さだったことに気づきました。 QueryPlanHash = "0x4410B0CA640CDA89" QueryPlanHash = "0x2262FEA4CE645569" QueryPlanHash = "0xED4F225CC0E97E5"-問題! QueryPlanHash = "0xBF878EEE6DB955EA" QueryPlanHash = "0x263B53BC8C14A452" QueryPlanHash = "0x89F5F146CF4B476F" QueryPlanHash = "0xEF47EA40805C8961" QueryPlanHash = "0xB7BE27D6E43677A5" QueryPlanHash = "0x815C54EC43A6A6E9" クエリプランハッシュはaとしてリストされていますBINARY 8-おそらくこれは常に同じ長さでなければなりませんが、私のような人はバイナリ値について何を知っていますか? XQueryを少し試してみたところ、2番目の位置から開始するように部分文字列を変更すると、有効な(正しくないとしても)ハッシュ値が得られることがわかりました。 WITH XMLNAMESPACES('http://schemas.microsoft.com/sqlserver/2004/07/showplan' AS p) SELECT QueryPlanCost = statement.value('sum(/p:StmtSimple/@StatementSubTreeCost)', 'float'), **q.n.value('substring(@QueryPlanHash, …

4
SQL Serverが単純なバイジェクションでインデックスを使用できない
これは別のクエリオプティマイザーの難問です。 たぶん私はクエリオプティマイザーを過大評価しているのかもしれませんし、何か不足しているかもしれません。 シンプルなテーブルがあります CREATE TABLE [dbo].[MyEntities]( [Id] [uniqueidentifier] NOT NULL, [Number] [int] NOT NULL, CONSTRAINT [PK_dbo.MyEntities] PRIMARY KEY CLUSTERED ([Id]) ) CREATE NONCLUSTERED INDEX [IX_Number] ON [dbo].[MyEntities] ([Number]) インデックスとそこに数千行あり、Number値0、1、2に均等に分散されています。 今、このクエリ: SELECT * FROM (SELECT [Extent1].[Number] AS [Number], CASE WHEN (0 = [Extent1].[Number]) THEN 'one' WHEN (1 = [Extent1].[Number]) THEN 'two' …

2
奇数ストリームの集計動作
クエリ: declare @X xml = ' <item ID = "0"/> <item ID = "1"/> <item/> <item/>'; select I.X.value('@ID', 'int') from @X.nodes('/item') as I(X); 結果: ----------- 0 1 NULL NULL 実行計画: 上のブランチはXMLを4行に細断し、下のブランチは属性の値をフェッチしますID。 奇妙に感じるのは、Stream Aggregateオペレーターから返される行の数です。Filterからの2つの行は、XMLのID最初と2番目のitemノードの属性です。Stream Aggregateは、各入力行に1つずつ、4つの行を返し、内部結合を外部結合に効果的に変換します。 これは、Stream Aggregateが他の状況でも行うことですか、それともXMLクエリを実行するときに奇妙なことですか? XMLバージョンのクエリプランで、このStream Aggregateの動作が以前に気付いた他のどのStream Aggregateとも異なるはずであるというヒントはありません。

3
突然インデックスやクエリを変更する必要がある理由に答える方法
私は3年の経験を持つジュニアDBAです。私たちの仕事は、クエリを微調整するか、特定のコードを書き換えるか、インデックスが必要であることを開発者にアドバイスすることです。 開発チームが頻繁に尋ねる1つの簡単な質問は、「昨日は問題なく動作しましたが、何が突然変化しましたか?」です。インフラストラクチャの側面を確認するよう求められます。問題に対する最初の反応は、常に検証される最初のことであるインフラストラクチャに最大の責任を負わせることです。 開発チームからの「何が変わったのか」という質問にどのように答えればよいでしょうか?皆さんは今まで同じ状況に直面しましたか?もしそうなら、あなたの経験を共有してください。

1
クエリプランをステートメントで分割して再利用できるようにした方がよいでしょうか。
クエリによってクエリプランがどのようにコンパイル、格納、および取得されるかについての限られた知識から、複数ステートメントクエリまたはストアドプロシージャがクエリプランを生成し、クエリプランキャッシュに格納されて、今後の実行でクエリによって使用されることを理解しています。 このプランは、クエリハッシュを使用してクエリプランキャッシュから取得されると思います。つまり、クエリを編集して実行すると、ハッシュが異なり、クエリプランキャッシュで一致するハッシュが見つからないため、新しいプランが生成されます。 私の質問は次のとおりです。ユーザーがマルチステートメントクエリのステートメントの1つであるステートメントを実行した場合、マルチステートメントクエリのキャッシュに既にあるクエリプランの関連部分を使用できますか?ハッシュ値が明らかに一致しないため、答えはノーだと思いますが、マルチステートメントクエリの各ステートメントをハッシュして、クエリから個々のステートメントを実行しているユーザーが使用できるようにした方がよいでしょうか? 私は考慮していない複雑な問題があると思います(そして、私が本当に知りたいのはこれらです)が、より多くのスペースを使用し、さらに多くのクエリプランに同じ「ステートメントプラン」を格納することができるようです生成するCPUと時間。 私の無知を示​​しているだけかもしれません。

2
統計、実行計画、および「昇順の主要な問題」を理解する
統計、実行計画、ストアドプロシージャの実行の間の関係を(概念的に)よりよく理解しようとしています。 統計はストアドプロシージャの実行プランを作成するときにのみ使用され、実際の実行コンテキストでは使用されないというのは正しいことですか?つまり、これが当てはまる場合、プランが作成されたら(そしてプランが適切に再利用されていると仮定して)、「最新の」統計はどのくらい重要ですか? 特に私が読んだ記事(統計、行の見積もり、昇順の日付の列)は、クライアントのデータベースのいくつかで毎日直面しているシナリオと非常によく似たシナリオを説明しています。 特定のストアドプロシージャを使用して定期的にクエリする最大のテーブルの1つに昇順の日付/時刻列があります。 1日に10万行が追加されるときに、実行プランが古くならないようにするにはどうすればよいですか。 この問題に対処するために統計を頻繁に更新する場合、このストアドプロシージャのクエリでOPTION(RECOMPILE)ヒントを使用することは理にかなっていますか? アドバイスや推奨事項をいただければ幸いです。 更新:SQL Server 2012(SP1)を使用しています。

2
PARTITION BYなしのROW_NUMBER()でもセグメントイテレータが生成される
私は、ランク付けおよび集計ウィンドウ関数、特にセグメントおよびシーケンスプロジェクトイテレータに関する私のブログ投稿を書いています。私が理解している方法は、Segmentがグループの終了/開始を構成するストリーム内の行を識別するため、次のクエリです。 SELECT ROW_NUMBER() OVER (PARTITION BY someGroup ORDER BY someOrder) セグメントを使用して、行が前の行以外の別のグループに属していることを通知します。次に、Sequence Projectイテレーターは、Segmentイテレーターの出力に基づいて、実際の行番号を計算します。 ただし、そのロジックを使用する次のクエリには、セグメント式がないため、セグメントを含める必要はありません。 SELECT ROW_NUMBER() OVER (ORDER BY someGroup, someOrder) ただし、この仮説を試すと、これらのクエリは両方ともセグメント演算子を使用します。唯一の違いは、2番目のクエリはGroupByセグメントにa を必要としないことです。そもそもセグメントの必要性を排除していませんか? 例 CREATE TABLE dbo.someTable ( someGroup int NOT NULL, someOrder int NOT NULL, someValue numeric(8, 2) NOT NULL, PRIMARY KEY CLUSTERED (someGroup, someOrder) ); --- Query 1: SELECT …

3
インデックススキャンではなくPostgreSQL順次スキャンなぜですか?
こんにちは、私はPostgreSQLデータベースクエリに問題があり、誰かが手伝ってくれるかどうか疑問に思っています。いくつかのシナリオでは、私のクエリは、2つのテーブルdataとを結合するために使用した、私が作成したインデックスを無視しているようdata_areaです。これが発生すると、シーケンシャルスキャンが使用され、クエリが非常に遅くなります。 順次スキャン(〜5分) Unique (cost=15368261.82..15369053.96 rows=200 width=1942) (actual time=301266.832..301346.936 rows=153812 loops=1) CTE data -> Bitmap Heap Scan on data (cost=6086.77..610089.54 rows=321976 width=297) (actual time=26.286..197.625 rows=335130 loops=1) Recheck Cond: (datasetid = 1) Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double …

1
関数呼び出しによる推定クエリプランと実際のクエリプラン
SQLサーバーにこのクエリがあります。マージレプリケーションクエリです。 SELECT DISTINCT b.tablenick, b.rowguid, c.generation, sys.fn_MSgeneration_downloadonly ( c.generation, c.tablenick ) FROM #belong b LEFT OUTER JOIN dbo.MSmerge_contents c ON c.tablenick = b.tablenick AND c.rowguid = b.rowguid; 推定クエリプランには、3つのクエリに関する情報が含まれます。 上記のクエリ fn_MSgeneration_downloadonlyへの関数呼び出し fn_MSArticle_has_downloadonly_propertyへの関数呼び出し 実際のクエリプランには、次の情報のみが含まれます。 上記のクエリ 関数については何もありません。実際のプランで機能情報が欠けているのはなぜですか? 私はこれらのオプションを試しました: SET STATISTICS PROFILE ON SET STATISTICS XML ON 実際のプランを作成しましたが、Management Studioで実際のクエリプランオプションを使用したときと同じように、パート2と3が欠落していました。 たとえば、プロファイラーを使用して関数呼び出しに関する情報を取得する場合、どのイベントを選択しますか? クエリプランに特に関連する回答は見つかりませんでしたが、SP:StmtStartingおよびSP:StmtCompletedのプロファイルを作成したところ、関数呼び出しが表示されました。

1
JOIN句でORを使用する場合の奇妙なクエリプラン-テーブル内のすべての行の定数スキャン
JOIN句でORを使用するよりも2つの結果セットのUNIONが優れている理由を示すために、サンプルクエリプランを作成しようとしています。私が書いたクエリプランには困惑しています。Users.Reputationの非クラスター化インデックスでStackOverflowデータベースを使用しています。 クエリは CREATE NONCLUSTERED INDEX IX_NC_REPUTATION ON dbo.USERS(Reputation) SELECT DISTINCT Users.Id FROM dbo.Users INNER JOIN dbo.Posts ON Users.Id = Posts.OwnerUserId OR Users.Id = Posts.LastEditorUserId WHERE Users.Reputation = 5 クエリプランはhttps://www.brentozar.com/pastetheplan/?id=BkpZU1MZEにあります。クエリの所要時間は4:37分で、26612行が返されました。 このスタイルの定数スキャンが既存のテーブルから作成されるのを見たことがありません-常に一定のスキャンがユーザーによって入力された単一の行に対して使用される場合、すべての単一の行に対して一定のスキャンが実行される理由がわかりませんたとえば、SELECT GETDATE()。なぜここで使用されるのですか?このクエリプランを読む際に、いくつかのガイダンスをいただければ幸いです。 そのORをUNIONに分割すると、同じ26612行が返される12秒で実行される標準プランが作成されます。 SELECT Users.Id FROM dbo.Users INNER JOIN dbo.Posts ON Users.Id = Posts.OwnerUserId WHERE Users.Reputation = 5 UNION SELECT Users.Id …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.