| Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース1（11.1） E05743-02 |
|
 戻る |
 次へ |
I/Oサブシステムは、Oracleデータベースに不可欠なコンポーネントです。基本的なI/O概念を紹介し、データベースの様々な部分のI/O要件について説明し、I/Oサブシステムの設計のための構成例を示します。
この章には次の項があります。
Oracle Databaseでディスク上のデータを読み書きする際は、必ずディスクI/Oが生成されます。多くのソフトウェア・アプリケーションのパフォーマンスは、本質的にディスクI/Oによって制限されます。CPUタイムの大部分をI/Oアクティビティが完了するまでの待機に使用するアプリケーションはI/Oバウンドと呼ばれます。
Oracle Databaseは、適切に作成されたアプリケーションのパフォーマンスが、I/Oで制限されないように設計されています。I/Oシステムが最大限またはそれに近い状態で動作しており、許容時間内にI/Oリクエストに対応できない場合は、I/Oのチューニングを行うと、アプリケーションのパフォーマンスを向上できます。ただし、アプリケーションがI/Oバウンドではない場合（たとえば、CPUが制限要因である場合）、I/Oをチューニングしてもパフォーマンスを改善できません。
I/Oシステムを設計するときは、次のデータベース要件を考慮してください。
ディスクの最小容量などの記憶域
継続的（24時間×7日）または営業時間のみなどの可用性
I/Oスループットやアプリケーション・レスポンス時間などのパフォーマンス
多くのI/O設計では、パフォーマンスが問題とならないと仮定して記憶域要件および可用性要件の計画を立てています。ただし、これに該当しない場合もあります。構成するディスクおよびコントローラの数はI/Oスループットおよび冗長性の要件で判断することが最適です。この場合、ディスクのサイズは記憶域要件で判断できます。
I/O設計計画を作成する場合は、自動ストレージ管理（ASM）の使用を検討します。ASMは、高パフォーマンスの統合データベース・ファイル・システムおよびディスク・マネージャです。これは、記憶域の管理を、管理者を煩わせることなくデータベースによって行うという原則に基づくものです。
データベースのファイル・ストレージとして、RAWデバイスやオペレーティング・システムのファイル・システムではなく、ASMを使用することをお薦めします。ASMには次のような大きな利点があります。
ストライプ化
ミラー化
オンラインでの記憶域の再構成と動的リバランス
管理対象ファイルの作成と削除
|
関連項目: ASMの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
Oracle DatabaseのI/O測定機能では、ストレージ・サブシステムのパフォーマンスを評価し、I/Oパフォーマンス問題がデータベースとストレージ・サブシステムのどちらを原因とするかを判別できます。I/Oを連続的に発行する外部のI/O測定ツールとは異なり、Oracle DatabaseのI/O測定機能では、Oracleデータファイルを使用してI/Oをランダムに発行し、ストレージ・メディアにアクセスするため、よりデータベースの実際のパフォーマンスに近い結果を得ることができます。
この項では、Oracle DatabaseのI/O測定機能の使用方法について説明します。この項には、次の項目があります。
I/O測定を実行する前に、次の前提条件が満たされていることを確認してください。
ユーザーにSYSDBA権限が付与されている必要があります。
timed_statisticsがTRUEに設定されている必要があります。
非同期I/Oが有効化されている必要があります。
ファイル・システムを使用している場合、初期化パラメータFILESYSTEMIO_OPTIONSをSETALLに設定することで非同期I/Oを有効化できます。
次の問合せを実行し、データファイルに対して非同期I/Oが有効化されていることを確認してください。
COL NAME FORMAT A50 SELECT NAME,ASYNCH_IO FROM V$DATAFILE F,V$IOSTAT_FILE I WHERE F.FILE#=I.FILE_NO AND FILETYPE_NAME='DATA FILE';
また、1つのデータベース・インスタンスに一度に実行できる測定は、1回のみです。
Oracle DatabaseのI/O測定機能には、DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを通じてアクセスします。このプロシージャでは、データベース・ファイルにI/O集中型の読取り専用ワークロード（1MBのランダムI/Oで構成されるワークロード）を発行し、ストレージ・サブシステムが耐えられる最大IOPS（1秒当たりのI/Oリクエスト）とMBPS（1秒当たりのI/OのMB）を判定します。I/Oワークロードの実行によりオーバーヘッドが発生するため、I/O測定はデータベースがアイドル状態のとき（つまりピーク時以外の時間）にのみ実行し、通常のデータベース・ワークロードに対するI/Oワークロードの影響を最小化する必要があります。
I/O測定を実行し、Oracle Databaseで使用されるストレージ・サブシステムのI/O性能を評価するには、次のようにDBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを使用します。
SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/
DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを実行する場合、次のことを考慮してください。
同じストレージ・サブシステムを使用する個々のデータベース全体にプロシージャを複数回実行しないでください。
インスタンスに対するI/Oを最小化するため、データベースを静止します。
Oracle Real Application Clusters（RAC）構成の場合、ノード全体でストレージ・サブシステムを測定できるようすべてのインスタンスがオープン状態にあることを確認します。
プロシージャの実行時間は、ストレージ・サブシステム内のディスク数に応じて変化し、データベースのノード数とともに増加します。
場合によっては、非同期I/Oがデータファイルで許可されている一方で、非同期I/Oを発行するI/Oサブシステムが最大限度に達し、I/O測定を継続できなくなります。このような場合、ポート固有のドキュメントを参照して、システムの非同期I/Oの最大限度をチェックしてください。
I/O測定プロセス中は、いつでもV$IO_CALIBRATION_STATUSビューで測定ステータスを問い合せることができます。I/O測定が正常に完了したら、DBA_RSRC_IO_CALIBRATE表でその結果を参照できます。
|
関連項目:
|
この項では、収集する基本情報およびシステムのI/O構成を定義するときの決定事項について説明します。必要な可用性、リカバリ能力およびパフォーマンスは維持しながら、できるだけ単純な構成を維持します。構成が複雑になるに従って、管理、メンテナンスおよびチューニングが困難になります。
この項では、次の項目について説明します。
オペレーティング・システムにLVMソフトウェアまたはハードウェア・ベースのストライプ化がある場合、これらのツールを使用してI/Oを分散できます。LVMまたはハードウェア・ストライプ化を使用するときの決定事項には、ストライプ深度およびストライプ幅が含まれます。
ストライプ深度は、ストライプのサイズで、ストライプ単位とも呼ばれます。
ストライプ幅は、ストライプ深度とストライプ・セットを構成するドライブ数の積です。
これらの値を適切に選択して、システムが必要なスループットを維持できるようにします。Oracleデータベースにおける適切なストライプ深度は、256KB〜1MBです。ストライプ深度によって、得られるアプリケーションの利点の種類が異なります。最適なストライプ深度およびストライプ幅は、次の項目により異なります。
表8-1に、I/Oサイズの設定で使用できるOracleおよびオペレーティング・システムのパラメータを示します。
表8-1 Oracleおよびオペレーティング・システム操作パラメータ
| パラメータ | 説明 |
|---|---|
|
|
単一ブロックI/Oリクエストのサイズ。また、このパラメータをマルチブロック・パラメータと組み合せて使用して、マルチブロックI/Oリクエスト・サイズを決定します。 |
|
OSブロック・サイズ |
REDOログおよびアーカイブ・ログ操作のI/Oサイズを決定します。 |
|
最大OS I/Oサイズ |
単一I/Oリクエストのサイズに上限を設けます。 |
|
全表スキャンの最大I/Oサイズは、このパラメータに |
|
|
|
ソート操作のためのI/Oサイズおよび同時実行性を決定します。 |
|
|
ハッシュ操作のためのI/Oサイズを決定します。 |
I/Oサイズの他に、同時実行性の程度も理想的なストライプ深度を調べる上で役立ちます。ストライプ幅およびストライプ深度を選択する場合は、次の点を考慮してください。
同時実行性の低い（順次）システムでは、単一I/Oが同じディスクに2回アクセスしないようにします。たとえば、ストライプ幅が4つのディスクであり、ストライプ深度が32KBであると仮定します。1MBの単一I/Oリクエスト（たとえば、全表スキャンの場合）がOracleサーバー・プロセスで発行された場合、ストライプ内の各ディスクは要求されたデータを戻すために8回I/Oを実行する必要があります。このような状況を回避するために、平均I/Oのサイズは、ストライプ深度とストライプ幅の積より小さいサイズにしてください。そうでない場合は、オペレーティング・システムに対してOracle Databaseが単一I/Oリクエストを行うと、同じディスクに対して複数の物理I/Oリクエストが発生します。
同時実行性が高い（ランダム）システムでは、単一I/Oリクエストが複数の物理I/Oコールに分解されないようにしてください。そうでなければ、システムで実行される物理I/Oリクエスト数が何倍にもなり、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に、ランダム・アクセスおよび順次読取りでお薦めする最小ストライプ深度を示します。
表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のバランスを維持できます。
|
注意: ストライプ幅が小さくなるほど、ボリューム上にファイルを分散する時間の必要性が高くなり、このプロシージャは手動によるI/Oの分散に近づきます。 |
システムにLVMまたはハードウェアのストライプ化がない場合、各ファイルのI/O要件に従ってファイルを分散することにより、使用可能なディスク間でI/Oを手動でバランス化する必要があります。ファイルの配置に関する決定を行うには、データベース・ファイルのI/O要件およびI/Oシステムの機能についてよく理解している必要があります。このようなデータに慣れておらず、解析対象の代表的なワークロードを取得できない場合は、まず推定を行い、次に使用量がわかったときにこのレイアウトをチューニングします。
ディスクを手動でストライプ化するには、ファイルの記憶域要件をI/O要件と関連付ける必要があります。
ファイルおよびディスクのサイズをチェックして、データベースのディスク記憶域要件を評価します。
1ファイル当たりの予測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ログを、他のファイルのない1つのディスクに置きます。可用性も考慮します。すなわち、リカバリ能力の目的で、同じグループのメンバーは異なる物理ディスクおよびコントローラ上にあることが必要です。
他のファイルを格納しない個別のディスク上に各REDOログ・グループを置きます。
オペレーティング・システムのストライプ化ツールを使用して、複数のディスクにまたがってREDOログ・ファイルをストライプ化します。（この場合、手動ストライプ化は不可能です。）
REDOログにRAID 5を使用しないでください。
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リクエストが影響を受けるおそれがあります。個別のディスクにアーカイブ・ログを移動する場合の利点は次のとおりです。
非常に高速なアーカイブを実行できます（順次I/Oを使用）。
アーカイブ先のディスク上でレスポンス時間が低下しても、その影響を受けるものは他にありません。
アーカイブ・ログ用のディスク数は、アーカイブ・ログ生成頻度およびアーカイブ記憶域の必要量により決定されます。
更新の多いOLTPシステムでは、REDOログは書込み中心です。他のディスクおよびアーカイブREDOログ・ファイルから分離されたディスクにREDOログ・ファイルを移動すると、次の利点があります。
REDOログの書込みは、可能なかぎり高速で行われます。したがって、トランザクション処理のパフォーマンスは最高になります。
REDOログの書込みが他のI/Oで損われることはありません。
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は、RAWデバイスでは使用できません。 |
Oracle Managed Filesをチューニングする場合はいくつかの点に注意する必要があります。
Oracle Managed Filesではファイル・システムを使用する必要があるため、DBAはデータのレイアウト方法は管理しません。したがって、ファイル・システムを正しく構成することが重要です。
Oracle Managed Filesシステムは、ストライプ化をサポートするLVM上に構築する必要があります。ロード・バランシングおよびスループットの向上のために、Oracle Managed Filesシステム内のディスクをストライプ化する必要があります。
Oracle Managed Filesは、動的に拡張可能な論理ボリュームをサポートするLVM上で使用するときに最高の機能を発揮します。それ以外の場合は、論理ボリュームをできるだけ大きく構成する必要があります。
Oracle Managed Filesは、ファイル・システムに大きな拡張可能なファイルがある場合、最高の機能を発揮します。
|
関連項目: Oracle Managed Filesの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
8KBのブロック・サイズはほとんどのシステムにとって最適です。ただし、OLTPシステムではより小さなブロック・サイズを、DSSシステムではより大きなブロック・サイズを使用することがあります。この項では、最適なパフォーマンスを得るためにデータベース・ブロック・サイズを選択するときの考慮事項を説明します。この項には、次の項目があります。
|
注意: 管理性の問題があるため、単一データベース・インスタンスでの複数のブロック・サイズの使用はお薦めしません。 |
データのサイズとは関係なく、目標は必要なデータを取り出すために必要な読取り回数を最小にすることです。
行が小さく、アクセスがきわめてランダムな場合は、小さなブロック・サイズを選択します。
行が小さく、アクセスがきわめて順次である場合は、大きなブロック・サイズを選択します。
行が小さく、アクセスがランダムかつ順次である場合は、大きなブロック・サイズを選択するのが有効です。
行が大きい（たとえば、ラージ・オブジェクト（LOB）データが含まれている）場合は、大きなブロック・サイズを選択します。
同時実行性の高いOLTPシステムで、大きなブロック・サイズを使用する場合は、INITRANS、MAXTRANSおよびFREELISTSの適切な値について検討します。これらのパラメータは、ブロック内で許可されている更新の同時実行性の程度に影響を与えます。ただし、自動セグメント領域管理を使用する場合は、FREELISTSの値を指定する必要はありません。
選択する必要があるブロック・サイズが不明な場合、多数のトランザクションを処理するシステムでは、8KBのデータベース・ブロック・サイズを試行してください。これは優れた妥協案であり、通常は有効です。8KBを超えるサイズが必要なのはLOBデータを処理するシステムのみです。
|
関連項目: 使用しているプラットフォームの最小および最大のブロック・サイズは、オペレーティング・システム固有のOracleマニュアルを参照してください。 |
表8-3に、様々なブロック・サイズの長所と短所を示します。
表8-3 ブロック・サイズの長所と短所
| ブロック・サイズ | 長所 | 短所 |
|---|---|---|
|
小さい |
行数が少なく大量のランダム・アクセスに適しています。 ブロック競合が低減されます。 |
メタデータ（すなわち、ブロック・ヘッダー）による比較的大きな領域のオーバーヘッドがあります。 行が大きい場合にはお薦めできません。1行がブロックに収まらない場合、1ブロック当たりの格納行数がわずかになったり、さらには行の連鎖が発生する可能性があります。 |
|
大きい |
オーバーヘッドが少ないため、データを格納する空間が多くなります。 1回のI/Oでバッファ・キャッシュに多数の行を読み取れます（行サイズおよびブロック・サイズにより異なります）。 順次アクセスまたは非常に大きな行（LOBデータなど）に適しています。 |
ブロック・サイズが大きい場合に少数の行にランダム・アクセスすると、バッファ・キャッシュ内の領域が消費されます。たとえば、8KBのブロック・サイズと50バイトの行サイズでは、ランダム・アクセスを行うときにバッファ・キャッシュ内の7,950バイトが消費されます。 OLTP環境で使用される索引ブロックには適しません。これは、索引リーフ・ブロック上のブロック競合が増えるためです。 |
