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

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

2
統計を更新するタイミング
以下を行うメンテナンスプランを継承しました。 古いデータをクリーンアップする DBの整合性をチェックします データベースとトランザクションログのバックアップを実行します インデックスを再編成します 統計の更新 古いバックアップとメンテナンスプランファイルを削除する 23分間のメンテナンスプランのうち、統計の更新には13分間という驚異的な時間がかかります。この13分間、データベースへのアクセスはブロックされます（または、少なくとも、このDBから他のデータベースへのレプリケーションは一時停止されます）。 私の質問は： 統計をいつ更新する必要がありますか？ これは、毎日よりも頻繁に行うべきではないように思えます。私は、不必要なメンテナンスを行うという「理由」の考え方から抜け出そうとしています。
3
インデックスを作成するよりも統計を作成したほうがよいのはいつですか？
私は上の情報をたくさん発見したものを STATISTICS、次のとおりです。彼らは、彼らがクエリやインデックスから手動または自動で作成する方法を、維持、およびようにしていますか。しかし、私は見つけることができなかったいかなるに関するガイダンスや「ベストプラクティス」の情報それらを作成するには：インデックスからではなく、手動で作成されたSTATISTICSオブジェクトのほうがどのような状況にメリットがあるか。私は手動でフィルターされた統計を作成し、パーティション化されたテーブルのクエリを支援しました（インデックス用に作成された統計はテーブル全体をカバーし、パーティションごとではないためです-brillaint！）インデックスの詳細を必要とせず、インデックスを維持したり、ブロック/デッドロックの可能性を高めたりするコストも必要ありません。 @JonathanFiteはコメントで、インデックスと統計の違いについて言及しました。 インデックスは、テーブル自体とは異なる方法でソートされたルックアップを作成することにより、SQLがデータをすばやく見つけるのに役立ちます。統計は、クエリを満たすために必要なメモリ/労力をSQLが判断するのに役立ちます。 主に質問を明確にするのに役立つからです。 どのようにこのことを知っている（または上の任意の他の技術的な情報はないものを Sとどのように行動しての性質に関連sをSTATISTICS）助けを決定するとき選択するCREATE STATISTICS以上CREATE INDEXの関連が作成されますインデックスを作成するときに、特に、STATISTICSオブジェクトを？どのようなシナリオでは、よりよい持っていることによって提供されることになるだけ STATISTICS情報をしていないインデックスを持ちますか？ 可能な場合、STATISTICSオブジェクトがに比べてより適しているシナリオの実用例があると、非常に便利INDEXです。 私は視覚的な学習者/思考者であるため、最適なタイミングを判断するのに役立つ可能性のある手段として、STATISTICSとINDEXes の違いを並べて確認すると役立つと思いSTATISTICSました。 Thingy PROs CONs ------- ---------- ------------------- INDEX * Can help sorts. * Takes up space. * Contains data (can * Needs to be maintained (extra I/O). "cover" a query). * More chances for blocking / dead-locks. STATISTICS …
1
sys.stats_columnsは間違っていますか？
Foo列ID1, ID2と複合主キーが定義されたテーブルがあるとしますID2, ID1。（私は現在、この方法で定義された複数のテーブルを持つSystem Center製品を使用しています。プライマリキー列は、テーブル定義に表示されるのとは逆の順序でリストされています。） CREATE TABLE dbo.Foo( ID1 int NOT NULL, ID2 int NOT NULL, CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED (ID2, ID1) ); GO -- Add a row and update stats so that histogram isn't empty INSERT INTO Foo (ID1, ID2) VALUES (1,2); UPDATE STATISTICS dbo.Foo; のkey_ordinal列はsys.index_columns、複合主キーで宣言されたのと同じ順序でインデックス列を示します。 SELECT t.name, i.name, …
1
SQL Serverの統計は物理的にどこに保存されますか？
クエリオプティマイザーが使用する統計情報は、SQL Serverデータベースファイルとバッファープール内に物理的に保存されていますか？ より具体的には、DMVやDBCCを使用して統計で使用されるページを把握する方法はありますか？ SQL Server 2008 InternalsとSQL Server Internals and Troubleshootingの両方の書籍を所有していますが、いずれも統計の物理構造については説明していません。もしそうなら、私はこの情報を見つけることができません。
3
統計更新のためのサンプルサイズによる奇妙な動作
SQL Server（2012）の統計情報の更新を使用してサンプリングのしきい値を調査し、いくつかの奇妙な動作に気付きました。基本的に、サンプリングされる行の数は、同じデータセットであっても、状況によって異なるようです。 このクエリを実行します。 --Drop table if exists IF (OBJECT_ID('dbo.Test')) IS NOT NULL DROP TABLE dbo.Test; --Create Table for Testing CREATE TABLE dbo.Test(Id INT IDENTITY(1,1) CONSTRAINT PK_Test PRIMARY KEY CLUSTERED, TextValue VARCHAR(20) NULL); --Insert enough data so we have more than 8Mb (the threshold at which sampling kicks in) INSERT INTO …
2
LIKE演算子のカーディナリティの推定（ローカル変数）
私はLIKE、未知のシナリオのすべての最適化で演算子を使用する場合、レガシーと新しいCEの両方が9％の見積もりを使用するという印象を受けました（関連する統計が利用可能であり、クエリオプティマイザーが選択性の推測に頼る必要がないと仮定）。 クレジットデータベースに対して以下のクエリを実行すると、CEごとに異なる推定値が得られます。新しいCEでは、予想していた900行の見積もりを受け取りますが、レガシーCEでは、241.416の見積もりを受け取りますが、この見積もりがどのように導出されるのかわかりません。誰もが光を当てることができますか？ -- New CE (Estimate = 900) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName; -- Forcing Legacy CE (Estimate = 241.416) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName OPTION ( QUERYTRACEON 9481, QUERYTRACEON 9292, QUERYTRACEON 9204, QUERYTRACEON …
3
実行計画で統計が欠落している場合の警告
私には理解できない状況があります。SQL Serverの実行計画では、テーブルの統計が欠落していると表示されますが、統計は既に作成されています。 しかし、テーブルを見ると、自動的に作成された統計があることがわかります。 誰かがそれがどのようになり得るかを理解するのを助けることができますか？ Auto_UpdateおよびAuto_Create統計は、現在のDBでオンになっています。 SQL Server 2014を使用しています。
1
増分更新後に統計が消える
増分統計を利用する大規模なパーティションSQL Serverデータベースがあります。すべてのインデックスはパーティション分割されています。パーティションごとにオンラインでパーティションを再構築しようとすると、インデックスが再構築された後にすべての統計が消えます。 以下は、AdventureWorks2014データベースを使用してSQL Server 2014の問題を再現するスクリプトです。 --Example against AdventureWorks2014 Database CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME) AS RANGE RIGHT FOR VALUES ( '20130501', '20130601', '20130701', '20130801', '20130901', '20131001', '20131101', '20131201', '20140101', '20140201', '20140301' ); GO CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO ( [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], …
1
列で統計が作成されないようにする方法は？
統計を作成または更新したくない列のあるテーブルがあります。クエリオプティマイザーがその列の統計ヒストグラムではなく主キーの統計の密度を使用するように強制すると、より優れた結合カーディナリティの推定値が得られます。自動更新と自動作成の統計はデータベースレベルでオンになっており、変更できません。 統計の作成を防ぐための代替案を提案したい場合、テーブルは何千もの異なるクエリによって参照されるビューで使用されることに留意してください。実行されるクエリを制御できません。 私の最初の戦略は、NOCOMPUTEとSAMPLE 0 ROWSオプションで列の統計を作成することでした。SQL Serverは、統計オブジェクトが既に存在する列に統計を自動的に作成しないという印象を受けましたが、これは開発サーバーとQAサーバーで発生しています。 の新しい統計情報が作成されましたCOL_GROUP。私のNORECOMPUTE統計は更新されませんでした。統計が作成された理由はわかりませんが、クエリを実行してそれをトリガーすることはできませんでした。 SQL Serverが1つの列の統計を自動的に作成しないようにする方法はありますか？私のテーブルには2つの列しかないので、1つのテーブルで自動統計が作成されないようにする解決策でも問題は解決します。 トレースフラグ4139および2371は、違いが生じる場合に備えてオンになっています。 テーブル構造を試してみたい場合は、以下の表データとサンプルデータを含めました。 CREATE TABLE X_NO_COLUMN_STATS( [COL_USER] [varchar](256) NOT NULL, [COL_GROUP] [int] NOT NULL, CONSTRAINT [PK_X_NO_COLUMN_STATS] PRIMARY KEY CLUSTERED ( [COL_USER] ASC, [COL_GROUP] ASC )WITH (DATA_COMPRESSION = PAGE) ); -- prevent stats from being updated on COL_GROUP CREATE STATISTICS [X_NO_COLUMN_STATS__COL_GROUP] ON X_NO_COLUMN_STATS …
1
SQL Server 2016の不適切なクエリプランにより、1週間に1回DBがロックされる
1週間に1度、過去5週間、ほぼ同じ時刻（早朝、人々が使用し始めたときのユーザーアクティビティに基づく場合があります）、SQL Server 2016（AWS RDS、ミラーリング）は多くのタイムアウトを開始しますクエリ。 すべてのテーブルの統計を更新すると、常にすぐに修正されます。 初回以降、すべてのテーブルのすべての統計を（毎週ではなく）毎晩更新しましたが、それでも起こりました（更新統計が実行されてから約8時間後ですが、毎日実行されるわけではありません）。 前回、クエリストアを有効にして、どの特定のクエリ/クエリプランであるかを確認できるかどうかを確認しました。私はそれを1つに絞り込むことができたと思います： そのクエリを見つけた後、この頻繁に使用されないクエリから欠落している推奨インデックスを追加しました（ただし、頻繁に使用される多くのテーブルに影響します）。 不適切なクエリプランは、インデックススキャンを実行していました（1万行のみのテーブルで）。同じスキャンを実行するために使用されたミリ秒単位で返された他のクエリプラン。新しいインデックスを作成した後の最新のクエリプランは、シークのみを行います。しかし、そのインデックスがなくても、99％の時間で数ミリ秒以内に戻りましたが、毎週、40秒以上かかりました。 タイムアウトする悪いもの：http : //brentozar.com/pastetheplan/?id=rymaWt56e タイムアウトしない以前の計画：http : //brentozar.com/pastetheplan/?id=HyN7ftcpe 新しいインデックスを使用した最新の計画：http : //brentozar.com/pastetheplan/?id=ryLuGKcag これは、2012年からSQL Server 2016に移行した後に発生し始めました。 DBCC CHECKDBはエラーを返しません。 新しいインデックスは問題を修正し、再び悪い計画を二度と選択しないようにしますか？ うまく機能する計画を「強制」する必要がありますか？ これが別のクエリ/プランで発生しないことを確認するにはどうすればよいですか？ これはより大きな問題の症状ですか？ 追加したばかりのインデックス： CREATE NONCLUSTERED INDEX idx_AppointmetnAttendee_AttendeeType ON [dbo].[AppointmentAttendee] ([UserID],[AttendeeType]) CREATE NONCLUSTERED INDEX [idx_appointment_start] ON [dbo].[Appointment] ( [ProjectID] ASC, [Start] ASC ) INCLUDE ( [ID], …
1
SQL Serverは、述語が相関していることをどのように知っていますか？
：診断しながら、SQL Server 2008 R2のが悪いカーディナリティ推定（シンプルインデックスにもかかわらず、最新の統計情報など）ので、貧弱なクエリ計画を照会し、私はおそらく関連のKBの記事見つけ クエリを実行するとパフォーマンスの低下：FIXをSQL Server 2008またはSQL Server 2008 R2またはSQL Server 2012の相関AND述語を含む KB記事の意味は「相関」によって推測できます。たとえば、述語＃2と述語＃1は、主に同じ行を対象としています。 しかし、SQL Serverがこれらの相関関係をどのように認識しているかはわかりません。テーブルには、両方の述語の列を含む複数列のインデックスが必要ですか？SQLは統計を使用して、ある列の値が別の列と相関しているかどうかを確認しますか？または、他の方法が使用されていますか？ 私はこれを2つの理由で尋ねています： この修正プログラムを使用してどのテーブルとクエリが改善される可能性があるかを判断するには ＃1に影響を与えるためにインデックス作成、統計などで何をすべきかを知るため
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.