ヘッダーをスキップ
Oracle Database Java開発者ガイド
10gリリース2(10.2)
B19189-01
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

10 Oracle Database Javaアプリケーションのパフォーマンス

Javaアプリケーションのパフォーマンスは、次の方法で向上させることができます。

10.1 ネイティブ・コンパイル・コード

Java言語は、プラットフォームに依存しない安全な開発モデル用に設計されました。この目標を達成するために、実行パフォーマンスがいくらか低下しました。これは、Javaのバイトコードをマシン命令に変換することによってパフォーマンスが低下するためです。特定のクラスをネイティブにコンパイルすると、低下したパフォーマンスをいくらか取り戻すことができます。たとえば、CPU集中型のクラスでコードをネイティブにコンパイルできます。

ネイティブ・コンパイルを使用しないと、サーバーにロードしたJavaコードが解析され、そのコードの基礎となるコア・クラス(java.lang.*など)がネイティブにコンパイルされます。

ネイティブ・コンパイルを使用すると、バイトコードを解析する場合と比較して、実行速度が2〜10倍高速化されます。ただし、厳密にどの程度高速化されるかは、次のような複数の要因によって異なります。

Javaバイトコードはコンパクトに設計されているため、ネイティブにコンパイルされるコードは、元のバイトコードよりもかなり大きくなる場合があります。ただし、ネイティブ・コードは共有ライブラリに格納されるため、データベースの全ユーザー間で共有されます。

ほとんどのJava仮想マシン(JVM)では、メソッドのコール時にJavaバイトコードをネイティブのマシン命令に変換するJust-In-Time(JIT)コンパイラが使用されています。Acceleratorでは、Ahead-Of-Timeコンパイラを使用してJavaクラスを再コンパイルします。 次の表で、ネイティブ・コンパイラについて簡単に説明します。

ネイティブ・コンパイラ 説明
Just-In-Time JVMには、アプリケーションから要求される直前にJava命令を変換する機能が提供されています。ネイティブ・コンパイラがどの程度正確にコード・ブランチと次の命令を予測するかによって、効果が異なります。予測が不正確な場合、パフォーマンスは向上しません。
Ahead-Of-Time Acceleratorは、実行前に、Javaアーカイブ(JAR)ファイル内のすべてのJavaコードを、Javaパッケージによって編成されるネイティブな共有ライブラリに、ネイティブにコンパイルします。実行時に、Acceleratorは、Javaパッケージがネイティブにコンパイルされているかどうかをチェックします。ネイティブにコンパイルされている場合、Acceleratorは、配置されたJavaコードを解析せずにマシン・コード・ライブラリを使用します。

この静的なコンパイル方法によって、ユーザー数やサーバー上を横断するコード・パスに関係なく、一定した多大なパフォーマンスの向上が得られます。コンパイル後は、loadjavaユーティリティを使用して、静的にコンパイルされたライブラリをOracle Databaseにロードでき、ユーザー、プロセスおよびセッション間で共有できます。

この項の内容は、次のとおりです。

10.1.1 Acceleratorの概要

ほとんどのAhead-Of-Timeネイティブ・コンパイラは、バイトコードをプラットフォームに依存した言語に直接コンパイルします。これは、移植性の要件としては望ましくありません。図10-1は、AcceleratorがJavaクラスをプラットフォームに依存しないCのバージョンに変換する方法を示します。Cコードはコンパイルおよびリンクされ、最終的にプラットフォームに依存する、ネイティブにコンパイルされた共有ライブラリまたはダイナミック・リンク・ライブラリ(DLL)として提供されます。

図10-1 Acceleratorを使用したネイティブ・コンパイル

Acceleratorを使用したネイティブ・コンパイル
画像の説明

JARファイルを指定すると、Acceleratorでは次の処理が実行されます。

  1. データベースにロードされたクラスを検証します。

  2. これらのクラスのJavaバイトコードをデータベースから取得して、Acceleratorがコールされたプロジェクト・ディレクトリに格納します。

  3. JavaバイトコードをCコードに変換します。

  4. プラットフォームのCコンパイラを使用して、Cコードをコンパイルおよびリンクします。

    Acceleratorは、クライアントで取得されたクラスを変換、コンパイルおよびリンクします。このため、このアプリケーションの配置先のプラットフォーム環境では、コードをネイティブにコンパイルする必要があります。その結果、プロジェクト内のすべてのクラスに対して1つの配置JARファイルが生成されます。

  5. 生成された共有ライブラリは、$ORACLE_HOME/javavm/adminディレクトリにロードされます。


注意:

Acceleratorでネイティブにコンパイルされたライブラリは、Oracle Database内でのみ使用できます。さらに、これらのライブラリは、そのライブラリが生成されたOracle Databaseと同じバージョン内でのみ使用できます。アプリケーションをそれ以降のリリースでネイティブにコンパイルする場合は、これらのクラスを再コンパイルする必要があります。つまり、既存のライブラリのネイティブな再コンパイルは、どのアップグレード・プロセスでも自動的には実行されません。

