1

実稼働システムのパフォーマンスの問題を調査しています。SQL の 1 つの部分は、実行回数が非常に多く、優れたパフォーマンスと相まって、ノードあたり 1 秒あたり 20 回以上のピークに達し、実行時間は約 1 秒でした。これは、V$SQL に表示される実行/フェッチの合計、またはアプリケーションの予想される動作とは一致しません。

いくつかの情報

  • 限られたパフォーマンス ツールキットがあります。このデータは 1 時間の統計パック スナップからのものです。標準版を実行しているため、AWR はありません。
  • 2 ノードの 11g RAC インストールで実行されています。
  • 昨日の数字を見ると、ノードあたり 9 時間で 500,000 回以上の実行が見られます。V$SQL は、8 日前の最初のロード時間から約 50,000 回の実行を示しています。
  • 危険なSPREPORTではなく、statspackテーブルを直接クエリすると、一致するデータが得られます。
  • 1 時間あたりの実行数は急増しています。1 日 1 ～ 2 回で、各ノードの平均の 10 ～ 20 倍です。時間はノードごとに異なります。通常の数値は、アプリの本来の動作から少し高く聞こえますが、許容範囲内です。

開発マネージャーは、アプリケーションがこのように動作することはあり得ないと主張していますが、これは合理的に聞こえます。しかし、レポートの不一致の原因は何でしょうか?

statspack が誤動作している可能性がありますが、なぜ定期的に発生するのでしょうか? RAC の問題でしょうか (私は RAC の初心者です)。

原因やさらなるトラブルシューティングのヒントに関する提案はありますか?

4

2 に答える 2

1

GV$SQLの代わりに使用V$SQLして、すべてのノードからの結果を表示します。

データはGV$SQLいくつかの理由で期限切れになる可能性があることに注意してください。誰かが実行すると、ほとんどのデータが削除されますalter system flush shared_pool;。統計の変更によりカーソルが無効になると、値が消えることがあります。また、おそらく共有プールが小さすぎるか、その他の大量のアクティビティがあるために、値が期限切れになると値が消える可能性があります。

標準版や統計パックの経験がありません。ただし、 orasashなどのオープン ソース オプションを検討することもできます。

于 2018-04-24T23:47:49.470 に答える