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

前へ
前へ
次へ
次へ
 

1 Oracle DatabaseにおけるJavaの概要

Oracle Databaseでは、Javaアプリケーションの開発、格納および配布がサポートされています。この章では、SQLデータと統合されたサーバー側アプリケーションの開発に習熟しているOracle PL/SQLの開発者を対象として、Java言語について説明します。これらの開発者は、Oracle Databaseのスケーラビリティおよびパフォーマンスを利用したJavaのサーバー側アプリケーションを開発できます。

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

1.1 Javaの概要

Javaは、優れたオブジェクト指向プログラミング言語として登場しました。Javaの重要な概念は次のとおりです。

このような概念から、オブジェクト指向で、アプリケーション・プログラムを効率的に作成できる言語であるJavaが開発されました。

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

1.1.1 Javaおよびオブジェクト指向プログラミングの用語

次の用語は、Oracle Database環境におけるJavaアプリケーション開発でよく使用される用語です。

1.1.1.1 クラス

クラスの概念は、どのオブジェクト指向プログラミング言語でもサポートされています。表定義のように、クラスでは、共通の特性を持つオブジェクトのテンプレートが提供されます。各クラスには、次の項目が含まれています。

  • 属性

    属性は、特定クラスの各オブジェクト(インスタンス)に存在する変数です。インスタンス内の属性はフィールドと呼ばれます。インスタンスのフィールドは、リレーショナル表の行のフィールドに類似しています。クラスによって、変数と各変数の型が定義されます。Javaでは、変数をstatic、およびpublicprivateprotectedまたはデフォルト・アクセスとして宣言できます。

    staticとして宣言されたクラスの変数はグローバルであり、そのクラスのすべてのインスタンスに共通です。staticとして宣言されない変数は、そのクラスの各インスタンス内で作成されます。

    publicprivateprotectedおよびデフォルト・アクセス修飾子では、アプリケーションの変数の範囲が定義されます。 Java言語仕様(JLS)では、すべての変数に対するデータの可視性規則が定義されます。可視性規則では、これらの変数内のデータにどのような場合にアクセスできるかが定義されます。

    図1-1の例では、従業員識別子がprivateとして定義されています。これは、他のオブジェクトがこの属性に直接アクセスできないことを示しています。この例で、オブジェクトがid属性にアクセスするには、getId()メソッドをコールします。

  • メソッド

    メソッドは、特定のタスクまたはアクションを実行するコードの集まりです。メソッドは、クラスのインスタンスでコールできます。また、クラスによって継承されているメソッドもコールできます。 メソッドによって、インスタンスは他のインスタンスやアプリケーションと対話できるようになります。属性と同様に、メソッドは、publicprivateprotectedまたはデフォルト・アクセスとして宣言できます。

1.1.1.2 オブジェクト

インスタンスの変数(属性)およびメソッドを使用するには、クラスをインスタンス化する必要があります。オブジェクトはクラスのインスタンスであり、リレーショナル表の行に類似しています。インスタンスには、データまたは状態と呼ばれる属性、およびクラス内で定義されているメソッドが含まれています。

図1-1に、2つの属性id(従業員識別子)とlastName(従業員の姓)、およびgetId()メソッドとsetId(String anId)メソッドで定義されているEmployeeクラスの例を示します。id属性とgetId()メソッドはprivateであり、lastName属性とsetId(String anId)メソッドはpublicです。

図1-1 クラスとインスタンス

クラスおよびインスタンスの例
画像の説明

インスタンスを作成すると、属性には、ある従業員にのみ関係する個人のプライベートな情報が格納されます。つまり、1つの従業員インスタンスに含まれる情報は、該当する特定の従業員のみが認識しています。図1-1の例は、Employeeクラスの2つのインスタンスを示しており、1つは従業員Smith用、もう1つはJones用です。各インスタンスには、個々の従業員に関連する情報が含まれています。

1.1.1.3 インタフェース

Javaでは単一の継承のみがサポートされます。つまり、各クラスは、1つのクラスからのみ属性およびメソッドを継承できます。複数のソースからプロパティを継承する必要がある場合、Javaは複数継承に相当するインタフェースの概念を提供します。インタフェースはクラスに類似しています。ただし、インタフェースではメソッドのシグネチャのみが定義され、実装は定義されません。インタフェースで宣言されたメソッドはクラスで実装されます。1つのクラスで複数のインタフェースを実装すると、複数継承が行われます。

1.1.1.4 カプセル化

カプセル化は、データとメソッドを他から隠すオブジェクトの機能を示します。カプセル化は、オブジェクト指向プログラミングの基本原理の1つです。Javaでは、クラスによって、属性(オブジェクトの状態を格納)およびメソッド(オブジェクトのアクションを定義)がカプセル化されます。カプセル化によって、再利用可能なプログラムを作成できます。また、publicと宣言されたオブジェクトの機能にのみアクセスを制限することもできます。その他の属性およびメソッドはprivateであり、内部的なオブジェクト処理に使用できます。

図1-1の例では、id属性がprivateであり、この属性へのアクセスは、それを定義しているオブジェクトに制限されます。他のオブジェクトがこの属性にアクセスするには、getId()メソッドを使用します。 カプセル化を使用すると、getId()メソッドをprivateとして宣言するか、またはgetId()メソッドを定義しないことによって、id属性へのアクセスを拒否できます。

1.1.1.5 継承

継承は、オブジェクト指向プログラミング言語の重要な機能です。この機能によって、クラスは他のクラスのプロパティを取得できます。プロパティを継承するクラスは子クラスまたはサブクラスと呼ばれ、プロパティの継承元のクラスは親クラスまたはスーパークラスと呼ばれます。この機能は、定義済コードの再利用にも役立ちます。

図1-1の例では、Employeeクラスのプロパティを継承するFullTimeEmployeeクラスを作成できます。継承されるプロパティは、スーパークラスの各属性およびメソッドに対して宣言されている接続修飾子によって決まります。

1.1.1.6 ポリモフィズム

ポリモフィズムは、異なるオブジェクトが同じメッセージに対してそれぞれ異なる応答をするための機能です。オブジェクト指向プログラミング言語では、1つ以上のメソッドを同じ名称で定義できます。これらのメソッドは異なるアクションを実行し、異なる値を戻すことができます。

図1-1の例で、各種の従業員がそれぞれの給与累計で応答できるようにする必要があるとします。給与は、従業員の種類ごとに異なる方法で計算されます。

  • フルタイム従業員は賞与の支払対象です。

  • 適用対象従業員は時間外手当の支払対象です。

手続き型言語では、考えられるケースをそれぞれ定義して、次のようなswitch文を記述します。

switch: (employee.type)
{
  case: Employee
        return employee.salaryToDate;
  case: FullTimeEmployee
        return employee.salaryToDate + employee.bonusToDate
  ...
}