10.1.2 Oracle DatabaseのコアなJavaクラス・ライブラリ

すべてのコアなJavaクラス・ライブラリ、およびOracle Database内のOracle提供のJavaコードは、実行速度を高めるためにネイティブにコンパイルされます。Javaクラスは$ORACLE_HOME/javavm/adminに共有ライブラリとして格納され、各共有ライブラリはJavaパッケージに対応しています。たとえば、Sun社のSolarisのorajox10java_lang.soおよびMicrosoft社のWindowsのorajox10java_lang.dllには、java.langクラスが保持されています。パッケージ化とネーミングの仕様は、プラットフォームによって異なる場合があります。Oracle JVMは、ネイティブにコンパイルされたJavaファイルを内部で使用し、実行時に必要に応じてオープンします。

10.1.3 Javaアプリケーションのクラス・ライブラリのネイティブ・コンパイル

コマンドライン・ツールであるncompは、コードをネイティブにコンパイルしてOracle DatabaseにロードするAcceleratorです。ただし、ncompを使用するには、最初にインストールの要件を満たす必要があります。

Acceleratorをコールする前に、次の作業を実行する必要があります。

  1. ncompを実行するコンピュータに、使用するプラットフォーム用のCコンパイラをインストールします。

  2. $ORACLE_HOME/javavm/jahomeディレクトリにあるSystem*.propertiesファイル内で正しいコンパイラ・コマンドとリンカ・コマンドが参照されていることを確認します。コンパイラおよびリンカの情報はプラットフォーム固有であるため、これらの項目の構成は、使用するプラットフォームのREADMEを参照してください。

  3. JAVA_HOME環境変数を、Java Development Kit(JDK)のインストール先に設定します。

  4. ncompを実行するユーザーに、次のロール・パーミッションとセキュリティ・パーミッションを付与します。

    1. JAVA_DEPLOY

      ユーザーには、ncompdeployncの両方のユーティリティを使用して実行可能なサーバーに共有ライブラリを配置できるように、JAVA_DEPLOYロールを割り当てる必要があります。たとえば、次のように、このロールをユーザーDAVEに割り当てることができます。

      SQL> GRANT JAVA_DEPLOY TO DAVE;
      
      
    2. FilePermission

      Acceleratorは、ネイティブにコンパイルされたコードが含まれる共有ライブラリをサーバーに格納します。Acceleratorで共有ライブラリを格納するために、ユーザーには、サーバー上の$ORACLE_HOMEにあるディレクトリやファイルへの読取りと書込みのアクセス権FilePermissionを付与する必要があります。対象となるすべてのディレクトリにFilePermissionを付与する方法の1つとして、次のようにユーザーにJAVASYSPRIVロールを付与します。

      SQL> GRANT JAVASYSPRIV TO DAVE;
      
      

      $ORACLE_HOMEがサーバー上の/private/oracleと同じ場合は、この権限付与を実行するパーミッションを保持しているパーティごとに次の権限付与を実行する必要があります。

      call dbms_java.grant_permission(<user>, 'java.io.FilePermission', '/private/oracle/-', 'read,write');
      
      

      次に、LarryがDaveに$ORACLE_HOMEに対するFilePermissionを付与する例を示します。この例では、$ORACLE_HOME/private/oracleにあります。grant_permission()メソッドに環境変数を指定することはできません。終了後に、Daveはncompを実行できます。

      connect larry/larry
      
      REM Grant DAVE permission to read and write the ncomp file.
      call dbms_java.grant_permission('DAVE', 'java.io.FilePermission', '/private/oracle/-','read,write');
      
      REM commit the changes to the PolicyTable
      commit;
      
      

    注意:

    DBAロールには、JAVA_DEPLOYロール、および$ORACLE_HOMEのすべてのファイルに対するFilePermissionが含まれています。

10.1.4 Acceleratorの実行

JARファイルに含まれるすべてのJavaクラスは、すでにデータベース内にロードされている必要があります。ncompツールを実行して、すべてのクラスをネイティブにコンパイルするようにAcceleratorに指示します。次のコードによって、pubProject.jarファイル内のすべてのクラスがネイティブにコンパイルされます。

ncomp -user scott/tiger pubProject.jar


注意:

ネイティブ・コンパイルではすべてのJavaクラスをコンパイルしてリンクする必要があるため、このプロセスの実行には数時間かかる場合があります。コードをネイティブにコンパイルするために要する時間は、コンパイルするクラスの数、およびコンピュータのハードウェアのタイプによって異なります。

このJARファイル内の任意のクラスを変更した場合、Acceleratorは、変更されたクラスが含まれるパッケージの共有ライブラリを再コンパイルします。この場合、すべての共有ライブラリを再コンパイルするわけではありません。ただし、以前にネイティブにコンパイルされたかどうかに関係なく、JARファイル内のすべてのクラスを再コンパイルするには、次のように、-forceオプションを指定してncompを実行します。

