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

クエリ最適化の統計は、テーブルまたはインデックス付きビューの1つ以上の列の値の分布に関する統計情報を含むオブジェクトです。

1
一意のインデックスの更新と統計行の変更カウンター
次の表、一意のクラスター化インデックス、および統計情報が与えられます。 CREATE TABLE dbo.Banana ( pk integer NOT NULL, c1 char(1) NOT NULL, c2 char(1) NOT NULL ); CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk); CREATE STATISTICS c1 ON dbo.Banana (c1); CREATE STATISTICS c2 ON dbo.Banana (c2); INSERT dbo.Banana (pk, c1, c2) VALUES (1, 'A', 'W'), (2, 'B', 'X'), …
1
SQL Serverによる毎日の計画の再作成
実稼働環境でこの問題が発生しています。 Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-Windows NT 6.1（ビルド7601：Service Pack 1）上のEnterprise Edition（64ビット）。 SQL Serverは、すべての（ほぼ100％）古い実行計画を削除し、毎日一晩中（午後11:00から8:00に）再作成しています。これは、「自動更新統計」が無効状態のときにも発生していました。過去2〜3週間、「自動更新統計」をオンにしました。しかし、それはまだ起こっています。 この計画の再生成をトリガーするものは実際にはわかりませんが、手動でそれを行わないことは確かです。 計画が再生成されるタイミングと実際に一致するのは、DBメンテナンスジョブのみです。毎日のインデックスの再編成（断片化が5〜30％の場合）と毎日のインデックスの再構築（断片化が30％を超える場合） ）仕事。通常、この毎日のメンテナンスジョブは再編成のみを行います（インデックスの断片化は毎日30％を超えないため）。 影響： これらの新しく作成されたプランにより、UDF呼び出し/クエリ呼び出し（UI / Webページから呼び出される）がかなり長くなり（1秒未満ではなく数分）、セッションが積み上げられてCPUが90％近くになります。 問題は、それらのスタックしたセッションが強制的に削除された瞬間（DB側）、1）対応するすべての実行プランが手動でクリアされたとき（クエリの場合）、2）UDFが変更されたとき（関数の場合）に消えます。その瞬間からSQLサーバーによって作成された新しい計画は、翌朝同じ問題が発生するまで1日を通して完璧に機能します。また、この動作は100％一貫しているわけではなく、毎朝実際に表示されるわけではありません。しかし、4〜5日間連続して表示されている期間がありました。 この問題は、ビジネスの朝に発生します。UI/ Webページがより集中的にアクセスされる場合です。 誰がこれを引き起こしているのか、この問題を解決する方法の手がかりを持っていますか？どんな助けでも大歓迎です。
2
stats_column_idとindex_column_idは、クラスター化インデックスの物理的な順序が変更されても更新されません
列の目的を誤解していない限り、次のコードは、クラスター化インデックスの構造を変更stats_column_idしてもsys.stats_columns DMVの列の順序位置（）が変更されないことを示しています。（AdventureWorks2014、AdventureWorks2008R2でテスト済み） select i.name, c.name, ic.column_id, ic.index_column_id from sys.indexes i join sys.index_columns ic on i.object_id = ic.object_id and i.index_id = ic.index_id join sys.columns c on i.object_id = c.object_id and ic.column_id = c.column_id where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID' order by ic.key_ordinal; select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id from sys.stats s join sys.stats_columns …
1
ヒストグラム外のカーディナリティー推定
セットアップ カーディナリティの推定値を理解するのに苦労しています。テストのセットアップは次のとおりです。 Stack Overflowデータベースの2010バージョン SQL Server 2017 CU15 + GDR（KB4505225）-14.0.3192.2 新しいCE（互換性レベル140） 私はこのプロシージャを持っています： USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO dbo.Postsテーブルに非クラスター化インデックスまたは統計がありません（にクラスター化インデックスがありますId）。 このための推定プランを要求すると、「推定行」dbo.Postsは1,934.99になります。 EXEC #sp_PostsByCommentCount @CommentCount = 51; 次の統計オブジェクトは、推定プランを要求したときに自動的に作成されました。 DBCC SHOW_STATISTICS('dbo.Posts', [_WA_Sys_00000006_0519C6AF]); そのハイライトは次のとおりです。 統計のサンプルレートは1.81％と非常に低い（67,796 …
3
並列統計更新
SQL Server 2008以降ではUPDATE STATISTICS WITH FULLSCAN、シングルスレッド操作ですか、それとも並列処理を使用できますか？デフォルトのサンプリングによる統計の更新はどうですか？並列処理を使用できますか？MAXDOPupdate statsで指定するオプションが表示されません。
1
SQL Serverがこれらの統計のフルスキャン以外の更新を拒否するのはなぜですか？
毎日のデータウェアハウスビルドで、比較的長時間（20分以上）統計の自動更新操作が実行されていることに気付きました。関係するテーブルは CREATE TABLE [dbo].[factWebAnalytics]( [WebAnalyticsId] [bigint] IDENTITY(1,1) NOT NULL, [MarketKey] [int] NOT NULL CONSTRAINT [DF_factWebAnalytics_MarketKey] DEFAULT ((-1)), /*Other columns removed*/ CONSTRAINT [PK_factWebAnalytics] PRIMARY KEY CLUSTERED ( [MarketKey] ASC, [WebAnalyticsId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [MarketKeyPS]([MarketKey]) ) ON …
1
統計は最新ですが、推定値が間違っています
するとdbcc show_statistics ('Reports_Documents', PK_Reports_Documents)、レポートID 18698に対して次の結果が得られます。 このクエリの場合： SELECT * FROM Reports_Documents WHERE ReportID = 18698 option (recompile) クラスター化インデックスPK_Reports_Documentsを期待どおりにシークするクエリプランを取得します。 しかし、私を困惑させるのは、推定行数の誤った値です： よると、この： サンプルクエリのWHERE句の値がヒストグラムのRANGE_HI_KEY値と等しい場合、SQL ServerはヒストグラムのEQ_ROWS列を使用して、等しい行の数を決定します これは私が期待する方法でもありますが、実際にはそうではないようです。またRANGE_HI_KEY、提供されたヒストグラムに存在する他のいくつかの値を試してみてshow_statistics、同じことを経験しました。私の場合、この問題により、一部のクエリで非常に最適でない実行プランが使用され、実行時間が数分になるのに対し、クエリヒントで1秒で実行できるように思われます。 全体として：EQ_ROWS推定行数にヒストグラムが使用されていない理由と、誤った推定値はどこから来たのかを誰かが説明できますか？ もう少し（おそらく役立つ）情報： 統計の自動作成はオンであり、すべての統計は最新です。 クエリされるテーブルには、約8000万行があります。 PK_Reports_Documentsなる組み合わせPKでありReportID INT、およびDocumentID CHAR(8) クエリは合計5つの異なる統計オブジェクトをロードしているように見えますが、すべてのオブジェクトにReportIDはテーブルの+他の列が含まれています。それらはすべて新しく更新されました。RANGE_HI_KEY以下の表にあるのは、ヒストグラムの上限の列値です。 +-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+ | name | stats_id | auto_created | user_created | Leading column Type | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | …
1
統計。複数列のヒストグラムは可能ですか？
高密度の2つの列があるが、これらの列が独立していない状況を考えています。 定義 これが、テスト目的で作成したテーブルの定義です。 CREATE TABLE [dbo].[StatsTest]( [col1] [int] NOT NULL, --can take values 1 and 2 only [col2] [int] NOT NULL, --can take integer values from 1 to 4 only [col3] [int] NOT NULL, --integer. it has not relevance just to ensure that each row is different [col4] AS ((10)*[col1]+[col2]) …
1
データウェアハウジングシナリオで「統計の自動更新」を無効にする必要がありますか？
SQL Serverに200 GBのデータウェアハウスがあります。 一部のクエリの実行時間が非常に遅くなっています。たとえば、をdelete使用した単純なクエリの場合は12時間ですinner join。 実行計画でいくつかの調査を行った後、WITH FULLSCANオプションを使用して、クエリに関連する2つのテーブルの統計を更新しました。 クエリは1秒未満で実行されるようになったため、統計は最新ではなかったようです。 auto update statisticsデータベースを無効にしてUPDATE STATISTICS、データウェアハウスの読み込み後に手動で実行することを検討しています。データウェアハウスは、ソースERPシステムから毎日、夜間に段階的に読み込まれます。 auto update statisticsデータウェアハウジングシナリオでは本当に役に立たないと想定しても正しいですか？代わりに、データのロード後に統計を手動で更新する方が理にかなっていますか？
1
インデックスシークが正しい行数を推定でき、ソート演算子が推定できないのはなぜですか？
次のような述語の関数を使用するクエリがあります。 commentType = 'EL' AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0) 40000行のcommentTypeにフィルター処理されたインデックスがあり、クエリを実行すると、インデックスシークの推定行数は非常に正確（約11K）ですが、次のステップ（ソート演算子）では、統計を完全に無視し、フィルターされたインデックスの行の総数を推定するだけです。 なんでこんなことが起こっているの？私はsargabilityの基本を知っており、正気を期すために、dateaddを実際の日付（2014-01-01）と実際の日付で置き換えてテストしました...ソートは行数を正しく推測し始めました... なぜこれが起こっているのですか、どうすれば修正できますか？決まった日を渡すことはできません...
2
統計、実行計画、および「昇順の主要な問題」を理解する
統計、実行計画、ストアドプロシージャの実行の間の関係を（概念的に）よりよく理解しようとしています。 統計はストアドプロシージャの実行プランを作成するときにのみ使用され、実際の実行コンテキストでは使用されないというのは正しいことですか？つまり、これが当てはまる場合、プランが作成されたら（そしてプランが適切に再利用されていると仮定して）、「最新の」統計はどのくらい重要ですか？ 特に私が読んだ記事（統計、行の見積もり、昇順の日付の列）は、クライアントのデータベースのいくつかで毎日直面しているシナリオと非常によく似たシナリオを説明しています。 特定のストアドプロシージャを使用して定期的にクエリする最大のテーブルの1つに昇順の日付/時刻列があります。 1日に10万行が追加されるときに、実行プランが古くならないようにするにはどうすればよいですか。 この問題に対処するために統計を頻繁に更新する場合、このストアドプロシージャのクエリでOPTION（RECOMPILE）ヒントを使用することは理にかなっていますか？ アドバイスや推奨事項をいただければ幸いです。 更新：SQL Server 2012（SP1）を使用しています。
1
SQL Serverの統計のデフォルトのサンプルサイズは何ですか？
MSDNから： サンプルオプション(SAMPLE, FULLSCAN, RESAMPLE)が指定されていない場合、クエリオプティマイザーはデータをサンプリングし、デフォルトでサンプルサイズを計算します。 統計のデフォルトのサンプルサイズを特定するにはどうすればよいですか？ MSDNを調べましたが、デフォルトのサンプルサイズを特定するための式や方法が見つかりませんでした。どこにも、自動統計更新をトリガーするための数式しかありません。どんなポインタも役に立ちます。
1
統計でヒストグラムのステップ数はどのように決定されますか
SQL Serverの統計でヒストグラムのステップ数はどのように決定されますか？ キー列に200以上の異なる値があるにもかかわらず、なぜ200ステップに制限されているのですか？決め手はありますか？ デモ スキーマ定義 CREATE TABLE histogram_step ( id INT IDENTITY(1, 1), name VARCHAR(50), CONSTRAINT pk_histogram_step PRIMARY KEY (id) ) テーブルに100レコードを挿入する INSERT INTO histogram_step (name) SELECT TOP 100 name FROM sys.syscolumns 統計の更新と確認 UPDATE STATISTICS histogram_step WITH fullscan DBCC show_statistics('histogram_step', pk_histogram_step) ヒストグラムの手順： +--------------+------------+---------+---------------------+----------------+ | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | …
2
クエリストア検索を終了しない
最初から私の質問/問題はこの前のものと似ていると言いますが、原因または開始情報が同じであるかどうかわからないため、質問をいくつか詳細に投稿することにしました。 手元の問題： 奇妙な時間（営業日の終わり近く）に、本番インスタンスの動作が不安定になります。 インスタンスのCPU使用率が高い（ベースラインが約30％の場合、約2倍になり、まだ増加し続けていた） 1秒あたりのトランザクション数の増加（ただし、アプリの負荷には変化が見られません） アイドルセッションの数の増加 この動作を表示しなかったセッション間の奇妙なブロッキングイベント（コミットされていない読み取りセッションでもブロッキングが発生していました） 間隔の上位の待機は1位で非ページラッチで、ロックは2位でした。 初期調査： sp_whoIsActiveを使用して、監視ツールによって実行されたクエリが非常に低速で実行され、大量のCPUを取得することを決定したことがわかりました。 その分離レベルはコミットされずに読み取られました。 奇妙な数字が見られた計画を調べました。StatementEstRows= "3.86846e + 010"で、約150 TBの推定データが返されます。 監視ツールのクエリモニター機能が原因であると考えたため、この機能を無効にしました（プロバイダーにチケットを開いて、問題が発生しているかどうかを確認しました） その最初のイベントから、それはさらに数回起こりました。セッションを終了するたびに、すべてが通常に戻ります。 クエリがクエリストアの監視のためにBOLでMSによって使用されるクエリの1つに非常に類似していることがわかります-パフォーマンスが最近低下したクエリ（異なる時点での比較） 同じクエリを手動で実行し、同じ動作を確認します（使用されるCPUが増え続ける、ラッチ待機が増える、予期しないロックなど）。 有罪の質問： Select qt.query_sql_text, q.query_id, qt.query_text_id, rs1.runtime_stats_id AS runtime_stats_id_1, interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), p1.plan_id AS plan_1, rs1.avg_duration AS avg_duration_1, rs2.avg_duration AS avg_duration_2, p2.plan_id AS plan_2, interval_2 = DateAdd(minute, …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.