ArcGIS Help 10.2 - Oracle の初期化パラメータ

ArcGIS を実行するために、Oracle インスタンスのデフォルト設定の変更は必須ではありません。ただし、大規模なシステムでは、Oracle インスタンスの設定をいくつか変更する必要があります。

Oracle インスタンスを起動するたびに、Oracle は init.ora ファイルまたは spfile.ora サーバパラメータファイルから初期化パラメータを読み取ります。これらのファイルはどちらもインスタンスの特性を定義しますが、管理方法は異なります。

init.ora ファイルは、ORACLE_BASE/admin/<ORACLE_SID>/pfile ディレクトリ（またはフォルダ）にあります。一般に、Oracle データベースインスタンスの初期化ファイルに与えられる名前は init.ora ですが、実際には特定のインスタンスのファイル名は init<ORACLE_SID>.ora になります。たとえば、Oracle システム ID（SID）が GIS である場合、このインスタンスの init.ora ファイルは initGIS.ora となります。

ALTER SYSTEM コマンドを使用してパラメータを変更すると、インスタンスがサーバパラメータファイルから起動された場合は、変更がサーバパラメータファイルに自動的に反映されます。init.ora ファイルを使用してインスタンスを起動した場合に、システムパラメータの変更を現在のデータベースインスタンスのみではなくその後も反映させるには、テキストエディタを使用してファイルを手動で編集する必要があります。

共有メモリに影響を与えるパラメータ

このセクションでは、共有メモリの割り当てを制御するパラメータについて説明します。Oracle の初期化パラメータの詳細については、使用しているバージョンの Oracle のドキュメントをご参照ください。

OPEN_CURSORS

OPEN_CURSORS 初期化パラメータは、1 つのセッションで一度に開くことのできるカーソルの数を指定します。デフォルト値は 300 です。セッションで新しいカーソルを開く際に、すでに最大数のカーソルを開いていた場合は、Oracle Error -1000 が返されます。ArcGIS では、パフォーマンスを向上させるために、頻繁に実行されるカーソルを開いたままにします。OPEN_CURSORS パラメータが十分に大きな値に設定されていないと、上記のエラーが発生します。Oracle のドキュメントによれば、パラメータを大きな値に設定しても、悪影響は何もありません。したがって、非常に大きな値（2,000 など）を設定することができます。これにより、実用の点では開いたカーソルの数が制限されなくなる一方で、膨大な量のカーソルリソースを消費しようとする悪意のあるプロセスに対する防御手段は引き続き提供されます。セッションで開かれるカーソルの予想数を計算したい場合は、組織のデータモデルに基づき、次の式をガイドラインとして使用することができます。

各種の ArcGIS データ管理カーソル（20）+
各種の匿名 PL/SQL ブロック（20）+
空間クエリ（レイヤにつき 6）+
ログファイルクエリ（11）+
バージョン対応登録されたテーブルの編集時に使用する各種クエリ（バージョン対応のテーブルまたはレイヤにつき 12）

したがって、ArcMap アプリケーションがドキュメントで 10 個のレイヤを編集する場合は、231 個のカーソル（20 + 20 + 60 + 11 + 120 = 231）が開く計算になります。カーソルが頻繁に不足する場合は、OPEN_CURSORS パラメータの値を 50 または 100 の単位で増やしてみてください。

注意:

Oracle 10g は、インスタンスで開かれたカーソルの数が 1,200 を超えた時点で、サーバアラートを生成するようにあらかじめ設定されています。1,200 個のカーソルを開くことはジオデータベースでは珍しくないため、このアラートの閾値を引き上げて、アラートキューの無駄な警告を削除することができます。

このパラメータの値を下げなければならない状況の 1 つとして、Oracle インスタンスを実行しているサーバ上のメモリリソースが不十分なために、各 Oracle 専用プロセスに十分なメモリを割り当てられない場合があります。専用プロセスのメモリ要件のサイズを取得するには、アプリケーションのプロトタイプを作成する必要があります。プロセスのメモリ要件は、複数の Oracle パラメータとアプリケーションの振舞い（SQL ステートメントなど）に左右される可能性があります。