ncomp -user scott/tiger -force pubProject.JAR

10.1.5 ncompツール

ncompツール内に実装されているAcceleratorは、指定したJARファイル、ZIPファイルまたはクラス・リスト内のすべてのクラスをネイティブにコンパイルします。Acceleratorは、これらのクラスをネイティブにコンパイルし、パッケージに従って共有ライブラリに配置します。クラスは、最初にデータベースにロードする必要があることに注意してください。

クラスがJARファイル内で指定され、すでにデータベースにロードされている場合は、次のように、Javaクラスをネイティブにコンパイルできます。

ncomp -user SCOTT/TIGER myClasses.jar

ネイティブ・コンパイルの詳細を管理できるオプションがいくつかあります。

構文

ncomp [ options ] class_designation_file
  -user | -u username/password [@database_url]
  [-load]
  [-projectDir | -d project_directory]
  [-force]
  [-lightweightDeployment]
  [-noDeploy]
  [-outputJarFile | -o jar_filename]
  [-thin]
  [-oci | -oci8]
  [-update]
  [-verbose]

引数の概要

表10-1は、ncompの引数の一覧です。class_designation_fileは、file.jarfile.zipまたはfile.classesファイルになります。

表10-1 ncompの引数の概要

引数 説明および値
file.jar ネイティブにコンパイルされるクラスが格納されているJARファイルのフルパス名とファイル名。JARファイルがあるディレクトリ内でncompを実行して、-projectDirオプションを指定しない場合、指定するのはJARファイル名のみで構いません。
file.zip ネイティブにコンパイルされるクラスが格納されているZIPファイルのフルパス名とファイル名。ZIPファイルがあるディレクトリ内でncompを実行して、-projectDirオプションを指定しない場合、指定するのはZIPファイル名のみで構いません。
file.classes ネイティブにコンパイルされるクラスのリストが格納されているクラス・ファイルのフルパス名とファイル名。クラス・ファイルがあるディレクトリ内でncompを実行して、-projectDirオプションを指定しない場合、指定するのはクラス・ファイル名のみで構いません。
-user | -u username/password [@database_url] ユーザー、パスワードおよびデータベース接続文字列を指定します。ファイルはこのデータベース・インスタンスにロードされます。このオプションにデータベースURLを指定する場合は、Oracle Call Interface(OCI)構文を使用して指定する必要があります。JDBC ThinデータベースURLを指定するには、-thinオプションを使用します。
-force すべてのクラスでネイティブ・コンパイルを実行します。以前にコンパイルされたクラスは渡されません。
-lightweightDeployment 共有ライブラリを配置するためのオプション、およびネイティブ・コンパイル情報を個別に提供します。この引数は、配置時にリソースを保持する必要がある場合に便利です。
-load 指定したクラス指定ファイルでloadjavaを実行します。このオプションは、file.classesのファイルと組み合せて使用することはできません。
-outputJarFile jar_filename ネイティブにコンパイルされたすべてのクラスの出力を、配置JARファイルに格納します。このオプションでは、配置JARファイルの名前とその接続先ディレクトリを指定します。指定しない場合、ncompツールでは、入力ファイルに接尾辞_depl.jarを追加した名前を、出力する配置JARファイルの名前とします。ディレクトリを指定しないと、出力するJARファイルはプロジェクト・ディレクトリ(-projectDirで示されます)に格納されます。
-noDeploy ネイティブ・コンパイルの結果は出力する配置JARファイルのみに反映し、サーバーに配置しないことを指定します。出力された配置JARファイルは、deployncツールを使用して、任意のサーバーに配置できます。
-thin -userオプションで指定されたデータベースURLでは、データベースURL構文のJDBC Thin URLアドレスが使用されます。
-oci | -oci8 -userオプションで指定されたデータベースURLでは、データベースURL構文のOCI URLアドレスが使用されます。ただし、-ociまたは-thinのいずれも指定しない場合は、OCIのデータベースURLを使用したとみなされます。
-projectDir | -d absolute_path プロジェクト・ディレクトリのフルパスを指定します。指定しない場合、Acceleratorは、ncompがコールされたディレクトリをプロジェクト・ディレクトリとして使用します。このディレクトリは、すでに存在している必要があります。つまり、ツールではこのディレクトリを作成しません。このディレクトリが存在しない場合は、カレント・ディレクトリが使用されます。
-update すでにネイティブにコンパイルされているclass_designation_fileにクラスを追加する場合は、このフラグを使用して、配置JARファイルが新規クラスの追加によって更新されることをAcceleratorに通知します。これによって、Acceleratorは、新規クラスをコンパイルして、適切な共有ライブラリに追加します。配置JARファイルは更新されます。
-verbose ネイティブ・コンパイル・テキストの詳細を出力します。

引数の詳細