新しい種類の従業員を追加する場合は、switch文を更新する必要があります。また、データ構造を変更する場合は、その構造を使用するswitch文をすべて変更する必要があります。Javaなどのオブジェクト指向言語では、Employeeクラスで定義されていない情報がサブクラスに含まれている場合、EmployeeクラスのサブクラスごとにメソッドcompensationToDate()を実装できます。たとえば、適用対象従業員のcompensationToDate()メソッドを次のように実装します。

private float compensationToDate()
{
  return (super.compensationToDate() + this.overtimeToDate());
}

フルタイム従業員の場合は、compensationToDate()メソッドを次のように実装できます。

private float compensationToDate()
{
  return (super.compensationToDate() + this.bonusToDate());
}

メソッド名を共通して使用することで、従業員の種類を指定しなくても、異なるクラスのメソッドをコールして、結果を取得できます。フルタイム従業員とパートタイム従業員を処理するために特別なメソッドを記述する必要はありません。

また、Employeeからプロパティを継承しないContractorクラスを作成し、このクラスにcompensationToDate()メソッドを実装することもできます。給与累計の合計を計算するプログラムは、フルタイム、パートタイム、契約社員のいずれであるかに関係なく給与計算時に全従業員に対して反復処理し、従業員ごとにcompensationToDate()メソッドをコールして戻された値を合算します。メソッドのコール元が正常に動作することを認識した上で、個々のcompensationToDate()メソッドまたはクラスを安全に変更できます。

1.1.2 Java言語の主な機能

Java言語には、サーバー・アプリケーションの開発に最適な機能がいくつかあります。次の機能があります。

  • 簡潔性

    Javaでは、オブジェクト・モデルが一貫して規定されているため、サーバー・アプリケーションの作成で使用される他のほとんどの言語より単純です。大規模なクラス・ライブラリの標準セットは、あらゆるプラットフォームのJava開発者が強力なツールとして使用できます。

  • 移植性

    Javaはプラットフォーム間で移植可能です。Javaでは、プラットフォームに依存するコードを記述でき、複数のシステム間でシームレスに移植するプログラムも容易に作成できます。


    関連項目:

    「JVM」

  • 自動記憶域管理

    JVMでは、プログラムの実行中にすべてのメモリー割当てと割当て解除が自動的に実行されます。Javaプログラマは、新規オブジェクトに対するメモリーの割当てや、参照されなくなったオブジェクトに対するメモリーの解放を明示的に行うことはできません。かわりに、これらの操作はJVMに依存して実行されます。メモリーの解放処理は、ガベージ・コレクションと呼ばれます。

  • 強い型指定

    変数を使用するには、その変数の型を宣言する必要があります。Javaの強い型指定によって、JavaアプリケーションとPL/SQLアプリケーション間における言語間のコールに対する適切で安全なソリューションが提供され、JavaコールとSQLコールが同じアプリケーション内に統合されます。

  • ポインタの不使用

    Javaの構文はC言語に類似していますが、ダイレクト・ポインタやポインタ操作はサポートされていません。プリミティブ型以外のすべてのパラメータは、値ではなく参照で渡します。この結果、オブジェクト識別性が保持されます。Javaでは、ポインタへの低水準の直接アクセスはサポートされていないため、メモリーの破損やリークを防ぐことができます。

  • 例外処理

    Java例外はオブジェクトです。Javaでは、開発者が、特定のクラスでメソッドによってスローされる例外を宣言する必要があります。

  • 柔軟なネームスペース

    Javaでは、クラスが定義され、そのクラスがインターネットのドメインのネームスペースを模倣した階層構造に格納されます。Javaアプリケーションは分散でき、名前の衝突を回避できます。 Java Naming and Directory Interface(JNDI)などのJava拡張機能によって、複数のネーム・サービスを統合するためのフレームワークが提供されます。 Javaのネームスペース・アプローチは非常に柔軟であるため、Oracleは、JLSに完全に準拠して、クラス名を解決するスキーマの概念を組み込むことができます。

  • セキュリティ

    JavaバイトコードとJVMの設計によって、Javaバイナリ・コードのセキュリティを組込みメカニズムで検証できます。 Oracle DatabaseとともにインストールされるSecurityManagerのインスタンスでは、Oracle Databaseのセキュリティと組み合せることによって、Javaメソッドをコールできるユーザーが判断されます。

  • リレーショナル・データベースへの接続性の標準

    Java Database Connectivity(JDBC)およびSQLJを使用すると、Javaコードで、リレーショナル・データベース内のデータに対するアクセスおよび操作ができます。Oracleには、ベンダーに依存しない移植性のあるJavaコードでリレーショナル・データベースにアクセスできるようにするドライバが用意されています。

1.1.3 JVM

Javaソースは、他の高水準のコンピュータ言語と同様に、低水準のマシン語命令にコンパイルされます。 Javaでは、これらの命令はバイトコードと呼ばれています。これは、各命令サイズが一律に1バイトであるためです。Cなど他のほとんどの言語は、IntelまたはHPプロセッサに固有の命令など、マシン固有の命令にコンパイルされます。

コンパイル時に、Javaコードは、JVMと対話する、プラットフォームに依存しない標準のバイトコード・セットに変換されます。JVMは、Javaコードを実行する特定のプラットフォーム用に最適化された個別のプログラムです。図1-2に、プラットフォームの独立性が、Javaによってどのように保持されるかを示します。各プラットフォームには、オペレーティング・システムに固有のJVMがインストールされています。Javaバイトコードは、JVMを介して、プラットフォームに依存する適切な処理へと解析されます。

図1-2 Javaコンポーネント構造

Javaコンポーネント構造
画像の説明

Javaアプリケーションの開発では、Java言語で記述された事前定義のコア・クラス・ライブラリを使用します。Javaコア・クラス・ライブラリは、一般的な機能を提供する各パッケージに論理的に分割されています。基本言語のサポートはjava.langパッケージによって、I/Oサポートはjava.ioパッケージによって、ネットワーク・アクセスはjava.netパッケージによってそれぞれ提供されます。JVMとコア・クラス・ライブラリによって提供されるプラットフォームでは、Javaプログラマは、Javaをサポートするすべてのオペレーティング・システムで正常に実行されるアプリケーションを開発できます。この概念は、「1回作成すれば、どこでも実行可能(write once, run anywhere)」というJavaの考え方を推進するものです。

図1-3は、OracleのJavaアプリケーションがJavaコア・クラス・ライブラリの上部に位置し、Javaコア・クラス・ライブラリがJVMの上部に位置していることを示しています。OracleのJavaサポート・システムはデータベース内に配置されているため、JVMはオペレーティング・システムと直接対話するかわりに、Oracle Databaseライブラリと対話します。

