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