10g リリース2（10.1.2） for Microsoft Windows
B15833-03
 目次 |
 索引 |
| Oracle Application Server アップグレードおよび互換性ガイド 10g リリース2（10.1.2） for Microsoft Windows B15833-03 |
|
この章では、アップグレード計画のガイドラインについて説明します。この章の内容は、次のとおりです。
アップグレード処理を開始する前に、バックアップ要件を十分理解しておく必要があります。これらの要件は、アップグレード対象が中間層か、OracleAS Metadata Repositoryか、OracleAS Identity Managementかによって若干異なります。
次の項で、詳細を説明します。
中間層インストールのアップグレード時に、Oracle Application Server 10g リリース2（10.1.2）を新しいOracleホーム・ディレクトリにインストールし、OracleAS Upgrade Assistantを使用して構成データをソースOracleホームからアップグレード先Oracleホームにコピーします。アップグレード処理は、10g リリース2（10.1.2）のアップグレード先Oracleホームのみを変更します。ソース・インスタンスは変更されません。そのため、Application Serverデータを保護するためのバックアップ計画以外は、ソースOracleホームに対して追加または新規のバックアップ計画を実施する必要はありません。
|
注意: 10g リリース2（10.1.2）中間層の新規インストールによってOracleAS Metadata Repositoryのスキーマが変更される場合もあります。その場合は、中間層を10g リリース2（10.1.2）にアップグレードする前に、OracleAS Metadata Repositoryデータベースをバックアップする必要があります。 詳細は、4.10.2項「OracleAS Wireless リリース2（9.0.2）中間層をアップグレードする場合の手順」を参照してください。 |
これに対して、OracleAS Upgrade Assistantを実行する前に、アップグレード先Oracleホームである新しい10g リリース2（10.1.2）のバックアップの作成が必要な場合があります。このバックアップによって、このOracleホームをアップグレード前の状態（新規インストールの状態）にリストアできます。アップグレードの結果に問題がある場合には、バックアップからリストアする方が、インスタンス全体を再インストールするよりも効率的です。次のバックアップは有用です。
ほとんどの場合、OracleAS Metadata Repositoryをアップグレードするときは、まずリポジトリをホスティングするデータベースを、10g リリース2（10.1.2）によってサポートされるデータベース・リリースにアップグレードする必要があります。
他のすべてのデータベース・アップグレードと同様に、標準の手順では、データベース・リリースをアップグレードする前にソースのOracleAS Metadata Repositoryをバックアップするように指示しています。詳細は、ご使用のプラットフォームおよびデータベース・リリースに対応するOracle Databaseドキュメントを参照してください。
データベースをアップグレードした後は、コンポーネント・スキーマが10g リリース2（10.1.2）中間層インスタンスと互換性を持つように、Metadata Repository Upgrade Assistant（MRUA）を実行してこれらのコンポーネント・スキーマをアップグレードする必要があります。このスキーマのアップグレードは、インプレース・アップグレードです。つまり、MRUAによって、データベースに存在するApplication Serverコンポーネント・スキーマが変更されます。スキーマまたはスキーマに含まれているデータのコピーが新しく作成されることはありません。MRUAによって加えられた変更は、元に戻せません。
そのため、MRUAを実行する前に、スキーマを含むデータベースのバックアップを実行する必要があります。このバックアップによって、MRUAの実行前の元の状態にデータベースをリストアできます。
OracleAS Identity Managementのアップグレードでは、OracleAS Identity ManagementインストールのOracleホームにある構成ファイルおよびデータ・ファイルのアップグレードおよびOracleAS Metadata Repositoryデータベース内に格納されているOracleAS Identity Managementスキーマのアップグレードを行う必要があります。
OracleAS Identity Managementインストールをアップグレードする際は、次のバックアップ計画を検討してください。
そのため、ソースOracleホームは、OracleAS Identity Managementのアップグレード処理によって変更されません。Application Serverデータを保護するためのバックアップ計画以外は、追加または新規のバックアップ計画は不要です。
OracleAS Identity Managementスキーマのアップグレードは、インプレース・アップグレードです。つまり、インストール手順によって、データベースに存在するOracleAS Identity Managementスキーマが変更されます。スキーマまたはスキーマに含まれているデータのコピーが新しく作成されることはありません。OracleAS Identity Managementのアップグレードによって加えられた変更は、元に戻せません。
そのため、アップグレードを行う前に、OracleAS Identity Managementスキーマを含むOracleAS Metadata Repositoryデータベースをバックアップする必要があります。
Oracle Application Server環境をアップグレードし、その検証が完了した後、この環境をアップグレード直後の状態に簡単にリストアできるように、Oracle Application Serverインストールのバックアップを検討します。
特に、アップグレード処理の直後に、新しくアップグレードしたOracleAS Metadata Repositoryデータベースのバックアップを検討してください。アップグレード後の初回バックアップによって、データベースの定期バックアップを開始できます。アップグレード後の初回バックアップによって、アップグレード処理を繰り返さなくても、環境をアップグレード直後の10g リリース2（10.1.2）の状態にリストアできるようになります。
また、新しくアップグレードしたOracle Application Serverインストールに開発作業またはデプロイ作業を移行した後、Oracle Application Serverの新しいOracleホームを含むように定期バックアップを必ず変更してください。
アップグレード処理中のシステムの可用性を高めるために、第2章「リリースの互換性について」を確認した後、次のことが可能になるようにアップグレードを計画してください。
この項では、システムの可用性を高める計画の例として、2つのOracle Application Server 10g （9.0.4）中間層インスタンスが1つの10g （9.0.4） Infrastructureインスタンスを使用する場合のアップグレード処理に必要な手順の概要を説明します。
この例の同じ場所に配置されたInfrastructureは、OracleAS Metadata RepositoryおよびOracleAS Identity Managementで構成されています。図3-1に示すように、システム全体で停止時間が発生するのは手順6のみです（システムがInfrastructureに依存する場合）。手順6では、OracleAS InfrastructureをアップグレードできるようにするためにOracleAS Infrastructureを停止する必要があります。
わかりやすくするために図に示されている中間層は2つのみですが、実際にはもっと多くの中間層が存在する場合があります。使用されている中間層が多ければ、アップグレード時の停止時間によるシステム許容量の低下は抑えられます。たとえば、中間層が2つの場合、1つがアップグレードのために停止されるとシステム許容量は50%低下します。中間層が4つの場合、1つがアップグレードのために停止されるとシステム許容量の低下は25%のみです。
図の「クライアント」は、ロード・バランサを指す場合もあります。ロード・バランサを使用している場合、ユーザーは中間層の停止時間を意識する必要はありません。
アップグレード処理時のシステムの状態は、次のように進行します。
アップグレード処理におけるこの手順は、暫定的な構成を表しています。
アップグレード処理におけるこの手順は、暫定的な構成を表しています。
アップグレード処理におけるこの手順は、最終構成を表しています。
この項では、Oracle Application Serverのアップグレードの計画で明らかにしておきたい次の点に関する情報を提供します。
停止時間を考慮する際は、アップグレードの準備作業およびアップグレード処理にかかる時間が重要となります。この項では、基本的な構成のアップグレードの予測時間を示します。
詳細は、表3-1「中間層アップグレードの予測時間」および表3-2「Infrastructureアップグレードの予測時間」を参照してください。
| 操作 | J2EE and Web Cache | Portal and Wireless |
|---|---|---|
|
10g リリース2（10.1.2）中間層のインストール: 10g リリース2（10.1.2）中間層は、リリース2（9.0.2）、リリース2（9.0.3）または10g （9.0.4）中間層と同じコンピュータにインストールする必要があります。 |
30分 |
60分1 |
|
OracleAS Upgrade Assistantの実行: 実行時間は、ソースの構成によって異なります。たとえば、デプロイされたJ2EEアプリケーションの数およびサイズが時間に大きく影響します。この予測時間は、基本的な構成を想定しています。 |
20分 |
30分 |
|
アップグレード後: アップグレードされたインスタンスの起動および基本的な検証テストの実行が含まれます。 |
20分 |
30分 |
|
合計 |
1時間10分 |
2時間 |
|
1
Oracle Application Server Wirelessをリリース2（9.0.2）のMetadata Repositoryに対して構成する最初の10g リリース2（10.1.2）のインスタンスによって、そのリポジトリのスキーマがアップグレードされます。このため、この操作にかかる時間が非常に長くなる場合があります。Oracle Application Server Wirelessが複数の中間層で実行されている場合、この操作を実行する前にそのすべての中間層でOracle Application Server Wirelessを停止する必要があります。詳細は、付録A.1.11「Oracle Application Server Wirelessのアップグレード処理」を参照してください。 |
| 操作 | Metadata Repository | Identity Management | 同じ場所に配置されたInfrastructure1 |
|---|---|---|---|
|
データベースのバックアップ: データベースのバックアップは、ユーザーが指定した手順で実行します。 |
1時間 |
該当なし |
該当なし |
|
Oracleホームのバックアップ: InfrastructureのOracleホームをバックアップします。 |
該当なし |
1時間 |
1時間 |
|
データベースのアップグレード: Metadata Repositoryの作成にOracleAS Metadata Repository Creation Assistantが使用され、データベースがサポートされていないリリースの場合、データベースをサポートされるリリースに手動でアップグレードする必要があります。 |
該当なし |
該当なし |
該当なし |
|
Oracle Universal Installerを使用したインストールおよびアップグレード: アップグレード対象のインストール・タイプに応じて、Oracle Universal Installerによって新しいOracleAS Identity Managementコンポーネントがインストールされます。OracleホームにOracleAS Metadata Repositoryが含まれている場合、OracleAS Metadata Repositoryデータベースは、サポートされるリリースに自動的にアップグレードされます。 |
3時間2 |
30分 |
3時間30分 |
|
MRUA実行前のデータベースのバックアップ |
1時間 |
該当なし |
1時間 |
|
MRUAを使用したOracleAS Metadata Repositoryのアップグレード: Metadata Repositoryのコンポーネント・スキーマをアップグレードします。 |
1時間 |
該当なし |
1時間 |
|
Identity Managementのアップグレード後: アップグレード後のすべてのタスクを実行します。 |
該当なし |
1時間 |
1時間 |
|
合計: |
6時間 |
2時間30分 |
7時間30分 |
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|