Oracleデータベース統計を実行する頻度は？
あなたの経験では、Oracleデータベースの統計をどのくらいの頻度で実行する必要がありますか？開発者のチームは最近、統計が2か月半も運用ボックスで実行されていないことを発見しました。私には長い時間のように思えますが、私はDBAではありません。
私の最後の仕事では、週に1回統計を実行しました。記憶が正しければ、木曜日の夜にスケジュールを立て、金曜日に、DBAは予想外の長時間のクエリの実行を注意深く監視しました。 （金曜日は、コードがリリースされた直後であることが多く、交通量がかなり少ない傾向があったために選ばれました。）悪いクエリを見つけた場合、より良いクエリプランを見つけて保存し、予期しない変更が起こらないようにしました。 。 （Oracleにはこれを自動的に行うツールがあり、最適化するクエリを指定して実行します。）
多くの組織では、不適切なクエリプランが突然表示されることを恐れて、統計の実行を避けています。しかし、これは通常、クエリプランが時間とともに悪化することを意味します。そして、統計を実行すると、多くの問題が発生します。結果としてこれらの問題を修正するためのスクランブルは、統計を実行することの危険性に対する彼らの恐れを確認します。しかし、統計を定期的に実行し、想定どおりに監視ツールを使用し、問題が解決した場合は、頭痛が少なくなり、一度に遭遇することはありません。
Oracle 11gの統計はデフォルトで自動的に収集されるため。
Oracle Databaseのインストール時には、2つのスケジューラのウィンドウが事前定義されています。
- WEEKNIGHT_WINDOWは午後10時から始まります。毎週月曜日から金曜日の午前6時に終了します。
- WEEKEND_WINDOWは土曜日と日曜日の終日をカバーします。
統計が最後に収集されたのはいつですか？
SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.
自動統計収集のステータス？
SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';
Windowsグループ？
SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;
ウィンドウスケジュール？
SELECT window_name, start_time, duration FROM dba_autotask_schedule;
このスキーマのデータベース統計を手動で収集します。
EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.
すべてのスキーマのデータベース統計を手動で収集してください！
-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;
データが「大幅に」変更されるたび。
テーブルが1行から200行になった場合、それは大きな変化です。テーブルが100,000行から150,000行に変わっても、それほど大きな変化ではありません。テーブルが、一般にクエリされる列Xのすべての値が同じ1000行から列Xのほぼ一意の値を持つ1000行に移行する場合、これは大きな変更です。
統計には、アイテム数と相対頻度に関する情報が格納されます。これにより、特定の条件に一致する行数を「推測」することができます。推測が間違っている場合、オプティマイザーはvery準最適なクエリプランを選択できます。
使用しているOracleバージョンは何ですか？ Oracle 10を参照するこのページを確認してください。
http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm
それは言います：
統計を収集するための推奨アプローチは、Oracleが統計を自動的に収集できるようにすることです。 Oracleは、すべてのデータベースオブジェクトの統計を自動的に収集し、定期的にスケジュールされたメンテナンスジョブでそれらの統計を維持します。
Oracleの10g以降のバージョンでは、オプティマイザが「適切な」実行計画を決定するために、テーブルとインデックスに関する最新の統計が必要です。統計を収集する頻度は、注意を要する呼び出しです。これは、アプリケーション、スキーマ、データレート、ビジネスプラクティスによって異なります。古いバージョンのOracleと下位互換性があるように作成された一部のサードパーティ製アプリは、新しいオプティマイザーではうまく機能しません。これらのアプリケーションでは、dbがルールベースの実行プランに戻るように、テーブルに統計情報がないことが必要です。ただし、平均的には、古い統計を持つテーブルで統計を収集することをお勧めします。テーブルを監視するように設定し、その状態をチェックして、失効したかどうかを分析させることができます。多くの場合それで十分ですが、いつかはそうではありません。本当にデータベースに依存します。私のデータベースには、OLTPテーブルがあり、パフォーマンスを維持するために毎晩の統計収集が必要です。他のテーブルは週に1回分析されます。大規模なdwデータベースでは、全体的なデータベースの負荷とパフォーマンスに影響を与えずに定期的に分析するには大きすぎるため、正しい答えは、アプリケーション、データの変更、およびビジネスニーズに依存します。
Oracleが支援する大規模なマルチユーザープランニングシステムを管理していたとき、DBAは統計を収集する毎週の仕事をしていました。また、統計に影響を与えるか、統計の影響を受ける可能性がある重要な変更をロールアウトした場合、物事を追いつくためにジョブのサイクルを強制的に実行します。
新鮮な統計がクエリプランの望ましくない変更を引き起こすリスクと、古い統計自体がクエリプランを変更するリスクとのバランスを必ずとってください。
テーブルISSUEと列CREATE_DATEがあり、列の値が多かれ少なかれ単調に増加するバグデータベースがあるとします。ここで、この列にヒストグラムがあり、この列の値が2008年1月1日から2008年9月17日の間に均一に分布していることをOracleに伝えます。これにより、オプティマイザーは、先週作成されたすべての問題（9月7日から13日）を探していた場合は返品してください。ただし、アプリケーションが引き続き使用され、統計が更新されない場合、このヒストグラムの精度は低下します。そのため、オプティマイザは、「先週作成された問題」のクエリが時間の経過とともに精度が低下することを期待し、最終的にOracleがクエリプランを否定的に変更する可能性があります。
一般に、データベースで一括挿入や大きなデータ変更が頻繁に発生するなど、強力な理由がない限り、データベース全体で頻繁に統計を収集することはお勧めしません。この頻度でデータベースの統計を収集すると、クエリの実行プランが新しい貧弱な実行プランに変更される場合があります。新しい貧弱なプランの影響を受けるすべてのクエリを調整しようとすると、時間がかかる場合があります。テストデータベースの新しい統計、またはそのための時間や人手がない場合は、少なくとも新しい統計を収集する前に元の統計をバックアップしてフォールバックプランを維持する必要があります。新しい統計を作成してからクエリが期待どおりに実行されなかった場合、元の統計を簡単に復元できます。
元の統計情報をバックアップして新しい統計情報を収集し、新しい統計情報を収集した後に予期したとおりに動作しなかった場合に元の統計を復元するために使用できるSQLコマンドを提供するのに役立つ非常に便利なスクリプトがあります。このリンクでスクリプトを見つけることができます： http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html
データウェアハウスタイプのシステムの場合、統計情報をまったく収集せず、動的サンプリング（optimizer_dynamic_samplingをレベル2以上に設定）に依存することを検討できます。