図1-3 Oracle DatabaseのJavaコンポーネント構造

Oracle Database Javaコンポーネント構造
画像の説明

Sun社によって、Java言語およびJVMの仕様が公開されています。 JLSで構文やセマンティクスなどが定義され、JVM仕様では、アプリケーションを実行するシステムに必要な下位レベルのアクションが定義されます。さらに、Sun社からは、JVMの実装者が仕様に従ってコンパイルしたかどうかを判断するための互換性テスト一式が提供されています。 このテスト一式は、Java Compatibility Kit(JCK)と呼ばれます。Oracle JVM実装は、JCKに完全に準拠しています。総合的なJava方針の一環として、公に規定された標準と、その標準への準拠を検証する簡単な方法によって、ベンダーはすべてのプラットフォームでJavaのサポートを統一できます。

1.1.4 Javaクラス階層

Javaでは、クラスは大規模なクラス階層内で定義されます。階層の最上部にObjectクラスがあります。Javaのすべてのクラスは、スーパークラスの継承連鎖内をさかのぼる過程で、あるレベルのObjectクラスを継承しています。クラスBがクラスAを継承している場合、クラスBの各インスタンスには、クラスBに定義されたすべてのフィールドとクラスAに定義されたすべてのフィールドが含まれます。たとえば、図1-4では、FullTimeEmployeeクラスはEmployeeクラスを継承しているため、このクラスには、Employeeクラスに定義されたidフィールドとlastNameフィールドが含まれます。また、FullTimeEmployeeクラスでは、FullTimeEmployeeにのみ含まれる別のフィールドbonusが追加されます。

クラスBのインスタンスでは、クラスAまたはクラスBのいずれかで定義された任意のメソッドをコールできます。例では、FullTimeEmployeeインスタンスでコールできるメソッドは、FullTimeEmployeeでのみ定義されたメソッド、およびEmployeeクラスで定義されたメソッドです。

図1-4 クラス階層

クラス階層
画像の説明

クラスBのインスタンスは、クラスAのインスタンスのかわりに使用できます。このように継承は、コードの再利用性を改善するための、オブジェクト指向言語の強力な構成メンバーの1つです。また、動作と状態を定義するクラスを、階層内の適切な場所、しかもクラス・ライブラリの既存の機能を利用できる場所に作成できます。

1.2 Oracle DatabaseにおけるJavaの使用

データベースでJavaアプリケーションを作成およびロードできる理由は、Javaが豊富なセキュリティ機能を備えた安全な言語であるためです。Javaは、Javaコードが格納されているオペレーティング・システムの改ざんを防止するように開発されています。Cなど、一部の言語では、データベースにセキュリティ上の問題が発生する可能性があります。これに対してJavaは、その設計により、データベース内の使用にも堅牢な言語です。

Java言語は開発者にとって多数の利点がありますが、Javaサーバー・アプリケーションをサポートするJVMをスケーラブルな方法で実装するのは容易ではありません。この項では、次の問題について説明します。

1.2.1 JavaとRDBMS: 堅牢な組合せ

Oracle Databaseでは、Javaアプリケーションに対して、複合問合せの実行や同一データの異なるビューでの表示をサポートする動的なデータ処理エンジンが提供されます。クライアントからの要求はすべてデータ問合せとして構成されて即時処理され、問合せ結果がすぐに生成されます。

Javaは、サーバー・プログラミングに最適な機能を備えています。Javaを使用すると、JavaBeansなどの既存のソフトウェア・コンポーネントを使用してアプリケーションを組み立てることができます。Javaの型の安全性と自動メモリー管理機能によって、データベースとの緊密な統合が可能です。さらに、Javaでは、アプリケーション・コンポーネントをネットワーク上で透過的に配布する機能がサポートされます。

JavaとOracle Databaseを組み合せることによって、ビジネス・ニーズの変化に応じて柔軟に拡張できるコンポーネントベースでネットワーク中心のアプリケーションを迅速に組み立てることができます。また、アプリケーションおよびデータ・ストアを、デスクトップからインテリジェント・ネットワークやネットワーク型のサーバーに移動できます。さらに重要なのは、これらのアプリケーションおよびデータ・ストアに任意のクライアント・デバイスからアクセスできることです。

図1-5に、従来の2層クライアント/サーバー構成を示します。この構成では、クライアントは、PL/SQLストアド・プロシージャのコールと同様の方法でJavaストアド・プロシージャをコールします。また、この図では、Oracle Net Services Connection Managerが、多数のネットワーク接続を単一のデータベース接続に結合する方法も示されています。このようにして、Oracle Databaseでは多数の同時ユーザーがサポートされます。

図1-5 2層クライアント/サーバー構成

2層クライアント/サーバー構成
画像の説明

1.2.2 マルチスレッド

マルチスレッドは、Java言語の主要なスケーラビリティ機能の1つです。Java言語とクラス・ライブラリによって、他の多くの言語に比べてマルチスレッド・アプリケーションをJavaで簡単に作成できます。しかし、依然としてどのような言語でも、信頼性が高くスケーラブルなマルチスレッド・コードを記述するのは困難な作業です。

Oracle Databaseは、データベース・サーバーとして多数のユーザーの作業を効率的にスケジュールします。Oracle JVMはデータベース・サーバーの機能を使用して、多数のユーザーのJavaアプリケーションの実行を同時にスケジュールします。Oracle DatabaseではJLSとJCKに必要なJava言語レベルのスレッドがサポートされていますが、データベースの有効範囲内でスレッドを使用するとスケーラビリティは向上しません。データベースの埋込みのスケーラビリティを使用すると、マルチスレッドJavaサーバーを記述する必要がなくなります。

ユーザーのスケジューリングには、シングル・スレッドJavaアプリケーションを作成してOracle Databaseの機能を使用してください。データベースが各アプリケーション間の処理をスケジューリングするため、スレッドを管理しなくてもスケーラビリティが実現します。また、マルチスレッドJavaアプリケーションの作成も可能ですが、複数のJavaスレッドを使用してもサーバーのパフォーマンスは向上しません。