表10-1は、すべての引数の一覧です。この項では、次の引数の詳細を説明します。

  • user

    {-user | -u} user/password[ @database_url ]
    
    

    @database_urlの形式は、-oci(デフォルト)を指定するか、または-thinを指定するかによって異なります。

    • -oci:@database_urlはオプションです。指定しない場合、ncompはユーザーのデフォルト・データベースを使用します。指定した場合、database_urlはTNS名またはOracle Net Servicesの名前/値リストのいずれかになります。

    • -thin:@database_urlは必須です。形式はhost:lport:SIDです。

      各項目は次のとおりです。

      • hostは、データベースが動作しているコンピュータの名前です。

      • lportは、Oracle Net Services接続のリスニング用に構成されたリスナー・ポートです。デフォルト・インストールでは5521です。

      • SIDは、データベース・インスタンスの識別子です。デフォルト・インストールではORCLです。

  • lightweightDeployment

    Acceleratorは、コンパイル情報とコンパイル済の共有ライブラリを1つのJARファイルに格納し、共有ライブラリをサーバー上の$ORACLE_HOME/javavm/adminにコピーして、コンパイル情報をサーバーに配置します。使用しているサーバー上に共有ライブラリを配置する場合は、lightweightDeploymentオプションを使用します。このオプションを使用すると、次の2つの手順で配置を実行できます。

    1. -noDeployオプションと-lightweightDeploymentオプションを使用して、JARファイルをネイティブにコンパイルします。これによって、推移閉包情報などのncomp情報のみ含まれた配置JARファイルが作成されます。共有ライブラリは、配置JARファイルに保存されません。この結果、配置JARファイルのサイズはかなり小さくなります。

    2. 次の手順で配置します。

      ネイティブ・コンパイルのプロジェクト・ディレクトリであるlibディレクトリからサーバーの$ORACLE_HOME/javavm/adminに、出力されたすべての共有ライブラリをコピーします。


      注意:

      このディレクトリに書き込むには、FilePermission権限が必要です。FilePermissionは、DBAおよびJAVASYSPRIVロールに含まれています。

      deployncを使用して、軽量の配置JARファイルをサーバーに配置します。

エラー

ネイティブ・コンパイル時に発生したエラーは、スクリーンに出力されます。共有ライブラリのサーバーへの配置時、または実行時に発生したエラーは、statusncツールを使用するか、またはJACCELERATOR$DLL_ERRORS表を参照して表示できます。

指定したクラスのネイティブ・コンパイル中にエラーが発生した場合、Acceleratorはエラーを表示し、現行パッケージでの作業を中止して、次のパッケージに関するコンパイル作業を継続します。ネイティブ・コンパイルは残りのパッケージに継続されます。エラーが発生したクラスを含んだパッケージが、ネイティブ・コンパイルされることはありません。

エラーが発生したクラスの問題を解決した後は、次のいずれかの処理を実行できます。

  • 共有ライブラリの再コンパイル

  • データベースへのJavaクラスの再ロード

クラスを再コンパイルせず、訂正したJavaクラスをデータベースにロードする場合、訂正したクラスとそのクラスの解決検証に含まれている全クラスは、インタプリタ・モードで処理されます。これらのクラスは、同じ共有ライブラリ内に配置されているかどうかに関係なく処理されます。つまり、JVMでは、これらのクラスをネイティブに実行しません。ネイティブにコンパイルされた他のすべてのクラスは、ネイティブ形式で実行が継続されます。再ロードしたクラス、または任意の参照先クラスでstatusncコマンドを実行すると、これらのクラスには、NEED_NCOMPINGステータス・メッセージが表示されます。

Javaクラスで発生する可能性があるエラーは、次のとおりです。

  • Javaクラスがデータベース内に存在しない場合。JavaクラスをOracle Databaseにロードしていない場合、Acceleratorはそのクラスを共有ライブラリに格納しません。そのクラスの処理はスキップされます。

  • Javaクラスが無効な場合。つまり、参照の1つが検出できない場合。

  • Javaクラスが未解決の場合、Acceleratorは、ネイティブにコンパイルする前にそのクラスを解決しようとします。ただし、解決できない場合、Acceleratorはそのクラスを無視します。

ネイティブにコンパイルされたJARファイルの配置時に発生する可能性があるエラーは、JARファイルのネイティブ・コンパイルは正常に実行されたが、配置に失敗した場合です。この場合は、JARファイルを再コンパイルせず、deployncコマンドを使用して、ネイティブにコンパイルされた出力JARファイルを配置します。

10.1.6 ネイティブ・コンパイルの使用例

次の使用例では、ncompツールの各オプションの使用方法を説明します。

テスト・プラットフォームでのネイティブ・コンパイル(Javaクラスがデータベースにロード済の場合)

すべてのクラスをデータベースにロードし、アプリケーションのテストが完了している場合は、Acceleratorを使用して、テスト済のクラスをネイティブにコンパイルできます。Acceleratorは、JARファイル、ZIPファイル、またはクラス・リストが格納されているファイルを受け入れて、ネイティブ・コンパイルに含めるパッケージとクラスを判断します。次に、指定されたすべてのクラスをサーバーから取得し、共有ライブラリにネイティブにコンパイルします。各ライブラリには、クラスの単一のパッケージが含まれています。

