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 の初期化パラメーターの詳細については、使用しているバージョンの Oracle のドキュメントをご参照ください。
OPEN_CURSORS
OPEN_CURSORS 初期化パラメーターは、1 つのセッションで一度に開くことのできるカーソルの数を指定します。デフォルト値は 300 です。セッションで新しいカーソルを開く際に、すでに最大数のカーソルを開いていた場合は、Oracle Error -1000 が返されます。ArcGIS では、パフォーマンスを向上させるために、頻繁に実行されるカーソルを開いたままにします。OPEN_CURSORS パラメーターが十分に大きな値に設定されていないと、上記のエラーが発生します。Oracle のドキュメントによれば、パラメーターを大きな値に設定しても、悪影響は何もありません。したがって、非常に大きな値 (2,000 など) を設定することができます。これにより、実用の点では開いたカーソルの数が制限されなくなる一方で、膨大な量のカーソル リソースを消費しようとする悪意のあるプロセスに対する防御手段は引き続き提供されます。セッションで開かれるカーソルの予想数を計算したい場合は、組織のデータ モデルに基づき、次の式をガイドラインとして使用することができます。ArcGIS では、決められた数のカーソルのうちの 80% が開くことを認識しておいてください。これにより、Oracle プロセスが残りの 20% を使用できるようになります。
- 各種の ArcGIS データ管理カーソル (20) +
- 各種の匿名 PL/SQL ブロック (20) +
- 空間クエリ (フィーチャクラスにつき 6) +
- ログ ファイル クエリ (11) +
- バージョン対応登録されたテーブルの編集時に使用する各種クエリ (バージョン対応のテーブルまたはレイヤーにつき 12)
したがって、ArcMap で 10 個のレイヤーを編集する場合は、231 個のカーソル (20 + 20 + 60 + 11 + 120 = 231) が開く計算になります。この場合は、デフォルト設定の 300 OPEN_CURSORS で十分です。この設定を使用すると、開いている 240 個のカーソルが ArcGIS で保持されます。ただし、カーソルが頻繁に不足する場合は、OPEN_CURSORS パラメーターの値を 50 または 100 刻みで増やしてもかまいません。
SESSION_CACHED_CURSORS
Oracle は、各セッションで送信される SQL ステートメントを監視します。同じステートメントが複数回送信されたことを検出した場合は、そのステートメントをカーソル キャッシュへ移動し、再利用できるようにカーソルを開いたままにします。SESSION_CACHED_CURSORS パラメーターは、カーソル キャッシュに配置できるカーソルの数を制御します。SESSION_CACHED_CURSORS パラメーターのデフォルト値は、Oracle のリリースによって異なります。インスタンスのカーソル キャッシュのカーソル数が 50 未満に設定されている場合は、このパラメーターの値を 50 に増やしてください。
SESSIONS
ジオデータベースは、ジオデータベースへの接続を無制限に許可するように構成されます。ジオデータベースに対して多数の同時接続が発生することが予想される場合、それに対応するために、Oracle SESSIONS パラメーターの変更が必要になります。
SESSIONS パラメーターは、Oracle が許可する同時セッションの合計数を直接制限します。デフォルト設定では予想される数のジオデータベース接続をサポートできない場合は、このパラメーターに対して、現在予想される接続の数に (Oracle の内部関数をサポートするために) 少なくとも 10% 上乗せした値を設定してください。
PROCESSES
Oracle が生成できるプロセスの最大数を PROCESSES パラメーターで制限することもできます。専用サーバー接続設定を使用する場合、このプロセスはデータベースがサポートする同時セッションの数にほぼ一致します。PROCESSES パラメーターは、必ず予想されるジオデータベースの同時接続数に 25 (Oracle の標準的なバックグラウンド プロセスの数) を足した数以上になるように設定してください。
Oracle の統計情報に影響するパラメーター
OPTIMIZER_MODE
OPTIMIZER_MODE パラメーターの値はデフォルト (all_rows) のままにしてください。この設定はほとんどのジオデータベースに最適であり、ジオデータベースの全体的なスケーラビリティを向上させます。
メモリに影響を与えるパラメーター
メモリに影響を与える初期化パラメーターを設定する場合には注意が必要です。ホスト コンピューターの物理メモリ リソースの限界を超えるパラメーターを設定すると、パフォーマンスが著しく低下します。一般的には、サーバーのデータベースには、サーバーの物理メモリの 70 パーセント以上を割り当てないでください。
SHARED_POOL_SIZE
共有プールは、Oracle SGA (System Global Area) のコンポーネントであり、データ ディクショナリ キャッシュとライブラリ キャッシュの両方を保持します。データ ディクショナリ キャッシュには、データ オブジェクト、空き領域、権限などに関する情報が格納されます。ライブラリ キャッシュには、最近解析された 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 がすでに物理メモリのサイズで設定可能な最大サイズになっている場合は、バッファー キャッシュのサイズを減らして共有プールのサイズを増やしてください。
作業領域と共有メモリの自動管理の使用
作業領域とメモリ割り当てを自動で管理する Oracle 提供のメカニズムを活用してください。作業領域とメモリの管理の設定方法については、使用している Oracle のバージョンの『Oracle Database 管理者ガイド』をご参照ください。
その他の変更点
初期化パラメーターではありませんが、UNDO_POOL データベース リソース マネージャー プラン ディレクティブを設定すると、sde ユーザー のコンシューマー グループに圧縮処理のための大きな UNDO 領域を割り当てることができます。
使用するには、sde ユーザーのコンシューマー グループを設定し、UNDO_POOL プラン ディレクティブを変更して、このコンシューマー グループの UNDO プールを無制限にする必要があります。
UNDO_POOL は、1 つのリソース グループのメンバー全員が一度に割り当てることのできる UNDO 領域の合計サイズを指定します。
編集にバージョン対応のジオデータベースを使用する場合は、圧縮処理を定期的に実施して古い情報を削除し、ジオデータベースのコンテンツをメンテナンスする必要があります。前回の圧縮処理以降、大量の編集が発生していた場合、新たな圧縮処理のため大きなトランザクションが作成され、大きな UNDO 領域が必要となる場合があります。UNDO_POOL の値が小さすぎると、圧縮処理が失敗して、パフォーマンスが低下するおそれがあります。可能であれば、sde ユーザーのコンシューマー グループの UNDO 領域を無制限に設定してください。それができない場合は、圧縮トランザクションのサイズを監視して、適切な大きさの UNDO 領域を選択する必要があります。