マルチスレッドで生じる問題の1つは、スレッドと自動記憶域管理またはガベージ・コレクションとの間の相互作用です。汎用JVMで実行されるガベージ・コレクタでは、どのJava言語スレッドが実行されているか、または基盤となるオペレーティング・システムでどのようにスケジュールされているかは認識されません。 非Oracle DatabaseモデルとOracle JVMモデルの相違点は、次のとおりです。

  • 非Oracle Databaseモデル

    単一のユーザーが単一のJavaスレッドにマップされ、単一のガベージ・コレクタによって全ユーザーからのガベージがすべて管理されます。通常、存続期間やサイズの異なるオブジェクトの割当てと回収は、異なる技法で処理されます。アプリケーションが過度にマルチスレッド化されると、少なくともネイティブ・スレッド用のオペレーティング・システム・サポートに依存するようになるため、信頼性が低下したり、スケーラビリティが限定される可能性があります。この種の実装の場合、高水準のスケーラビリティは十分に実証されていません。

  • Oracle JVMモデル

    多数のユーザーがサーバーに接続して同じJavaコードを実行する場合も、各ユーザーは各自のJVMで独自のJavaコードを実行しているように感じます。Oracle JVMの役割は、オペレーティング・システムのプロセスとスレッド、およびOracle Databaseのスケーラブルなアプローチを利用することです。このアプローチによって、一度に複数のユーザーからガベージが収集されることがなくなるため、Oracle JVMのガベージ・コレクタの信頼性と効率が向上します。

1.2.3 ガベージ・コレクションを使用した自動記憶域管理

ガベージ・コレクションはJavaの自動記憶域管理機能の主要な機能であり、Java開発者はメモリーの割当てと解放を明示的に行う必要がなくなります。そのため、CやC++のプログラムで一般に問題となるメモリー・リークの大きな原因がなくなります。ただし、ガベージ・コレクションはプログラムの実行スピードとフットプリントのオーバーヘッドに影響を与えます。

ガベージ・コレクションは、高スケーラブルで高速なJavaプラットフォームを提供しようとするJVM開発者に対する1つの課題です。Oracle JVMは、このような課題に次の方法で対応します。

  • Oracle JVMでは、複数のユーザーを効率的に管理できるOracle Databaseのスケジューリング機能が使用されます。

  • ガベージ・コレクションは単一セッション内の単一ユーザーを対象とするため、複数ユーザーに対しても一貫して実行されます。Oracle JVMの場合、ユーザー数が増加してもメモリー・マネージャの作業の負荷や複雑さは変わらないため、その点において有利です。メモリー・マネージャは単一セッション内でオブジェクトの割当てと回収を実行します。通常はこれが単一ユーザーのアクティビティに変換されます。

  • Oracle JVMでは、使用するメモリーのタイプに応じて異なるガベージ・コレクションの技法が使用されます。これらの技法によって、効率が向上し、オーバーヘッドが低減します。

2種類のメモリー領域は、コール領域とセッション領域です。

メモリー領域 説明
コール領域 高速でコストの低いメモリーです。主にコール期間中に存在します。コール・メモリー領域は新規セグメントと旧セグメントに分割されます。新規オブジェクトはすべて新規メモリー内に作成されます。数回のスキャベンジ後も存在し続けているオブジェクトは、旧メモリーに移動されます。
セッション領域 コストの高いパフォーマンス重視のメモリーです。主にセッション期間中に存在します。コール存続期間より長い期間存在するすべてのstatic変数とオブジェクトは、この領域に存在します。

図1-6 ガベージ・コレクション

ガベージ・コレクション
画像の説明

Oracle JVM内のガベージ・コレクション・アルゴリズムは、次のルールを遵守します。

  1. 新規オブジェクトは新規コール領域内に作成されます。

  2. スキャベンジは既定の間隔で行われます。プログラマによっては、オブジェクトを短期間のみ頻繁に作成する場合があります。このようなタイプのオブジェクトは、新規コール領域内に作成され、すぐにガベージ・コレクションされます。これはスキャベンジと呼ばれます。

  3. スキャベンジを数回繰り返した後も存在し続けているオブジェクトは、しばらくの間存在する可能性のあるオブジェクトとみなされます。これらのオブジェクトは、新規コール領域から旧コール領域に移動されます。移動中にも圧縮が行われます。旧コール領域はスキャベンジ(ガベージ・コレクション)される回数が少ないため、パフォーマンスが向上します。

  4. コール終了時に、コール後も存在するオブジェクトはセッション領域に移動されます。

図1-6は、前述の説明の手順を示しています。このアプローチでは、オブジェクトの種類や存続期間にあわせて、効率的な割当と回収の仕組みが適用されます。たとえば、新規オブジェクトは、迅速な割当とアクセスを目的として設計された、高速でコストの低いコール・メモリーに割り当てられます。Java static変数で保持されるオブジェクトは、より貴重でコストの高いセッション領域に移行されます。

1.2.4 フットプリント

Javaプログラムの実行によるフットプリントは、次の様々な要因の影響を受けます。

  • プログラムのサイズ

    プログラムのサイズは、クラス数、メソッド数およびそれらのコードの量によって決まります。

  • プログラムの複雑さ

    プログラムの複雑さは、プログラム自体ではなく、プログラムの実行時にOracle JVMで使用されるコア・クラス・ライブラリの数によって決まります。

  • JVMが使用する領域の量

    JVMが使用する領域の量は、JVMが割り当てるオブジェクトの数とサイズ、および複数コール間で保持する必要のあるオブジェクトの数によって決まります。

  • ガベージ・コレクタとメモリー・マネージャが、プログラムの実行の要求を処理する能力

    通常、この能力は非決定的要因です。オブジェクトの割当て速度および他のオブジェクトによって保持される方法が、この要因の重要度に影響を与えます。

スケーラビリティの観点から、複数のクライアントを同時にサポートするには、ユーザー当たりのセッション・フットプリントを最小限に抑えることが重要です。Oracle JVMでは、Javaバイトコードなど、ユーザー用のすべての読取り専用データを共有メモリーに格納することで、ユーザー当たりのセッション・フットプリントを最小限に抑えます。ユーザー・セッションのフットプリントが大きくならないように、コールとセッションのメモリーに対して、適切なガベージ・コレクション・アルゴリズムが適用されます。Oracle JVMでは、ユーザーのセッション・メモリーのメンテナンスに、次の種類のガベージ・コレクション・アルゴリズムが使用されます。

  • ジェネレーション・スキャベンジ: 存続期間の短いオブジェクトの場合

  • マーク/レイジー・スイープ・コレクション: 単一コールの間に存在するオブジェクトの場合

  • コレクタのコピー: 存続期間の長いオブジェクト、つまり、セッション内の複数コールにわたって存在するオブジェクトの場合

1.2.5 パフォーマンス

Oracle JVMのパフォーマンスは、ネイティブ・コンパイラを実装することで向上します。プラットフォームに依存しないJavaバイトコードはJVMの上部で実行され、そのJVMは特定のハードウェア・プラットフォームと対話します。ソフトウェア内でレベルを追加すると、パフォーマンスが低下します。Javaでは、バイトコードを解析するために仲介部分を通過する必要があるため、Javaアプリケーションには、C言語のようなプラットフォームに依存する言語を使用して開発されたアプリケーションと比較して、ある程度の非効率性が伴います。この問題に対処するために、複数のJVMサプライヤがネイティブ・コンパイラを作成しています。ネイティブ・コンパイラによって、Javaバイトコードはプラットフォームに依存するネイティブ・コードに変換されます。この結果、インタプリタによる処理が不要になり、パフォーマンスが向上します。