クラスがすでにサーバーにロードされている場合は、次のコマンドを実行して、pubProject.jarファイルなどのクラス指定ファイル内にリストされているすべてのクラスをネイティブにコンパイルします。

ncomp -user SCOTT/TIGER pubProject.jar

クラス指定ファイル内にある任意のクラスを変更して再コンパイルを要求すると、Acceleratorは、変更されたクラスが含まれているパッケージのみ再コンパイルします。すべてのパッケージを再コンパイルするわけではありません。

データベース内にロードされていないJavaクラスのネイティブ・コンパイル

指定したクラスをテストした後、そのクラスをテスト・コンピュータとは別のホストにネイティブにコンパイルする場合があります。この場合は、指定したクラス・ファイルをプラットフォームに転送した後、ネイティブ・コンパイルを実行する前に、そのファイル内のクラスをデータベースにロードする必要があります。次のコマンド例では、loadjavaを使用してクラスをロードし、クラス指定ファイルpubProject.jar内のクラスのネイティブ・コンパイルを実行します。

ncomp -user SCOTT/TIGER@dbhost:5521:orcl -thin -load pubProject.jar

将来の配置のためのクリーン・コンパイルと出力の生成

以前にネイティブ・コンパイルされたかどうかに関係なく、クラス指定ファイル内のすべてのクラスを再コンパイルする場合は、-forceオプションを指定してncompを実行します。-forceオプションを使用すると、すべてのクラスがコンパイルされ、他のOracle Databaseインスタンスに配置できる配置JARファイルの作成が保証されます。ネイティブ・コンパイルの配置JARファイルは、-outputJarFileオプションを使用して指定できます。次のコマンド例では、強制的にクラス指定ファイルpubProject.jar内のすべてのJavaクラスを再コンパイルし、pubworks.jarという名前の配置JARファイルを作成します。

ncomp -user SCOTT/TIGER -force -outputJarFile pubworks.jar pubProject.jar

配置JARファイルには、クラスの共有ライブラリとその共有ライブラリに対して指定されたインストール・クラスが格納されます。元のJavaクラスは格納されません。ネイティブにコンパイルされた配置JARファイルを、適切なプラットフォーム・タイプの任意のOracle Databaseインスタンスに配置するには、次の手順を実行する必要があります。

  1. 元のJavaクラスを接続先サーバーにロードします。たとえば、クラス指定ファイルpubProject.jarは、loadjava ツールを使用してデータベースにロードされます。

  2. deployncツールを使用して、ネイティブにコンパイルされた配置JARファイルを配置します。

ネイティブ・コンパイルの作成環境の管理

デフォルトでは、Acceleratorは、ncompが実行されたディレクトリを作成環境として使用します。さらに、このディレクトリに複数のクラス・ファイルをダウンロードし、コンパイルとリンクのプロセスでこのディレクトリを使用します。

Acceleratorが任意のファイルをカレント・ディレクトリに格納しないようにするには、作業ディレクトリを作成し、-projectDirオプションを使用して、その作業ディレクトリをプロジェクト・ディレクトリに指定します。次のコマンド例では、Acceleratorで/tmp/jaccel/pubCompedを作成ディレクトリとして使用するように指定します。

ncomp -user SCOTT/TIGER -projectDir /tmp/jaccel/pubComped pubProject.jar


注意:

この作業ディレクトリは、-projectDirオプションを使用して指定する前に存在している必要があります。つまり、Acceleratorではこのディレクトリを作成しません。

特定のクラスのネイティブ・コンパイル

.classesファイルには、ネイティブにコンパイルするクラスを1つ以上指定できます。次の構文を使用すると、このファイル内に、パッケージまたは個別のクラス(あるいはその両方)を指定できます。

  • 次のように入力して、1つ以上のパッケージ内にあるクラスを指定します。

    import com.myDomain.myPackage.*;
    import com.myDomain.myPackage.mySubPackage.*;
    
    

    注意:

    Javaには、サブパッケージという正式な概念はありません。各パッケージは個別で指定する必要があります。

  • 次のように入力して、クラスを個別に指定します。

    import com.myDomain.myPackage.myClass;
    
    

明示的に指定した後、このクラス指定ファイルの名前と場所をコマンドラインに指定します。

次のpubworks.classesファイルについて考えます。

import com.myDomain.myPackage.*;
import com.myDomain.hisPackage.hisSubPackage.*;
import com.myDomain.herPackage.herClass;
import com.myDomain.petPackage.petClass;

次のコマンド例では、pubworks.classesファイル内で指定したすべてのクラスをAcceleratorでコンパイルするように指定します。

ncomp -user SCOTT/TIGER /tmp/jaccel/pubComped/pubworks.classes

myPackagehisSubPackage内のすべてのクラス、およびherClassクラスとmyClassクラスがコンパイルされます。

全体または一部が変更されたパッケージのネイティブ・コンパイル