SESSION_CACHED_CURSORS

Oracle は、各セッションで送信される SQL ステートメントを監視します。同じステートメントが複数回送信されたことを検出した場合は、そのステートメントをカーソルキャッシュへ移動し、再利用できるようにカーソルを開いたままにします。SESSION_CACHED_CURSORS パラメータは、カーソルキャッシュに配置できるカーソルの数を制御します。SESSION_CACHED_CURSORS パラメータのデフォルト値は、Oracle のリリースによって異なります。インスタンスのカーソルキャッシュのカーソル数が 50 未満に設定されている場合は、このパラメータの値を 50 に増やしてください。

UNDO_MANAGEMENT および UNDO_TABLESPACE

Oracle は、現在ユーザが変更しているデータのコピーを複数格納します。データを変更するトランザクションの実行中、元データのコピーは、他のセッションでのデータベース読み取り一貫性を提供するために使用されます。さらに、変更ユーザが ROLLBACK ステートメントを発行して変更内容を元に戻すことを選択するか、ユーザのプロセスがトランザクションの途中でクラッシュした場合、Oracle は作業内容を元に戻して、データベースを一貫した状態に復元する必要があります。

こうした状況をすべてサポートするために、Oracle は編集前のデータを特別なデータ構造（UNDO または ROLLBACK セグメント）に格納します。UNDO_MANAGEMENT または UNDO_TABLESPACE パラメータを設定すると、Oracle が UNDO セグメントを自動的に作成して管理するようになります。UNDO 管理を自動化するには、まず、UNDO_MANAGEMENT パラメータを auto に設定します。次に、UNDO_TABLESPACE パラメータをシステム管理の UNDO セグメントが格納される表領域の名前に設定します。

システム管理の UNDO セグメントの格納に任意の表領域を使用できないことに注意してください。そのための表領域は、作成時に UNDO 表領域として指定する必要があります。自動的な UNDO の監視と管理の詳細については、『Oracle Database 管理者ガイド』をご参照ください。

SESSIONS

ジオデータベースは、オペレーティングシステムに応じて、デフォルトでは 48 または 64 の同時接続を許可するように設定されています。SDE.SERVER_CONFIG データディクショナリテーブルで大量の接続を許可する場合は、新しい設定に合わせて SESSIONS パラメータを変更する必要があります。

SESSIONS パラメータは、Oracle が許可する同時セッションの合計数を直接制限します。デフォルト設定では予想される数のジオデータベース接続をサポートできない場合は、このパラメータに対して、現在予想される接続の数に（Oracle の内部関数をサポートするために）少なくとも 10% 上乗せした値を設定してください。

注意:

Oracle Shared Server 設定を使用する場合、SHARED_SERVER_SESSIONS パラメータは、共有サーバ接続にのみ適用されることを除いて、上記の SESSIONS パラメータと同様の役割を果たします。ただし、すべてのセッション（共有サーバ接続および専用サーバ接続）は、より一般的な SESSIONS パラメータによって制限されます。

PROCESSES

Oracle が生成できるプロセスの最大数を PROCESSES パラメータで制限することもできます。専用サーバ接続設定を使用する場合、このプロセスはデータベースがサポートする同時セッションの数にほぼ一致します。許可する接続の数を増やす場合は、PROCESSES パラメータを、少なくともジオデータベース接続の数に一般的な Oracle バックグラウンドプロセスの数である 25 を足した値に設定してください。

Oracle の統計情報に影響するパラメータ

OPTIMIZER_MODE

OPTIMIZER_MODE パラメータの値はデフォルトのままにしてください。Oracle 10g および 11g のデフォルト値は all_rows です。この設定はほとんどのジオデータベースに最適であり、ジオデータベースの全体的なスケーラビリティを向上させます。

メモリに影響を与えるパラメータ

メモリに影響を与える初期化パラメータを設定する場合には注意が必要です。ホストコンピュータの物理メモリリソースの限界を超えるパラメータを設定すると、パフォーマンスが著しく低下します。一般的には、サーバのデータベースには、サーバの物理メモリの 70 パーセント以上を割り当てないでください。