次の表に、ネイティブ・コンパイルの2つの方法を示します。

コンパイラ 説明
Just-In-Time(JIT)コンパイル JITコンパイラは、実行時にJavaバイトコードをプラットフォーム固有(ネイティブ)のマシン・コードに迅速にコンパイルします。これらのコンパイラでは、プラットフォームで実行される実行可能ファイルは生成されません。かわりに、変換後に直接実行されるプラットフォームに依存するコードがJavaバイトコードから作成されます。JITコンパイラは、頻繁に実行され、Cなどの他言語で開発されたコードとほぼ同じ速度で実行されるJavaコードに対して使用してください。
Ahead-of-Timeコンパイル このコンパイルでは、実行前にJavaバイトコードがプラットフォームに依存しないCコードに変換されます。次に、標準的なCコンパイラで、Cコードがターゲット・プラットフォーム用の実行可能ファイルにコンパイルされます。この方法は、あまり変更されないJavaアプリケーションに適しています。この方法は、最近のCコンパイラで採用されている成熟した効率的なプラットフォーム固有のコンパイル技術を利用しています。

Oracle Databaseは、Ahead-of-Timeコンパイルを使用して、JDBCコードなどのコアなJavaクラス・ライブラリをネイティブにコンパイル済の形式で配布しています。この方法は、Oracleがサポートしているすべてのプラットフォームで適用できます。JITを使用する方法では、プラットフォームごとにプロセッサに依存する低水準のコードを記述してメンテナンスする必要があります。このネイティブ・コンパイル技術は、独自のJavaコードに使用できます。

図1-7に示すように、ネイティブにコンパイルされたコードは、解析されるコードに比較して最高で10倍速く実行されます。この結果、プログラムで使用するネイティブ・コードが多いほど、実行速度が速くなります。

図1-7 インタプリタとAccelerator

インタプリタとAcceleratorの相違点
画像の説明

1.2.6 動的クラス・ロード

Javaのもう1つの強力な機能は、動的クラス・ロードです。クラス・ローダーは、クラスをディスクからロードし、解析に必要なJVM固有のメモリー構造に格納します。また、クラスをCLASSPATH内で検索し、プログラムの実行中に使用される場合にのみロードします。この方法はアプレットに適していますが、サーバー環境では次の問題があります。

問題 説明 解決策
予測可能性 クラス・ロード操作は、プログラムの初回実行時に重大なペナルティを伴います。単純なプログラムの場合でも、Oracle JVMによって、そのニーズをサポートするための多数のコア・クラスがロードされる可能性があります。ロードされるクラスの数は、プログラマが簡単に予測または判断することはできません。 Oracle JVMは、他のJVMと同様に、クラスを動的にロードします。1回のクラス・ロードの速度は同じです。ただし、クラスは共有メモリーにロードされるため、そのクラスの他のユーザーはクラスを再ロードする必要はなく、単に同じ事前ロード・クラスを使用します。
信頼性 動的クラス・ロードの利点は、プログラムの更新がサポートされることです。たとえば、サーバー上でクラスを更新すると、プログラムをダウンロードして動的にロードするクライアントでは、次回そのプログラムを使用するときに更新されたことがわかります。サーバー・プログラムでは、信頼性が重視されます。開発者は、各クライアントが特定のプログラム構成を実行していることを認識する必要があります。意図していない一部のクラスがクライアントによって不注意にロードされないようにしてください。 Oracle Databaseでは、アップロードおよび解決操作が、実行時のクラス・ロード操作と分離されます。開発したJavaコードをサーバーにアップロードするには、loadjavaユーティリティを使用します。CLASSPATHを使用するかわりに、インストール時にリゾルバを指定します。リゾルバはCLASSPATHに類似していますが、クラスが存在するスキーマを指定できます。このように解決操作をクラス・ロードから分離することで、ユーザーがどのプログラムを実行しているかを常に把握できます。

関連項目: 第11章「スキーマ・オブジェクトおよびOracle JVMユーティリティ」


1.3 Oracle JVM

Oracle JVMは、Pure Javaアプリケーションを実行する標準的なJava互換環境です。Sun社が規定するJLSおよびJVM仕様との互換性があります。標準Javaバイナリ形式および標準Java APIをサポートしています。また、Oracle Databaseは、実行時のクラスの動的ロードも含めて、標準的なJava言語のセマンティクスに準拠しています。

Oracle DatabaseにおけるJavaでは、次の用語が使用されます。


注意:

セッションとコールの概念は、Oracle Databaseの使用時に必ず適用されます。

他のJava環境とは異なり、Oracle JVMは、Oracle Database内に埋め込まれているため、多くの新しい概念が導入されています。この項では、Oracle JVMと一般的なクライアントJVMとの重要な相違点をいくつか説明します。

1.3.1 プロセス領域

標準的なJava環境では、コマンドラインで次のコマンドを発行することで、インタプリタを介してJavaアプリケーションを実行します。このコマンドで、classnameは、JVMで最初に解析するクラスの名称です。

java classname

このコマンドによって、アプリケーションはオペレーティング・システムのプロセスで実行されます。ただし、Oracle JVMでは、アプリケーションをデータベースにロードし、インタフェースを公開してから、データベース・セッションでアプリケーションを実行する必要があります。


関連項目:

Javaアプリケーションのロード、公開および実行の詳細は、第2章「Oracle DatabaseでのJavaアプリケーション」を参照してください。

1.3.2 main()メソッド

クライアントベースのJavaアプリケーションでは、トップレベルのメソッド(public static void main(String args[]))が1つ宣言されます。このメソッドではアプリケーションのプロファイルが定義されます。アプレットと同様に、サーバーベースのアプリケーションには、このような内部ループ構造がありません。かわりに、論理的に独立したクライアントによって動作します。

各クライアントは、セッションを開始し、トップレベルのエントリ・ポイント経由でサーバー側の論理モジュールをコールし、セッションを終了します。サーバー環境では、ホスティング対象のJavaプログラムから、セッション、ネットワークおよびその他の共有リソースの管理のプロセスが隠されます。

1.3.3 GUI

サーバーではGUIは提供されませんが、GUIを動作させるロジックが提供されます。Oracle JVMでは、Java Abstract Window Toolkit(AWT)のヘッドレス・モードのみがサポートされます。サーバー上でGUIを実体化しようとしないかぎり、すべてのJava AWTクラスをサーバー環境で使用でき、プログラムでJava AWTの機能を利用できます。

