10g リリース2（10.1.2） for Microsoft Windows
B15833-03
 目次 |
 索引 |
| Oracle Application Server アップグレードおよび互換性ガイド 10g リリース2（10.1.2） for Microsoft Windows B15833-03 |
|
この章では、Oracle Application Serverインストールの中間層のアップグレード方法について説明します。正常にアップグレードするためにシステムを準備する方法、さらにOracle Application Server Upgrade Assistantを起動および使用する方法について説明します。
OracleAS Upgrade Assistantの処理の終了後に個々のコンポーネントで実行する必要があるアップグレード後のタスクについても詳細に説明します。
この章の内容は、次のとおりです。
各中間層について、次のアップグレード・タスクを実行します。
upgradeディレクトリにインストールされているOracleAS Upgrade Assistantを使用して、カスタム・アプリケーションおよび構成データを新しいOracleホームにコピーします。
Oracle Application Server中間層のアップグレード処理では、最初に新しい10g リリース2（10.1.2）中間層をインストールします。これが、アップグレード先Oracleホームとなります。
次の項では、アップグレード準備のために新しい10g リリース2（10.1.2）中間層をインストールする場合に実行する必要があるタスクについて説明します。
リリース2（9.0.2）のOracle Internet Directoryを使用している場合は、2.6.5項「10g リリース2（10.1.2）中間層をインストールする前のリリース2（9.0.2） Oracle Internet Directoryのエントリの更新」に示す手順を使用します。
これは、10g リリース2（10.1.2）中間層がリリース2（9.0.2）のOracle Internet Directoryで動作するために必要な手順です。
リリース2（9.0.2）中間層をアップグレードする前に、mod_osso Oracle HTTP Serverモジュールが正しく構成されていることを確認します。mod_ossoモジュールは、OracleAS OracleAS Single Sign-Onアプリケーションへの認証を提供します。
特に、mod_ossoがOracleAS Web Cacheポートを使用するよう構成されていることを確認する必要があります。デフォルトでは、リリース2（9.0.2）のインストール時に、mod_ossoがOracle HTTP Serverのリスニング・ポートを使用するよう構成されます。
mod_ossoを再構成するには、リリース2（9.0.2）のossoreg.jarユーティリティを使用して、OracleAS Web Cacheポートを使用するようにリリース2（9.0.2）のOracleAS Single Sign-Onソフトウェアを再登録します。
ossoreg.jarユーティリティの使用方法については、Oracle9i AS Single Sign-Onのリリース・ノートのSingle Sign-On ServeへのOracle HTTP Serverの登録に関する項を参照してください。リリース2（9.0.2）のリリース・ノートは、Oracle Technology Networkで入手可能なプラットフォーム固有のリリース2（9.0.2）ドキュメント・ライブラリにあります。
http://www.oracle.com/technology/documentation/ias.html
リリース2（9.0.2）のossoreg.jarユーティリティを実行するときは、すべてのポート指定をOracleAS Web Cacheポートに置換します。このポートは、リリース2（9.0.2）のOracleホームのportlist.iniファイルに記載されています。
ORACLE_HOME¥install¥portlist.ini
portlist.iniファイルの内容を表示した場合、最初のエントリはOracle HTTP Serverポートです。OracleAS Single Sign-Onサーバーはデフォルトでこのポートに登録されています。このファイルで次にリストされているポートは、OracleAS Web Cacheポートです。ossoreg.jarユーティリティを実行するときは、このOracleAS Web Cacheポートを使用します。
中間層のアップグレード手順は、最新パッチ・セットを使用してテスト済です。この最新パッチ・セットはOracleMetaLinkから入手できます。
したがって、Oracle Application Server リリース2（9.0.2）からのアップグレードの準備として10g リリース2（10.1.2）をインストールする前に、アップグレード対象のソース中間層およびその中間層が依存するOracleAS Infrastructureコンポーネントに、Oracle Application Serverリリース2（9.0.2）の最新パッチ・セットを適用します。
OracleMetaLinkのWebサイトは、次のURLにあります。
http://metalink.oracle.com/
このドキュメントが発行された時点では、Oracle9i AS 9.0.2.3パッチ・セット（3038037）がOracle9i ASの最新パッチ・セットです。このパッチ・セットを入手するには、 OracleMetaLinkでパッチ番号3038037を検索します。
中間層のアップグレード処理では、最初にOracle Application Server 10g リリース2（10.1.2）中間層をインストールします。
後で時間を節約し、新しいOracleホームにアップグレードする場合に発生する可能性のある問題を回避するため、10g リリース2（10.1.2）の新しいアップグレード先Oracleホームをインストールする前に、次のチェックリストを確認してください。
次の項では、中間層のApplication Serverインスタンスのアップグレードを開始する前に、実行する必要があるタスクについて説明します。
OracleAS Upgrade Assistantを実行すると、ソースOracleホームおよびアップグレード先Oracleホームのすべてのプロセスが停止します。ただし、リリース2（9.0.2）またはリリース2（9.0.3）のソースOracleホーム内のEnterprise Manager Web Siteは停止しません。
いくつかの理由により、OracleAS Upgrade Assistantでは、Enterprise Manager Web Siteは自動的に停止されません。そのため、次の手順を使用して、手動でEnterprise Manager Web Siteを停止する必要があります。
アクティブなEnterprise Manager Web Siteは、Windowsレジストリの次のエントリに格納されています。
HKEY_LOCAL_MACHINE¥SOFTWARE¥ORACLE¥em_loc
ACTIVE_EM_ORACLE_HOME¥bin¥emctl stop
Enterprise Managerによって、ias_adminの管理パスワードを入力するように要求されます。
ACTIVE_EM_ORACLE_HOME¥bin¥emctl switch home
このコマンドによって、アクティブなOracle Enterprise Managerが含まれる別のOracle9i ASインスタンスを選択できるダイアログ・ボックスが表示されます。
SOURCE_ORACLE_HOME¥bin¥emctl stop
多数のアプリケーションまたはOC4Jインスタンスをアップグレードする場合、OC4Jアップグレードの抽出フェーズのためにメモリーを増やすと効果的です。アップグレード処理の抽出フェーズでは、新しいJavaプロセスが開始されます（つまり、新しいJava Virtual Machine（JVM）が起動されます）。JVMの最小および最大のメモリーを構成できます。これを行うには、次の構成ファイルのJavaVMプロパティを構成します。
DESTINATION_ORACLE_HOME¥upgrade¥Oc4jPlugin.cfg
例4-1に、調整可能なJavaVMのプロパティおよび引数を示します。
<JavaVM> <JVMproperties property="-Xms256m"/> <JVMproperties property="-Xmx512m"/> </JavaVM>
例4-1にはデフォルト値の最小256MBおよび最大512MBが示されていますが、複数のOC4Jインスタンスおよび多数の大規模なアプリケーションをアップグレードするには、上限を1024MBにすると効果的です。
Infrastructureを使用する中間層をアップグレードする前に、Infrastructureを起動してアクセス可能にする必要があります。Infrastructureが停止されている場合、特定のアップグレード処理に失敗します（Oracle Application Server Containers for J2EE、OracleAS PortalおよびOracle Application Server Wirelessなど）。
次の項では、Oracle Application Serverインスタンスを10g リリース2（10.1.2）にアップグレードするためのOracleAS Upgrade Assistantの使用方法について説明します。
OracleAS Upgrade Assistantには、Oracle Application Server中間層のアップグレード時に発生する可能性がある問題のトラブルシューティングに使用できる一連のログ・ファイルがあります。
OracleAS Upgrade Assistantのデフォルトのロギング動作は、次の構成ファイルのプロパティを設定することにより、オプションでカスタマイズできます。
DESTINATION_ORACLE_HOME¥upgrade¥iasua.properties
ロギング・プロパティおよびその用途は、次のとおりです。
log.level=NOTIFICATIONは、OracleAS Upgrade Assistantによってアップグレードされるすべてのコンポーネントのロギング・レベルを「NOTIFICATION」に設定します。（デフォルト値は、「NOTIFICATION」です。）
OC4J.log.level=TRACEは、OracleAS Upgrade Assistantのロギング・レベルが「通知」に設定されている場合でも、Oracle Application Server Containers for J2EEのアップグレードのロギング・レベルを「TRACE」に設定します。（デフォルト値は、「NOTIFICATION」です。）
log.append=TRUEは、ログ・エントリを既存のログ・ファイルに追加します。（デフォルト値は、「TRUE」です。）
表4-1 OracleAS Upgrade Assistantのロギング・プロパティ
この項では、アップグレードを実行するためのOracleAS Upgrade Assistantの使用方法を手順を追って説明します。
DESTINATION_ORACLE_HOME¥upgrade¥iasua.bat
「ようこそ」画面が表示されます。
「Oracleホーム」画面が表示されます。ソースOracleホームのドロップダウン・リストに、リリース2（9.0.2）、リリース2（9.0.3）および10g （9.0.4）のOracleホームの名前が示されます。ここに示されるのは、現在のコンピュータ上のOracle製品のインベントリにあるOracleホーム、およびアップグレード先Oracleホームのインストール・タイプと互換性があるインストール・タイプを使用してインストールされたOracleホームです。
アップグレード先Oracleホームは、OracleAS Upgrade Assistantが実行されている10g リリース2（10.1.2）のOracleホームです。
アップグレード前の必須タスクの多くは、アップグレード処理が開始される前に、OracleAS Upgrade Assistantによって自動的に実行されます。
ただし、場合によっては、自動的に実行されないアップグレード前の要件を示すダイアログ・ボックスが表示されます。OracleAS Upgrade Assistantの動作を正常に継続させるには、これらの要件を満たす必要があります。
このダイアログ・ボックスが表示されるシナリオには、次の2つがあります。
「コンポーネントの調査」ダイアログ・ボックスが表示されます。OracleAS Upgrade AssistantがソースOracleホームの各コンポーネントを調査し、アップグレードが必要かどうかを判断します。
各コンポーネントの「ステータス」列に、表4-2に示す調査ステータス値のいずれかが示されます。
アップグレードを継続するために失敗した調査に対応する必要がある場合は、問題を解決してからOracleAS Upgrade Assistantを再起動するようダイアログ・ボックスにメッセージが表示されます。
調査によって、アップグレード対象のコンポーネントの一部にのみ影響を与える問題が明らかになった場合、OracleAS Upgrade Assistantによって、失敗したコンポーネントを示すダイアログ・ボックスが表示されます。ここで、次に実行する手順について「ヘルプ」をクリックします。
「アップグレード中」画面が表示されます。
各コンポーネントの「ステータス」列に、表4-3に示すステータス値のいずれかが示されます。
アップグレードが正常に完了すると、「アップグレードに成功しました」画面が表示されます。
アップグレードが失敗すると、「アップグレード失敗」画面が表示されます。
問題を解決しOracleAS Upgrade Assistantを再起動する方法については、4.5.1項「OracleAS Upgrade Assistant エラーの解決」および4.5.2項「OracleAS Upgrade Assistantの再起動」を参照してください。
関連項目:
「アップグレードに成功しました」画面に、アップグレード・ログ・ファイルの場所、および各種のコンポーネントで実行する必要があるアップグレード後のタスクが一覧で示されます。
この項では、アップグレードを実行するためのOracleAS Upgrade Assistantコマンドライン・バージョンの起動および使用方法を説明します。
DESTINATION_ORACLE_HOME¥upgrade¥iasua.bat -sourcehome SOURCE_ORACLE_HOME
例4-2に、iasua.batコマンドにより表示される出力の例を示します。アップグレード対象の中間層がOracleAS Infrastructureに依存している場合は、Infrastructureを起動するように要求されます。中間層がリリース2（9.0.2）インストールまたはリリース2（9.0.3）インストールの場合は、OracleAS Upgrade Assistantによって自動的に停止されないEnterprise Manager Web Siteのプロセスを停止するように要求されます。
例4-3に示すようなメッセージが画面に表示されます。（メッセージは、Oracleホームにあるコンポーネントによって異なります。）
prompt> iasua.bat -sourcehome D:¥private¥oracle¥appserver1 Validating Oracle homes Validating component plug-ins Initializing component plug-ins Pre-upgrade requirements: Start the Infrastructure Associated with the source and destination Oracle home. Verify that each of the pre-upgrade requirements above have been met. Have the pre-upgrade requirements been met?[No]Yes例4-3 コマンドライン・バージョンのOracleAS Upgrade Assistantからの出力例（追加）
Examining component "Oracle Process Manager and Notification Server (OPMN)" Examining component "Instance Configuration" Examining component "Oracle Application Server Containers for J2EE (OC4J)" Examining component "Oracle HTTP Server" Examining component "OracleAS Web Cache" Examining component "Oracle mod_plsql" Examining component "Oracle Enterprise Manager" Upgrading component "Oracle Process Manager and Notification Server (OPMN)" Upgrading component "Instance Configuration" Upgrading component "Oracle Application Server Containers for J2EE (OC4J)" Upgrading component "Oracle HTTP Server" Upgrading component "OracleAS Web Cache" Upgrading component "Oracle mod_plsql" Upgrading component "Oracle Enterprise Manager" The command completed successfully
次の項では、中間層のアップグレード時に発生する問題のトラブルシューティング方法について説明します。
アップグレード処理のいずれかの段階でエラーが発生した場合、その原因を解決してからアップグレードを再試行する必要があります。次の項で、OracleAS Upgrade Assistantエラーを解決するうえでのガイドラインを説明します。
特定の条件のもとでは、OracleAS Upgrade Assistantはアップグレードを実行できません。たとえば、複数のプロセスが複数のOracleホームで実行されている場合、Infrastructureサービスが使用不可の場合、大規模なOC4Jアプリケーションのアップグレードに対してメモリーが不十分な場合にはアップグレードを実行できません。
この項では、それぞれの条件とその原因を明らかにし、解決方法を説明します。
「Oracleホーム」画面のドロップダウン・リストに必要なソースOracleホームが表示されない場合の条件として、インストール・タイプが誤っている、複数のOracleホームが異なるコンピュータにある、OracleホームがOracle製品のインベントリで識別されないのいずれかが考えられます。それぞれの解決方法は、次のとおりです。
ソース中間層のインストール・タイプがアップグレード先中間層インスタンスのインストール・タイプと互換性がない場合、ソースOracleホームは表示されません。この場合、次のいずれかを実行します。
ソース中間層インスタンスがアップグレード先中間層インスタンスと異なるコンピュータにインストールされている場合も、ソース中間層が選択肢として表示されません。この場合、アップグレード先中間層インスタンスを、アップグレードされるソース・インスタンスと同じコンピュータにインストールする必要があります。
OracleAS Upgrade Assistantでは、Oracleインベントリの内容を分析して、システム上にあるOracle Application ServerのOracleホームを検出します。
Oracleソフトウェア製品をホスト・コンピュータにインストールするごとに、ソフトウェア・インストールに関する情報が、Oracle Universal Installerによってハード・ディスクに保存されます。このソフトウェア構成情報が含まれているディレクトリおよびファイルは、「Oracle Universal Installerインベントリ」と呼ばれます。
場合によって、特定のインストールがインベントリに表示されないことがあります。その場合は、インベントリ・ディレクトリが削除されたか、または損傷を受けたか、あるいはコンピュータ上に複数のインベントリがインストールされている可能性があります。
OPMN、OC4JまたはOracle HTTP Serverのアップグレード時にアップグレードが失敗する場合、原因としてソースおよびインストール先の両方のインスタンス、またはいずれかのインスタンスでOPMNがまだ実行されていることが考えられます。OracleAS Upgrade Assistantを起動する前に、OPMNを停止する必要があります。
調査フェーズでアップグレードが失敗する場合、原因としてInfrastructureが使用不可であることが考えられます。OracleAS Upgrade Assistantは特定の操作でInfrastructureサービスを必要とするので、OracleAS Upgrade Assistantを起動する前にInfrastructureを起動する必要があります。
多数のOC4Jアプリケーションまたは大規模なOC4Jアプリケーションのアップグレード時にアップグレードが失敗する場合、原因としてメモリー不足が考えられます。このような場合のアップグレード操作には、メモリーを増やします。
OracleAS Upgrade Assistantログ・ファイルを使用すると、調査およびアップグレードの失敗の原因を特定できます。
OracleAS Upgrade Assistantログ・ファイルは、次の場所にあります。
DESTINATION_ORACLE_HOME¥upgrade¥log¥iasua.log
|
注意: デフォルトでは、OracleAS Upgrade Assistantは、ロギング・データを既存のログ・ファイルに追加します。OracleAS Upgrade Assistantの各セッションで既存のログ・ファイルが上書きされるように、このデフォルトの動作を変更する方法は、4.4.1項「OracleAS Upgrade Assistantのロギング動作の指定（オプション）」を参照してください。 |
調査が失敗した原因を特定するには、次の手順を実行します。
DESTINATION_ORACLE_HOME¥upgrade¥log¥iasua.log
Starting to examine component_nameを探します。
アップグレードが失敗した原因を特定するには、次の手順を実行します。
DESTINATION_ORACLE_HOME¥upgrade¥log¥iasua.log
Starting to upgrade component_nameを探します。
次の項では、Oracle Application Server Containers for J2EEのアップグレードの失敗の原因と、その解決方法について説明します。
アップグレード後に構成が正しく実行されない場合、OC4Jアプリケーション・ファイルに対する構成変更がApplication Server Controlコンソール以外の方法で行われた可能性があります。OracleAS Upgrade Assistantによって実行されるOC4Jアップグレードでは、Application Server Controlコンソールによって行われた変更のみがアップグレードされます。手動で編集したファイルは管理対象の構成の範囲外になる場合があり、その編集内容がアップグレードで保持されない可能性があります。
OC4JのデプロイではJ2EE準拠ルールが規定されているため、J2EEに完全に準拠していないアプリケーションはOracleAS Upgrade Assistantによってアップグレードされない場合があります。OracleAS Upgrade Assistantは、単にソースOracleホームのファイルを読み取ってアップグレード先Oracleホームにデプロイするだけであるため、デプロイが失敗した場合、アプリケーションがJ2EE準拠でない可能性があります。OracleAS Upgrade Assistantは、なんらかの原因でアプリケーションをデプロイできないと、次のログ・ファイルに例外を記録します。
DESTINATION_ORACLE_HOME¥upgrade¥log¥iasua.log
明示的にJ2EE準拠の問題として示されない例外も、J2EE準拠の問題が失敗の原因である場合があります。J2EEおよびEJBの仕様やアプリケーションに使用されるEJB機能に関する知識は、デプロイの失敗の防止およびトラブルシューティングに役立ちます。10g リリース2（10.1.2）は、リリース2（9.0.2）またはリリース2（9.0.3）より後のリリースのEJB仕様をサポートすることに注意してください。
J2EEアプリケーションの開発は標準化され移植可能ですが、XML構成ファイルは異なります。OC4Jアプリケーションをデプロイするには、複数のXMLファイルを構成しなければならない場合があり、アプリケーションが使用するサービスによって必要な構成が異なります。たとえば、アプリケーションがデータベースを使用する場合は、data-sources.xmlファイルのDataSourceオブジェクトを構成します。
アプリケーションはデプロイ可能でも、サーバーが予測不能または望ましくない動作になる可能性があるため、アップグレード前にすべてのアプリケーションがJ2EEに全面的に準拠しているかどうかを確認することをお薦めします。たとえば、各アプリケーションでapplication.xmlに一意のコンテキスト・ルートが定義されていることを確認します。
dcmctlユーティリティは、J2EE準拠を検証するコマンドを提供します。1つの入力（EARファイルの名前）を受け取って、そのファイルの準拠していない特性をリストします。構文は次のとおりです。
DESTINATION_ORACLE_HOME¥dcm¥bin¥dcmctl validateEarFile -f full_path_and_filename_for_ear_file
EARファイルのフルパスを指定する必要があります。
プロキシ・サーバーを使用してインターネットに接続する場合、検証ルーチンがたとえばSun社のサイトのDTDにアクセスできるようにプロキシ設定を構成します。
詳細は、4.5.1.3.4項「validateEarFileコマンドのプロキシ設定の構成」を参照してください。
外部ネットワークとの接続にプロキシ・サーバーを使用しない場合、このコマンドに-noproxyフラグを使用します。たとえば、次に示すとおりです。
DESTINATION_ORACLE_HOME¥dcm¥bin¥dcmctl validateEarFile -f full_path_and_filename_for_ear_file -noproxy
validateEarFileコマンドからの出力例については、例4-4および例4-5を参照してください。
dcmctl validateEarFile -v -f simple.ear No J2EE XML/DTD validation errors were found例4-5 validateEarFileコマンドとJ2EE非準拠アプリケーションの出力
dcmctl validateEarFile -v -f petstore.ear Warning: J2EE/DTD validation errors were found ADMN-906001 {0} Base Exception: oracle.ias.sysmgmt.deployment.j2ee.exception.J2eeDeploymentException: Cannot get xml document by parsing /var/tmp/jar50152.tmp: Invalid element 'servlet' in content of 'web-app', expected elements '[servlet-mapping, session-config, mime-mapping, welcome-file-list,error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, ejb-ref]'.
validateEarFileコマンドのプロキシ設定を構成するには、プロキシのホスト名およびポートを指定する環境変数ORACLE_DCM_JVM_ARGSを定義します。
たとえば、Windows 2000 Systemsでは、次のように「システム」コントロール パネルを使用できます。
-Dhttp.Proxyhost=hostname.domain -Dhttp.Proxyport=port
前述の例では、hostname.domainをプロキシ・サーバーのホスト名およびドメインに置き換え、portをプロキシ・サーバーのポートに置き換えます。
かわりに、DOSコマンド・ウィンドウで次のコマンドを発行し、変数を設定することもできます。
set ORACLE_DCM_JVM_ARGS=-Dhttp.Proxyhost=www-proxy.hostname.com -Dhttp.Proxyport=9999
Oracleホームの処理の一部または全体を終了したOracleAS Upgrade Assistantは再起動できます。次の手順を実行します。
前のアップグレードの結果によって、OracleAS Upgrade Assistantが次のメッセージを表示します。
前のアップグレードが失敗だった場合のメッセージは、次のとおりです。
The OracleAS Upgrade Assistant has already processed this destination Oracle home directory, it didn't complete successfully.
前のアップグレードが成功だった場合のメッセージは、次のとおりです。
The OracleAS Upgrade Assistant has already successfully processed this destination Oracle home directory.
「はい」を選択して（コマンドライン・バージョンの場合）アップグレードを続行します。
この項では、OracleAS Upgrade Assistantによる処理の終了後に、新しくアップグレードした10g リリース2（10.1.2）インスタンスが機能するために必要なタスクの実行方法について説明します。
この項では、次の項目について説明します。
中間層をOracle Application Server 10g リリース2（10.1.2）へアップグレードすると、アップグレードされたインスタンスは、ソース・インスタンスと同じポートを使用するように、OracleAS Upgrade Assistantによって構成されます。そのため、アップグレード後にソースおよびアップグレード先の中間層インスタンスを同時に起動できません。同時に起動すると、ポート競合が発生します。
アップグレード前後のポート割当てに関する重要な情報は、次の項を参照してください。
portlist.iniファイルは、アップグレードされたポート設定を反映せず、アップグレード先インスタンスがインストールされたときにインストーラによって割り当てられたポート値のままになります。portlist.iniファイルは、アップグレード先Oracleホームの次の場所にあります。
DESTINATION_ORACLE_HOME¥install¥portlist.ini
アップグレードされた中間層の現在のポート設定は、Application Server ControlコンソールのApplication Serverのホームページにある「ポート」ページを使用して調べることもできます。「ポート」ページには、Oracle Application Serverインスタンスで使用されるすべてのポートが表示されます。
Application Server Controlコンソールを表示するには、ブラウザで次のURLを入力します。
http://appserver_host_name:app_server_control_port_number
Application Server Controlコンソールのポートが不明な場合は、Application ServerのOracleホーム内の次の構成ファイルにあるStandaloneConsoleURLエントリで、ポート番号を確認できます。
DESTINATION_ORACLE_HOME¥sysman¥emd¥targets.xml
リリース2（9.0.2）からアップグレードした場合、OracleAS Upgrade AssistantではApplication Server Controlコンソールのポートを元のポートにリセットできません。これは、コンソールへのアクセスに使用されるポートが、アップグレードされたOracleホーム内で定義されていない場合があるためです。
ただし、10g （9.0.4）からアップグレードする場合は、Application Server Controlコンソールのポート番号がOracleAS Upgrade Assistantによって自動的にリセットされるため、ソースOracleホームの元のポート番号が使用されます。
10g （9.0.4）からアップグレードした後、10g リリース2（10.1.2）の「ようこそ」ページは引き続き10g リリース2（10.1.2）のインストール時に割り当てられたApplication Server Controlコンソールのポート番号にリンクされます。そのため、10g （9.0.4）からアップグレードした後は、10g リリース2（10.1.2）の「ようこそ」ページからApplication Server Controlコンソールへのリンクは機能しません。
|
関連項目:
10g リリース2（10.1.2）のアップグレード前後におけるApplication Server Controlコンソールのポートの割当て方法の例については、4.6.1.4項「アップグレード前後のポート割当ての例」を参照してください。 リリース2（9.0.2）およびリリース2（9.0.3）のEnterprise Manager Web Siteと10g （9.0.4）および10g リリース2（10.1.2）のApplication Server Controlコンソールの相違点の詳細は、『Oracle Application Server管理者ガイド』にあるOracle Application Serverの旧リリースの管理の項を参照してください。 |
OracleAS Upgrade Assistantによって、新しい10g リリース2（10.1.2）のOracleホームに初期ポートがどのように割り当てられ、変更されるかを説明するために、表4-5に、Oracle HTTP Server、Oracle Enterprise Manager 10g Application Server ControlコンソールおよびOracle Application Server Web Cacheのアップグレード前後の値の例を示します。
| コンポーネント | ソースOracleホームのポート | インストーラによって割り当てられたアップグレード先Oracleホームのポート値、およびportlist.iniファイルのポート値 | アップグレード後のポート値 |
|---|---|---|---|
|
Oracle HTTP Server |
リスニング: 4444（SSL） |
リスニング: 4445（SSL） |
リスニング: 4444（SSL）1 |
|
Oracle Enterprise Manager 10g Application Server Controlコンソール |
1810 |
1812 |
ソースOracleホームがリリース2（9.0.2）またはリリース2（9.0.3）の場合は1812。 ソースOracleホームが10g （9.0.4）の場合は1810。 |
|
Oracle Application Server Web Cache |
統計: 4002 |
統計: 4005 |
統計: 4002 |
|
1
詳細は、4.6.3.1項「アップグレード後のSecure Sockets Layer（SSL）構成の確認」を参照してください。 |
中間層をアップグレードした後は、アップグレード先Oracleホームで次のパスワードを使用します。
ias_adminパスワードを使用します。
Administratorパスワードを使用します。
次の項では、Oracle HTTP Serverのアップグレード後のタスクについて説明します。
ソースOracleホームでSSLを有効にした場合は、OracleAS Upgrade Assistantを使用した後、コンポーネントの構成がセキュアな通信用のままになっていることを確認します。
セキュアなOracle HTTP Serverの構成が適切であるかを確認するために、次の手順を使用して、opmn.xml構成ファイルおよびhttpd.conf構成ファイルで必要な値を調べます。この手順に従ってこれらの両方のファイルを構成しないと、SSLの構成に問題が発生する可能性があります。
DESTINATION_ORACLE_HOME¥opmn¥conf¥opmn.xml
opmn.xmlファイルでias-componentエントリを検索します。
<ias-component id="HTTP_Server"> <process-type id="HTTP_Server" module-id="OHS"> <module-data> <category id="start-parameters"> <data id="start-mode" value="ssl-enabled"/> </category> </module-data>
start-parametersカテゴリ・タグで、start-modeパラメータがssl-enabledに設定されていることを確認します。この設定により、Oracle HTTP ServerはOPMNによってSSLモードで起動されます。
DESTINATION_ORACLE_HOME¥Apache¥Apache¥conf¥httpd.conf
httpd.confファイルで次のエントリを検索します。
<IfDefine SSL> LoadModule ossl_module libexec/mod_ossl.so </IfDefine>
特に、LoadModule ossl_moduleコマンドが<IfDefine SSL>タグで囲まれていることを確認します。これにより、OPMNがSSLモードでの起動を指示した場合にのみ、Oracle HTTP ServerはSSLモードで起動されます。<IfDefine SSL>タグで囲まれていない場合、Oracle HTTP Serverは、OPMN構成にかかわらず、SSLモードで起動します。
10g リリース2（10.1.2）では、SSL構成は、OPMNによって制御されます。そのため、opmn.xmlファイルおよびhttpd.confファイルの両方で設定が一致していることが重要です。
OracleAS Upgrade Assistantは、Oracle HTTP Serverの標準設定をアップグレードします。構成ファイルまたはドキュメントが、標準以外の場所にある場合、または標準以外の方法で参照される場合は、それを手動でアップグレードする必要があります。そのような場合、あるいは手動のアップグレードが必要となる他の場合について説明します。
mod_ossoが構成されていた場合、アップグレード後もosso.confファイルはSingle Sign-OnサーバーでソースOracleホームのパートナ・エントリを使用します。使用するエントリの名前が適切でない場合（ソースOracleホームを表す場合）は、適宜名前を変更します。
httpd.conf、mod_oc4j.conf、mod_osso.confおよびmoddav.confの各ファイルがデフォルトの場所にない場合、ソースOracleホームにあるファイルのカスタマイズ内容をアップグレード先Oracleホームのファイルに適用することによって、手動でこれらのファイルをアップグレードします。
Alias、mod_rewriteなどのディレクティブやErrorLogなどのログ・ディレクティブが参照するファイルまたはディレクトリが存在する可能性があります。これらのアイテムをすべて手動でアップグレードして、ディレクティブが参照する所定の場所に存在するようにします。アップグレード後にこれらのファイルまたはディレクトリが見つからないと、Oracle HTTP Serverは起動しません。エラーを特定するには、アップグレード後にOracle HTTP Serverを個別に起動し、次のファイルを調べてこれらのアイテムに関連するエラーを検索します。
DESTINATION_ORACLE_HOME¥Apache¥Apache¥logs¥error_log
dms.confファイルに再配置する必要があります。
表4-6 Oracle HTTP ServerとOracle Application Server Web CacheのPort設定
| Oracle HTTP Serverのディレクティブ | Oracle Application Server Web Cacheの要素 |
|---|---|
|
VirtualHost |
サイト定義 |
|
Listen |
オリジナル・サーバー・ポート |
|
VirtualHost、Listen |
サイトからサーバーへのマッピング |
|
Port |
Listen |
DocumentRootディレクティブに指定される場所で、アップグレードする静的ドキュメント・ファイルおよびディレクトリを検出します。DocumentRootディレクティブは、静的ドキュメントおよび関連ディレクトリの場所を定義します。ベース・サーバーにはドキュメント・ルートの場所があり、各仮想ホストにもあります。OracleAS Upgrade Assistantは、これらのディレクトリ下のファイルをアップグレード先Oracleホームにコピーします。デフォルトのDocumentRootディレクトリに含まれているのは、インストーラによって配置されたデモ・プログラムおよびリリース・ノートであるため、OracleAS Upgrade Assistantはこのディレクトリをアップグレードしません。このディレクトリは、手動でアップグレードする必要があります。
SOURCE_ORACLE_HOME¥Apache¥Apache¥htdocs
OracleAS Upgrade Assistantは、Oracle Application Server Containers for J2EE（OC4J）のアップグレード・タスクの多くを実行します。ただし、OC4Jの一部のコンポーネントでは、Oracle Application Server 10g リリース2（10.1.2）を使用する前に、手動による調整が必要となる場合、または特性を認識しておく必要がある場合があります。
次の項では、OC4Jのアップグレードを完了するために必要なタスクの一部を説明します。
OC4J Upgrade Assistantはアップグレード時に、OC4J インスタンスのJ2EEアプリケーションを新しい10g リリース2（10.1.2）のOracleホームに再デプロイします。したがって、アプリケーションのEARファイル内に含まれるjazn-data.xmlおよびjazn.xmlファイルに加えられた変更は、自動的に移行されます。
ただし、次の場合は、一般的ではありませんが、手動による手順が必要になります。
orion-application.xmlファイルでは、アプリケーションによってjazn-data.xmlファイルの場所が次のように指定されている場合があります。
<jazn provider="XML" location="SOURCE_ORACLE_HOME¥j2ee¥jazn-data.xml">
アプリケーションのEARファイルにjazn-data.xmlが含まれていない場合は、新しい10g リリース2（10.1.2）環境にjazn-data.xmlを手動でコピーする必要があります。それに応じて、orion-application.xmlファイルでもこのファイルの場所を更新する必要がある場合もあります。
orion-application.xmlファイルでは、アプリケーションが次の構文を使用してjazn.xmlを指し示す場合があります。
<jazn config="path_to_jazn.xml" />
アプリケーションのEARファイルにjazn.xmlが含まれていない場合は、新しいインストール環境にこのファイルを手動でコピーする必要があります。それに応じて、orion-application.xmlファイルでもこのファイルの場所を更新する必要がある場合もあります。
リリース2（9.0.2）のOracleホームのOC4Jインスタンスをアップグレードする場合、Oracle Application Server 10g （9.0.4）および10g リリース2（10.1.2）では、jazn.jarファイルはjazn.jarとjazncore.jarの2つのJARファイルに分割されます。
そのため、JAZNを使用し、動的コンパイル（JSPなど）を必要とするOC4Jアプリケーションのアップグレード後、両方のJARファイルの名前をapplication.xmlファイルのライブラリ・パス・エントリに追加する必要があります。
次のように両方のエントリがapplication.xmlファイルに含まれていることを確認します。
<library path="DESTINATION_J2EE_HOME¥jazn.jar"/> <library path="DESTINATION_J2EE_HOME¥jazncore.jar"/>
この例では、DESTINATION_J2EE_HOMEを次のディレクトリ・パスに置き換えます。
DESTINATION_ORACLE_HOME¥j2ee¥home
デフォルトのOC4Jインスタンスは、Oracle Universal Installerによって自動的にインストールされ、Oracle Application Serverコンポーネントによって使用されます。
アップグレード時、デフォルトのOC4Jインスタンスは、OracleAS Upgrade Assistantではアップグレードされません。これらのデフォルトのOC4Jインスタンスは、10g リリース2（10.1.2）インストール手順によってアップグレード先Oracleホームにインストールされる新しいデフォルトのインスタンスに置き換えられます。ほとんどの場合、これらのデフォルトのインスタンスは、Oracle Application Serverコンポーネントでの特殊な用途を対象としています。これらのデフォルトのインスタンスには、次のものがあります。
ユーザー作成のOC4Jインスタンスは、ユーザーによって作成または変更されます。これにはhomeインスタンスが含まれます。
OracleAS Upgrade Assistantによって、homeインスタンスを含む、ユーザー作成のOC4Jインスタンスにおけるほとんどのプロパティおよび属性がアップグレードされます。ただし、ユーザー作成のOC4Jインスタンスのプロパティおよび属性には、自動的にアップグレードされないものもあります。
たとえばOracleAS Upgrade Assistantは、oc4j.propertiesで定義されているプロパティを、opmn.xmlの対応するjava-optionsセクション（起動および停止パラメータの両方）に追加します。ただし、OracleAS Upgrade Assistantは、このインスタンスについてJava Virtual Machine（JVM）によって定義される番号を定義するprocess-set プロパティはアップグレードしません。
次の項では、ユーザー作成の各OC4Jインスタンスで自動的にアップグレードできるopmn.xmlファイルの属性およびプロパティを判断するために、OracleAS Upgrade Assistantで使用される規則を説明します。
作成する各OC4Jインスタンスの属性およびプロパティは、Oracle Process Manager and Notification Server（OPMN）で管理される他のOracle Application Serverコンポーネントとともにopmn.xmlファイルで定義されます。
例4-6に、homeインスタンスを定義するopmn.xmlファイルの標準的なエントリを示します。このhomeインスタンスは、ユーザーが使用し変更できるデフォルトのOC4Jインスタンスです。
<ias-component id="OC4J"> <process-type id="home" module-id="OC4J" status="enabled"> <module-data> <category id="start-parameters"> <data id="java-options" value="-server -Djava.security.policy=$ORACLE_ HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"/> </category> <category id="stop-parameters"> <data id="java-options" value="-Djava.security.policy=$ORACLE_ HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"/> </category> </module-data> <start timeout="600" retry="2"/> <stop timeout="120"/> <restart timeout="720" retry="2"/> <port id="ajp" range="3301-3400"/> <port id="rmi" range="3201-3300"/> <port id="jms" range="3701-3800"/> <process-set id="default_island" numprocs="1"/> </process-type> </ias-component>
OC4Jインスタンスが、例4-6のjava-optionsタグ、start-parametersおよびstop-parametersによって定義されていることに注意してください。
java-optionsが-D以外の文字で始まる場合、OracleAS Upgrade Assistantは、opmn.xmlファイルに定義されているユーザー作成のOC4Jインスタンスについて、次の評価および処置を実行します。
java-optionsタグで定義されている引数をアップグレード先Oracleホームに定義された引数と比較します。
java-optionsが、ソースOracleホームにのみ存在し、アップグレード先Oracleホームには存在しない場合、OracleAS Upgrade Assistantは、ソースOracleホームに定義されているjava-optionsを、アップグレード先Oracleホームのjava-optionsタグに付加します。
OracleAS Upgrade Assistantでは、java-optionパラメータのセマンティックの解析は行いません。たとえば、ソースのopmn.xmlファイルに-Xmx256mが定義され、アップグレード先ファイルに-Xmx512mが定義されている場合、ファイルの内容は次のようになります。
<data id="java-options" value="-server -Djava.security.policy=$ORACLE_ HOME¥j2ee¥home¥config¥java2.policy -Djava.awt.headless=true" -Xmx512m -Xmx256m />
ただし、リリース2（10.1.2）のデフォルトのjava-optionsには、いずれの-Xオプションも含まれないため、中間層アップグレード時には、アップグレード先のjava-optionsタグに追加の引数が含まれる可能性はありません。特に、home OC4Jインスタンスのデフォルトのjava-optionsは、opmn.xmlファイルに次のように記述されます。
<data id="java-options" value="-server -Djava.security.policy=$ORACLE_ HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true"
java-optionsが-Dで始まる場合、OracleAS Upgrade Assistantは、opmn.xmlファイルに定義されているユーザー作成のOC4Jインスタンスについて、次の評価および処置を実行します。
java-optionsタグの-Dパラメータは、プロパティ/値ペアで構成されます。値がファイルのパスで、このパスにソースOracleホームが含まれている場合、OracleAS Upgrade Assistantはパラメータを無視します。
-Dパラメータを追加します。
10g （9.0.4）のOracleホームのアップグレード時、OracleAS Upgrade Assistantは、opmn.xmlファイルのstart-parametersセクションおよびstop-parametersセクションのjava-optionsをアップグレードします。
ただし、Oracle Application Server リリース2（9.0.2）の場合、java-optionは各OC4Jインスタンスについて1つのみ存在します。この場合、OracleAS Upgrade Assistantは、各インスタンスについて1つのjava-optionsタグをアップグレードし、定義済のパラメータをOC4Jインスタンスの開始および停止に適用します。
ライブラリ・パス、Javaオプション、OC4Jオプションなどのapplication.xmlファイルのエントリをカスタマイズした場合、それを手動でアップグレードする必要があります。
Oracle Application Server 10g リリース2（10.1.2）では、デフォルトのOC4JはJ2EE 1.3仕様に準拠します。その結果、場合によっては以前のOC4J実装で見られたのとは異なる動作が発生することがあります。下位互換性のためにOC4JはCTS準拠フラグをサポートしています。falseに設定すると、次のコンポーネントを以前のOC4J動作に戻すことができます。
OC4Jの互換性動作は、フラグoracle.cts.useCtsFlags（デフォルト値はtrue）によって決定されます。特定のアプリケーションのアップグレードにおいていずれかの点で問題が発生する場合には、CTS準拠を無効にしてOC4Jインスタンスを古い動作に戻すことができます。その場合、OC4Jプロパティ・ファイルでフラグの値をfalseに設定し、プロパティ・ファイルの場所をOC4Jに指定します。
たとえば、次の構成ファイルについて考えてみます。
DESTINATION_ORACLE_HOME¥j2ee¥home¥config¥oc4j.properties
このファイルには、次のフラグが含まれているとします。
oracle.cts.useCtsFlags=false
opmn.xmlファイルの<oc4j-option>要素を使用して、プロパティ・ファイルの名前および場所をOC4Jに指定します。opmn.xmlファイルは、次のディレクトリにあります。
DESTINATION_ORACLE_HOME¥opmn¥conf¥opmn.xml
<oc4j-option>要素の出力例を次に示します。
<oc4j> ... <oc4j-option value="-p DESTINATION_ORACLE_HOME¥j2ee¥home¥config¥oc4j.properties"/> ... </oc4j>
これは、次のようにスタンドアロン・モードでOC4Jを起動するのと同じです。
java -jar oc4j.jar -p DESTINATION_ORACLE_HOME¥j2ee¥home¥config¥oc4j.properties
J2EE 1.3に準拠するOracle JMS（OJMS）のOracle Application Server 10g リリース2（10.1.2）実装では、一部の動作がOracle9i ASリリース1.0.2.2のOJMS動作と異なります。（Oracle9i ASリリース2（9.0.2）およびリリース2（9.0.3）には、このようなアップグレードの考慮事項はありません。）相違点は、次のとおりです。
OJMS 1.0.2.2実装では、デキューされたメッセージのJMSExpirationヘッダー値は、メッセージの期限切れまでの時間です（ミリ秒単位）。メッセージが期限切れにならない場合の値は-1です。
OJMS 1.0.2.2の実装では、優先順位はjava.lang.Integer.MIN_VALUEが最高、Integer.MAX_VALUEが最低、1がデフォルトです。
OJMS 1.0.2.2の実装では、同じ名前の永続トピック・サブスクライバは、異なるトピックにサブスクライブされる場合に許可されます。
OJMS 1.0.2.2実装では、セレクタ式構文はこのような制限やSQL92構文の特定サブセットに従う必要はありません。
J2EE 1.3に準拠するOracle JDBCのOracle Application Server 10g リリース2（10.1.2）実装では、一部の動作がOracle9i ASリリース2（9.0.2）以下のJDBC動作と異なります。相違点は、次のとおりです。
java.sql.ResultSetインスタンス）のgetObject()メソッドは、NUMBER列に対して正確なjava.lang.Double値を返します。または、NUMBER列に対して不正確なjava.math.BigDecimal値を返します。リリース2（9.0.2）以下では、getObject()はNUMBER列に対してBigDecimal値を返します。
NUMBER列のメタデータ: 10g リリース2（10.1.2）では、結果セット・メタデータ・オブジェクト（java.sql.ResultSetMetaDataインスタンス）のgetColumnTypeName()メソッドは、NUMBER列に対して正確な"FLOAT"を返します。または、NUMBER列に対して不正確な"NUMBER"を返します。getColumnType()メソッドは、NUMBER列に対して正確なjava.sql.Types.FLOATを返します。または、NUMBER列に対して不正確なTypes.NUMBERを返します。リリース2（9.0.2）以下では、getColumnTypeName()はNUMBER列に対して"NUMBER"を返し、getColumnType()はNUMBER列に対してTypes.NUMBERを返します。
getObject()メソッドは、DATE列に対してjava.sql.Date値を返し、TIMESTAMP列に対してjava.sql.Timestamp値を返します。リリース2（9.0.2）以下では、getObject()はDATE列に対してjava.sql.Timestamp値を返します。（TIMESTAMP列はサポートされていませんでした。）
executeQuery()コールにSELECT文以外（INSERT、UPDATE文など）が含まれる場合、JDBCドライバが例外をスローするのが正常な動作です。同様に、executeUpdate()コールにSELECT文が含まれる場合、ドライバは例外をスローします。（UPDATE、INSERTまたはDELETE文が必要です。）リリース2（9.0.2）以下では、このような場合は例外になりません。
J2EE 1.3に準拠するXML Parser for JAXP/XDKのOracle Application Server 10g リリース2（10.1.2）実装では、一部の動作がOracle9i ASリリース2（9.0.2）以下のXMLパーサーの動作と異なります。相違点は、次のとおりです。
getNamespaceURI()のNULL戻り値: 10g リリース2（10.1.2）では、要素または属性にネームスペースが定義されていない場合、getNamespaceURI()メソッドは'null'を返します。リリース2（9.0.2）以下では、このような場合、getNamespaceURI()メソッドは'""'を返します。
getLocalName()のNULL戻り値: 10g リリース2（10.1.2）では、要素または属性がcreateElement()またはcreateAttribute()へのDOMレベル1 APIコールを使用して作成された場合、getLocalName()メソッドは'null'を返します。リリース2（9.0.2）以下では、このような場合、getLocalName()メソッドは'"Transfer interrupted!"'を返します。
getPrefix()のNULL戻り値: 10g リリース2（10.1.2）では、要素または属性がcreateElement()またはcreateAttribute()へのDOMレベル1 APIコールを使用して作成された場合、getPrefix()メソッドは'null'を返します。リリース2（9.0.2）以下では、このような場合、getPrefix()メソッドは'""'を返します。
SAXExceptionまたはSAXParseExceptionをスローします。リリース2（9.0.2）以下では、エラー・ハンドラはエラー条件でXMLParseExceptionをスローします。
IOExceptionがスローされます。リリース2（9.0.2）以下では、IOExceptionはXMLParseExceptionにラップされます。
Oracle9i AS リリース2（9.0.3）以上では、Oracle Application Server Containers for J2EEは、完全にJ2EE 1.3仕様に準拠してEnterprise JavaBeans（EJB）2.0仕様を実装しています。したがって、リリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードする場合、コンテナ管理の永続性およびコンテナ管理の関係の領域でEJB機能を使用するアプリケーションは変更が必要です。
次の項では、アップグレードによって影響を受けるJSP設定について説明します。
Oracle9i ASリリース2（9.0.3）以上では、OC4J JSPコンテナはデフォルトで、JSP仕様に従って次にリストするパッケージをJSPページにインポートします。pageディレクティブのimport設定は必要ありません。
javax.servlet.*
javax.servlet.http.*
javax.servlet.jsp.*
以前のリリースでは、次のパッケージもデフォルトでインポートされていました。
java.io.*
java.util.*
java.lang.reflect.*
java.beans.*
下位互換性のための方法として、JSPのextra_imports構成パラメータを使用できます。あるいは、pageディレクティブによるか、グローバル・インクルードによって必要なインポートを追加できます。詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。
Oracle Application Server 10g リリース2（10.1.2）にアップグレードしてJSPページを使用する場合は、次の主要なJSP構成パラメータの適切な設定を使用します。
これらは、global-web-application.xmlファイルまたはアプリケーションのorion-web.xmlファイルでJSPフロントエンド・サーブレットの初期化パラメータとして設定します。例4-7に、JSP構成パラメータの例を示します。
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class> <init-param> <param-name>check_page_scope</param-name> <param-value>true</param-value> </init-param> ... </servlet>
JSP構成パラメータの詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。
check_page_scope（ブール型、デフォルトはfalse）: このパラメータは、Oracle9i ASリリース2（9.0.3）で導入されました。OC4J環境の場合、これをtrueに設定して、JspScopeListenerユーティリティによるOracle固有のpageスコープ・チェックを有効化します。
このパラメータは、OC4J以外の環境では関係ありません。JServの場合、Oracle固有のpageスコープ・チェックは常に有効です。他の環境の場合、このOracle固有の実装は使用されないので、JspScopeListenerページ・スコープ機能のcheckPageScopeカスタム・タグを使用する必要があります。JspScopeListenerの詳細は、『Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス』を参照してください。
forgive_dup_dir_attr（ブール型、デフォルトはfalse）: このパラメータは、Oracle9i ASリリース2（9.0.3）で導入されました。これをtrueに設定して、OC4JなどのJSP 1.2環境において、単一のJSP変換単位（JSPページとJSPページがincludeディレクティブによってインクルードしたもの）内の同じディレクティブ属性に重複設定がある場合に変換エラーを回避します。
JSP 1.2仕様では、pageディレクティブのimport属性を例外として、ディレクティブ属性が単一のJSP変換単位内で複数回設定されていないことをJSPコンテナが確認する必要があると規定しています。
JSP 1.1仕様では、このような制限は指定されていませんでした。OC4Jは、下位互換性のためにforgive_dup_dir_attrパラメータを提供しています。
Oracle Application Server 10g リリース2（10.1.2）に同梱されているSun社のJDK 1.4環境へ移行する場合の考慮事項の中で、サーブレットおよびJSPの開発者にとって特に重要な問題があります。
Sun社は、「コンパイラは、名前のないネームスペースから型をインポートするimport文を拒否するようになりました」と述べています。（セキュリティ問題および以前のバージョンのJDKでの曖昧性に対応することを目的としています。）これは基本的にパッケージ内に存在しないクラス（クラスのメソッド）をコールできないことを意味します。コールしようとすると、コンパイル時にすべて致命的エラーになります。
この問題は、特にJSP開発者がJSPページからJavaBeansをコールする場合に影響します。このようなBeanは通常パッケージ外にあります（ただし、現在JSP2.0仕様では新規のコンパイラの要件を満たすためにBeanはパッケージ内にある必要があります）。パッケージ外のJavaBeansをコールする場合、OC4J 9.0.3 / JDK 1.3.1以下の環境で作成されて実行されていたJSPアプリケーションは、OC4J 9.0.4 / JDK 1.4環境では動作しません。
アプリケーションをアップグレードしてすべてのJavaBeansおよびコールされるその他のクラスがパッケージに存在するようになるまでは、この問題を回避するためにJDK 1.3.1環境に戻すことができます。
パッケージにないクラスの問題およびその他のJDK 1.4互換性の問題の詳細は、次のWebサイトを参照してください。
http://java.sun.com/j2se/1.4/compatibility.html
特に、「Incompatibilities Between Java 2 Platform, Standard Edition, v1.4.0 and v1.3」を参照してください。
Oracle Application Server 10g リリース2（10.1.2）にアップグレードしてサーブレットを使用する場合、サーブレットのAPIおよび動作の次の変更点について注意してください。
Oracle HTTP Serverは、以前のOracle9i ASリリースでは、リクエストを受け取ると常にそのURIをデコードしてからOC4Jに渡しました。したがって、getRequestURI()（リクエスト・オブジェクトのメソッド）の応答に基づいて計算を行うサーブレットは、一度デコードされた値を暗黙的に受け取っていました。OC4J 9.0.4実装では、Oracle HTTP ServerはOC4Jに対して変更されないバージョンのURIを送信するため、その値はgetRequestURI()の戻り値としてOC4Jによって使用されます。
Oracle HTTP ServerとOC4Jの通信にmod_rewriteモジュールをmod_oc4jとともに使用する場合、mod_oc4jに送信される書き換えられたURIは、OC4Jに送信されるURIと同じであり、getRequestURI()の戻り値ではmod_rewriteのルールが適用されます。
mod_rewriteおよびmod_oc4jモジュールについては、『Oracle HTTP Server管理者ガイド』を参照してください。mod_rewriteの詳細は、Apache Serverのマニュアルにもあります。
以前のOracle Application Serverリリースでは、フィルタ処理されるサーブレットが別のサーブレットに転送される場合、または別のサーブレットをインクルードする場合、そのターゲット・サーブレットもデフォルトでフィルタ処理されました。Oracle Application Server 10g リリース2（10.1.2）では、この動作はデフォルトではなくなりました。ターゲット・サーブレットをデフォルトでフィルタ処理しないことにより、サーブレットの仕様の方向性に従います。
この動作は、OC4J 9.0.4実装では、oracle.j2ee.filter.on.dispatch環境フラグ（デフォルトはfalse）に従い、将来の実装では、サーブレット2.4仕様に規定されているようにweb.xml構成に従うように構成できます。
Oracle Application Server 10g リリース2（10.1.2）にアップグレードした後、新しくアップグレードした10g リリース2（10.1.2）インスタンスのOC4Jコンポーネントを使用して、J2EEアプリケーションを再デプロイします。
ただし、Oracle Business Components for Java（BC4J）の機能を使用するアプリケーションを再デプロイする前に、アプリケーションの.EARファイルを再パッケージ化する必要があります。特に、bc4jhtml.jarファイルの10g リリース2（10.1.2）バージョンを、アプリケーションの.EARファイルのWEB-INF/libディレクトリ内にパッケージ化する必要があります。
次の項では、OracleAS Web Cacheクラスタの一部である中間層をアップグレードする際に検討する手順について説明します。
OracleAS Web Cacheクラスタをアップグレードする場合は、キャッシュ・クラスタ・メンバーを一度に1つずつアップグレードします。キャッシュは引き続き機能しますが、アップグレードしたメンバーは他のクラスタ・メンバーの構成とリリースが異なるため、別のリリースで動作するキャッシュ・クラスタ・メンバーにリクエストを転送しません。
たとえば、Cache_Aを現行のリリースにアップグレードし、Cache_BおよびCache_Cをアップグレードしていない場合、Cache_Aはキャッシュ・クラスタ・メンバーCache_BおよびCache_Cにリクエストを転送しません。
この場合、Web Cache Managerの「操作」ページに「the Operation Needed is Incompatible software version」と表示されます。
各キャッシュ・クラスタ・メンバーを10g リリース2（10.1.2）にアップグレード後、クラスタのメンバーの構成を同期化するために次の手順を実行する必要があります。
opmnctl startproc ias-component=WebCache
このコマンドにより、OracleAS Web Cacheのキャッシュ・サーバー・プロセスおよび管理サーバー・プロセスが開始されます。
ias_adminユーザーまたはadministratorユーザーのユーザー名とパスワードを入力します。OracleAS Web Cacheインスタンスをアップグレードした後、OracleAS Web CacheのソースOracleホームのインストールおよび構成時に定義したAdministratorを使用してOracleAS Web Cache Managerにログインします。
「Operations」ページが表示されます。
Web Cacheが、キャッシュ固有の構成情報をリモート・キャッシュ・クラスタ・メンバーから取得します。その後、Web Cache Managerに「Operation Needed is Propagate Configuration」と表示されます。
リリース2（9.0.2）のキャッシュは、10g リリース2（10.1.2）のキャッシュからの無効化メッセージを受け取れません。リリース2（9.0.2）と10g リリース2（10.1.2）のクラスタ・メンバーの混成のOracleAS Web Cacheクラスタを使用する構成では、ロード・バランサによって無効化メッセージがリリース2（9.0.2.x）メンバーに対してのみ送信されるように構成する必要があります。
キャッシュ・クラスタのリリース2（9.0.2）から10g リリース2（10.1.2）へのアップグレードの際には、ロード・バランサの無効化プールからクラスタ・メンバーを1つずつ削除してアップグレードしていきます。すべてのクラスタ・メンバーをアップグレードしたら、それらを無効化プールに戻します。例として、リリース2（9.0.2.x）で実行される4つのメンバー（webche1-host、webche2-host、webche3-hostおよびwebche4-host）からなるキャッシュ・クラスタの前にロード・バランサがある構成の場合を示します。このキャッシュ・クラスタをアップグレードするには、次の手順を実行します。
webche1-hostを削除します。
webche1-hostをリリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードします。
webche2-hostを削除します。
webche2-hostをリリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードします。
webche3-hostを削除します。
webche3-hostをリリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードします。
webche4-hostをリリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードします。これはロード・バランサの構成で最後のキャッシュ・メンバーなので、無効化プールから削除する必要がありません。
webche1-host、webche2-hostおよびwebche3-hostを無効化するプールに戻します。
10g リリース2（10.1.2）のアップグレード先Oracleホームをインストールすると、OracleAS Web Cacheの「ようこそ」ページが、10g リリース2（10.1.2） Application Server ControlコンソールのURLにリンクするよう構成されます。ただし、中間層のアップグレード時には、OracleAS Upgrade Assistantによって、10g （9.0.4）のソースOracleホームをインストールしたときに割り当てた元のポート番号からアクセスできるようにApplication Server Controlが構成されます。
そのため、OracleAS Web Cache 10g （9.0.4）から10g リリース2（10.1.2）にアップグレードした後は、OracleAS Web Cache の「ようこそ」ページにあるOracle Enterprise Manager Application Server Controlコンソールへのリンクが機能しません。Application Server Controlコンソールにアクセスするには、10g （9.0.4） Application Server ControlのURLを使用します。
HTTPSリクエスト用にOracleAS Web Cacheを構成した場合は、HTTPSプロトコルをサポートするためにOracleAS Web Cacheが使用する必要のあるWalletを定義しました。
OracleAS Upgrade Assistantでは、OracleAS Web CacheのWalletがOracleホーム・ディレクトリに格納されていれば、アップグレード先OracleホームのそのWalletの場所が自動的にアップグレードされます。
ただし、Walletへのパスを指定したときに大/小文字の違いがあった場合は、OracleAS Upgrade Assistantによって、WalletがOracleホームの外部に格納されていると誤って認識される場合があります。その場合、アップグレード先Oracleホームでは、Walletへのパスは正常に更新されません。
そのため、OracleAS Web Cacheをアップグレードした後、WalletがソースOracleホームでなく、アップグレード先Oracleホームに格納されるようにOracleAS Web Cacheが構成されていることを確認します。
この項では、OracleAS Upgrade Assistantによる処理の終了後に、Portalのアップグレードの完了に必要な手動による手順の実行方法について説明します。この項では、次の項目について説明します。
中間層を介してアクセスするPortalインスタンスが使用しているOracle Internet Directoryが、中間層の登録先と異なる場合は、中間層のアップグレード後に追加の手順を実行する必要があります。これらの手順では、OracleAS Portalの依存性設定ファイルに格納されたOracle Internet Directoryの詳細情報が正しいことを確認します。アップグレードを実行しても、すべての値がアップグレード・ツールで使用できるわけではありません。これらの値は、デフォルト値に設定されるのみです。
Oracle Internet Directoryプロパティを確認するには、次の手順を実行します。
DESTINATION_ORACLE_HOME¥portal¥conf¥iasconfig.xml
特に、ファイル内の各PortalInstance要素に注意してください。例4-8に、標準的なiasconfig.xmlファイルの内容を示します。
PortalInstance要素について、次のことを行います。
iasconfig.xmlファイルを閉じます。
DESTINATION_ORACLE_HOME¥portal¥conf¥ptlconfig -encrypt
iasconfig.xmlおよびptlconfigツールの詳細は、『Oracle Application Server Portal構成ガイド』を参照してください。
<IASInstance Name="midtier.abc.company.com" Host="abc.company.com"> <WebCacheComponent AdminPort="4000" ListenPort="80" InvalidationPort="4001" InvalidationUsername="invalidator" InvalidationPassword="@BdS/zVGJHrElbOMohqLzurxsPR1au77peA==" SSLEnabled="false"/> <EMComponent ConsoleHTTPPort="1811" SSLEnabled="false"/> </IASInstance> <IASInstance Name="infra.xyz.company.com" Host="xyz.company.com"> <OIDComponent AdminPassword="welcome1" AdminDN="cn=orcladmin" SSLEnabled="false" LDAPPort="389"/> </IASInstance> <PortalInstance DADLocation="/pls/portal30" SchemaUsername="portal30" SchemaPassword="welcome1" connectString="dbserver.company.com:1521:orcl"> <WebCacheDependency ContainerType="IASInstance" Name="midtier.abc.company.com"/> <OIDDependency ContainerType="IASInstance" LDAPSSLPort="4339" Name="infra.xyz.company.com"/> <EMDependency ContainerType="IASInstance" Name="midtier.abc.company.com"/> </PortalInstance>
ソースOracleホームで追加された新しいデプロイ・プロパティ・ファイルは、アップグレード先Oracleホームにコピーされます。ただし、インストール時の元の値が変更されたプロパティ・ファイルはコピーされません。これらのファイルの変更内容は、アップグレード先Oracleホームに手動で適用する必要があります。
プロパティ・ファイルの場所は、Webプロバイダ間で異なり、Webプロバイダのサービス識別子を使用することによって検索できます。サービス識別子は、アプリケーション内のプロバイダを識別します。デプロイ・プロパティ・ファイルの命名規則は、次のとおりです。
SOURCE_ORACLE_HOME¥j2ee¥OC4J_Portal¥applications¥application_name¥ web_application_name¥WEB-INF¥deployment¥service_identifier.properties
たとえば、識別子がsampleであるJPDKサンプルWebプロバイダのデプロイ・プロパティは、次のファイルにあります。
SOURCE_ORACLE_HOME¥j2ee¥OC4J_Portal¥applications¥jpdk¥jpdk¥WEB-INF¥ deployment¥sample.properties
変更されたデプロイ・プロパティをソースOracleホームからアップグレード先Oracleホームに移行するには、次の手順を実行します。
Oracle9i AS Discovererリリース2リリースに（9.0.2.52）以前からアップグレードする場合は、10g リリース2（10.1.2）でOracle Business Intelligence Discoverer 10g （9.0.4）を使用するために、End User Layerスキーマをアップグレードする必要があります。
手順については、8.5.1項「Oracle Business Intelligence Discoverer End User Layerスキーマのアップグレード」を参照してください。
次の項では、OracleAS Reports Servicesのアップグレード後に実行するタスクについて説明します。
OracleAS Upgrade Assistantは、Oracle Application Server Reports Servicesのアップグレードの大部分を実行します。ただし、次のファイルは処理しません。
.batスクリプト・ファイル
SOURCE_ORACLE_HOME¥reports¥samples¥scripts¥rw*.bat SOURCE_ORACLE_HOME¥reports¥samples¥scripts¥reports.bat
SOURCE_ORACLE_HOME¥reports¥conf¥rwserver.template
jdbcpds.conf構成ファイル
SOURCE_ORACLE_HOME¥reports¥conf¥jdbcpds.conf
これらのファイルのいずれかをカスタマイズした場合は、アップグレード先Oracleホームの対応するファイルにカスタマイズを適用する必要があります。
また、ソースOracleホームのキャッシュ・ファイルおよびキャッシュ・ディレクトリを保持するには、レポート・サーバーのキャッシュ・ディレクトリをソースOracleホームからアップグレード先Oracleホームにコピーします。
中間層でOracleAS Reports Servicesをアップグレードした後、targets.xml構成ファイルを次のように変更して、アップグレードしたOracleAS Reports ServicesサーバーをApplication Server Controlコンソールから管理します。これらの変更は、EM統合をアップグレード済のOracleAS Reports Servicesプロセス内サーバーと連携させるために必要です。
DESTINATION_ORACLE_HOME¥sysman¥emd¥targets.xml
targets.xmlファイルで、次のエントリを検索します。
TYPE="oracle_repserv" and DISPLAY_NAME="Reports Server: new_server_name
new_server_nameは、次の形式になることに注意してください。
rep_hostname_newOracleHome
この例では、hostnameはドメイン名なしのホスト・コンピュータ名、newOracleHomeはアップグレード先Oracleホームです。
oracle_repservエントリでは、出現するすべてのnew_server_nameを、中間層のアップグレードの実行前にソースOracleホームで使用されていた元のサーバー名に置換します。例4-9では、targets.xmlファイルのoracle_repservエントリに出現する通常の新しいサーバー名を太字で示します。
元のサーバー名は、次のOracleAS Reports Services構成ファイルにあります。
DESTINATION_ORACLE_HOME¥reports¥conf¥rwservlet.properties
<Target TYPE="oracle_repserv" NAME="appserv1.acme.com_Reports_Server: new_server_name" DISPLAY_NAME="Reports Server: new_server_name" VERSION="1.0" ON_HOST="appserv1.acme.com"> <Property NAME="IASInternalName" VALUE="new_server_name"/> <Property NAME="Password" VALUE="77c1ed41793a5ce6" ENCRYPTED="TRUE"/> <Property NAME="Server" VALUE="new_server_name"/> <Property NAME="Servlet" VALUE="http://appserv1.acme.com:port/reports/rwservlet"/> ... ... </Target>
OracleAS Reports Servicesのスタンドアロン・サーバーは、OracleAS Upgrade Assistantではアップグレードできません。そのため、スタンドアロンのOracleAS Reports Servicesサーバーを使用している場合は、それらのサーバーを手動でOracle Process Manager and Notification Server（OPMN）およびOracle Enterprise Manager 10g Application Server Controlに登録する必要があります。
スタンドアロン・サーバーをOPMNおよびApplication Server Controlに登録すると、opmn.xmlおよびtargets.xml構成ファイルが更新されます。Oracle Application Serverでは、自動的に更新を実行するスクリプトが提供されます。
OracleAS Reports Servicesのスタンドアロン・サーバーを登録するには、登録するスタンドアロン・サーバーに1回ずつ次のコマンドを実行します。
DESTINATION_ORACLE_HOME¥bin¥addNewServerTarget.bat standalone-server-name
この例では、standalone-server-nameを、OPMNおよびOracle Enterprise Managerに登録するOracleAS Reports Servicesのスタンドアロン・サーバーの名前に置き換えます。
OracleAS Upgrade Assistantは、リリース2（9.0.2）または10g （9.0.4）のBusiness Intelligence & Forms構成をOracle Application Server 10g リリース2（10.1.2）のBusiness Intelligence & Forms構成にアップグレードします。OracleAS Upgrade Assistantは、デプロイされたレポートを含む可能性のある、この構成の外部にあるOC4Jインスタンス、またデプロイされたレポートを実行可能にするためにそれらのインスタンスに対して行われたカスタマイズを認識しません。
したがって、標準のBusiness Intelligence and Forms OC4Jインスタンス以外のOC4Jインスタンスを使用する場合は、それらのインスタンスに対して実行した手動のデプロイ手順を、Oracle Application Server 10g リリース2（10.1.2）の該当するインスタンスに適用する必要があります。
この項は、リリース2（9.0.2）または10g （9.0.4）のBusiness Intelligence & Formsインストール・タイプから10g リリース2（10.1.2.0.2）のForms and Reports Servicesインストール・タイプにアップグレードする場合にのみ該当します。
10g リリース2（10.1.2.0.2）のForms and Reports Servicesインストール・タイプにアップグレードした後、次の手順を実行して、すべてのレポート・サーバー（プロセス内サーバーおよびスタンドアロン・サーバー）を非セキュアにするとともに正常に機能できるようにします。
server_name.confファイルを次のように変更します。
server_name.conf構成ファイルを検索して開きます。
DESTINATION_ORACLE_HOME¥reports¥conf¥server_name.conf
<security id="rwSec" class="oracle.reports.server.RWSecurity"> <!--property name="securityUserid" value="portal_db_username/portal_db_ password@%portal_db_tnsname" confidential="yes" encrypted="no"/--> <property name="oidEntity" value="reports_oid_entity"/> </security>
セキュリティ要素内の既存のコメント文字（<!--および-->）を必ず削除してください。
<!--security id="rwSec" class="oracle.reports.server.RWSecurity"> <property name="securityUserid" value="portal_db_username/portal_db_ password@%portal_db_tnsname" confidential="yes" encrypted="no"/> <property name="oidEntity" value="reports_oid_entity"/> </security-->
server_name.conf構成ファイルを保存して閉じます。
rwservlet.propertiesファイルを変更します。
rwservlet.properties構成ファイルを開きます。
DESTINATION_ORACLE_HOME¥reports¥conf¥rwservlet.properties
rwservlet.propertiesファイルでOID_ENTITYエントリを検索します。次に例を示します。
OID_ENTITY=reportsApp.acme.com_FD502C79FB3F660CE0340003BA182918
OID_ENTITYエントリを次のようにコメント化します。
#OID_ENTITY=reportsApp.acme.com_FD502C79FB3F660CE0340003BA182918
rwservlet.propertiesファイルを保存して閉じます。
次の項では、Oracle Application Server Wireless中間層のリリース2（9.0.2）または10g （9.0.4）から10g リリース2（10.1.2）へのアップグレードについて説明します。
10g リリース2（10.1.2）で追加されたOracleAS Wirelessの新機能を使用するには、OracleAS Metadata Repositoryを10g リリース2（10.1.2）にアップグレードする必要があります。詳細は、第7章「OracleAS Metadata Repositoryのアップグレード」を参照してください。
注意:
この項では、Oracle Application Server Wireless System ManagerのOracle Application Server Wireless リリース2（9.0.2）通知エンジンによって作成された通知をアップグレードする方法について説明します。通知エンジンのアーキテクチャおよび機能はここでは説明しません。
10g （9.0.4）からのアップグレードの場合、この手順は不要です。
通知をリリース2（9.0.2）から10g リリース2（10.1.2）にアップグレードするには、migrateNotifications.batスクリプトを使用します。スクリプトを実行するには、次の手順を実行します。
¥wireless¥binに移動します。
migrateNotifications.bat -name deprecated master alert name(s) -owner owner user name
migrateNotifications.bat -oid deprecated master alert oid -owner owner user nameスクリプトによって次の処理が行われます。
old master alert name_Newという名前の新規マスター・アラート・サービスの作成（この処理には、必要に応じてメッセージ・テンプレートの有効なモバイルXMLへの変換も含まれます。）
¥master¥notificationsの作成（存在しない場合）
old master alert name_MSの作成
¥Users Home¥username¥notificationsの作成（存在しない場合）
AlertServiceオブジェクトの検出、およびそれらのリンク・オブジェクトへの変換（この処理で、トップレベル認証がフラット化されてレベル認証にリンクされる）
次のコマンドは、名前がStockAlertで始まるすべての9.0.2.xマスター・アラート・サービス（StockAlertNews、StockAlertWarningなど）をアップグレードします。すべての新規オブジェクトは、orcladminユーザーによって所有されます。
migrateNotifications.bat -name StockAlert% -owner orcladmin
次のコマンドは、StockAlertという名前の9.0.2.xマスター・アラート・サービスをアップグレードし、すべての新規オブジェクトをsystemadminユーザーに割り当てます。
migrateNotifications.bat -name StockAlert -owner systemadmin
次のコマンドは、オブジェクトIDが1973である9.0.2.xマスター・アラート・サービスをアップグレードし、すべての新規オブジェクトをsystemadminユーザーに割り当てます。
migrateNotifications.bat -oid 1973 -owner systemadmin
同じInfrastructureサービスを使用するOracle9i AS Wirelessリリース2（9.0.2）中間層およびOracle Application Server Wireless 10g リリース2（10.1.2）中間層による環境を運用できます。ただし、この構成には次に示す制限があります。
OC4J_Wireless OC4Jインスタンスが再起動されるまで、これらの変更はリリース2（9.0.2）のEnterprise Manager Web Siteに反映されません。特に、あるリリースのインスタンスでドライバ・アカウント（電子メール・ドライバの電子メール・アカウントなど）を削除して、異なるリリースのインスタンスに追加した場合（たとえばリリース2（9.0.2）から10g リリース2（10.1.2））、メッセージが失われる可能性があります。この問題は、OC4J_Wireless OC4Jインスタンスを再起動すると解決します。
このタスクを行うのに便利なアップグレード・スクリプトがあります。詳細は、『Oracle Application Server Wireless開発者ガイド』を参照してください。Oracle9i AS Wirelessリリース2（9.0.2）のアラートAPIは推奨されていないので、かわりにOracle Application Server Wireless 10g リリース2（10.1.2）のAPIを使用できるようにアプリケーションをアップグレードする必要があります。
複合モード環境では、Oracle9i AS Wireless リリース2（9.0.2）およびOracle Application Server Wireless 10g リリース2（10.1.2）に、受信メッセージを受け取るためのトランスポート・ドライバが構成されている場合があります。Oracle9i AS Wirelessリリース2（9.0.2）およびOracle Application Server Wireless 10g リリース2（10.1.2）の2つのエントリ・ポイントを、デバイスに対して同時に使用可能にしないようにする必要があります。ユーザーがリリース2（9.0.2）インスタンスにリクエストを発行した場合、その後3時間はOracle Application Server Wireless 10g リリース2（10.1.2）インスタンスのトランスポート・ドライバに定義されているエントリ・ポイントに別のリクエストを送信できません。このユーザーは、たとえばこれに違反した場合、後のエントリ・ポイント宛てのリクエストに対するレスポンスを受信できません。
リリース2（9.0.2）と10g リリース2（10.1.2）ではドライバ構成が異なるので、Oracle9i AS Wireless リリース2（9.0.2）インスタンスをOracle Application Server Wireless 10g リリース2（10.1.2）にアップグレードした場合、リクエストが正常に処理されるようにトランスポート・ドライバを管理する必要があります。
10g リリース2（10.1.2）では、サイトレベル・ドライバを使用可能または使用不可にできます。デフォルトでは使用可能です。使用不可になっているドライバはルーティング・アルゴリズムによって認識されないため、メッセージ・システムで使用されません。リリース2（9.0.2）では、すべてのサイトレベル・ドライバがルーティング・アルゴリズムによって認識されます。
リリース2（9.0.2）インスタンスに2つの中間層がある場合、一方の中間層およびInfrastructureを10g リリース2（10.1.2）にアップグレードすると、そのアップグレードされた中間層ではサイトレベル・ドライバを使用可能または使用不可にできます。ただし、アップグレードされていない中間層は、すべてのドライバが使用可能であると認識します。そのためこのような環境では、ドライバを使用不可にするのではなく削除することをお薦めします。
リリース2（9.0.2）のトランスポート・メカニズムでは、メッセージをルーティングできるのは1つのドライバに対してのみであり、そのドライバに構成されているインスタンスがあるかどうかには関係ありません。つまり、インスタンスが構成されていないドライバにメッセージがルーティングされた場合、メッセージはどこにも配信されません。そのため、リリース2（9.0.2）および10g リリース2（10.1.2）の複合環境も含め、すべてのリリース2（9.0.2）環境では、インスタンスが構成されていないすべてのドライバを削除することをお薦めします。
Oracle Application Server Wireless 10g リリース2（10.1.2）インストール後に、このリリースではなくOracleAS Wireless リリース2（9.0.2）を使用する場合は、リリース2（9.0.2）のWIRELESSスキーマをリストアできます。
これを行うには、wirelessrm.sqlスクリプトを実行します。Oracleホームは、9.0.4中間層のOracleホームを参照します。
cd %ORACLE_HOME%¥wireless¥repository¥sql sqlplus system/password@service_name @wirelessrm.sql
imp system/password@service_name file=iasw902.dmp fromuser=wireless touser=wireless
10g リリース2（10.1.2）へのアップグレードを行っても、Oracle Sensor EdgeServerプロセスは自動的に作成されません。そのため、OracleAS Upgrade Assistantを実行しOracleAS Metadata Repositoryを10g リリース2（10.1.2）にアップグレードした後、これらのプロセスを手動で作成する必要があります。
ただし、OracleAS Metadata Repositoryを10g リリース2（10.1.2）にアップグレードするまで、Oracle Sensor EdgeServerプロセスを作成できないことに注意してください。
OracleAS Wireless中間層を10g リリース2（10.1.2）にアップグレードした後、10g リリース2（10.1.2）中間層からOracle Application Server Wirelessで提供されるCommerce、Location、PIM、Examplesなどのアプリケーションにアクセスすると、エラーが発生します。これらのエラーが発生しないようにするには、OracleAS Metadata Repositoryを10g リリース2（10.1.2）にアップグレードします。
OracleAS Upgrade Assistantは、OracleAS Forms Services構成データの大部分をソースOracleホームからアップグレード先Oracleホームに移動します。ただし、アップグレード後に手動タスクが残っている場合があります。この項では、それらのタスクの実行方法について説明します。
詳細は、次の項を参照してください。
Oracle Application Server 10g リリース2（10.1.2.0.2）では、OracleAS Forms Servicesの多くのファイル、ディレクトリ、URLおよび環境変数の名前が変更されています。OracleAS Upgrade Assistantは、OracleAS Forms Servicesの構成を新しい名前に自動的に変換します。
|
関連項目:
OracleAS Forms Servicesにおける名前の変更の完全なリストは、A.1.13.6項「10g リリース2（10.1.2.0.2）でのOracleAS Forms Servicesのファイル名、ディレクトリ名、URLおよび変数名の変更」を参照してください。 |
OracleAS Forms Servicesの実行可能ファイル（.fmxファイル）がソースOracleホーム内に存在する場合は、それらのファイルをアップグレード先Oracleホームの相対パスに手動でコピーします。ただし、それらのファイルがソースOracleホームにない（たとえば、FORMS_PATH環境変数によって参照される別のディレクトリにある）場合は、この手動による手順は必要ありません。
ソースOracleホームでは、OracleAS Forms Services EARファイル（forms90app.ear）がデフォルトでOC4J_BI_Forms OC4Jインスタンスにforms90appとしてデプロイされています。このEARファイルをOC4J_BI_Forms OC4Jインスタンスのカスタマイズ済構成に再デプロイした場合は、OracleAS Upgrade Assistantによってこのデプロイがアップグレード先Oracleホームに自動的にアップグレードされます。
ただし、このEARファイルを他のデフォルトOC4Jインスタンス（home、OC4J_Portal、OC4J_Wireless）またはユーザー定義OC4Jインスタンスにデプロイした場合、この構成はアップグレードされません。その場合は、OracleAS Forms ServicesのEARファイルをアップグレード先Oracleホームの対応するOC4Jインスタンスに再デプロイします。
OracleAS Forms Services 10g リリース2（10.1.2.0.2）のformsapp.earファイルは次のディレクトリにあります。
DESTINATION_ORACLE_HOME¥forms¥j2ee
OracleAS Upgrade Assistantの処理が終了し、アップグレード後のすべての手動タスクを完了すると、アップグレードされた中間層インスタンスを起動できます。
次の項で、詳細を説明します。
中間層インスタンスがInfrastructureを使用する場合、Infrastructureが実行されていることを確認します。
中間層インスタンスを起動するには、次の手順を実行します。
Portalインスタンスは、URLによってWebプロバイダにアクセスします。このURLを指定する処理は、プロバイダ登録といいます。アップグレード先OracleホームにソースOracleホームと異なるホスト名またはポート番号（あるいはその両方）を使用してアクセスする場合、またはWebプロバイダが異なるURLパスにデプロイされている場合、アップグレードされたWebプロバイダにアクセスするために使用されるURLを更新する必要があります。Webプロバイダは複数のPortalインスタンスによって参照可能であるため、それらのすべてのURLを更新する必要があります。
WebプロバイダのURLを更新するには、次の手順を実行します。
「Portalナビゲータ」ページが表示されます。
登録されたプロバイダのソートされたリストが表示されます。
「プロバイダの編集」ページが表示されます。
この項はリリース2（9.0.2）インスタンスに対してのみ適用されます。OracleAS Portalが含まれている10g （9.0.4）中間層をアップグレードする場合には、適用されません。
イベント/パラメータ受渡しのサンプル・プロバイダの定義は、リリース2（9.0.2）以上で変更されています。したがって、リリース2（9.0.2）中間層をアップグレードする場合は、OracleAS Portal Repositoryでプロバイダを更新する必要があります。
プロバイダを参照するリリース2（9.0.2）のOracleAS Portalインスタンスごとに、次の手順を繰り返します。
WebプロバイダのURLを更新するには、次の手順を実行します。
「Portalナビゲータ」ページが表示されます。
登録されたプロバイダのソートされたリストが表示されます。
次の項では、中間層のアップグレード後にアップグレードが正常に行われたことを検証するために実行するタスクについて説明します。
次の手順に従って、アップグレードされた中間層コンポーネントが起動することを確認します。
次に例を示します。
http://midtierhostname:port
正しいポート番号が入力されていることを確認します。中間層のアップグレード後にApplication Server Controlコンソール・ポートを判断する方法は、4.6.1項「アップグレード後のポート値とportlist.iniファイル」を参照してください。
Enterprise Managerによって、Application Server Controlコンソールへログインするように要求されます。
ias_adminログイン資格証明を入力します。Oracle Application Serverインスタンスをアップグレードした後、アップグレード先Oracleホームのインストール時に定義したパスワードを使用して、アップグレード先10g リリース2（10.1.2）インスタンスのApplication Server Controlコンソールにログインします。
Enterprise Managerによって、ブラウザ・ウィンドウに「ファーム」ページが表示されます。このページの「スタンドアロン・インスタンス」セクションに中間層インスタンスのリンクが表示されます。
「システム・コンポーネント」ページが表示されます。
次の手順に従って、Oracle HTTP ServerおよびアプリケーションのURLにアクセスできることを確認します。
http://midtierhost.mycompany.com:7777
前述のとおり、中間層をアップグレードしても、ソースOracleホームは変更されません。つまり、ソースOracleホームは引き続き稼働しています。ただし、10g リリース2（10.1.2）にアップグレードした後にソース中間層に戻すことを決定した場合は、OracleAS Portalの使用方法に関して次の情報を参照してください。
ソース中間層を使用するように戻す場合、Oracleホームを再度使用するには、「Portalビルダー」ページで「サービス」ポートレットの「Portalサービスのモニタリング」リンクをリセットする必要があります。
Oracle Application Serverには、「Portalサービスのモニタリング」リンクのリセット処理を自動化するmonseed.sqlスクリプトが用意されています。
このスクリプトを使用するには、次の手順を実行します。
%ORACLE_HOME%¥portal¥admin¥plsql¥wwc
monseed.sqlスクリプトを実行します。
@monseed.sql EM_host EM_port Portal_DAD middle_tier_host middle_tier_port instance_ name
次に例を示します。
@monseed.sql midtierhost.acme.com 1810 portal midtierhost.acme.com 7777 ias902mid.midtierhost.acme.com
monseed.sqlスクリプトに指定する必要がある引数については、表4-7を参照してください。
monseed.sqlスクリプトを実行します。
@monseed.sql EM_protocol EM_host EM_port Portal_DAD instance_name
次に例を示します。
@monseed.sql http midtierhost.acme.com 1810 portal as904.midtierhost.acme.com
monseed.sqlスクリプトに指定する必要がある引数については、表4-7を参照してください。
10g リリース2（10.1.2.0.2）にアップグレードし、ソースOracleホームに戻した後、再度10g リリース2（10.1.2.0.2）のOracleホームに戻す場合は、「Portalサービスのモニタリング」リンクに関して次の情報を考慮してください。
リリース2（9.0.2）、10g （9.0.4）および10g リリース2（10.1.2.0.0）を含むOracle Application Serverの旧リリースでは、「Portalサービスのモニタリング」リンクをクリックすると、Application Server Control Consoleに「Portalサービスのモニタリング」ページが表示されます。
10g リリース2（10.1.2.0.2）以上では、このリンクの動作が変更されています。Application Server Controlコンソールには、「ファーム」ページが表示されます。この場合、モニタリングするPortalを実行しているApplication Serverを選択し、システム・コンポーネント表のPortalターゲットを選択することで、「Portalサービスのモニタリング」ページにアクセスできます。
そのため、10g リリース2（10.1.2.0.2）にアップグレードし、ソースOracleホームに戻した後、再度10g リリース2（10.1.2.0.2）のOracleホームに戻す場合は、4.8.3.1項「ソースOracleホームにおける「Portalサービスのモニタリング」リンクのリセット」とは若干異なる引数セットを指定してmonseed.sqlスクリプトを実行する必要があります。
そうでないと、「Portalサービスのモニタリング」リンクが正しく機能しません。
10g リリース2（10.1.2.0.2）のOracleホームに戻すには、4.8.3.1項で説明した手順1〜3を実行した後、次のコマンドを入力して、10g リリース2（10.1.2.0.2）の「Portalサービスのモニタリング」リンクをリセットします。
monseed.sql EM_protocol EM_host EM_port
この例の内容は、次のとおりです。
アップグレード処理では、ソースOracleホームは変更されずに残されます。現在のインストール・タイプおよび将来の必要性に応じて、ソースOracleホームの削除するか、なんらかの理由で保持することを選択できます。
|
注意: 特定のコンポーネントにはアップグレード後も同じポート値が設定されるので、保持した場合のソースOracleホームはアップグレード先Oracleホームと同時に運用できません。4.6.1項「アップグレード後のポート値とportlist.iniファイル」を参照してください。 |
次の項で、アップグレードされたソースOracleホームの廃棄の詳細を説明します。
アップグレード先Oracleホームによって参照または使用されるソースOracleホームのアプリケーション・ファイルまたはログ・ファイルがある場合、ソースOracleホームを廃棄する前にそれらを別の場所に移し、アップグレード先Oracleホームにおいてファイルへの参照設定を新しい場所に変更する必要があります。
リリース2（9.0.2）または10g （9.0.4） Portal Repositoryの運用を続ける場合、後で他の言語をリリース2（9.0.2）または10g （9.0.4） Portal Repositoryにロードする可能性があるときは、ソースOracleホームを廃棄しないでください。Oracle Application Server 10g リリース2（10.1.2）の言語をロードするためのユーティリティは、リリース2（9.0.2）または10g （9.0.4）のOracleAS Portalと互換性がありません。
アップグレードした中間層インスタンスがOracleAS Farmのメンバーである場合は、ソースOracleホームを削除する前に、必ずソース・インスタンスをファームから削除してください。
OracleAS Infrastructureを使用していたインスタンスをアップグレードすると、ソース・インスタンスがApplication Server Controlコンソールの「ファーム」ページにあるインスタンス・リストに残ります。
ソース・インスタンスをファームおよび「ファーム」ページから削除するには、ソースOracleホームで次のコマンドを使用します。
SOURCE_ORACLE_HOME¥dcm¥bin¥dcmctl leavefarm
アップグレードが成功して必要なバックアップをすべて行い、ソースOracleホームに戻す予定がないことを確認したら、ソースOracleホームからファイルを削除できます。インスタンスの削除にはOracle Universal Installerを使用します。
ただし、インスタンスの削除を開始する前に、次の項を確認する必要があります。
同一コンピュータ上にリリース2（9.0.2）またはリリース2（9.0.3）インスタンスおよび10g リリース2（10.1.2）インスタンスがある場合のリリース2（9.0.2）インスタンスまたはリリース2（9.0.3）インスタンスを削除するには、次の手順を実行します。
パッチの適用が必要な理由については、4.9.4.2項「問題: 10g リリース2（10.1.2）インスタンスにアクティブなOracle Enterprise Managerが含まれていてはいけない」を参照してください。
たとえば、リリース2（9.0.2）およびリリース2（9.0.3）インスタンスの場合は、「スタート」メニューからインストーラを起動します（「スタート」→「プログラム」→「Oracle Installation Products」→「Universal Installer」）。
同一コンピュータ上にリリース2（9.0.2）またはリリース2（9.0.3）（あるいはその両方）のインスタンスが複数含まれている場合、これらのインスタンスは1つのOracle Enterprise Managerを共有します。これが、「アクティブなOracle Enterprise Manager」です。インストーラを使用して、アクティブなOracle Enterprise Managerが含まれるインスタンスを削除する場合、インストーラによってアクティブなOracle Enterprise Managerを残りのインスタンスのいずれかに切り替える必要があります。残りのインスタンスが1つのみの場合、そのインスタンスは自動的にアクティブなOracle Enterprise Managerになります。複数のインスタンスが残っている場合は、インストーラによって、アクティブなOracle Enterprise Managerを含めるインスタンスを選択するように要求されます。
リリース2（9.0.2）またはリリース2（9.0.3）インスタンスとは異なり、同一コンピュータ上のOracle Application Server 10g リリース2（10.1.2）では、Oracle Enterprise Managerを共有しません。10g リリース2（10.1.2）の各インスタンスには専用のOracle Enterprise Managerが与えられます。
10g リリース2（10.1.2）インスタンスでは、Oracle Enterprise Managerを共有しないため、アクティブなOracle Enterprise Managerを含めるインスタンスとして10g リリース2（10.1.2）を選択する必要はありません。アクティブなOracle Enterprise Managerを含めるインスタンスとして、リリース2（9.0.2）またはリリース2（9.0.3）インスタンスを選択する必要があります。
10g リリース2（10.1.2）インスタンスを選択するか、またはインストーラがアクティブなOracle Enterprise Managerを残りのインスタンスに自動的に切り替え、それが10g リリース2（10.1.2）インスタンスの場合、10g リリース2（10.1.2）のOracleホームのファイルはリリース2（9.0.2）またはリリース2（9.0.3）ホームからのファイルに置き換えられます。これにより、Oracle Enterprise Managerの動作が停止します。
残りのインスタンスが10g リリース2（10.1.2）インスタンスのみの場合、4.9.4.1項「10g リリース2（10.1.2）インスタンスも含まれているコンピュータからのリリース2（9.0.2）またはリリース2（9.0.3）インスタンスの削除」で説明したパッチによって、アクティブなOracle Enterprise Managerが10g リリース2（10.1.2）インスタンスに自動的に切り替えられることを回避できます。また、アクティブなOracle Enterprise Managerを含めるインスタンスの選択リストに、10g リリース2（10.1.2）インスタンスが表示されることを回避できます。
10g リリース2（10.1.2）インスタンスがアクティブなOracle Enterprise Managerになると、Oracle Enterprise Managerの動作は停止します。
これを修正するには、10g リリース2（10.1.2）のOracleホームで次の手順を実行します。
DESTINATION_ORACLE_HOME¥bin¥emctl stop iasconsole
activeを付けて、これらのファイル名を変更してもかまいません（iasadmin.properties.activeなど）。
DESTINATION_ORACLE_HOME¥sysman¥config¥iasadmin.properties DESTINATION_ORACLE_HOME¥sysman¥emd¥targets.xml DESTINATION_ORACLE_HOME¥sysman¥j2ee¥config¥jazn-data.xml DESTINATION_ORACLE_HOME¥sysman¥webapps¥emd¥WEB-INF¥config¥consoleConfig.xml
バックアップ・ファイルは、前述の手順に示されているファイルと同じディレクトリにあります。バックアップ・ファイルの名前には、数字が接尾辞として付いています（iasadmin.properties.1など）。バックアップ・ファイルが最新のものであるかを判別するために、バックアップ・ファイルのタイムスタンプまたは内容をチェックします。
DESTINATION_ORACLE_HOME¥bin¥emctl start iasconsole
active接尾辞を付けて名前を変更したファイル）をリリース2（9.0.2）インスタンスまたはリリース2（9.0.3）インスタンスのOracleホームにコピーします。これらのファイルの名前を、元の名前（active接尾辞を削除）に戻します。
HKEY_LOCAL_MACHINE / SOFTWARE / ORACLE / EM_LOC
キーを更新するには、次の手順を実行します。
i. 「スタート」→「ファイル名を指定して実行」を選択します。regeditと入力して、「レジストリ エディタ」を起動します。
ii.左側のフレームで、HKEY_LOCAL_MACHINE / SOFTWAREを展開します。
iii.左側のフレームで、ORACLEを選択します。
iv.右側のフレームで、EM_LOCをダブルクリックします。新しいアクティブなOracle Enterprise Managerを指すようにパスを更新して「OK」をクリックします。
アップグレードが成功して必要なバックアップをすべて行い、ソースOracleホームに戻す予定がないことを確認したら、ソースOracleホームからファイルを削除できます。インスタンスの削除にはOracle Universal Installerを使用します。
次の特別な考慮事項は、Oracle Application Server Clusterの一部である中間層をアップグレードする場合、またはOracleAS Wireless リリース2（9.0.2）かOracle Workflow中間層のいずれかをアップグレードする場合に適用されます。
Oracle Application Server Clusterを使用している場合は、クラスタを構成する中間層をアップグレードする前に、次の項を確認してください。
次の項は、実際にOracle Application Server Clusterを使用し、Oracle Application Server Clusterの作成および管理方法を理解していることを前提としています。
OracleAS Clusterの概念については、4.10.1.1項「Oracle Application Server Clusterのコンポーネントの理解」の他に、『Distributed Configuration Management管理者ガイド』も参照してください。
注意:
Oracle Application Server Clusterを使用している場合は、複数のOracle Application Server中間層インスタンスがインストールされ、複数のインスタンスが同じファームおよび同じOracleAS Clusterに属しています。
ファームとは、同じDistributed Configuration Management（DCM）リポジトリを共有するインスタンスの集合です。DCMリポジトリは、次のいずれかです。
データベース・ベースのリポジトリは、Oracle Application Server Infrastructureインストールの一部としてインストールされたOracleAS Metadata Repositoryか、またはOracle Application Server Metadata Repository Creation Assistant（OracleAS Metadata Repository Creation Assistant）を使用して作成されたOracleAS Metadata Repositoryのいずれかです。
いずれの場合も、データベース・リポジトリには、DCMスキーマおよびその他の多数のOracle Application Serverコンポーネントで使用されるスキーマが含まれています。
ファイル・ベースのリポジトリには、DCMスキーマのみが含まれ、様々なOracle Application Serverコンポーネントに必要な他のコンポーネント・スキーマは含まれていません。そのため、複数のJ2EE and Web CacheインストールでOracleAS Farmとしてのみ使用できます。
ファイル・ベースのDCMリポジトリにクラスタを作成する場合、データベースは存在しませんが、クラスタ内のいずれかのインスタンスがリポジトリ・ホストになります。ファイル・ベースのリポジトリが存在するのは、リポジトリ・ホストです。
データベース・ベースのリポジトリ内のOracle Application Server Clusterをアップグレードするには、次の手順を実行します。
クラスタのメンバーの確認には、DCMコマンドラインまたはApplication Server Controlコンソールを使用できます。
DCMコマンドラインを使用するには、次の手順を実行します。
SOURCE_ORACLE_HOME¥dcm¥bin¥dcmctl listclusters
SOURCE_ORACLE_HOME¥dcm¥bin¥dcmctl listinstances -cl cluster_name
Application Server Controlコンソールを使用するには、「クラスタ」ページに移動して、クラスタ内のインスタンスのリストを参照します。
SOURCE_ORACLE_HOME¥dcm¥dcmctl leavecluster SOURCE_ORACLE_HOME¥dcm¥dcmctl leavefarm
Application Server Controlコンソールを使用すると、各インスタンスをファームに追加できます。
DCMコマンドライン（dcmctl）を使用するか、またはApplication Server Controlコンソールの「ファーム」ページを使用すると、クラスタを再作成し、各インスタンスをクラスタに追加できます。
ファイル・ベースのリポジトリ内のOracleAS Clusterをアップグレードするには、次の手順を実行します。
リポジトリ・ホストとは、ファイル・ベースのリポジトリの作成時にログインしたコンピュータです。ファイル・ベースのリポジトリは、このホストに存在します。
クラスタのメンバーの確認には、DCMコマンドラインまたはApplication Server Controlコンソールを使用できます。
DCMコマンドラインを使用するには、次の手順を実行します。
SOURCE_ORACLE_HOME¥dcm¥bin¥dcmctl listclusters
SOURCE_ORACLE_HOME¥dcm¥bin¥dcmctl listinstances -cl cluster_name
Application Server Controlコンソールを使用には、「クラスタ」のホームページに移動して、クラスタ内のインスタンスのリストを参照します。
インストール時に、10g リリース2（10.1.2）インスタンスの新しいファイル・ベースのリポジトリを作成します。この項の後述の手順が完了するまで、元のソースOracleホームを10g リリース2（10.1.2）にアップグレードする際、OracleAS Upgrade Assistantは使用しないでください。
インストール時に、リポジトリ・ホスト上に10g リリース2（10.1.2）をインストールしたときに作成した10g リリース2（10.1.2）ファームを追加します。
DCMコマンドライン（dcmctl）を使用するか、またはApplication Server Controlコンソールの「ファーム」ページを使用すると、クラスタを再作成し、各インスタンスをクラスタに追加できます。
リクエストのルーティング構成を保持するためのクラスタをアップグレードした後、次の追加タスクを実行します。
Oc4jMountディレクティブのインスタンス名およびクラスタ名をメモします。
DESTINATION_ORACLE_HOME¥Apache¥Apache¥conf¥mod_oc4j.conf
Oc4jMountディレクティブをmod_oc4.confファイルにコピーします。
Oc4jMountディレクティブのURLパターンに一致するリクエストが正しいインスタンスにルーティングされることを確認します。
Oracle Application Server Wirelessを実行している1つ以上のリリース2（9.0.2）中間層をアップグレードする場合は、OracleAS Upgrade Assistantを実行する前に次の手順を実行する必要があります。
次の手順で、Oracle Application Server Wireless 10g リリース2（10.1.2）中間層をインストールすると、Wireless Configuration Assistantによってリリース2（9.0.2）のOracleAS Metadata RepositoryのWIRELESSスキーマが10g （9.0.4）にアップグレードされるため、この手順を実行することをお薦めします。
後述の手順で、OracleAS Metadata Repositoryを10g リリース2（10.1.2）にアップグレードすると、Metadata Repository Upgrade Assistant（MRUA）によって10g （9.0.4）のWIRELESSスキーマは10g リリース2（10.1.2）にアップグレードされます。
WIRELESSスキーマは、エクスポート・データベース・ユーティリティを使用してバックアップできます。
exp system/password@service_name file=iasw902.dmp owner=WIRELESS
この例では、次の値を指定する必要があります。
asdbなど）。
このコマンドによって、WIRELESSスキーマの内容が格納されたデータベース・エクスポート・ファイルiasw902.dmpが作成されます。
中間層のアップグレード処理には、10g リリース2（10.1.2）中間層をインストールする手順も含まれます。リリース2（9.0.2） Infrastructureに対して10g リリース2（10.1.2）のPortal and Wirelessインストールをインストールすると、Wireless Configuration AssistantによってWIRELESSスキーマが9.0.4にアップグレードされます。
同じOracleAS Metadata Repositoryに対して追加のOracle Application Server Wireless 10g リリース2（10.1.2）中間層をインストールすると、Configuration Assistantはスキーマがすでにアップグレードされていることを検出し、アップグレードは行いません。
Oracle Workflowをアップグレードするには、次の手順に従ってアップグレードを実行する必要があります。
http://www.oracle.com/technology/documentation/cm_sdk.html
Workflow Configuration Assistantは、中間層に対して追加のアップグレード・タスクを実行し、必要に応じてOracle Workflowスキーマをアップグレードします。
Workflow Configuration Assistantを実行する場合は、次のことに注意してください。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|