配置JARファイル内の任意のクラスを変更した場合、Acceleratorは、変更されたクラスが格納されている共有ライブラリのみを再コンパイルします。JARファイルで指定されたすべての共有ライブラリを再コンパイルするわけではありません。ただし、以前にネイティブにコンパイルされたかどうかに関係なく、JARファイル内のすべてのクラスを再コンパイルするには、次のように、-forceオプションを指定してncompを実行する必要があります。

ncomp -user scott/tiger -force pubProject.JAR

10.1.7 deployncツール

deployncコマンドを使用すると、任意の配置JARファイルを配置できます。これには、デフォルトの出力JARファイルfile_depl.jar、またはncomp -outputJarFileオプションを使用して作成されたJARファイルが含まれます。オペレーティング・システムおよびOracle Databaseのバージョンは、ネイティブ・コンパイルを実行したプラットフォームと同じであることが必要です。


注意:

Oracle Databaseに配置された共有ライブラリは、JACCELERATOR$DLLS表にリスト表示されます。

構文

deploync [options] deployment.jar
  -user | -u username/password [@database_url]
  [-projectDir | -d project_directory]
  [-thin]
  [-oci | -oci8]

引数の概要

表10-2は、deployncの引数の一覧です。

表10-2 deployncの引数の概要

引数 説明および値
deployment.jar 配置JARファイルのフルパス名とファイル名。このJARファイルは、ncompツールで-outputJarFileオプションを指定して作成します。deployncツールは、ファイルがネイティブ・コンパイルの配置JARファイルであることを確認しないことに注意してください。
-user | -u username/password [@database_url] ユーザー名、パスワードおよびデータベース接続文字列を指定します。ファイルはこのデータベース・インスタンスにロードされます。このオプションにデータベースURLを指定する場合は、OCI構文を使用して指定する必要があります。JDBC ThinデータベースURLを指定するには、-thinオプションを使用します。
-projectDir | -d absolute_path プロジェクト・ディレクトリのフルパスを指定します。指定しない場合、Acceleratorは、ncompがコールされたディレクトリをプロジェクト・ディレクトリとして使用します。
-thin -userオプションで指定されたデータベースURLでは、データベースURL構文のJDBC Thin URLアドレスが使用されます。
-oci | -oci8 -userオプションで指定されたデータベースURLでは、データベースURL構文のOCI URLアドレスが使用されます。ただし、-ociまたは-thinのいずれも指定しない場合、デフォルトではOCIのデータベースURLを使用したとみなされます。

次の例では、ネイティブにコンパイルされた配置JARファイルpub.jarを、dbhostデータベースに配置します。

deploync -user SCOTT/TIGER@dbhost:5521:orcl -thin /tmp/jaccel/PubComped/pub.jar

10.1.8 statusncツール

ネイティブ・コンパイルの完了後は、statusncコマンドを使用して、Javaクラスのステータスをチェックできます。このツールは、各クラスのステータスをスクリーンまたは指定されたファイルのいずれかに出力します。さらに、このツールは、常にその出力をJACCELERATOR$STATUS表に保存します。可能な値は次のとおりです。

ネイティブ・コンパイル・クラスのステータス 説明
ALREADY_NCOMPED 現在、クラスはネイティブにコンパイルされています。
NEED_NCOMPING 共有ライブラリ内のクラスがネイティブ・コンパイル後に再ロードされました。このため、この共有ライブラリは再コンパイルする必要があります。
INVALID データベースにロードされたクラスが無効です。Acceleratorで検証を試みましたが失敗しました。このクラスは、ネイティブ・コンパイルされた共有ライブラリから除外されます。


注意:

JACCELERATOR$STATUS表には、最後に実行されたstatusncコマンドの出力のみ格納されます。statusncは、実行時にこの表のレコードを消去してから新規レコードを書き込みます。

構文

statusnc [ options ] class_designation_file
  -user user/password[@database_url]
  [-output | -o filename]
  [-projectDir | -d directory]
  [-thin]
  [-oci | -oci8]

引数の概要

表10-3は、statusncの引数の一覧です。class_designation_fileは、.jar.zipまたは.classesファイルになります。

表10-3 statusncの引数の概要

引数 説明
file.jar ネイティブにコンパイルされたJARファイルのフルパス名とファイル名。
file.zip ネイティブにコンパイルされたZIPファイルのフルパス名とファイル名。
file.classes ネイティブにコンパイルされたクラスのリストが格納されているクラス・ファイルのフルパス名とファイル名。
-user | -u username/password [@database_url] ユーザー名、パスワード、およびファイルがロードされるデータベース接続文字列を指定します。このオプションにデータベースURLを指定する場合は、OCI構文を使用して指定する必要があります。JDBC ThinデータベースURLを指定するには、-thinオプションを使用します。
-output filename statusncコマンドの出力の送信先を、スクリーンではなく、指定したテキスト・ファイルに指定します。
-projectDir | -d absolute_path プロジェクト・ディレクトリのフルパスを指定します。指定しない場合、Acceleratorは、ncompがコールされたディレクトリをプロジェクト・ディレクトリとして使用します。
-thin -userオプションで指定されたデータベースURLでは、データベースURL構文のJDBC Thin URLアドレスが使用されます。
-oci | -oci8 -userオプションで指定されたデータベースURLでは、データベースのOCI URLアドレスが使用されます。ただし、-ociまたは-thinのいずれも指定しない場合、デフォルトではOCIのデータベースURLを使用したとみなされます。