1.3.4 IDE

Oracle JVMは、Javaアプリケーションの開発ではなく、配布指向です。アプリケーションの作成とテストは、Oracle JDeveloperなどの任意の統合開発環境(IDE)で行い、その後、クライアントによるアクセスおよび実行用にデータベース内に配布できます。


関連項目:

「開発ツール」

Javaのバイナリ互換性によって、任意のIDEで作成したJavaクラス・ファイルをサーバーにアップロードできます。Javaソース・ファイルをデータベースに移動する必要はありません。かわりに、強力なクライアント側のIDEを使用して、サーバー上に配布したJavaアプリケーションをメンテナンスできます。

1.4 Oracle JVMの主要コンポーネント

この項では、Oracle JVMの主要コンポーネントおよびそれらが提供する機能の一部を簡単に説明します。

Oracle JVMは、Javaアプリケーションを実行するための、Java2との完全互換の環境です。そのメモリー・ヒープを共有し、リレーショナル・データに直接アクセスすることで、データベース・カーネルと同じプロセス空間およびアドレス空間で稼働します。この設計によって、メモリー使用が最適化され、スループットが向上します。

Oracle JVMでは、Javaオブジェクト用のランタイム環境が提供されます。Javaデータ構造、メソッド・ディスパッチ、例外処理および言語レベルのスレッドが完全にサポートされています。また、java.langjava.iojava.netjava.mathおよびjava.utilを含むコアなJavaクラス・ライブラリもすべてサポートされています。図1-8に、Oracle JVMの主要コンポーネントを示します。

図1-8 Oracle JVMの主要コンポーネント

Oracle JVMの主要コンポーネント
画像の説明

Oracle JVMは、標準のJavaネームスペースをデータベース・スキーマに埋め込みます。この機能によって、Javaプログラムで、企業のOracle Databaseやアプリケーション・サーバーに格納されているJavaオブジェクトにアクセスできます。

また、Oracle JVMは、データベースのスケーラブルな共有メモリー・アーキテクチャと緊密に統合されています。Javaプログラムでは、ユーザーの介入なしで、コール、セッションおよびオブジェクトの存続期間が効率的に使用されます。この結果、Oracle JVMおよび中間層のJavaビジネス・オブジェクトは、それらが長く存続するセッションの場合でも適切に調整できます。

次の項では、Oracle JVMの一部のコンポーネント、およびJDBCドライバとSQLJトランスレータの概要について説明します。

1.4.1 ライブラリ・マネージャ

JavaクラスをOracle Databaseに格納するには、loadjavaコマンドライン・ユーティリティを使用します。このユーティリティは、SQLのCREATE JAVA文を使用して格納を実行します。CREATE JAVA {SOURCE | CLASS | RESOURCE}文によってコールされると、ライブラリ・マネージャはJavaのソース、クラスまたはリソース・ファイルをデータベースにロードします。これらのJavaスキーマ・オブジェクトは直接アクセスされることはなく、Oracle JVMのみが使用します。

1.4.2 コンパイラ

Oracle JVMには、標準のJavaコンパイラが組み込まれています。 CREATE JAVA SOURCE文が実行されると、Javaコンパイラは、Javaソース・ファイルをバイトコードと呼ばれるアーキテクチャに依存しない1バイトの命令に変換します。各バイトコードは、命令コードとそれに続くオペランドで構成されています。結果として、Javaの標準に完全に準拠したJavaクラス・ファイルが生成され、実行時にインタプリタに送信されます。

1.4.3 インタプリタ

Javaプログラムを実行するために、Oracle JVMには標準Java2のバイトコード・インタプリタが組み込まれています。インタプリタとそれに関連するJavaランタイム・システムによって、標準のJavaクラス・ファイルが実行されます。ランタイム・システムでは、ネイティブ・メソッド、およびホスト環境からのコールとホスト環境へのコールがサポートされます。


注意:

パフォーマンスを向上させるためにJavaコードをコンパイルすることもできます。Oracle JVMでは、ネイティブにコンパイルされたコアなJavaクラス・ライブラリ、SQLJトランスレータおよびJDBCドライバが使用されます。

1.4.4 クラス・ローダー

ランタイム・システムからの要求に応答して、Javaクラス・ローダーは、データベースに格納されているJavaクラスを検索、ロードおよび初期化します。クラス・ローダーはクラスを読み込み、そのクラスの実行に必要なデータ構造を生成します。不変のデータやメタデータは、初期化が1回の共有メモリーにロードされます。この結果、セッションごとに必要なメモリー量が低下します。クラス・ローダーは、必要に応じて外部参照を解決しようとします。また、ソース・ファイルが使用可能な場合、Javaクラス・ファイルを再コンパイルする必要があるときは、Javaコンパイラを自動的にコールします。

1.4.5 検証機能

Javaクラス・ファイルは、完全に移植可能で、明確に定義された形式に準拠しています。検証機能は、プログラム・フローを改ざんしたり、アクセス制限に違反する恐れのあるにせのJavaクラス・ファイルが誤って使用されるのを防止します。OracleのセキュリティとJavaのセキュリティが検証機能と連携することによって、ユーザーのアプリケーションとデータが保護されます。

1.4.6 サーバー側JDBC内部ドライバ

JDBCは標準であり、ベンダーに依存しないリレーショナル・データへのアクセスを提供するJavaクラスのセットを定義します。Sun社によって仕様が作成され、ODBCおよびX/Open SQL Call Level Interface(CLI)をモデルにしたJDBCクラスは、複数のデータベースへの同時接続、トランザクション管理、単純な問合せ、ストアド・プロシージャのコール、LONG型の列データへのストリーム形式のアクセスなどの標準的な機能を提供します。

特別にチューニングされたJDBCドライバは、下位レベルのエントリ・ポイントを使用してOracle Database内で直接実行され、Javaストアド・プロシージャからOracleデータへの高速アクセスを提供します。サーバー側JDBC内部ドライバは、標準のJDBC仕様に完全に準拠しています。JDBCドライバは、データベースと緊密に統合されているため、Oracle固有のデータ型、グローバリゼーション・キャラクタ・セットおよびストアド・プロシージャをサポートしています。また、クライアント側とサーバー側のJDBC APIが同じであるため、アプリケーションの分割を容易に行うことができます。

1.4.7 サーバー側SQLJトランスレータ

SQLJを使用すると、SQL文をJavaプログラムに埋め込むことができます。SQLJはJDBCよりも簡潔であり、静的な分析と型チェックに対するレスポンス速度が早くなります。それ自体がJavaプログラムであるSQLJプリプロセッサは、SQLJ句が埋め込まれているJavaソース・ファイルを入力として取得します。次に、SQLJ句を、指定したSQL文を実装するJavaクラス定義に変換します。Java型システムによって、これらのクラスのオブジェクトは正しい引数でコールされることが保証されます。