LOG_BUFFER

ログバッファは、Oracle SGA（System Global Area）のコンポーネントです。SGA は、Oracle のバックグラウンドプロセスがデータベースへのコミットされていない変更内容をディスク上の格納領域に書き込めるようになるまで、それらをメモリ上に保持します。これらの書き込みは頻繁に（少なくとも 3 秒おきに）発生するので、ログバッファに大きな領域を割り当てる必要はなく、1MB 未満のサイズに設定することができます。REDO ログバッファのサイズは、LOG_BUFFER パラメータによって制御されます。ログバッファのデフォルトサイズは、ほとんどのジオデータベースに適しています。ただし、書き込み操作が頻繁に行われるデータベースでは、複数のユーザがログバッファに同時にアクセスしようとして、パフォーマンスが低下することがあります。この状況を診断して緩和するには、ラッチ（回路）や待機イベントの監視など、高度なテクニックが要求されます。詳細については、『Oracle Database パフォーマンスチューニングガイド』と MetaLink Knowledge Base をご参照ください。

注意:

大量のデータを読み込むトランザクションを処理するために LOG_BUFFER に大きな値を設定すると、実際にはパフォーマンスが低下することがあります。ログバッファが大きすぎるために、トランザクション間でラッチ競合が発生することもあります。

SHARED_POOL_SIZE

共有プールも Oracle SGA のコンポーネントの 1 つであり、データディクショナリキャッシュとライブラリキャッシュの両方を保持します。データディクショナリキャッシュには、データオブジェクト、空き領域、権限などに関する情報が格納されます。ライブラリキャッシュには、最近解析された SQL ステートメントが格納されます。一般に、共有プールのサイズがライブラリキャッシュのリソース要件を満たすのに十分であれば、データディクショナリキャッシュを保持するのにも十分です。ジオデータベースでは、他の Oracle アプリケーションより大きな共有プールを使用することがパフォーマンスの向上に有効です。ArcGIS は、クライアントアプリケーションから送信された SQL ステートメントのキャッシュをメモリ上に保持します。共有プールを大きくすると、より多くのカーソルを開いたままにすることができるため、カーソル管理操作が削減され、パフォーマンスが向上します。共有プールのサイズは、SHARED_POOL_SIZE パラメータによって制御されます。Esri がサポートするすべてのシステムに対応できるように SHARED_POOL_SIZE パラメータを 16MB の倍数に設定することが推奨されます。少なくとも 128MB に設定してください。次に例を示します。

shared_pool_size = 128,000,000

たとえば公共設備やパーセル編集システムをサポートする負荷の高いジオデータベースでは、SHARED_POOL_SIZE パラメータを 250MB 程度に設定しなければならない場合もあります。

3 つの SGA バッファのうち、最も重要なのは共有プールです。SGA がすでに物理メモリのサイズで設定可能な最大サイズになっている場合は、バッファキャッシュのサイズを減らして共有プールのサイズを増やしてください。

DB_CACHE_SIZE

バッファキャッシュも Oracle SGA のコンポーネントの 1 つであり、最近使用されたデータブロックを格納します。データブロックは、Oracle のデータ転送の最小単位です。ユーザがデータベースを編集したり検索したりするたびに、データベースとの間でデータブロックが読み書きされます。バッファキャッシュのサイズは、DB_CACHE_SIZE パラメータによって制御されます。

共有プールやログバッファとは異なり、バッファキャッシュに推奨される最小サイズはありません。バッファキャッシュのサイズを設定するときの目標は、できるだけ多くのデータベースのデータメモリ上に保持することです。このため、システム全体のニーズについて検討した後、利用可能なメモリをすべてバッファキャッシュに割り当てるよう計画ください。そのための見積もりを取得する手順は次のとおりです。

サーバに搭載されている物理 RAM の量を確認します。
このサイズに 0.66 を掛けると、SGA の目安となるサイズが割り出されます。
このサイズから SHARED_POOL_SIZE と LOG_BUFFER の値を差し引くと、バッファキャッシュに利用できるメモリのサイズが算出されます。
Oracle が内部的に使用するメモリがあるので、この値を 10% 減らします。
さらに、これをデータベースブロックサイズで割ると、最終的な DB_BLOCK_BUFFERS のサイズが決定します。

