10gリリース2（10.2）
B19207-02
 目次 |
 索引 |
| Oracle Database パフォーマンス・チューニング・ガイド 10gリリース2（10.2） B19207-02 |
|
I/Oサブシステムは、Oracleデータベースに不可欠なコンポーネントです。基本的なI/O概念を紹介し、データベースの様々な部分のI/O要件について説明し、I/Oサブシステムの設計のための構成例を示します。
この章には次の項があります。
多くのソフトウェア・アプリケーションのパフォーマンスは、本質的にディスクI/Oによって制限されます。CPUタイムの大部分をI/Oアクティビティが完了するまでの待機に使用するアプリケーションはI/Oバウンドと呼ばれます。
Oracleは、適切に作成されたアプリケーションのパフォーマンスが、I/Oで制限されないように設計されています。I/Oシステムが最大限またはそれに近い状態で動作しており、許容時間内にI/Oリクエストに対応できない場合は、I/Oのチューニングを行うと、アプリケーションのパフォーマンスを向上できます。ただし、アプリケーションがI/Oバウンドではない場合（たとえば、CPUが制限要因である場合）、I/Oをチューニングしてもパフォーマンスを改善できません。
I/Oシステムを設計するときは、次のデータベース要件を考慮してください。
多くのI/O設計では、パフォーマンスが問題とならないと仮定して記憶域要件および可用性要件の計画を立てています。ただし、これに該当しない場合もあります。構成するディスクおよびコントローラの数はI/Oスループットおよび冗長性の要件で判断することが最適です。この場合、ディスクのサイズは記憶域要件で判断できます。
この項では、収集する基本情報およびシステムのI/O構成を定義するときの決定事項について説明します。必要な可用性、リカバリ能力およびパフォーマンスは維持しながら、できるだけ単純な構成を維持します。構成が複雑になるに従って、管理、メンテナンスおよびチューニングが困難になります。
オペレーティング・システムにLVMソフトウェアまたはハードウェア・ベースのストライプ化がある場合、これらのツールを使用してI/Oを分散できます。LVMまたはハードウェア・ストライプ化を使用するときの決定事項には、ストライプ深度およびストライプ幅が含まれます。
これらの値を適切に選択して、システムが必要なスループットを維持できるようにします。Oracleデータベースにおける適切なストライプ深度は、256KB〜1MBです。ストライプ深度によって、得られるアプリケーションの利点の種類が異なります。最適なストライプ深度およびストライプ幅は、次の項目により異なります。
表8-1に、I/Oサイズの設定で使用できるOracleおよびオペレーティング・システムのパラメータを示します。
I/Oサイズの他に、同時実行性の程度も理想的なストライプ深度を調べる上で役立ちます。ストライプ幅およびストライプ深度を選択する場合は、次の点を考慮してください。
従来のOLTP環境などの高度な小さい同時I/Oリクエストが存在するシステムでは、ストライプ深度を大きく保つことが有効です。I/Oサイズより大きいストライプ深度を使用することは粗密なストライプ化と呼ばれます。同時実行性の高いシステムのストライプ深度は次のようになります。
n * DB_BLOCK_SIZE
nは1より大
粗密なストライプ化ではアレイ内の1ディスクで複数のI/Oリクエストに対応できます。この方法では、一連のストライプ化ディスクで多数の同時I/Oリクエストに対応でき、I/Oセットアップ・コストも最小限で済みます。粗密なストライプ化では全体的なI/Oスループットが最大化されます。全表スキャンの場合も同様に、ストライプ深度が大きく、かつ1つのドライブで対応可能な場合は、マルチブロック読込みが有益です。DSS環境のパラレル問合せも、粗密なストライプ化の候補です。これは、それぞれ個別のI/Oを発行する個々のプロセスが多数存在するためです。粗密なストライプ化は、同時要求が少ないシステムで使用されると、ホット・スポットが生成される可能性があります。
従来のDSS環境や同時実行性の低いOLTPシステムなどの大きいI/Oリクエストがほとんど存在しないシステムでは、ストライプ深度を小さく保つことが有益です。これはファイングレイン・ストライプ化と呼ばれます。そのようなシステムのストライプ深度は次のように表されます。
n * DB_BLOCK_SIZE
n はマルチブロック読込みパラメータ（DB_FILE_MULTIBLOCK_READ_COUNTなど）よりも小さくなります。
ファイングレイン・ストライプ化では、複数のディスクで単一I/Oリクエストを処理できます。ファイングレイン・ストライプ化では、個々のI/Oリクエストまたは応答時間のパフォーマンスが最大化されます。
一部のOracleポートでは、Oracleブロック境界がストライプと揃わない可能性があります。ストライプ深度がOracleブロックのサイズと同じである場合、Oracleから発行された単一I/Oによって2つの物理I/O操作が発生する場合があります。
これは、OLTP環境では最適ではありません。1つの論理I/Oで物理I/Oが1つのみ発生する確率が高くなるようにするには、最小のストライプ深度がOracleブロック・サイズの少なくとも2倍である必要があります。表8-2に、ランダム・アクセスおよび順次読取りでお薦めする最小ストライプ深度を示します。
| ディスク・アクセス | 最小ストライプ深度 |
|---|---|
|
ランダム読込みおよび書込み |
最小ストライプ深度は、Oracleブロック・サイズの2倍です。 |
|
順次読取り |
最小ストライプ深度は、Oracleブロック・サイズを乗算した |
LVMの場合、最も管理の簡単な構成は、使用可能なすべてのディスク上に単一ストライプ化ボリュームを構成したものです。この場合、ストライプ幅はすべての使用可能なディスクを包含します。すべてのデータベース・ファイルはそのボリューム内に常駐し、効果的に負荷を均等分散します。この単一ボリューム・レイアウトは、ほとんどの状況で適切なパフォーマンスを実現します。
単一ボリューム構成は、RAID 1などの簡単なリカバリを可能にするRAID技術と併用する場合のみ有効です。それ以外の場合、単一のディスクを失うことはすべてのファイルを同時に失うことであり、完全なデータベースのリストアおよびリカバリを実行する必要があることを意味します。
パフォーマンスの他に、管理性の問題があります。システムの設計で、ディスクを簡単に追加できるようにして、データベースの拡張を可能にする必要があります。課題は、負荷のバランスを維持しながら拡張を行うことです。
たとえば、初期構成で、64個の16GBのディスク上に単一ストライプ化ボリュームを作成する必要があるとします。これはプライマリ・データの1TBの合計ディスク領域になります。場合によっては、システムが動作した後に、将来のデータベース拡張を可能にするためにさらに80GB（すなわち、5つのディスク）を追加する必要があります。
この領域をデータベースで使用できるようにするオプションには、5つの新しいディスクを含む第2のボリュームの作成があります。ただし、これらの新しいディスクがその上に配置されたファイルに必要なI/Oスループットを保持できない場合、I/Oボトルネックが発生する可能性があります。
もう1つのオプションは、元のボリュームのサイズを増やすことです。LVMは高度になりつつあり、ストライプ幅の動的な再構成を可能にするので、システムがオンライン中にディスクを追加できます。このため、本番環境で単一ストライプ化ボリューム上にすべてのファイルを配置できるようになってきました。
LVMがストライプへのディスクの動的な追加をサポートできない場合は、より小さく管理しやすいストライプ幅を選択する必要があります。そのようにすると、新しいディスクを追加する場合、ストライプ幅だけシステムを拡張できます。
前述の例で、8個のディスクがより管理しやすいストライプ幅といえます。これは、8個のディスクで1秒間に必要な数のI/Oを維持できる場合のみ可能です。したがって、追加のディスク領域が必要なときは、別の8ディスク・ストライプを追加して、ボリューム間でI/Oのバランスを維持できます。
システムにLVMまたはハードウェアのストライプ化がない場合、各ファイルのI/O要件に従ってファイルを分散することにより、使用可能なディスク間でI/Oを手動でバランス化する必要があります。ファイルの配置に関する決定を行うには、データベース・ファイルのI/O要件およびI/Oシステムの機能についてよく理解している必要があります。このようなデータに慣れておらず、解析対象の代表的なワークロードを取得できない場合は、まず推定を行い、次に使用量がわかったときにこのレイアウトをチューニングします。
ディスクを手動でストライプ化するには、ファイルの記憶域要件をI/O要件と関連付ける必要があります。
手動I/O分散の一般的な方法として、頻繁に使用される表をその索引から分離することが挙げられます。これは正しくありません。一連のトランザクション中は、索引が読み込まれてから表が読み込まれます。これらのI/Oは順次に発生するので、表と索引を同じディスク上に格納しても競合は発生しません。データファイルには索引や表データが含まれているため、これを単純に分離するだけでは十分ではありません。ファイルを分離する決定は、そのファイルのI/O率がデータベースのパフォーマンスに影響を与える場合にのみ行ってください。
オペレーティング・システムのストライプ化または手動I/O分散を使用するかどうかに関係なく、I/OシステムまたはI/Oレイアウトが要求されたI/O率をサポートできない場合は、I/O率の高いファイルをそれ以外のファイルから分離する必要があります。このようなファイルは計画段階かシステムの本稼働後に確認できます。
ファイルを分離する決定は、I/O率、リカバリ能力の問題、管理可能性の問題によってのみ影響を受けます（たとえば、LVMがストライプ幅の動的な再構成をサポートしない場合、同一構成の新しいストライプを作成してn 個のディスクを追加できるように、さらに小さいストライプ幅を作成する必要がある場合があります）。
ファイルを分離する前に、ボトルネックが実際にI/Oの問題であるかどうかを検証します。ボトルネックの調査から生成されたデータでは、最高のI/O率を持つファイルを識別します。
I/Oの多いファイルが表および索引を含む表領域に属するデータファイルである場合は、これらのファイルのI/OをSQLのチューニングまたはアプリケーション・コードのいずれかで削減できるかどうかを識別します。
I/Oの多いファイルがTEMP表領域に属するデータファイルである場合は、このアクティビティを回避するためにディスク・ソートを実行するSQL文をチューニングするか、あるいはソートをチューニングするかを調べます。
不要なI/Oを回避するようにアプリケーションをチューニングした後、I/Oレイアウトが引き続き必要なスループットを維持できない場合は、I/Oの多いファイルの分離を考慮してください。
I/Oの多いファイルがREDOログ・ファイルである場合は、REDOログ・ファイルをその他のファイルから分離することを考慮してください。可能な構成には、次のことが含まれています。
REDOログ・ファイルは、ログ・ライター（LGWR）プロセスで順次書き込まれます。同じディスクに対する同時実行アクティビティが存在しない場合、この操作はさらに高速にできます。REDOログ・ファイルに別々の専用ディスクを割り当てると、さらにチューニングしなくても通常はLGWRが円滑に実行されます。システムが非同期I/Oをサポートせず、この機能が現在構成されていない場合、この機能を使用することが有効かどうかを確認します。LGWRに関連するパフォーマンス上のボトルネックはめったにありません。
アーカイバが遅い場合、アーカイバ読込みとLGWR書込みが分離されるようにして、アーカイバ・プロセスとLGWRの間のI/O競合を防止することが賢明です。これは、ログを代替ドライブに置くことで達成されます。
たとえば、システムに4つのREDOログ・グループが存在し、各グループが2つのメンバーを持っているとします。個別ディスク・アクセスを作成するには、8つのログ・ファイルにそれぞれ1a、1b、2a、2b、3a、3b、4a、4bのラベルを付けてください。この場合、最低でも4つのディスクと、アーカイブ・ファイル用に1つのディスクが必要です。
図8-1は、競合を最小限にするために、ディスク間でREDOメンバーを分散する方法を示しています。
この例では、LGWRはログ・グループ1（メンバー1aと1b）から切り替えられ、ログ・グループ2（2aと2b）に書込みを行います。同時に、アーカイバ・プロセスはグループ1から読込みをして、アーカイブ先に書込みを行います。REDOログ・ファイルがどのようにして競合から分離されているかに注意してください。
REDOログはシリアルに書き込まれるので、REDOログ・アクティビティ専用のドライブでは一般にヘッドの移動はわずかです。このため、ログ書込みのスピードが大幅に向上します。
この項では、I/Oシステムを構成する高水準の例を3つ示します。これらの例には、ディスク・トポロジやストライプ深度などを定義する計算例が含まれています。
I/O構成の最も簡単なアプローチは、すべての使用可能ディスクにまたがってストライプ化された、1つの大きなボリュームを作成することです。リカバリ能力を考慮して、ボリュームがミラー化されます（RAID 1）。ディスク当たりのストライプ化の単位は、頻繁なI/O操作のための最大I/Oサイズより大きくする必要があります。そうすると、ほとんどの場合は十分なパフォーマンスが得られます。
アーカイブ・ログが他のファイルと同じディスク・セット上でストライプ化されている場合、REDOログがアーカイブされる際、これらのディスク上のI/Oリクエストが影響を受けるおそれがあります。個別のディスクにアーカイブ・ログを移動する場合の利点は次のとおりです。
アーカイブ・ログ用のディスク数は、アーカイブ・ログ生成頻度およびアーカイブ記憶域の必要量により決定されます。
更新の多いOLTPシステムでは、REDOログは書込み中心です。他のディスクおよびアーカイブREDOログ・ファイルから分離されたディスクにREDOログ・ファイルを移動すると、次の利点があります。
REDOログ用のディスク数は、ほとんどの場合に、現行技術のディスク・サイズと比較して一般に小さいREDOログ・サイズで決定されます。一般に、2つのディスクを持つ構成（フォルト・トレランスのために4つのディスクにミラー化など）で十分です。特に、2つのディスク上でREDOログ・ファイルを交互に使用すると、1つのファイルにREDOログ情報を書き込む場合、アーカイブの完了したREDOログの読込みが妨げられません。
ファイル・システムを使用してすべてのOracleデータを取り込むシステムの場合、データベース管理はOracle Managed Filesを使用して簡単に行えます。表領域、テンポラリ・ファイル、オンライン・ログおよび制御ファイルについては、Oracleは内部的に標準ファイル・システム・インタフェースを使用して、必要に応じてファイルを作成および削除します。管理者は、特定のタイプのファイルに使用するファイル・システム・ディレクトリのみを指定します。データファイルについてはデフォルトの場所を1つ、制御ファイルおよびオンラインREDOログ・ファイルについては複数の場所を最大5つ指定できます。
Oracleでは、一意のファイルが作成された後、そのファイルが不要になると削除されます。このため、管理者が誤ったファイルを指定したことにより発生する破損、および廃止されたファイルで消費される無駄なディスク領域が減り、テスト・データベースおよび開発データベースの作成が簡素化されます。また、オペレーティング・システム固有のファイル名をSQLスクリプトに設定する必要がないため、ポータブルなサード・パーティのツールの開発を容易にします。
新しいファイルは管理ファイルとして作成できますが、古いファイルは古い方法で管理されます。したがって、データベースにはOracle Managed Filesと手動管理ファイルの両方を配置できます。
Oracle Managed Filesをチューニングする場合はいくつかの点に注意する必要があります。
8KBのブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTPシステムではより小さなブロック・サイズを、DSSシステムではより大きなブロック・サイズを使用することがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・サイズを選択するときの考慮事項を説明します。
データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読込み回数を最小にすることです。
同時実行性の高いOLTPシステムで、大きなブロック・サイズを使用する場合は、INITRANS、MAXTRANSおよびFREELISTSの適切な値について検討します。これらのパラメータは、ブロック内で許可されている更新の同時実行性の程度に影響を与えます。ただし、自動セグメント領域管理を使用する場合は、FREELISTSの値を指定する必要はありません。
選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシステムでは、8KBのデータベース・ブロック・サイズを試行してください。これは優れた妥協案であり、通常は有効です。8KBを超えるサイズが必要なのはLOBデータを処理するシステムのみです。
表8-3に、様々なブロック・サイズの長所と短所を示します。
|
 Copyright © 2000, 2008, Oracle Corporation. All Rights Reserved. |
|