高度に最適化されたSQLJトランスレータはデータベース内で直接実行され、サーバー側JDBC内部ドライバを使用して、Oracleデータへのランタイム・アクセスを提供します。SQLJフォームには、問合せ、データ操作言語(DML)文、データ定義言語(DDL)文、トランザクション制御文、およびストアド・プロシージャのコールを組み込むことができます。クライアント側とサーバー側のSQLJ APIが同じであるため、アプリケーションの分割を容易に行うことができます。

1.5 OracleのJavaアプリケーション方針

Oracleは、エンタープライズ・アプリケーションの開発者に、Javaアプリケーションの作成、配布および管理のためのエンド・トゥ・エンドのJavaソリューションを提供します。この総合的なソリューションは、クライアント側とサーバー側のプログラム・インタフェース、Java開発をサポートするツール、Oracle Databaseと統合されたJVMで構成されています。これらの製品はすべて、Java標準と完全に互換性があります。この項の内容は、次のとおりです。

1.5.1 データベース・アプリケーション開発におけるJava

データベース・アプリケーション開発におけるJavaの最も重要な機能は、次のとおりです。

  • JDBCおよびSQLJレベルの対称型データ・アクセスに対する、Java2 Platform, Standard Edition(J2SE)アプリケーションの柔軟な分割の提供。

  • SQLとJava2 Platform, Enterprise Edition(J2EE)のブリッジ。次の方法があります。

    • JSPやサーブレットなどのWebコンポーネントのコール

    • Enterprise JavaBeans(EJB)コンポーネントのコール

    • SQLとWebサービスのブリッジ

      • Webサービスのコール

    • ERP統合ハブとしてのOracle JVMの使用

    • キャッシュの無効化

1.5.2 Javaプログラミング環境

Javaプログラミング環境には、Oracle JVM以外に次のコンポーネントがあります。

  • Javaストアド・プロシージャ。PL/SQLに対するJavaの等価および連携プロシージャ。Javaストアド・プロシージャは、PL/SQLと緊密に統合されています。PL/SQLパッケージからJavaストアド・プロシージャをコールでき、Javaストアド・プロシージャからPL/SQLプロシージャをコールできます。

  • SQLデータにアクセスするためのJDBCおよびSQLJプログラミング・インタフェース。

  • クラスの開発、ロードおよび管理に役立つツールとスクリプト。

どのような場合にどのJava APIを使用するかを判断するには、次の表を参考にしてください

必要な機能のタイプ 使用するJava API
トリガーなどのJavaプロシージャをSQLからコールする場合 Javaストアド・プロシージャ
既知の列名を持つ既知の表にある静的で単純なSQL文を、Javaオブジェクトからコールする場合 SQLJ
動的な複合SQL文をJavaオブジェクトからコールする場合 JDBC

1.5.3 Javaストアド・プロシージャ

Javaストアド・プロシージャは、PL/SQLストアド・プロシージャと同様に、サーバーで作成および配布され、サーバーで実行されるJavaプログラムです。Javaストアド・プロシージャを起動するには、SQL*Plusなどの製品から直接起動するか、またはトリガーを使用して間接的に起動します。また、OCIやPRO*などのすべてのOracle Netクライアント、あるいはJDBCまたはSQLJからアクセスできます。

また、Javaを使用して、PL/SQLに依存しない強力なサーバー側プログラムを開発することもできます。Oracle Databaseには、標準Javaプログラミング言語および完全準拠のJVMの完全な実装が用意されています。

Oracle Databaseでは、Javaストアド・プロシージャ・セッションの存続期間は、それが埋め込まれているデータベース・セッションの存続期間と同じです。Javaで表される状態は、データベース・セッションの存続期間中は透過的に存在し、Oracleの抽象データ型のストアド・プロシージャ、トリガーおよびメソッドの作成プロセスを単純にします。

1.5.4 PL/SQLの統合とOracle RDBMSの機能

既存のPL/SQLプログラムをJavaからコールしたり、JavaプログラムをPL/SQLからコールできます。このソリューションでは、PL/SQLおよびJavaのコードを保護して利用しながら、Javaベースのインターネット・コンピューティングの利点と機会を活用できます。

Oracle Databaseでは、SQLデータにアクセスするためのJava APIが、JDBCとSQLJの2種類提供されています。両方のAPIをクライアントとサーバーで使用できます。このため、コードを変更せずに、クライアントとサーバーにアプリケーションを配布できます。

次の各項では、Oracle Databaseで提供されるJava APIおよびJPublisherのツールについて説明します。

1.5.4.1 JDBCドライバ

JDBCはデータベース・アクセス・プロトコルです。これを使用することによってデータベースに接続し、データベースに対するSQL文や問合せを実行できます。コアなJavaクラス・ライブラリに用意されているJDBC APIはjava.sqlの1つのみです。ただし、JDBCは、ベンダーが特定のデータベースに対して必要な特別機能を持つドライバを提供できるように設計されています。 Oracleには、次のJDBCドライバが個別に用意されています。

ドライバ 説明
JDBC Thinドライバ JDBC Thinドライバを使用すると、Oracle SQLのデータにアクセスするPure Javaのアプリケーションおよびアプレットを作成できます。JDBC Thinドライバは、他のJavaアプレットと同様にWebページから動的にダウンロードできるため、Webベースのアプリケーションとアプレットに特に適しています。
JDBC OCIドライバ JDBC OCIドライバは、クライアントまたは中間層にあるOracle固有のネイティブ・コード(つまり非Javaコード)およびライブラリにアクセスします。JDBC Thinドライバと比較してパフォーマンスが向上しますが、サイズが極端に大きくなること、およびクライアント側でインストールが必要であるという問題があります。
サーバー側JDBC内部ドライバ Oracle Databaseでは、Javaコードがサーバー上で実行される場合に、サーバー側内部ドライバが使用されます。これによって、サーバーのOracle JVMで実行中のJavaアプリケーションは、ローカルに定義されたデータ(つまり、同じシステムの同じプロセスにあるデータ)にJDBCを使用してアクセスできます。また、基盤となるOracle RDBMSライブラリを直接使用できるため、パフォーマンスが向上し、JavaコードとSQLデータ間のネットワーク接続によるオーバーヘッドは発生しません。Oracle Databaseでは、サーバー上で同じJava-SQLインタフェースをサポートすることで、配布時にコードの再作成を必要としません。


関連項目:


1.5.4.2 SQLJ