たとえば、次のようになります。

memory available to SGA = physical RAM * 2/3

memory available to buffer cache
= (memory available to SGA - (shared_pool_size + log_buffer)) * 0.9

db_block_buffers 

= memory available to buffer cache / db_block_size

PGA_AGGREGATE_TARGET

Oracle サーバプロセスの PGA（Program Global Area）の領域を割り当てます。通常、この領域はテーブル結合時にデータのソートとマージを行うための一時バッファとして使用されます。WORKAREA_SIZE_POLICY を AUTO に設定した後、物理メモリの合計サイズに 0.16 を掛けた値で PGA_AGGREGATE_TARGET を初期設定します。アプリケーションをしばらく使用した後、『Oracle Database パフォーマンスチューニングガイド』の手順に従って、PGA_AGGREGATE_TARGET を調整します。

workarea_size_policy = auto
pga_aggregate_target = <total physical RAM * 0.16)

注意:

Oracle では、WORKSPACE_POLICY が AUTO に設定されている場合にのみ、PGA_AGGREGATE_TARGET を使用してソートのためのメモリを割り当てます。それ以外の場合は、以前の手動によるソート領域の管理を使用します。これには、SORT_AREA_SIZE パラメータと HASH_AREA_SIZE パラメータの設定が使用されます。

作業領域の自動管理

Oracle では、ユーザセッションを処理するサーバプロセスのプライベートメモリを自動的に管理することができます。ソート、ハッシュ、ビットマップインデックスの処理に使用される SQL 作業領域は、データベース管理者（DBA）が固定サイズに設定するのではなく、Oracle によって利用可能な大きなメモリプールからすべての PGA に対して動的に割り当てることができます。作業領域の自動管理を有効にするには、WORKAREA_SIZE_POLICY パラメータを AUTO に設定します。次に、PGA_AGGREGATE_TARGET パラメータの値としてサイズを指定することにより、すべての PGA に利用可能なメモリの合計サイズを設定します。デフォルトでは、PGA の集約サイズは SGA のサイズの 20% に設定されます。出発点としては申し分ありませんが、PGA のサイズは、SGA のサイズを基準にするのではなく、サーバプロセスによって実行される作業のタイプに基づいて設定すべきです。データベースが標準的な負荷で実行されるようになったら、実際の作業の負荷を監視して、PGA のサイズを微調整することができます。このプロセスの詳細については、『Oracle Database パフォーマンスチューニングガイド』をご参照ください。

共有メモリの自動管理

メモリの割り当てを自動で管理する Oracle 提供のメカニズムを活用する必要があります。メモリ管理の設定方法については、使用している Oracle のバージョンの『Oracle Database 管理者ガイド』をご参照ください。

その他の変更点

初期化パラメータではありませんが、UNDO_POOL データベースリソースマネージャプランディレクティブを設定すると、sde ユーザのコンシューマグループに圧縮処理のための大きな UNDO 領域を割り当てることができます。

使用するには、sde ユーザのコンシューマグループを設定し、UNDO_POOL プランディレクティブを変更して、このコンシューマグループの UNDO プールを無制限にする必要があります。

UNDO_POOL は、1 つのリソースグループのメンバー全員が一度に割り当てることのできる UNDO 領域の合計サイズを指定します。

編集にバージョン対応のジオデータベースを使用する場合は、圧縮処理を定期的に実施して古い情報を削除し、ジオデータベースのコンテンツをメンテナンスする必要があります。前回の圧縮処理以降、大量の編集が発生していた場合、新たな圧縮処理のため大きなトランザクションが作成され、大きな UNDO 領域が必要となる場合があります。UNDO_POOL の値が小さすぎると、圧縮処理が失敗して、パフォーマンスが低下するおそれがあります。可能であれば、sde ユーザのコンシューマグループの UNDO 領域を無制限に設定してください。それができない場合は、圧縮トランザクションのサイズを監視して、適切な大きさの UNDO 領域を選択する必要があります。

5/10/2014