statusnc -user SCOTT/TIGER -output pubStatus.txt /tmp/jaccel/PubComped/pub.jar

10.2 Javaのメモリー使用量

標準およびカスタムのデータベース・インストール・プロセスでは、開発時に標準的なJava使用のために構成されているデータベースが提供されます。ただし、Javaの実行時の使用量は、配置されたアプリケーションのシステム・リソースの使用率によって決まります。開発時に使用するリソース率は、実行するアクティビティによって大きく異なる場合があります。 次の各項では、メモリーの構成方法、システム・グローバル領域(SGA)メモリーの使用量を調べる方法、およびJavaが使用するメモリーの問題を示すエラーについて説明します。

10.2.1 メモリー初期化パラメータの構成

次のデータベース初期化パラメータを変更して、アプリケーションに必要なメモリー使用量がより正確に反映されるようにメモリー使用量をチューニングできます。

  • SHARED_POOL_SIZE

    共有プール・メモリーはJVM内のクラス・ローダーによって使用されます。クラス・ローダーはクラスをロードするたびに平均8KBを使用します。共有プール・メモリーは、データベースにクラスをロードして解決するときに使用されます。また、データベース内でソースをコンパイルする場合やデータベースでJavaリソース・オブジェクトを使用する場合にも使用されます。

    SHARED_POOL_SIZEで指定したメモリーは、loadjavaの使用時に一時的に消費されます。データベース初期化プロセスでは、約8,000クラスのJavaバイナリをロードして解決するため、SHARED_POOL_SIZEを50MBに設定する必要があります。コール仕様を作成するとき、および実行時に動的にロードされたJavaクラスをシステムで追跡するときも、SHARED_POOL_SIZEリソースが消費されます。

  • JAVA_POOL_SIZE

    Oracle JVMのメモリー・マネージャは、実行時に他のJavaの状態に対して、JAVA_POOL_SIZEを使用して割り当てたメモリー量を割り当てます。このメモリーには、Javaメソッドとクラス定義の共有メモリー内表現の他に、コール終了時にセッション領域に移行したJavaオブジェクトも含まれます。前者の場合は、メモリー・コストをすべてのJavaユーザー間で分担します。後者の場合は、共有サーバーにおいて、各セッションのstatic変数で保持する実際の状態数に基づいて、JAVA_POOL_SIZEの割当てを調整する必要があります。

  • JAVA_SOFT_SESSIONSPACE_LIMIT

    このパラメータを使用すると、1つのセッションにおけるJavaのメモリー使用量に弱い制限を指定でき、Javaのメモリー制限を増やす必要がある場合は警告を表示できます。メモリーが割り当てられるたびに、割り当てられたメモリーの合計量がこの制限に対してチェックされます。

    ユーザーのセッション中にJavaの状態がこのサイズを超えると、Oracle JVMが警告を生成し、トレース・ファイルに書き込みます。この警告は情報用のメッセージでアプリケーションに影響を与えませんが、配置するクラスのメモリー要件、特にセッション領域の使用量に関する要件を把握して管理する必要があります。

  • JAVA_MAX_SESSIONSPACE_SIZE

    ユーザーがコール可能でサーバー上で実行されているJavaプログラムを、メモリー使用量を制限しない方法で実行できる場合は、このパラメータを使用して、使用可能なセッション領域に対して強い制限を設定できます。デフォルトは4GBです。この上限は、通常到達することのない高い値に設定します。

    ユーザーのセッション中のJavaの状態がこのサイズを超えそうになると、メモリー不足障害が発生します。

10.2.1.1 データベース・テンプレート内のプール・サイズの初期化

データベースのインストール・テンプレートのJAVA_POOL_SIZEおよびSHARED_POOL_SIZEに対して、デフォルト値を設定できます。図10-2に示すように、これらの値は、Database Configuration Assistantの「メモリー」セクションで変更できます。

図10-2 Oracle JVMのメモリー・パラメータの構成

Oracle JVMのメモリー・パラメータの構成
画像の説明

10.2.2 Javaプール・メモリー

Javaプール・メモリーは、JVM内のすべてのセッション固有Javaコードとデータ用にサーバー・メモリーで使用されます。Javaプール・メモリーの使用方法は、Oracle Database Serverの実行モードによって異なります。

専用サーバーで使用されるJavaプール・メモリー