オラクル社は、IBM社、Tandem社、Sybase社およびSun社などの他のベンダーと共同で作業し、SQL文をJavaプログラムに埋め込む、SQLJと呼ばれる標準方式を開発しました。この結果、JDBCより単純で生産性の高いプログラミングAPIに関して、新しい標準ANSI x.3.135.10-1998が作成されました。ユーザーはこの高水準のAPIに対するアプリケーションを作成し、プリプロセッサを使用して、そのプログラムをJDBCコールが含まれる標準のJavaソースに変換します。実行時に、プログラムは、標準のJDBCドライバを使用してマルチベンダーのデータベースと通信できます。

SQLJは、Javaからデータベースにアクセスするクライアント・サイド・アプリケーションと中間層アプリケーションの両方を開発するための、単純ですが強力な方法を提供します。SQLJは、Oracle Database 10g環境内のストアド・プロシージャ、トリガーおよびメソッドで使用できます。また、SQLJプログラムはJDBCと結合できます。

SQLJトランスレータは、Javaソース・コードの埋込みSQLをJDBCベースのPure Javaコードに変換するJavaプログラムです。Oracle Database 10gでは完全なJava環境が提供されているため、サーバーで実行されるSQLJプログラムをクライアントでコンパイルすることはできません。かわりに、サーバーで直接コンパイルできます。Oracle Databaseはインターネット標準に準拠しているため、必要に応じて開発スタイルを選択できます。


関連項目:


1.5.4.3 JPublisher

JPublisherは、既存のOracleリレーショナル・データベース表にアクセスするJavaプログラムを作成するための、使いやすい便利なツールを提供します。


関連項目:

『Oracle Database JPublisher ユーザーズ・ガイド』

1.5.5 開発ツール

JavaをOracle Databaseに導入することによって、複数のJava IDEを使用できるようになります。 Oracle Databaseは、Javaの標準と仕様およびオープン・インターネットの標準とプロトコルに完全に準拠しているため、作成したJavaのプログラムは、Oracle Database上に配布したときに正常に動作することが保証されます。Oracleには、Javaで作成されているツールやユーティリティが多数あり、Javaサーバー・アプリケーションの開発および配布を容易にします。また、Oracle JDeveloper(Oracleが提供するJava IDE)には、Javaストアド・プロシージャとEJBの配布を容易にするために特別に設計された機能が多数あります。JDeveloperは、http://www.oracle.com/technology/software/products/jdev/index.htmlからダウンロードできます。

1.6 Oracle DatabaseにおけるJ2EEテクノロジの非サポート

Oracle Application Server Containers for J2EE(OC4J)(新しく軽量で、使いやすく、処理速度が速い認証済のJ2EEコンテナ)の導入に伴い、Oracleでは、データベースからのJ2EEおよびCommon Object Request Broker Architecture(CORBA)スタックのサポートを、Oracle9i リリース2(9.2)から停止しました。 ただし、データベース埋込み型Oracle JVMは従来どおり存在し、データベースでJ2SE機能、Javaストアド・プロシージャおよびJDBCとSQLJを提供するように継続的に拡張される予定です。

Oracle9i リリース2(9.2)以降、データベースの次のテクノロジはサポートされなくなりました。

サーブレット、JSPページ、EJBおよびCORBAオブジェクトは、Oracleデータベースに配布できなくなります。Oracle9i リリース1(9.0.1)は、J2EEおよびCORBAスタックをサポートする最後のデータベース・リリースとなります。データベースで実行している既存のJ2EEアプリケーションは、OC4Jに移行することをお薦めします。

1.7 専用モード・セッションのメモリー・モデル

Oracle Database 10gのOracle JVMには、専用サーバーを介してデータベースに接続するセッション用に新しいメモリー・モデルが用意されています。 専用サーバーを使用するセッションでは、すべてのデータベース・コールに対する同じプロセスの使用が保証されているため、プロセス・グローバル領域(PGA)はセッション固有のメモリーおよびオブジェクトの割当てに使用されます。つまり、各コールの終了時に再利用されるいくつかのオブジェクトおよびリソースが、複数コールにわたって存在できるようになります。特に、スレッドやオープン・ファイルなど、特定のオペレーティング・システムに固有のリソースは、各データベース・コールの終了時にクリーン・アップされなくなりました。

共有サーバーを使用するセッションの場合、以前のリリースで適用されていた複数のコールに関する制限は現在も有効です。これは、共有サーバーを使用するセッションは、後続のデータベース・コールによる同一プロセスへの接続が保証されていないためです。したがって、複数コールにわたって保持する必要があるセッション固有のメモリーおよびオブジェクトは、システム・グローバル領域(SGA)に保存されます。つまり、スレッド、オープン・ファイルおよびソケットなどのプロセス固有のリソースは、各コールの終了時にクリーン・アップする必要があるため、次のコールでは使用できません。

1.8 このリリースの新機能

次の各項では、このリリースで追加された機能について説明します。

1.8.1 J2SE 1.4.2へのアップグレード

このリリースでは、システム・クラスがJ2SE 1.4.1からJ2SE 1.4.2にアップグレードされました。 Sun社では、J2SE 1.4.2と以前のバージョンとの非互換リストを次のWebサイトで公開しています。

http://java.sun.com/j2se/1.4.2/compatibility.html

1.8.2 Javaスキーマ・オブジェクトに関連するSQL文の監査

Oracle Database 10g リリース2(10.2)では、Javaスキーマ・オブジェクトに関連するDDL文の監査がサポートされています。つまり、Javaソース、クラスおよびリソース・スキーマ・オブジェクトの作成、変更および削除に使用されるSQL文を監査できます。


関連項目:

詳細は、「監査」を参照してください。

1.8.3 PGA_AGGREGATE_TARGETパラメータ

PGA_AGGREGATE_TARGETパラメータは、init.oraファイルで設定できるデータベース・パラメータです。 このパラメータを使用して設定された目標値よりもPGAの使用量が多い場合、JVMでは、コールの最後に追加のメモリー管理アクションが実行され、PGAの使用量が削減されます。 特に、Javaヒープのライブ・コンテンツが新規領域にコピーおよび圧縮され、既存のJavaヒープは解放されます。 新規領域は後続のコールに対するJavaヒープとなります。 この手順は、データベース・コールの合間にJavaヒープを必要最小サイズまで圧縮するために実行されます。 ただし、コールの最後にライブJavaスレッドが存在する場合、この手順は実行されません。


関連項目:

『Oracle Databaseパフォーマンス・チューニング・ガイド』


注意:

  • 『Oracle Databaseパフォーマンス・チューニング・ガイド』のPGA_AGGREGATE_TARGETの初期設定に関する項では、Javaアプリケーションのメモリー使用量は考慮されていません。

  • サーバーにおけるJavaコードのメモリー使用量は、SQLのメモリー使用量と比べて予測がつきません。 したがって、自動PGAメモリー管理を監視およびチューニングすることが重要です。