データベースパフォーマンスの調整

お客様は通常、次の上位10のチューニングの問題に直面します。

• 不正な接続管理： 開発者は、アプリケーションでデータベースに接続するためのコードを記述したり、クエリを実行してデータベースからデータをフェッチしたりします。データがフェッチされ、それ以上何も必要なくなったら、コードはデータベースへの接続を閉じる必要があります。ただし、これは多くの場合発生しないため、データベース内の非アクティブなセッションの数が増加します。これらのセッションでは、他のアクティブな接続に使用された可能性のある貴重なリソースを使用します。

• カーソルと共有プールの不適切な使用： カーソルは、開発者の武器庫にあるツールであり、ほとんど使用されていません。カーソルがないと、Oracleは実行するたびにコードをハード解析する必要があります。これは、繰り返し実行されるSQLクエリのパフォーマンスに大きな影響を与えます。 DBAは、インスタンス効率のパーセンテージ-実行して％を解析するを調べることで、この問題を特定できます。 AWRレポートセクション。

• 不正なSQL： SQLクエリの記述方法（データをフェッチするための結合条件を使用）は、実行後のSQLのパフォーマンスに大きく影響します。大きなテーブルの全表スキャンは避けてください。 SQLの準備ができたら、開発者とDBAは、そのSQLについて説明プランを実行して、データベースでSQLを実行するコストを理解する必要があります。カーソル、バインド変数、およびインデックスを使用することで、効率を上げることができます。

• 非標準の初期化パラメータの使用： DBAは、常に標準または推奨の初期化パラメーターのみを使用する必要があります。非標準の初期化パラメータは、Oracle Service Request（SR）によって提案された場合にのみ使用してください。

• データベースI/Oを間違える： データベースハードウェアを選択するDBAがデータベースを複数のディスクに分散し、ネットワークチームを巻き込んで、データベースサーバーからエンドユーザーにデータが行き来する速度について話し合う必要がある場合。 DBAは、ボトルネックやパフォーマンスの問題を回避するために、ネットワークスイッチとルーターの速度を考慮する必要があります。

• ログ設定の問題をやり直す： Oracleがクラッシュの場合にトランザクションをやり直すことができるように、やり直しバッファからのデータを格納するためにやり直しログが必要です。 REDOログのサイズが不十分な場合、データベースで複数のスイッチが発生し、パフォーマンスの問題が発生する可能性があります。これにより、アーカイブ生成の負荷も増加します。

• バッファキャッシュ内のデータブロックのシリアル化： これは、空きリストグループまたは元に戻るセグメントが不足しているために発生します。この状況は、アクティブユーザーのベースが多く、元に戻るセグメントが少ない挿入が多いデータベースで発生し、最終的にパフォーマンスの問題につながります。

• 全表スキャン： 説明プランを実行して、クエリの全表スキャンを確認します。通常、全表スキャンを実行するクエリは、不正なSQLdesignを反映します。これは、インデックスを使用し、必要なデータを絞り込むことで修正できます。まれに、特に小さなテーブルの場合、全表スキャンが有益な場合があります。

• 再帰SQL： 再帰SQLは、正しく使用すれば開発者に恩恵をもたらす可能性がありますが、両刃の剣になる可能性があります。正しく行われると、出力が効率的に提供されます。そうしないと、データベースのパフォーマンスに大きな影響を与えます。

• ディスク内の並べ替え： ディスク内の並べ替えは、データベースにとって非常にコストのかかる作業です。これは、SQLの設計が不十分で最適化が不十分であることを示しています。この問題は、インスタンスアクティビティ統計–並べ替え（ディスク）で特定できます。 AWRレポートセクション。