次に、専用サーバーで使用されるJavaプール・メモリーの構成を示します。

  • セッションごとに使用される各Javaクラスの共有部分。

    これには、コード・ベクトルやメソッドなどの読取り専用メモリーが含まれます。合計すると、各クラスについて約4KB〜8KBになります。

  • 各セッションのセッション当たりのJavaの状態は使用されません。

    専用サーバーの場合、これはSGAではなく、プログラム・グローバル領域(PGA)内のユーザー・グローバル領域(UGA)に格納されます。

専用サーバーでは、必要なJavaプール・メモリー合計は実行するアプリケーションによって異なり、10MB〜50MB程度になります。

共有サーバーで使用されるJavaプール・メモリー

次に、共有サーバーで使用されるJavaプール・メモリーの構成を示します。

  • セッションごとに使用される各Javaクラスの共有部分。

    これには、ベクトルやメソッドなどの読取り専用メモリーが含まれます。合計すると、各クラスについて約4KB〜8KBになります。

  • 各セッションのセッション状態に使用されるUGAの一部は、SGA内のJavaプール・メモリーから割り当てられます。

    Javaプール・メモリーのサイズは一定であるため、アプリケーションで必要なメモリー量を見積り、アプリケーションで作成する同時実行セッション数を乗じて、必要なJavaプール・メモリーの総量を計算する必要があります。各UGAは必要に応じて拡大または縮小できます。ただし、UGA全体が一定のJavaプール領域に収まるようにしてください。

共有サーバーでは、この数字は非常に大きくなる場合があります。Java集中型のマルチ・ユーザー・ベンチマークでは、100MB以上が必要になる場合があります。


注意:

クライアントでコードをコンパイルしてからサーバーにロードするのではなく、サーバー上でコードをコンパイルする場合は、JAVA_POOL_SIZEをデフォルトの20MBより大きいサイズに設定する必要がある場合があります。

10.2.3 Javaプール・メモリー使用量の表示

V$SGASTAT表を表示すると、Javaプール・メモリーの使用量を調べることができます。この表の行には、プール、名前およびバイト数が表示されます。特に、最後の2行にはJavaプール・メモリーの使用量と空き容量が表示されます。この2行の数字の合計値は、データベース初期化ファイルに設定したバイト数と等しくなります。

SVRMGR> select * from v$sgastat;

POOL        NAME                            BYTES
----------- -------------------------- ----------
            fixed_sga                       69424
            db_block_buffers              2048000
            log_buffer                     524288
shared pool free memory                  22887532
shared pool miscellaneous                  559420
shared pool character set object            64080
shared pool State objects                   98504
shared pool message pool freequeue         231152
shared pool PL/SQL DIANA                  2275264
shared pool db_files                        72496
shared pool session heap                    59492
shared pool joxlod: init P                   7108
shared pool PLS non-lib hp                   2096
shared pool joxlod: in ehe                4367524
shared pool VIRTUAL CIRCUITS               162576
shared pool joxlod: in phe                2726452
shared pool long op statistics array        44000
shared pool table definiti                    160
shared pool KGK heap                         4372
shared pool table columns                  148336
shared pool db_block_hash_buckets           48792
shared pool dictionary cache              1948756
shared pool fixed allocation callback         320
shared pool SYSTEM PARAMETERS               63392
shared pool joxlod: init s                   7020
shared pool KQLS heap                     1570992
shared pool library cache                 6201988
shared pool trigger inform                  32876
shared pool sql area                      7015432
shared pool sessions                       211200
shared pool KGFF heap                        1320
shared pool joxs heap init                   4248
shared pool PL/SQL MPCODE                  405388
shared pool event statistics per sess      339200
shared pool db_block_buffers               136000
java pool   free memory                  30261248
java pool   memory in use                19742720
37 rows selected.

10.2.4 メモリー不足エラーの修正

クラスのロード中にメモリー不足になると、エラーが何も表示されずにロードが失敗し、データベースに無効なクラスが残されます。無効なクラスをコールまたは解決しようとすると、実行時にClassNotFoundExceptionインスタンスまたはNoClassDefFoundExceptionインスタンスがスローされます。破損したクラス・ファイルをロードしようとした場合も同じ例外が発生します。この場合には次の処置を実行してください。

  • サーバーにロードするセットに、実際にクラスが含まれていることを検証します。

  • loadjava -forceオプションを使用して、新しいクラスをロードすることによって、サーバーにすでに常駐しているクラスを強制的に置き換えます。

  • loadjava -resolveオプションを使用して、ロード・プロセス時にクラスの解決を試みます。これによって、実行時ではなくロード時に、欠落しているクラスを捕捉できます。

  • 新しくロードされたクラスの状態を再確認するために、そのクラスが含まれているスキーマのデータベースに接続して、次のように実行します。

    SELECT * FROM user_objects WHERE object_name = dbms_java.shortname('');
    
    

    STATUSフィールドにVALIDと表示されていることを確認してください。loadjavaからメモリーの問題や接続を失うなどの障害が発生した場合は、SHARED_POOL_SIZEおよびJAVA_POOL_SIZEを増やして再試行してください。