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

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

1
SQL Serverが複合列統計ヒストグラムを実行しないのはなぜですか？
SQL Serverには「マルチカラム統計」と呼ばれるものがありますが、それが意味するものとは異なります。 次のサンプルテーブルを見てみましょう。 CREATE TABLE BadStatistics ( IsArchived BIT NOT NULL, Id INT NOT NULL IDENTITY PRIMARY KEY, Mystery VARCHAR(200) NOT NULL ); CREATE NONCLUSTERED INDEX BadIndex ON BadStatistics (IsArchived, Mystery); これで、2つの統計が2つのインデックスで作成されています。 BadIndexの統計： +--------------+----------------+-------------------------+ | All density | Average Length | Columns | +--------------+----------------+-------------------------+ | 0.5 | 1 | IsArchived …
3
統計の自動更新をFalseに設定する理由
幅広い買収プロジェクトの一環として、SQL Serverのインスタンスを約20継承しました。私はパフォーマンスを評価している最中であり、メンテナンスプランの実装方法が気に入らない。 毎日のブランケットインデックスの再構築（これを処理できます）と、統計の毎日の手動更新が表示されています。 データベースの約半分は、統計の自動更新= Falseに設定されています。理由は、「パフォーマンスの問題」を減らすことだと言われていること以外は明確ではありません... 私は常にこれをTrueに設定するベストプラクティスを考え、これに取り組みました。この設定がTrueの場合、手動更新は必要ないと感じました。私が間違っている？ 誰もがこれをFalseに設定することの利点を説明できますが、代わりに毎日手動で更新することはできますか？ 一部のデータベースはトランザクション性が高い（1日あたり数百万の挿入、削除、更新）データベースもあります。その他のデータベースはトランザクション率が低く、一部はすべて読み取り専用です。Auto Update設定がFalseに設定されているのに、韻や理由はありません。宝くじのようです。
2
SQL Serverサンプルの統計更新では、昇順キー列で最も高いRANGE_HI_KEYが欠落しています
統計のサンプリングがどのように機能するか、およびサンプリングされた統計の更新に対して以下の動作が期待されるかどうかを理解しようとしています。 数十億行の日付で分割された大きなテーブルがあります。分割日は前の営業日であり、昇順のキーです。前日のデータのみをこのテーブルにロードします。 データの読み込みは夜間に実行されるため、4月8日金曜日に7日目のデータを読み込みました。 実行するたびに、統計を更新しますが、ではなくサンプルを使用しFULLSCANます。 たぶん私はナイーブですが、SQL Serverが範囲内の最高のキーと最低のキーを識別して、正確な範囲サンプルを確実に取得することを期待していました。この記事によると： 最初のバケットの場合、下限は、ヒストグラムが生成される列の最小値です。 ただし、最後のバケット/最大値については言及していません。 サンプリングされた統計の更新が8日の朝に行われたため、サンプルは表（7日）で最も高い値を逃しました。 前日のデータに対して多くのクエリを実行したため、カーディナリティの推定が不正確になり、多くのクエリがタイムアウトしました。 SQL Serverはそのキーの最高値を特定し、それを最大値として使用するべきではありませんRANGE_HI_KEYか？それとも、これを使用しない場合の更新の制限の1つにすぎFULLSCANませんか？ バージョンSQL Server 2012 SP2-CU7。OPENQUERYSQL ServerとOracleの間のリンクサーバークエリの数値を切り捨てていたSP3の動作が変更されたため、現在アップグレードできません。
1
統計を更新するときにサンプリングはどのように機能しますか？
私はいくつかの巨大なテーブルを持っています。毎週のメンテナンスプランを使用して、統計が最新であることを確認したいと思います。 ただし、これには時間がかかりすぎます。 指定した場合 WITH SAMPLE 50 PERCENT SQL Serverは次にサンプルを行います： ページの最初の50％ 他のすべてのページ または他の戦略？ BOLはこれについて明確ではありません。
1
1日を通してランダムに統計が消える/空になる
SQL Server 2017（CU9）データベースを使用していますが、これは、インデックス統計に関連していると思われるパフォーマンス関連の問題をいくつか示しています。トラブルシューティング中に、統計が更新されていないことを発見しました（DBCC SHOW_STATISTICSがすべてのNULL値を返すことを意味します）。 影響を受けるテーブルでUPDATE STATISTICSを実行し、SHOW_STATISTICSが昨日の午後4時に実際の値を返すことを確認しました。今朝8:00 AMに統計は再び空になりました（NULL値を返します）。 クライアントには、毎日午前4:00に実行するようにスケジュールされたメンテナンスジョブがあり、データベースのインデックスを再作成してから、データベース全体に対してsp_updatestatsを実行します。統計が午前4時にプロファイラートレースで更新されることを確認しました。 なぜ統計が空になるのか途方に暮れていますが、それは4:00 AMに実行されているメンテナンスジョブですか？このバージョンのSQL Serverで気付いていないバグはありますか？ よろしくお願いします。 より詳しい情報： 自動統計更新が有効になっています。 統計の自動更新を非同期で無効にします。 増分統計の自動作成が無効になっています。 スクリプトの再インデックス（難読化）： USE DBNAME; DECLARE @CERTENG_Lock INT DECLARE @WebSite_Control_ProcessRunning_Lock INT DECLARE @WebSite_Control_Disabled_Lock INT DECLARE @LogMessage VARCHAR(1024) SELECT @CERTENG_Lock = Lock FROM application.CERTENG_Lock SELECT @WebSite_Control_Disabled_Lock = MAX(CAST(Disabled AS INT)), @WebSite_Control_ProcessRunning_Lock = MAX(CAST(ProcessRunning AS INT)) FROM application.WebSite_Control …
1
本番サーバーでsp_updatestatsを実行すると、どのような影響がありますか？
運用sp_updatestats環境のSQL Serverで実行しても安全ですか？ または、SQLサーバーのすべての統計を更新すると、どのような影響がありますか？SQLサーバーを実行中に「チョーク」して、ユーザーにタイムアウトやその他の問題を引き起こすことはできますか？
1
STATISTICS_NORECOMPUTEの使用の妥当性
最近、いくつかの興味深いインデックスの問題がある一連のデータベースの保守に携わってきました。私を最も悪化させるものの1つは、開発、テスト、モデル、および生産マシン間のインデックスの違いです。違いによりクエリのチューニングが難しくなるため、クエリの同期は私の最初のプロジェクトの1つです。 テスト環境とモデル環境を比較したところ、モデル環境のほとんどのインデックスがSTATISTICS_NORECOMPUTE設定されているのONに対し、テスト環境のインデックスはそうではないことに気付きました。すべての環境で、すべてのデータベースの統計を更新する夜間ジョブがあります。 私はこれまでに対処したことがないSTATISTICS_NORECOMPUTEので、ここに私の質問があります。この設定を扱う際のベストプラクティスはありますか？1日の終わりに統計の更新を行っている場合STATISTICS_NORECOMPUTE、すべての環境ですべてのインデックスをオンにするのが最善ですか？それとも、正当な理由がないのですか？ 編集：私はここでこの件に関するキンバリートリップのブログの1つを見つけましたが、それSTATISTICS_NORECOMPUTEはせいぜい控えめに使用する必要があることを示唆しているようです。しかし、私はまだそれをグローバルにオフにすることを心配しています。誰かがこれを試しましたか、そして彼らは何を経験しましたか？
1
パーセンタイルを計算するための高速な一般的な方法
PostgreSQLでソートされていない列のn> 1パーセンタイルを検索したい。たとえば、20、40、60、80、100パーセンタイル。 明白な解決策は、列を数えて並べ替えてから調べますが、もっと良い解決策を期待しています。何か案は？ PS私はMySQLの良い解決策を見つけましたが、それをpsqlに変換できません
1
中央値、モード、パーセンタイル、およびOLAP
私は頭をOLAPに巻き込もうとしている初心者ですが、いくつか質問があります。 質問1： OLAPキューブは中央値、モード、パーセンタイルを格納できますか？ 質問2：ユーザー作成のMDXクエリは、行レベルのデータの概要を返すことができますか？（例：％トランザクション> $ 100）。または、キューブデザイナーはこれをキューブに追加する必要がありますか？ 質問3：行レベルのデータにアクセスするためのメカニズムを提供するOLAP製品はありますか？どっち？ 当社のIT部門は、特定のMS Analsis Services ROLAPキューブでどのような問題が発生しているかについてのフィードバックを求めています。その背後にあるリレーショナルデータベースへのアクセス権がないため、現在キューブ内のメジャーとして使用できない計算を実行する必要があります。 私にこの権利があるかどうか見てみましょう。 キューブは、カウント、平均、比率、標準偏差の統計を提供できます。 キューブデザイナが提供するメジャーで特定の統計が提供されていない場合、MDXクエリを記述してそれを取得できますか？または、行レベルのデータから事前計算するためにキューブを変更する必要がありますか？ キューブは、中央値、モード、パーセンタイルなどの統計を提供できません。これらの統計は適切に集計されないためです。 Leland WilkinsonのThe Grammar of Graphicsと、Data MiningとOLAPに関する彼の章を読んでいると彼は言う これらの[キューブ操作]は、カウント、平均、比率、標準偏差などの統計でうまく機能します。サブクラスの単純な集計は、和、二乗和、および線形関数で結合されて基本的な要約統計量を生成する他の項を操作することによって計算できます。 これらの統計の集計はそれらの集計の統計ではないため、中央値、モード、パーセンタイルなどの統計では正しく機能しません。たとえば、中央値の中央値は、集計の中央値ではありません。 彼は続けて追加します： しかし、より洗練されたROLAPモデルが最近登場しました。いくつかのテクノロジーを通じて、統計アルゴリズムがリレーショナルモデルを通じて生データにリアルタイムでアクセスできるようにすることができます。このアプローチは、データキューブなどの構造によって提供される固定集計よりも有望です。 このアーキテクチャの最もエレガントな形式では、アプリケーションはリモート接続を要求して、データ処理方法に関する情報を提供し、返された情報に応じて適切なアクションを実行できます。この形式では、コンポーネントアーキテクチャは、分散コンピューティングの真の期待、つまりサイト、オペレーティングシステム、または言語に依存しない設計と実行を実現できます。 それは2005年頃に書かれました。行レベルのデータアクセスを可能にするためにこの方法論を採用している製品を知っている人はいますか？
9 ssas  statistics  olap 
1
Azure SQL（SQL Server）データベースが一度に一定期間データIOで過負荷になるのはなぜですか？[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、データベース管理者のスタック交換のトピックになるようにします。 6か月前に閉鎖。 S2エディション（50 DTU）でAzure SQLデータベースを実行しています。サーバーの通常の使用では、通常、約10％のDTUがハングします。ただし、このサーバーは定期的にデータベースのDTU使用率を85〜90％に数時間送信する状態になります。その後、突然、通常の10％の使用量に戻ります。 この過負荷状態の間、アプリケーションからのサーバーに対するクエリは、まだ高速に動作しているようです。 サーバーをS2 =>何からでもスケーリングできます（たとえば、S3）=> S2。サーバーがハングしている状態をすべてクリアするように見えます。しかし、数時間後、同じ過負荷状態のサイクルが繰り返されます。私が気付いたもう1つの奇妙なことは、このサーバーをS3プラン（100 DTU）で24時間年中無休で実行した場合、この動作は観察されなかったことです。データベースをS2プラン（50 DTU）にダウンスケールした場合にのみ発生するようです。S3プランでは、私は常に5-10％DTU使用率で座っています。明らかに十分に活用されていません。 不正なクエリを探してAzure SQLクエリレポートをチェックインしましたが、実際に異常なものは見られず、期待どおりにリソースを使用してクエリが表示されます。 ここでわかるように、使用法はすべてData IOからのものです。ここでパフォーマンスレポートを変更して、MAXごとの上位のデータIOクエリを表示すると、次のようになります。 これらの長期にわたる要求を見ると、統計の更新が指摘されているようです。私のアプリケーションから実際には何も実行されていません。たとえば、クエリ16302には次のように表示されます。 SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000] FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM …
2
昇順の主要な問題-「静止」というブランドの主要な列-SQL Server
私はデータベースで実行速度の遅いクエリを調査しており、これが古典的な昇順キー問題であると結論付けました。新しい行がほぼ常に挿入され、DBから最新のデータを引き出すための特定のSQLが30分ごとに実行されるため、30分ごとに統計を更新する最初のオプションは、リソースを浪費する可能性があるようです。 したがって、私はトレースフラグ2389を調べましたが、これは原則的には役立つはずですが、先行列を昇順としてブランド化する必要があり、トレースフラグ2388を使用して（PK）インデックス統計を確認すると、先行列が実際に定常としてブランド化されます-同時に更新される他のテーブルのいくつかのPKインデックスのためです。 Stationaryのブランド化の結果に関するガイダンスはそれほど多くないようですが、KB2952101は、挿入の90％未満が古い最大値よりも大きい場合、それはStationaryとして分類されると述べています。すべての挿入は新しい送信であり、最初の列はbigint IDENTITY列であるため、挿入の100％は以前の最大値より大きくなければなりません。 それで、私の質問は、明らかに昇順であるのに、なぜ列がステーショナリーとしてブランド化されるのでしょうか？ 毎日実行中のSQLでこの問題を解決するための以前の試み（これは非常にうまく機能しました）により、このテーブルの統計を毎晩更新するジョブがセットアップされました。更新ではFULLSCANが実行されないため、サンプリングされたスキャンで新しい行が欠落することがあり、常に昇順で表示されるとは限りませんか？ これに影響を与える可能性があると私が考えることができる他の唯一のことは、特定の期間を超えて行を削除する舞台裏でアーカイブジョブが実行されていることです。これはブランディングに影響を与える可能性がありますか？ サーバーはSQL Server 2012 SP1です。 更新：別の日、別の統計情報の更新-同じ静止したブランド。前回の統計更新以降、28049の新しい挿入がありました。各行には、挿入されたときのタイムスタンプがあるため、timestamp <'20161102'であるテーブルからmax（id）を選択すると23313455が得られます。 これらの違いは28049の新しい挿入です。ご覧のように、すべての新しい挿入には新しい昇順キーが（期待どおりに）与えられています。これは、先頭の列を固定ではなく昇順としてブランド化する必要があることを示しています。 同じ期間に、アーカイブジョブによって213,629行が削除されました（古いデータは徐々に消去されます）。行数の削減が定常的なブランディングに貢献する可能性はありますか？私はこれを以前にテストしたことがあり、それが何かの違いをもたらすようには見えませんでした。 更新2：別の日、別の統計が更新され、列に昇順のフラグが付けられます！これに影響する削除に関する理論に従って、私は削除と比較して挿入である更新のパーセンテージをチェックしました、そして昨日の13％は挿入でしたが、過去2日間の挿入は約12％を占めました。それが決定的なものになるとは思いません。 興味深いことに、このメインテーブルに挿入された各行に対して平均4行が挿入され、同時に統計が更新される関連テーブルで、IDENTITY PK列はまだ静止していますか？ 更新3：週末に追加の挿入物を取得します。今朝、リーディングコラムはステーショナリーに戻りました。前回の統計更新では、46840の挿入と34776の削除しかありませんでした。 繰り返しになりますが、興味深いことに、上記で説明した関連テーブルには、昇順というブランドの主要な列があります。これを説明できるドキュメントはありませんか？ 更新4：約1週間が経過しました。アーカイブジョブによりバックログがクリアされたため、挿入される行数の約3分の2を一貫して削除しています。統計は、すべて同じように比例して更新されているにもかかわらず、関連するテーブル全体で混合結果を示しています。1つは定常を示し、2つは上昇を示しています。
5
SQL Selectの実行に時間がかかりすぎる
これは一時テーブルからの単純な選択であり、既存のテーブルを主キーに結合したままにします。結合されたテーブルを参照するトップ1を使用する2つのサブ選択があります。 コードで： SELECT TempTable.Col1, TempTable.Col2, TempTable.Col3, JoinedTable.Col1, JoinedTable.Col2, ( SELECT TOP 1 ThirdTable.Col1 -- Which is ThirdTable's Primary Key FROM ThirdTable WHERE ThirdTable.SomeColumn = JoinedTable.SomeColumn ) as ThirdTableColumn1, ( SELECT TOP 1 ThirdTable.Col1 -- Which is also ThirdTable's Primary Key FROM ThirdTable WHERE ThirdTable.SomeOtherColumn = JoinedTable.SomeColumn ) as ThirdTableColumn2, FROM …
1
この列で自動作成された統計が空になるのはなぜですか？
情報 私の質問は、ヒープである適度に大きなテーブル（約40GBのデータスペース）に関するもの です（残念ながら、アプリケーションの所有者はテーブルにクラスター化インデックスを追加できません） ID列（ID）に自動作成された統計が作成されましたが、空です。 統計の自動作成と統計の自動更新がオンになっています テーブルで変更が行われました 更新されている他の（自動作成された）統計があります インデックスによって作成された同じ列に別の統計があります（重複） ビルド：12.0.5546 重複する統計が更新されています： 実際の質問 私の理解では、まったく同じ列（重複）に2つの統計がある場合でも、すべての統計を使用でき、変更が追跡されるので、なぜこの統計が空のままなのですか？ 統計情報 DB統計情報 テーブルサイズ 統計が作成される列情報 [ID] [int] IDENTITY(1,1) NOT NULL ID列 select * from sys.stats where name like '%_WA_Sys_0000000A_6B7099F3%'; 自動作成 別の統計に関する情報を取得する select * From sys.dm_db_stats_properties (1802541555, 3) 私の空の統計と比較して： 「生成スクリプト」からの統計+ヒストグラム： /****** Object: Statistic [_WA_Sys_0000000A_6B7099F3] Script Date: 2/1/2019 10:18:19 AM ******/ …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.