| Oracle® Databaseパフォーマンス・チューニング・ガイド 12cリリース1 (12.1) B71276-05 |
|
 前 |
 次 |
最適なシステム・パフォーマンスは設計段階で決まり、その効果は使用しているシステムが存続するかぎり持続します。初期の設計段階でパフォーマンス問題を慎重に検討すると、本番環境でのチューニングが容易になります。
この章は次の項で構成されています:
コンピュータ・システムの規模が拡大して複雑になり、ビジネス・アプリケーションでのインターネットの役割が重要になるに従い、システムのパフォーマンスはますます重要になっています。オラクル社では、この状況にあわせて、設計およびパフォーマンスに関する長年の経験に基づいてパフォーマンス方法論を作成しました。この方法論は、システム・パフォーマンスを大幅に向上させる、明瞭で簡潔なアクティビティについて説明したものです。
パフォーマンス計画は、その効果によって異なります。業務システムや意思決定支援システムなどのようにシステムの目的が異なると、求められるパフォーマンス・スキルも異なります。このマニュアルでは、データベース設計者、管理者またはパフォーマンス・エンジニアが重点的に考慮する必要がある事柄について説明します。
システムのパフォーマンスは、設計してシステムに組み込むものです。偶然にパフォーマンスが良くなるわけではありません。パフォーマンスの問題は、通常、システム・リソースの競合、またはシステム・リソースを使い切ったことが原因で発生します。システム・リソースを使い切ると、システムを拡張してパフォーマンス・レベルを向上させることができません。ここで説明する新しいパフォーマンス方法論は、データベースの慎重な計画と設計に基づいており、システム・リソースを使い切ったことが原因で停止時間が発生するのを防止します。リソースの競合を除去することによって、ビジネス要件を満たすレベルまでシステムをスケーラブルにすることができます。
高性能のプロセッサ、メモリーおよびディスク・ドライブが比較的安価に入手できることから、安易なシステム・リソースの追加購入によって、パフォーマンスを改善しようとする傾向があります。多くの場合、新しいCPU、メモリーまたはディスク・ドライブの増設によって、確かにパフォーマンスは一時的には改善されます。しかし、ハードウェア増設によるパフォーマンスの改善は、目の前の問題の短期的解決にすぎません。アプリケーションに対する需要と負荷が増加し続けると、すぐに同じ問題に直面する可能性があります。
状況によっては、ハードウェアを増設してもシステムのパフォーマンスがまったく改善されない場合もあります。システム設計が不適切な場合、追加のハードウェアをいくつ割り当ててもパフォーマンスは改善されません。ハードウェアを追加購入する前に、アプリケーション内にシリアライズやシングル・スレッドがないことを確認してください。長期的には、各ビジネス・トランザクションで使用する物理リソース数の観点からみて、アプリケーションの効率を上げるほうが一般的には効果的です。
スケーラブルという用語は、開発環境の様々な状況で使用されます。次の項では、アプリケーション設計者とパフォーマンス・エンジニアを対象にしたスケーラビリティについて説明します。
この項の内容は次のとおりです。
スケーラビリティとは、より多くのワークロードを処理するためのシステムの能力で、それと比例してシステム・リソースの使用が増大します。つまり、スケーラブルなシステムでは、ワークロードが2倍になると、使用するシステム・リソースも2倍になります。これは当たり前のようですが、システム内で競合が発生すると、元のワークロードに対し、リソースの使用が2倍よりも多くなる場合があります。
リソースの競合によってスケーラビリティが低くなる例を次に示します。
ユーザー数の増加に伴い、アプリケーションでかなりの同時実行性管理が要求される場合
ロック・アクティビティが増加した場合
データ整合性に関するワークロードが増加した場合
オペレーティング・システムのワークロードが増加した場合
データ量の増加に伴い、トランザクションでデータ・アクセスの増加が要求される場合
SQLと索引の不適切な設計が原因で、同じ戻り行数に対する論理I/O数が増加した場合
データベース・オブジェクトのメンテナンス時間が長くなったことで、可用性が低下した場合
アプリケーションのワークロードが増加してもこれ以上のスループットの向上は不可能という点までシステム・リソースを使い切った場合、そのアプリケーションは拡張性がありません。このようなアプリケーションでは、スループットが固定化し、レスポンス時間が長くなります。
リソースを使い切った例を次に示します。
ハードウェアを使い切った場合
大量トランザクションでの表スキャンによって、ディスクI/O不足が発生する場合
過剰なネットワーク・リクエストによって、ネットワークとスケジューリングにボトルネックが発生する場合
メモリー割当てによって、ページングとスワッピングが発生する場合
プロセスやスレッドの過剰な割当てによって、オペレーティング・システムのスラッシングが発生する場合
このことから、アプリケーション設計者は、ユーザー数やデータ量に関係なく同一リソースを使用するように設計し、限界を超える負荷をシステム・リソースに与えないようにする必要があります。
インターネット経由でアクセスできるアプリケーションでは、パフォーマンスや可用性の要件がさらに複雑になります。インターネット専用に設計および作成されたアプリケーションもありますが、一般会計アプリケーションなどの典型的なバック・オフィス・アプリケーションであっても、データの一部またはすべてをオンラインで利用できるようにすることが必要な場合があります。
インターネット時代のアプリケーションの特徴は、次のとおりです。
1日24時間、1年365日の可用性
同時ユーザー数が予測不可能で正確な把握が困難
容量の計画が困難
あらゆるタイプの問合せが選択可能
多層アーキテクチャ
ステートレスなミドルウェア
短い開発期間
最小限のテスト時間
図2-1は、需要が増大するときの典型的なワークロード成長曲線を示しています。アプリケーションは、ワークロードの増大に伴い拡張できる必要があります。また、増大する需要をサポートするためにハードウェアが追加されたときにも拡張できる必要があります。設計に失敗すると、ハードウェア・リソースの増設や再設計に関係なく、実装が限界に達する可能性があります。
アプリケーションは非常に短期間での開発が要求され、テストや評価の時間も限定されています。しかし、一般的に、不適切な設計は、後でシステムの再構築および再実装が必要になることを意味します。アーキテクチャや実装に既知の制限があるアプリケーションをインターネット上にデプロイした場合、ワークロードが需要予測を超過すると、実際に障害が発生する可能性があります。ビジネスの観点からは、低いパフォーマンスは顧客を失うことにつながります。Webユーザーの場合、7秒以内にレスポンスがないと、ユーザーの興味は二度と喚起できません。
多くの場合、新規の実装に移行するためにシステムを停止する間のコストも含めて、システムを再設計するコストは、最初からシステムを適切に構築する場合のコストを上回ります。ここでの教訓は単純明快です。開発の当初からスケーラビリティに留意して設計と実装を行うということです。
アプリケーションを作成するとき、設計者とアーキテクトは、可能なかぎり完全なスケーラビリティに近づけることを目指す必要があります。これは線形のスケーラビリティと呼ばれ、システムのスループットがCPUの数に比例するものです。
線形のスケーラビリティにすることは、設計者の制御の及ばない部分があるため、実際には不可能です。しかし、アプリケーションの設計や実装に可能なかぎりスケーラブルにしておくと、現在も、将来においても、ハードウェア・コンポーネントの拡張やCPUテクノロジの発展とともにパフォーマンス目標を達成できます。
線形のスケーラビリティを妨げる要因としては次のものが考えられます。
不適切なアプリケーションの設計、実装および構成
アプリケーションは、スケーラビリティに最も大きく影響します。次に例を示します。
スキーマ設計が不適切であると、SQLにコストがかかり、拡張性を持ちません。
トランザクション設計が不適切であると、ロックおよびシリアライズの問題が発生します。
接続管理が不適切であると、レスポンス時間が長くなり、システムの信頼性が低下します。
問題となるのは、設計のみではありません。アプリケーションの物理的な実装が弱点になる場合があります。次に例を示します。
システムが誤ったI/O方針のまま本番環境で使用される場合。
テスト時に生成された実行計画とは異なる実行計画が本番環境で使用される場合。
実行時のメモリーの解放を十分に考慮せずに、大量のメモリー割当てを行うメモリー集中型アプリケーションで、メモリーが過剰に使用される可能性がある場合。
非効率的なメモリー使用やメモリー・リークによって、動作中の仮想メモリー・サブシステムに高いストレスがかかる場合。このようなストレスは、パフォーマンスや可用性に影響を与えます。
ハードウェア価格の低下に伴い、どのハードウェア・コンポーネントについても容量計画が不適切で問題になるということは少なくなっています。ただし、容量が大きすぎると、システムでワークロードが増大したときに、スケーラビリティの問題が隠されてしまう場合があります。
ソフトウェア・コンポーネントの制限
すべてのソフトウェア・コンポーネントに、スケーラビリティおよびリソース使用上の制限があります。このことは、アプリケーション・サーバー、データベース・サーバーおよびオペレーティング・システムでも同様です。アプリケーションの設計では、ソフトウェアの処理能力を超えた要求をしないでください。
ハードウェアは、完全にはスケーラブルになりません。ほとんどのマルチプロセッサ・コンピュータでは、限られた数のCPUでほぼ線形の拡張性を達成できますが、ある数を超えると、CPUの追加でパフォーマンスが全体的には向上しても、その数に見合った向上はありません。CPUをさらに続けて追加していくと、ある時点からパフォーマンスは向上しなくなり、むしろ低下する場合もあります。この動作は、ワークロードとオペレーティング・システムの設定に深く関連しています。
注意:
前述の要因は、スケーラブルでないシステムのチューニングにおいてオラクル社のサーバー・パフォーマンス・グループが得た経験を基にしたものです。
システム・アーキテクチャには主に、ハードウェア・コンポーネントとソフトウェア・コンポーネントが含まれます。
今日の設計者とアーキテクトは、多層環境の各層でハードウェアのサイズ指定と容量計画を行う必要があります。バランスの取れた設計を実現するのは、アーキテクトの責任です。これは、橋の設計に似ています。橋の設計者は、橋に関する様々なペイロードや構造上の要件をすべて考慮する必要があります。橋の強度は、最も弱いコンポーネントの強度にしかなりません。このため、橋は、すべてのコンポーネントがその設計上の限界に同時に達するように、バランス良く設計されています。
次に、システムの主要なハードウェア・コンポーネントを示します。
CPU
CPUは1つ以上使用されており、その処理能力は、携帯端末に見られるような単純なCPUのものから高性能サーバーのCPUのものまで様々です。他のハードウェア・コンポーネントのサイズは、通常、システム上のCPUの倍数になります。
コンピュータに共通のハードウェア・コンポーネントがあるように、アプリケーションにも共通の機能コンポーネントがあります。ソフトウェアの開発を機能コンポーネントごとに分割することで、アプリケーションの設計やアーキテクチャがより理解しやすくなります。システムのコンポーネントの中には、アプリケーションの実装の高速化や、共通コンポーネントの再作成の防止のために購入された既成のソフトウェアによって実行されるものもあります。
ソフトウェア・コンポーネントとハードウェア・コンポーネントの違いは、ハードウェア・コンポーネントが1つのタスクしか実行しないのに対して、ソフトウェアはその1つ1つが様々なソフトウェア・コンポーネントの役割を実行できるということです。たとえば、ディスク・ドライブはデータの格納と取出ししか行いませんが、クライアント・プログラムはユーザー・インタフェースを管理し、ビジネス・ロジックを実行できます。
ほとんどのアプリケーションに、次に関するソフトウェア・コンポーネントが含まれています。
ユーザー・インタフェース
ユーザー・インタフェースは、アプリケーション・ユーザーの目に触れることが最も多いコンポーネントです。次のような機能があります。
ユーザーへの画面の表示
ユーザー・データの収集とビジネス・ロジックへのデータの転送
データ入力の検証
アプリケーションのレベル間または状態間のナビゲーション
ビジネス・ロジック
このコンポーネントは、アプリケーション機能の中心となるコア・ビジネス・ルールを実装します。このコンポーネントでのエラーは、修復に相当なコストを要する場合があります。このコンポーネントは、宣言型アプローチとプロシージャ型アプローチの組合せで実装されます。宣言アクティビティの例としては、一意キーと外部キーの定義があります。また、プロシージャ・ベースのロジックの例としては、値引計画の実装があります。
このコンポーネントの一般的な機能は、次のとおりです。
リレーショナル表構造へのデータ・モデルの移行
リレーショナル表構造での制約の定義
ビジネス・ルールを実装するプロシージャ型ロジックのコーディング
ユーザーのリクエストを管理するリソース
このコンポーネントは、すべてのソフトウェアに実装されます。ただし、アプリケーション設計の影響を受けるリクエストやリソースがある一方で、影響を受けないリクエストやリソースもあります。
マルチ・ユーザー・アプリケーションでは、ユーザー・リクエストによるリソース割当てのほとんどは、データベース・サーバーまたはオペレーティング・システムで処理されます。ただし、ユーザー数や使用パターンが不明または急増している大規模アプリケーションの場合、システム・アーキテクトはどのソフトウェア・コンポーネントも過負荷や不安定にならないように事前に対処する必要があります。
このコンポーネントの一般的な機能は、次のとおりです。
データベースとの接続管理
効率的なSQLの実行(カーソルとSQLの共有)
クライアント状態情報の管理
ハードウェア・リソース間でのユーザー・リクエストのロード・バランシング
ハードウェアおよびソフトウェア・コンポーネントの操作目標の設定
タスクの非同期実行のための永続キューイング
初期のシステム・アーキテクチャを構成する作業は、反復的な処理です。システム・アーキテクトは、予算やスケジュールの制約内でシステム要件を満たす必要があります。対話型ユーザーがデータベースの内容に基づいてビジネスの取引や意思決定を行うシステムの場合、ユーザー要件が主体のアーキテクチャになります。システム上に対話型ユーザーがほとんどいない場合は、プロセス主体のアーキテクチャになります。
対話型ユーザー・アプリケーションの例を、次に示します。
経理アプリケーションや会計帳簿アプリケーション
注文入力システム
電子メール・サーバー
Webベースの小売販売アプリケーション
取引システム
プロセス主体のアプリケーションの例を、次に示します。
公共料金支払システム
不正検出システム
ダイレクト・メール
多くの点で、プロセス主体のアプリケーションのほうが、ユーザー・インタフェース要素がないのでマルチ・ユーザー・アプリケーションよりも設計が容易です。しかし、目的がプロセス指向であるため、大量のデータや様々な成功要因の扱いに慣れていないシステム・アーキテクトは混乱することがあります。プロセス主体のアプリケーションでは、ユーザー・ベースのアプリケーションとデータ・ウェアハウス・アプリケーションの両方で使用されるスキルを利用します。したがって、このマニュアルでは、対話型ユーザー向けの新しいシステム・アーキテクチャについて、重点的に説明します。
注意:
システム・アーキテクチャの生成は、決定論的なプロセスではありません。ビジネス要件、テクノロジの選択肢、既存のインフラストラクチャやシステム、さらに予算や人員などの実際の物理リソースなどを慎重に考慮する必要があります。
次の質問事項は、システム・アーキテクチャの完全なガイドではありませんが、システム・アーキテクチャに関する思考力を高めます。これらの質問では、アーキテクチャ、実装しやすさ、さらにシステムの全体的なパフォーマンスと可用性に対して、ビジネス要件がどのように影響を及ぼすかを示しています。次に例を示します。
ほとんどのアプリケーションは、次のいずれかのカテゴリに該当します。
あまり使用されない専用のコンピュータでごく少数のユーザーをサポートする場合
このタイプのアプリケーションでは、通常、ユーザーは1人です。この場合のアプリケーション設計の重点は、レスポンス時間を短くし、しかもアプリケーションの管理を最小限に抑えることで、シングル・ユーザーの生産性をできるだけ高くすることにあります。このようなアプリケーションのユーザーは、相互に介入することはほとんどなく、リソースの競合も最小限に抑えられます。
中規模から大規模の数の社内ユーザーが共有アプリケーションを使用する場合
このタイプのアプリケーションでは、ユーザー数は、社内でシステムを実際に使用してビジネスを行う従業員の数に限定されます。したがって、ユーザー数は予測可能です。ただし、信頼性のあるサービスを提供することが、ビジネスにとっては必須です。ユーザーはリソースを共有する必要があるため、アプリケーションを設計する際には、大量のシステム・ロード下でのレスポンス時間、各セッションで使用されるリソースの増加および将来の拡張のための余地に重点を置きます。
無数のユーザーがインターネット上に存在する場合
このタイプのアプリケーションでは、すべてのシステム・コンポーネントがそれぞれの限界を超えないように設計する必要があります。ボトルネックが作成されると、システムが停止するか不安定になります。このようなアプリケーションでは、複合的なロード・バランシング、ステートレスなアプリケーション・サーバーおよび効率的なデータベース接続管理が必要です。さらに、システムの過負荷が原因でユーザー・リクエストが満たされない場合にユーザーがフィードバックを得られるように、統計情報およびガバナーを使用します。
ユーザー・インタフェースの選択肢は、単純なWebブラウザからカスタム・クライアント・プログラムまで様々です。
ユーザー間の距離は、ネットワーク待機時間に対処するためのアプリケーションの設計方法に影響します。また、ユーザーの位置は、1日の中でピークの時間帯、つまりバッチ機能やシステム・メンテナンス機能を実行できない時間帯の決定にも影響を与えます。
ネットワーク速度は、データ量に影響を与え、アプリケーション・サーバーやデータベース・サーバーとのユーザー・インタフェースの対話特性にも影響を与えます。対話主体のユーザー・インタフェースでは、キー・ストロークごとまたはフィールド・レベルの妥当性チェックごとにバックエンド・サーバーと通信します。対話が少ないインタフェースは、画面ごとに送受信を行うモデルで機能します。通信速度が遅いネットワークでは、対話主体のユーザー・インタフェースを使用しても高速のデータ入力速度は実現できません。
ユーザーがアクセスするデータ量はどれくらいで、そのデータの中で読取り専用データが占める割合はどの程度ですか。
オンラインでの問合せのデータ量は、表や索引の設計からプレゼンテーション層にいたる設計のあらゆる局面に影響を与えます。データベースのサイズによってユーザーのレスポンス時間が影響されないように設計する必要があります。アプリケーションが主として読取り専用の場合は、アプリケーション・サーバーのローカル・キャッシュへのレプリケーションとデータ配分が有効な選択肢になります。また、これにより、主要トランザクション・サーバーでのワークロードが削減されます。
ユーザー・タイプに関する考慮が重要です。ユーザーが経営者で、瞬時に意思決定を行うために正確な情報を必要とする場合は、ユーザー・レスポンス時間の妥協は許されません。データ入力操作を行うユーザーなど、他のタイプのユーザーの場合は、それほど高いパフォーマンスは必要としません。
取引が1日24時間行われている今日のインターネット・アプリケーションの場合、24時間連続稼働は必須です。ただし、1つのタイム・ゾーンでのみ稼働する企業システムの場合は、終業後にシステムを停止できます。この終業後の停止時間を利用して、バッチ処理やシステム管理を実行できます。このような場合は、連続稼働システムでない方が経済的です。
変更はすべてリアルタイムで行う必要がありますか。
ユーザーのレスポンス時間内にトランザクションを実行する必要があるか、またはキューに入れて非同期で実行できるかを判断することが重要です。
次の質問は二次的な質問です。これらは設計にも影響を及ぼしますが、予算や実装しやすさの面に、より大きく影響します。次に例を示します。
データベースの規模は、データベース・サーバーのサイズ決定に影響します。大規模データベースを使用するサーバーでは、ワークロードから判断されるサイズよりも大型のコンピュータを用意することが必要になる場合があります。これは、大規模データベースに伴う管理オーバーヘッドが、主としてデータベース・サイズに比例するためです。表および索引が大きくなると、許容できる時間内に表を再編成したり索引を作成する必要があるため、必要なCPUの数もそれに比例して増加します。
ビジネス・トランザクションで必要とされるスループットはどの程度ですか。
可用性に関する要件は何ですか。
このアプリケーションを作成して管理するためのスキルはありますか。
予算上の制約からどのような妥協を求められますか。
アプリケーションは、設計と開発を伴う他の製品となんら変わりはありません。通常、適切に設計された構造、コンピュータおよびツールは、信頼性があり、使用方法やメンテナンスが容易で、コンセプトもシンプルです。ごく一般的に表現すると、設計が適切に見えるものは、実際に適切に設計されているといえます。アプリケーションの作成では、この原則を常に覚えておいてください。
次の設計の問題を考慮してください。
表の設計が複雑で、誰も完全に理解できない場合、その表の設計は不適切であるといえます。
SQL文が非常に長く、どのオプティマイザでもリアルタイムに効率よく最適化できない場合、そのSQL文、基になるトランザクションまたは表の設計が不適切であるといえます。
表に索引があり、同じ列が繰り返し参照される場合は、索引の設計が不適切であるといえます。
問合せを送信したときに、オンライン・ユーザーにとって必要な迅速なレスポンス能力がなかった場合は、ユーザー・インタフェースまたはトランザクションの設計が不適切であるといえます。
ソフトウェアの多くの層で、データベース・コールがアプリケーション・ロジックから離れて抽象化される場合は、ソフトウェアの開発方法が不適切であるといえます。
表の設計は、主に、主要トランザクションの柔軟性とパフォーマンスの間でバランスを取る作業です。データベースの柔軟性を保持しながら予想外のワークロードに対処できるようにするには、表の設計をデータ・モデルとほぼ同じようにする必要があり、最低でも第3正規形に正規化しておく必要があります。ただし、ユーザーが必要とする特定のトランザクションでは、パフォーマンス向上のために選択的な非正規化が求められることがあります。
この技法の例としては、事前に結合された表の格納、導出列の追加および集計値があります。Oracle Databaseでは、クラスタ化機能およびマテリアライズド・ビュー機能によって、集計データおよび事前結合データに関する多数のストレージ・オプションが提供されています。これらの機能によって、より簡潔な表の設計を最初から採用できます。
ここでも、最適のパフォーマンスを実現できるように、ビジネス上重要な表に重点的にリソースを使用する必要があります。重要でない表の場合は、アプリケーション開発を迅速に進めるためにも、設計に簡略な方法を採用できます。ただし、プロトタイプおよびテストの結果、重要でない表でパフォーマンスの問題が発生する場合は、ただちに設計を修正する必要があります。
索引の設計も、アプリケーション設計者が生成したSQLに基づく、主として反復的なプロセスです。ただし、主キー制約を適用する索引や個人名など既知のアクセス・パターンに対する索引を作成することから開始することも可能です。アプリケーションの開発が進み、実際のデータ量でテストを実行するときは、適切な索引を作成して特定の問合せのパフォーマンスを改善する必要があります。新しい索引を作成する際には、索引の設計に関する次の事項を検討してください。
問合せをスピードアップする簡単な方法の1つは、実行計画から表アクセスを排除して論理I/Oの数を減らすことです。これは、問合せによって参照されるすべての列を索引に追加することで実現できます。これらの列は、選択リスト列、および結合またはソートに必要な列です。この方法は、時間がかかるI/Oを削減して、オンライン・アプリケーションのレスポンス時間を短縮する場合に特に役立ちます。これは、適切なサイズのデータを使用してアプリケーションを初めてテストするときに最も効果を発揮します。
この技法を最も積極的に使用しているのが、索引構成表(IOT)の作成です。ただし、IOTのリーフ・サイズの増加がI/O削減効果を妨げないように注意する必要があります。
選択できる索引のタイプはいくつかあり、それぞれ特定の状況に応じた利点があります。各タイプの索引に関連したパフォーマンスの考慮点を、次のリストに示します。
ビットマップ索引
この索引は、カーディナリティが低いデータに適しています。この索引は、圧縮技法によって最小限のI/Oで多数のROWIDを生成できます。選択列以外の列に対するビットマップ索引を組み合せることによって、最小限のI/Oと多数のROWIDでAND演算とOR演算を効率よく実行できます。ビットマップ索引は、索引内で問合せを満たすことができるため、COUNT()を使用した問合せで特に効果的です。
ファンクション索引
この索引では、ベース・データ上のファンクションから導出された値に対するBツリー経由でアクセスできます。ファンクション索引ではNULLの使用に制限があり、問合せオプティマイザを有効にしておく必要があります。
ファンクション索引は、複合列への問合せで導出される結果を生成する場合や、データベースへのデータの格納方法における制限を克服する場合に、特に役立ちます。その例として、(販売価格 - 値引)×数量から算出された特定の値を超える注文の明細項目(表内の列)の問合せがあります。別の例としては、UPPERファンクションをデータに適用した、大/小文字を区別しない検索があります。
索引構造の作成とメンテナンスにはコストがかかり、ディスク領域、CPUおよびI/O容量などのリソースを消費します。設計者は、索引のメンテナンスにかかるコストより、索引の使用による利点が上回るように設計する必要があります。
索引のメンテナンスにかかるコストを見積る簡単な目安があります。それは、索引キーに対してINSERT、DELETEまたはUPDATEを実行することでメンテナンスされる索引では、索引ごとに、表に対する実際のDML操作で使用されるリソースの3倍のリソースが必要になる、というものです。したがって、3つの索引を持つ表へのINSERTは、索引のない表へのINSERTよりも約10倍遅くなります。DMLの場合、特にINSERT操作が多いアプリケーションでは、問合せとINSERT操作のパフォーマンスとの間のバランスを取る必要があるため、索引の設計は十分に検討する必要があります。
関連項目:
索引の使用状況の監視方法の詳細は、『Oracle Database管理者ガイド』を参照してください
ビューを使用すると、アプリケーションの設計がスピードアップされ簡潔になります。簡単なビュー定義により、データの取出し、表示、収集および格納処理を優先するプログラマが、複雑なデータ・モデルから解放されます。
ただし、ビューは、クリーンなプログラミング・インタフェースを提供する一方で、最適とはいえないリソース集中型の問合せの原因になる場合があります。ビューの最も不適切な使用例は、ビューが他の複数のビューを参照し、その複数のビューが問合せ内で結合されている場合です。多くの場合、開発者はビューを使用せずに表から直接問合せを満たすことができます。ビューが持つ本来の特性により、通常は、オプティマイザによる最適な実行計画の生成が困難になります。
システム開発の設計およびアーキテクチャ・フェーズでは、アプリケーション開発者がSQLの実行効率を理解していることが重要です。この目標を達成するには、開発環境が次の特性をサポートしている必要があります。
データベース接続の適切な管理
データベースへの接続は、コストが高くスケーラブルでない操作です。このため、データベースへの同時接続数はできるだけ少なくする必要があります。アプリケーションの初期化時にユーザーが1人接続しているという単純なシステムが理想的です。しかし、Webベース・アプリケーションや多層アプリケーションでは、複数のアプリケーション・サーバーが使用されてユーザーへのデータベース接続が多重化しているため、接続数を少なくするのは困難です。このようなタイプのアプリケーションでは、データベース接続をプールし、ユーザー・リクエストごとに接続が再確立されないように設計する必要があります。
カーソルの適切な使用および管理
ユーザー接続のメンテナンスも、システムでの解析アクティビティの最小化にとっては同じように重要です。解析とは、SQL文を解釈し、そのSQL文の実行計画を作成する処理です。この処理には、構文検査、セキュリティ検査、実行計画の生成、共有プールへの共有構造のロードなど、多くのフェーズがあります。解析操作には、次の2種類があります。
SQL文が初めて送信され、共有プール内に一致するものがない場合です。ハード解析は、解析に関連するすべての操作を実行するため、最もリソース集中型であり、スケーラブルではありません。
SQL文が初めて送信され、共有プール内に一致が見つかった場合です。別のユーザーが以前に実行した結果が一致することがあります。SQL文は共有されるため、パフォーマンスが向上します。ただし、ソフト解析では、システム・リソースを消費する構文検査やセキュリティ検査が必要であり、理想的とはいえません。
解析はできるだけ最小限にする必要があるため、アプリケーション開発者は、SQL文を1回解析し、そのSQL文を複数回実行するようにアプリケーションを設計してください。これは、カーソルを使用して行います。経験のあるSQLプログラマであれば、カーソルのオープンと再実行の概念を理解しています。
アプリケーション開発者は、SQL文が共有プール内で共有されるようにする必要もあります。この目標を達成するには、問合せの中で実行ごとに変化する部分をバインド変数として表します。これを行わないと、SQL文は1回解析された後、他のユーザーから再利用されない可能性があります。SQLの共有を確実にするには、SQL文ではバインド変数を使用し文字列リテラルは使用しないようにします。次に例を示します。
文字列リテラルがある文は、次のとおりです。
SELECT * FROM employees WHERE last_name LIKE 'KING';
バインド変数がある文は、次のとおりです。
SELECT * FROM employees WHERE last_name LIKE :1;
次の例は、単純なOLTPアプリケーションでのテスト結果です。
Test #Users Supported No Parsing all statements 270 Soft Parsing all statements 150 Hard Parsing all statements 60 Re-Connecting for each Transaction 30
このテストは、4台のCPUを搭載したコンピュータで実行されました。システム上のCPUの数が増えると、差異も大きくなります。
開発環境およびプログラミング言語の選択は、開発チームのスキルと、アプリケーションの指定時に決定したアーキテクチャにより決定します。ただし、簡単なパフォーマンス管理規則がいくつかあり、これに従うと、スケーラブルで高パフォーマンスのアプリケーションの実現につながります。
ソフトウェア・コンポーネントに適した開発環境を選択し、その環境によってパフォーマンスに関する設計が制限されないようにしてください。設計が制限される場合は、選択した言語または環境が不適切であるといえます。
プログラミング・モデルには、HTML生成からウィンドウ・システムの直接コールまで様々なモデルがあります。開発方法では、ユーザー・インタフェース・コードのレスポンス時間に重点を置く必要があります。HTMLまたはJavaをネットワークで送信する場合は、ネットワーク通信量や対話を最小限に抑えるようにしてください。
JavaやPL/SQLなどのインタプリタ型言語は、ビジネス・ロジックのエンコードには理想的です。これらの言語は完全に移植可能であるため、ロジックのアップグレードが比較的簡単にできます。どちらの言語も構文が豊富で、読みやすく解析しやすいコードを作成できます。ビジネス・ロジックで複雑な数学関数が必要な場合は、コンパイラ型バイナリ言語が必要になる場合があります。ビジネス・ロジック・コードは、クライアント・コンピュータ、アプリケーション・サーバーおよびデータベース・サーバーに配置できます。ただし、アプリケーション・サーバーに配置するのが最も一般的です。
プログラミング言語の影響はほとんど受けませんが、データベース接続およびカーソルの管理をマスクするツールおよび第4世代言語では、非効率的なメカニズムが使用されることがあります。このようなツールや環境を評価するときは、データベース接続モデルおよびカーソルやバインド変数の使用方法をチェックしてください。
データ管理とトランザクション
これに関しては、プログラミング言語による影響はほとんどありません。
ソフトウェア・コンポーネントを実装するときは、その機能を実装するようにし、他のコンポーネントに関連付けられている機能は実装しないでください。他のコンポーネントの機能を実装すると、設計や実装が最適でなくなります。これはすべてのコンポーネントに当てはまります。
機能のギャップをそのまま放置したり、検討中のソフトウェア・コンポーネントを設計、実装またはテストで使用しないでください。多くの場合、ギャップは、アプリケーションを展開するか、実際のボリュームでテストするまで検出されません。このギャップは、通常、アーキテクチャまたは当初のシステム仕様が不適切であることを示します。データのアーカイブ・モジュールおよびパージ・モジュールは、初期のシステム設計、作成および実装時には最も無視されやすいモジュールです。
プロシージャ型ロジックを実装するときは、C、JavaまたはPL/SQLなどの手続き型言語で実装するようにします。データ・アクセス(問合せ)またはデータ変更(DML)を実装するときは、SQLを使用します。これは、プロシージャ型コードとデータ・アクセス(非プロシージャ型SQL)コードが混在しているビジネス・ロジック・モジュール特有の規則です。SQLアクセスにプロシージャ型ロジックを使用することも考えられます。しかし、これはリソースを多く消費するSQLになる傾向があります。DECODEケース文を含むSQL文は、多くの場合、最適化が必要です。大量のOR述語または集合演算子(UNIONやMINUSなど)を含む文も同様です。
頻繁にアクセスし、変更がほとんどなく、繰り返し取り出すのにコストがかかるデータは、キャッシュします。ただし、キャッシュ・メカニズムは使いやすくして、元の方法でデータにアクセスするよりもコストが実際に低くなるようにしてください。これは、頻繁に使用するデータ値はリモート・データ・ストアまたはコストがかかるデータ・ストアから繰り返し取り出すよりも、キャッシュするかローカルに格納する必要があるすべてのモジュールにあてはまります。
ローカルにキャッシュするデータの一般的な候補例をいくつか示します。
本日の日付。SELECT SYSDATE FROM DUALが、データベースにかかるワークロードの60%以上を占めることもあります。
現行ユーザー名。
税率、値引率、位置情報など、繰り返し使用するアプリケーション変数および定数。
ローカルでのデータ・キャッシュは、さらに、アプリケーション・サーバー中間層へのローカル・データ・キャッシュの作成へ発展させることができます。これにより、中央のデータベース・サーバーの負荷が減ります。ただし、ローカル・キャッシュを作成するときは、パフォーマンス上の利点がなくなるほどキャッシュが複雑にならないように注意してください。
ローカル順序の生成。
キャッシュを使用する場合は、設計上の意味を考慮してください。たとえば、ユーザーが午前0時に接続して日付がキャッシュされた場合、ユーザーの日付値は無効になります。
コンポーネント間のインタフェースを最適化し、すべてのコンポーネントが最もスケーラブルな構成で使用されるようにします。この規則に説明はほとんど不要で、すべてのモジュールとインタフェースに当てはまります。
外部キー参照を使用します。アプリケーションから参照整合性を適用するのはコストがかかります。外部キー参照は、子の列値を親から選択してその存在を確認することで、メンテナンスできます。Oracleが提供する外部キー制約(SQLを使用しない)は高速で、しかも簡単に宣言でき、ネットワーク・トラフィックを作成しません。
End to End Application Tracingで使用するアクション名およびモジュール名の設定を検討してください。設定すると、ワークロードの問題を柔軟にトレースできます。
今日のアプリケーション開発には、2つの大きな特徴があります。1つは、コンパイラ型のCまたはC++アプリケーションにかわってJavaの使用が増えていること、もう1つは、スキーマ設計に影響を与えるオブジェクト指向手法の使用が増えていることです。
Javaはコードの移植性に優れ、高い可用性をプログラマに提供します。ただし、Javaにはパフォーマンスに影響することがいくつかあります。Javaはインタプリタ型言語であるため、C言語などのコンパイラ型言語に比べてロジックの実行速度が遅くなります。その結果、クライアント・コンピュータでのリソース使用量が増加します。このため、強力なCPUをクライアント・コンピュータや中間層コンピュータに設置する必要があり、プログラマは効率的なコードを作成するようにさらに注意を払う必要があります。
Javaはオブジェクト指向言語であるため、ビジネス・ロジックを実行しないクラスへのデータ・アクセスの分離を奨励します。この結果、プログラマは、使用するデータ・アクセス・メソッドの効率を認識せずにそのメソッドを呼び出す可能性があります。このため、データベース・アクセスが最小限になり、データベースへのインタフェースには最も簡潔で単純なインタフェースが使用される可能性があります。
このタイプのソフトウェア設計では、常にすべてのWHERE述語が問合せに効率的に組み込まれるとは限らず、行のフィルタ処理はJavaプログラムで実行されます。これはかなり非効率的です。さらに、DML操作、特にINSERT操作では単一のINSERTが実行され、配列インタフェースは使用できません。これが、プロシージャ・コールによりさらに非効率的になることがあります。データベースとのデータのやり取りでは、実際のデータベース・コールよりも多くのリソースが使用されます。
一般に、最善の総合的トランザクション設計を実現するには、データ・アクセス・コールをビジネス・ロジックの次に配置するのが最適です。
プログラミング・レベルでのオブジェクト指向の採用は、Oracleサーバー内にオブジェクト指向データベースを作成することに発展しています。これは、オブジェクト構造のBLOBへの格納および効果的な索引付きカード・ファイルとしてのデータベースの使用から、Oracle Databaseオブジェクト・リレーショナル機能の使用まで、様々な形で現れています。
オブジェクト指向アプローチをスキーマ設計に採用する場合は、リレーショナル・ストレージ・モデルの柔軟性が失われないようにします。多くの場合、スキーマ設計でのオブジェクト指向アプローチにより、データ構造にかなりの非正規化が生じ、相当なメンテナンスが必要になり、オブジェクトに関連付けられたREFポインタも必要になります。このような設計は、多くの場合、リレーショナル格納方式に置き換わる前の階層データベースやネットワーク・データベースの設計に戻ることを意味します。
要約すると、データベースにデータを長期間格納する場合、また同一スキーマに対する非定型問合せまたはアプリケーション開発をある程度予期している場合は、リレーショナル格納方式が最善のパフォーマンスと柔軟性をもたらす可能性があります。
この項では、ワークロードの見積り、モデル化、実装およびテストについて説明します。この項の内容は次のとおりです。
不適切なサンプル・セットを使用すると、可変長データを扱うときにサイズの見積りを誤ることがあります。データ量の増加に伴い、キーの長さも大幅に長くなり、列サイズの見積りに変更が生じます。
システムは、本番稼働が始まると、データベース規模の拡大、特に索引の増加は予想が困難になります。表は時間とともに増大し、索引は、キーの生成、挿入パターンおよび行の削除というアプリケーションの個々の動作によって変化します。最悪のケースは、昇順キーを使用して行を挿入してから、一部の行を残してほとんどの行を表の左側から削除した場合です。これによって、ギャップと無駄な領域が残ります。索引をこのように使用している場合は、オンラインの索引再作成機能の使用方法を理解している必要があります。
DBAは、オブジェクトごとに領域割当てを監視し、増大して制御できなくなる可能性のあるオブジェクトを探します。アプリケーションを十分に理解することで、急速にまたは予測を超えて増大する可能性のあるオブジェクトを発見できます。これは、あらゆるシステムのパフォーマンス計画と可用性計画の両方で重要なことです。本番データベースを実装するときは、対話型ユーザーがアプリケーションを使用しているときに領域管理が最小限になるように設計する必要があります。これは、データ・セグメント、一時セグメントおよびロールバック・セグメントのすべてに当てはまります。
含まれる変数の数を考えると、容量計画およびテストのためのワークロードの見積りは非常に困難です。しかし、設計者は、CPU、メモリーおよびディスク・ドライブを搭載したコンピュータを指定して、最終的にはアプリケーションを展開する必要があります。サイズ設定に使用する技法はいくつかあり、それぞれに利点があります。サイズを設定するときは、次の方法を使用して意思決定プロセスを検証し、サポート用ドキュメントを準備することをお薦めします。
類似システムからの推定
これは完全に経験に基づくアプローチで、特性が類似しており、パフォーマンスが把握されている既存のシステムを基礎システムとして使用します。このシステムの仕様を、サイズ設定の担当者が既知の相違点に応じて変更します。このアプローチでは、既存のシステムと関連する部分は参考になりますが、相違点のある部分を扱うときにはほとんど参考になりません。
このアプローチは、巨大なビル、船舶、橋梁、石油掘削装置などの大規模エンジニアリング分野のほとんどすべてで、エンジニアリング・プロジェクトのコストを見積るときに使用されています。参照システムがサイズの点で計画しているシステムと大きな差がある場合は、一部のコンポーネントが設計上限を超えてしまう可能性があります。
ベンチマーク
ベンチマーク・プロセスは、リソースと時間をかなり消費し、必ずしも正確な結果が得られるとはかぎりません。開発初期またはプロトタイプの段階でアプリケーションをシミュレーションすると、実際の本番システムの場合とは異なるものを計測する危険性があります。予想外かもしれませんが、オラクル社では長年にわたりデータベース開発組織とともに顧客アプリケーションのベンチマークを行っていますが、ベンチマーク・アプリケーションと実際の本番システムとの間に信頼に値する相関関係はまだ認められていません。これは、開発プロセスでアプリケーションの非効率な点がいくつか組み込まれてしまうことが主な原因です。
しかし、ベンチマークは、許容可能なレベルの精度でシステムのサイズを設定するためには有効に利用されています。特に、ベンチマークは、システムの負荷が最大になったときの実際のI/O要求数の判断やリカバリ処理のテストに効果があります。
ベンチマークでは、その性質上、システムの全コンポーネントに対してそれぞれの上限までストレスがかけられます。すべてのコンポーネントにストレスがかけられるため、ベンチマーク中にアプリケーションの設計および実装のエラーがすべて明らかになります。また、ベンチマークでは、データベース、オペレーティング・システムおよびハードウェア・コンポーネントもテストされます。ほとんどのベンチマークが急いで実行されるため、システム・コンポーネントが失敗すると障害や問題が発生すると考えてください。ベンチマークは実施者にストレスがかかる作業であり、ベンチマークから最大限の結果を得るには豊富な経験が必要です。
アプリケーションのモデル化は、複雑な数学的モデル化から、封筒の裏を使用するような典型的な単純計算まで多岐にわたります。どちらの方法にもメリットがあり、一方は高い精度を目標とし、もう一方は大まかな見積りを作成します。デメリットは、どちらも実装エラーや効率の悪さが考慮されないことです。
見積りやサイズ設定のプロセスは、正確性に欠ける技法です。しかし、このプロセスを精査することで、ある程度知的な見積りを行うことができます。見積りプロセス全体としては、不適切なSQL、索引の設計またはカーソル管理によるアプリケーションの非効率は考慮されていません。サイズ設定担当者は、アプリケーションの非効率性に対応する余裕を組み入れる必要があります。パフォーマンス・エンジニアは、非効率性を検出し、見積りを現実的なものにします。アプリケーションの非効率性を検出する方法は、Oracleのパフォーマンス改善方法で説明しています。
テスト・プロセスは、主に機能テストと安定性テストで構成されます。このプロセスの途中で、パフォーマンス・テストが実施されます。
アプリケーションのパフォーマンス・テストを実行するときの簡単な規則を説明したリストを次に示します。適切に文書化した場合、このリストは、アプリケーション稼働後の本番アプリケーションと容量計画プロセスにとって重要な情報を提供します。
自動データベース診断モニター(ADDM)とSQLチューニング・アドバイザを使用した設計の検証
現実的なデータ量とデータ配分によるテスト
すべてのテストは、データが完全に含まれている表を使用して行う必要があります。テスト用データベースには、データ量や表のカーディナリティという点で本番システムと同様のデータを入れておく必要があります。本番と同様の索引をすべて作成し、スキーマ統計を正しく入力します。
正しいオプティマイザ・モードの使用
すべてのテストは、本番で使用するオプティマイザ・モードで実行する必要があります。Oracle Databaseのすべての研究開発の取組みは、問合せオプティマイザに重点が置かれています。したがって、問合せオプティマイザの使用をお薦めします。
シングル・ユーザーのパフォーマンスのテスト
アイドル状態または使用率の低いデータベースで、シングル・ユーザーのパフォーマンスが許容範囲にあるかテストします。シングル・ユーザーのパフォーマンスが理想的な条件下で許容範囲に達しない場合、実際の条件下で複数のユーザーが許容可能なパフォーマンスを得ることはできません。
全SQL文の計画の取得と文書化
各SQL文の実行計画を取得します。このプロセスを使用して、オプティマイザの実行計画が最適かどうか、およびSQL文の相対コストがCPU時間と物理I/O数の観点から把握されているかどうかを検証します。このプロセスは、将来において多くのチューニングおよびパフォーマンスの必要な頻繁に使用されるトランザクションを識別するのに役立ちます。
マルチ・ユーザーのテスト
ユーザーのワークロードやプロファイルがまだ完全に定量化されていない可能性があるため、このプロセスを正確に実行するのは困難です。しかし、DML文を実行するトランザクションをテストして、ロックの競合やシリアライズの問題がないことは確認する必要があります。
正しいハードウェア構成でのテスト
できるだけ本番システムに近い構成でテストを行います。実際的なシステムの使用は、ネットワーク待機時間、I/Oサブシステム帯域幅およびプロセッサのタイプと速度についてテストする場合に特に重要です。このアプローチを使用しなかった場合、潜在的なパフォーマンスの問題を正しく分析できません。
安定した状態でのパフォーマンスの測定
ベンチマークを行うときは、安定した状態でパフォーマンスを測定することが重要です。各ベンチマークの実行には開始フェーズが必要です。このフェーズでは、ユーザーがアプリケーションに接続し、アプリケーションでの作業を徐々に開始します。このプロセスによって、安定した状態になる前に、頻繁にキャッシュされるデータをキャッシュに初期化し、解析などの1回のみ実行する操作を完了しておくことができます。同様に、ベンチマークの実行後には終了フェーズが必要です。このフェーズでは、リソースをシステムから解放し、ユーザーは作業を終了して接続を切断します。
新しいアプリケーションをロールアウトするときは、次の2つの方法が一般的です。
いずれの方式にもメリットとデメリットがあります。ビッグ・バン・アプローチでは、必要な規模でアプリケーションを十分にテストしておく必要がありますが、旧システムは完全に使用されなくなるため、旧システムからのデータの変換と旧システムとの同期が最小限で済みます。トリクル・アプローチでは、ワークロードの増加に伴いスケーラビリティの問題をデバッグできますが、移行中に旧システムとの間でデータを相互に移行する必要性が発生することがあります。
いずれの方法も、それぞれ移行実施中にシステムの停止につながるリスクがあるため、どちらかを推奨することは困難です。トリクル・アプローチでは、実際のユーザーが新しいアプリケーションに移行するにつれてユーザー・プロファイルを作成できるので、システムを再構成しても、その影響を受けるのは移行済ユーザーのみです。この方式は、初期の段階で移行したユーザーの作業に影響を与えますが、サポート・サービスの負荷は限定されます。これは、スケジュール外の停止が発生しても、影響を受けるユーザーの割合が小さいことを意味します。
新規アプリケーションのロールアウト方法は、ビジネスごとに判断してください。採用するどのアプローチにも、それぞれ固有の長所と短所があります。テストを重ねて、そのテストから得られた知識が増えるほど、最善のロールアウト方式を判断できます。
本番での最適なパフォーマンスの可能性を高め、アプリケーションの迅速なデバッグを可能にするタスクのリストを作成すると、ロールアウトの際に役立ちます。次の手順を実行します。
MAXINSTANCES、MAXDATAFILES、MAXLOGFILES、MAXLOGMEMBERSおよびMAXLOGHISTORYをロールアウトで予測されるよりも大きい値に設定することで、データベースの成長に対応します。この方法では、ディスク領域の使用量が増えて制御ファイルも大きくなりますが、後でこれらを緊急に拡張する必要が生じたときに時間を節約できます。INSERT/UPDATE/DELETE操作が頻繁に発生する表と索引を作成するには、自動セグメント領域管理を使用する必要があります。自動UNDO管理を使用して、ロールバック・セグメントの競合を回避します。WHERE句の述語が文字列リテラルとして送信されていることです。プリコンパイラを使用してアプリケーションを開発する場合は、アプリケーションをプリコンパイルする前に、MAXOPENCURSORS、HOLD_CURSORおよびRELEASE_CURSORの各パラメータのデフォルト値からの再設定が必要です。