リリース 12.1.1
B57077-01
目次
前へ
次へ
| Oracle Applicationsリリース11iから12.1.1へのアップグレード・ガイド リリース 12.1.1 B57077-01 | 目次 | 前へ | 次へ |
この章の内容は次のとおりです。
このマニュアルでは、Oracle Applicationsテクノロジ・スタックと製品を（サポート対象）リリース11iからリリース12.1.1にアップグレードする作業の高レベルの概要を説明します。
このリリースには、既存のリリース11.5.9（ベース、CU1、CU2）および11.5.10（ベース、CU1、CU2）からリリース12.1.1への直接アップグレードを可能にする、再梱包されたRapid Installが含まれています。
次の表に、Oracle Applications 11iについてサポートされているアップグレード・パス（暫定アップグレード・ステップが必要なリリースなど）を示します。この表およびこのマニュアルの他の項に記載されているマニュアルへのリンクについては、「はじめに」の「関連ドキュメント」を参照してください。
| リリース・レベル | アップグレード・パス | 参照マニュアル |
|---|---|---|
| 11.0 | リリース11.5.10 CU2 > リリース12.1.1 | 『Oracle Applicationsのアップグレード リリース11.5.10.2』 > 『Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1』 |
| 11.5.1 - 11.5.8 | リリース11.5.10 CU2 > リリース12.1.1 | 『Maintenance Pack Installation Notes, Release 11.5.10 CU2』（Doc ID: 289788.1） > 『Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1』 |
| 11.5.9または11.5.10（ベース、CU1、CU2） | リリース12.1.1 | 『Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1』 |
リリース12.1.1へのアップグレードを完了するには、データベースをOracle 10gリリース2（10.2.0）以降に移行またはアップグレードする必要があります。
データベースのアップグレード要件の概要を次に示します。
「Oracle10gリリース2以降へのデータベースの移行（条件付き）」（アップグレードに伴う停止時間ウィンドウ中）の説明に従って、データベースをアップグレードします。
リリース11.5.9ベース、11.5.9 CU1、11.5.10ベースおよび11.5.10 CU1
「Oracle10gリリース2以降へのデータベースの移行（条件付き）」（アップグレードに伴う停止時間ウィンドウ中）の説明に従って、データベースをアップグレードします。
注意: 詳細は、『Database Preparation Guidelines for an Oracle E-Business Suite Release 12.1.1 Upgrade』（Doc ID: 761570.1）を参照してください。
アップグレード・プロセスが拡張され、簡素化されています。Rapid InstallとAutoPatchには、機能向上のために新機能が追加されました。また、アップグレードはAutoUpgradeプロセスに依存しなくなっています。すべてのアップグレード機能は1つの統合アップグレード・ドライバに連結されており、以前にAutoUpgradeの画面で取得された情報に依存せずにアップグレードが実行されます。
Rapid Installにより、Oracle Applications製品の最新の動作保証済バージョンと、動作保証済のテクノロジ・スタック・コンポーネントが提供されます。アップグレード時には、アプリケーション（中間）層コンポーネント用の新規ファイル・システムと、データベース用の新規ファイル・システムが作成されます。アップグレード後にRapid Installを再度実行して、サーバーを構成し、サービスを起動します。
アップグレードには、スクリプトの実行やパッチの適用を指示するステップなど、様々な手動ステップも含まれています。リリース12.1.1へのアップグレードを実行する統合ドライバなど、すべてのパッチの適用はAutoPatchに依存します。
このマニュアルは、アップグレード・プロセスとアップグレードによるシステム拡張の全容を示すために、各章と付録の2つにわかれています。各章はシステム・アップグレードの技術的側面を担当するデータベース管理者（DBA）を対象としており、付録はアップグレードに伴う業務への影響と機能変更を理解して管理する必要のあるアプリケーション専門家を対象としています。
このリリースから、このマニュアルの付録部分に、各製品ファミリの機能変更、アップグレードに伴う停止時間を短縮するための提案、データ移行の検証方法と、アップグレード・ドライバでは自動的に実行されないデータ移行の管理方法が記載されています。さらに、後日または特定のニーズが生じた時点でアップグレード可能な特定のデータセットの定義など、要求時アップグレード・プロセスに関する情報も記載されています。
アップグレード計画の一環として、この情報をDBAと機能の専門家が協力して慎重に検討することが重要です。これにより、アップグレード中やアップグレード後に予期せぬ停滞が発生してプロセス自体が長期化したり、システム・ユーザーが機能タスクを再開する際に混乱が生じるのを回避しやすくなります。
注意: アップグレードの成否は、DBAとアプリケーション専門家のコラボレーションにかかっています。両者が計画プロセスの一環としてアップグレードのあらゆる側面を理解し、協力する必要があります。
アプリケーションのアップグレードにより、Oracle Applicationsシステムの技術面と機能面の両方が変化します。テクノロジ・スタックとファイル・システムが変更されるのみでなく、アップグレードの既存製品の動作およびルック・アンド・フィールに影響する特定の変更も開始されます。これらの機能変更（業務関連変更）は、日常業務における製品の使用方法に影響します。
共通データ・モデルによりデータの品質が向上し、管理が簡素化され、共有サービス・センターが世界規模の運用に容易に従事して意思決定者にビジネス関連情報を提供できるようになります。
共通データ・モデルとともに、Oracle FinancialsおよびOracle Procurement製品と他のアプリケーションとの統合も強化されています。統合アプリケーションにより、事前定義済のベスト・プラクティスが可能になり、組織間や地域間でビジネス・プロセスを標準化できます。標準化には、共通のプロセス方法論および量産効果などの利点があります。
このマニュアルでは、リリース12.1.1へのアップグレードに関連して次の機能上のトピックを説明します。
変更理由と、新機能の恩恵を受ける領域
一時的に使用不可になる機能または廃止になった機能
ユーザー・インタフェース、用語または概念およびメニュー・オプションの変更
すべての取引データが予期したとおりにアップグレードされたかどうかを確認するステップ
停止時間短縮のための提案
システムと製品データを準備する前に、アップグレード・プロセス、必要なツール、関連タスクの数とタイプ、リリース12.1.1におけるシステムと製品の参照方法に関する情報を収集する必要があります。マニュアル・ロードマップはMy Oracle Supportで検索できます。『Oracle Applications Documentation Resources』（Doc ID: 790942.1）を参照してください。特に、既知の問題に関する項に注意する必要があります。
このリリースに関連するマニュアルに目を通す必要があります。マニュアルは、My Oracle Supportの『Oracle Applications Documentation Resources』で入手できます。基本的な必読マニュアルのリストについては、このマニュアルの付録H「製品マニュアル一覧」を参照してください。また、アップグレード・テクノロジに関するプレゼンテーション資料、Business Intelligence System、複数組織に関するホワイト・ペーパー、各種コンサルティング・サービスへのリンク、Oracle University研修コースなども確認しておくと役立ちます。
アプリケーション専門家と機能ユーザーは、システムで有効な製品に関するリリース内容文書（RCD）、eTRMおよび情報転送（TOI）文書に特に注意する必要があります。これらの文書には、リリース12.1.1の新機能情報が記載されています。
注意: 保守ウィザードでは、多数のマニュアルや他の文書に記載されている指示がまとめられ、段階的なアップグレード手順が作成されています。この章の「保守ウィザード」を参照してください。
インストール済のコンポーネント、システム・サイズ情報、NLSに関する考慮事項、カスタマイズの管理方法などを理解します。この情報はこの章で後述します。
第2章「アップグレードの準備」の説明に従ってタスクを完了します。手動アップグレード・スクリプト（TUMS）の実行手順に特に注意してください。アップグレード・プロセスから省略可能なタスクを判別できるリストが生成されます。このタスクを実行すると、アップグレード完了までの所要時間を大幅に短縮できます。
リリース12.1.1環境を準備するために、Rapid Installを実行します。Rapid Installにより、アプリケーション層コンポーネント（APPL_TOP）用の新規ファイル・システムとデータベース用の新規ORACLE_HOMEが作成されます。
注意: システム・アップグレードの準備に必要なパッチのリストについては、付録I「事前アップグレードのパッチ一覧」を参照してください。
第3章「リリース12.1.1へのアップグレード」では、システム停止時間が開始します。この章に記載されているタスクは、データベースのアップグレード（未実行の場合）や、AutoPatchを使用した必須パッチの適用などです。
第4章「アップグレード後のタスク」のタスクでは、アップグレード・プロセスを完了し、ユーザー・ログオン用にシステムと製品を準備します。
通常、アプリケーション専門家はアップグレード時に次のタスクを実行します。
アップグレード後にユーザーが経験する機能変更を理解します。このマニュアルの付録AからDの情報を確認してください。
実際のアップグレードに先立って、付録E「停止時間の短縮」のタスク（オプション）を完了します。アップグレード・プロセス中にシステムがオフラインになっている時間を大幅に短縮できる場合があります。
取引データが意図したとおりにアップグレードまたは移行されたかどうかの確認に必要なタスクを実行します。これらのタスクについては、付録F「検証タスク」を参照してください。
履歴データに最も適したアップグレード方法を決定します。初期アップグレード・プロセス（重大な停止時間ウィンドウ）から省略可能であり、後日または必要になった時点でアップグレードできるデータのタイプについては、付録G「要求時アップグレード」を参照してください。たとえば、すべてのOracle Financials会計データを停止時間中にアップグレードするかわりに、最終会計年度のみをアップグレード対象に含めることができます。他の会計年度（数か月後または数年後でも）のアップグレードが必要になった場合は、アップグレード後にいつでも実行できます。
このアップグレードを完了すると、システムはリリース12.0の更新レベル12.1.1にアップグレードされます。引き続き最新のRelease Update Pack（RUP）を適用することで、常にシステムを最新のリリース・レベルで利用することができます。各Release Update Packは、該当するファミリに関連付けられているすべてのパッチを含む、個別の製品ファミリRUPで構成されています。Release Update Pack全体を適用することも、個別に製品ファミリ・パックを適用することも可能です。
RUPは定期的にリリースされます。各RUPは累積的で、最新のRUPだけでなくそれ以前のすべてのRUPに対する、エラー修正およびシステム更新が提供されます。
『Oracle Applications リリース・ノート』（Doc ID: 405293.1）の最新バージョンを確認することによって、最新のリリース情報だけでなく、新しいRUPのお知らせおよびアップグレードに影響する可能性のあるその他の更新を常に取得することができます。
この項では、Rapid Installにより提供される動作保証済のコンポーネントと、アップグレードに関する一般的なシステム要件を説明します。一般に、CPU、メモリーおよびディスク領域（ログ・ファイルおよびバックアップ用）の要件は、通常の操作中よりもアップグレード時の方がはるかに大きいことに注意してください。
Rapid Installでは、データベース層とアプリケーション層の両方について、必須のテクノロジ・スタック・コンポーネントが自動的にインストールおよび構成されます。リリース12.1.1の新規インストールのデータベース層のテクノロジ・スタックはOracle 11gリリース1（11.1.0.7）です。Oracle 10gリリース2またはOracle 11gリリース1を含むリリース11iからのどちらのアップグレードもサポートしています。
アプリケーション層には、他のコンポーネントとともに次のテクノロジ・スタックがインストールされます。
Oracle Application Server（AS）10g リリース2（10.1.2）
Oracle Application Server（AS）10g 10.1.3
Oracle Developer 10g（Oracle Formsを含む）
Java （J2SE）ネイティブ・プラグイン1.6.0_10
Java Developer Kit（JDK）6.0
システムによってはプラットフォーム固有のリリース保守ツールが必要な場合があり、一部のプラットフォームのリリース12.1.1には必須ツールの新規バージョンがあります。これらのツールのリストについては、該当するプラットフォームの『Oracle Applications インストレーションおよびアップグレード・ノート』を参照してください。
アップグレードには、Oracle 10gリリース2（10.2.0）以降が必須です。Oracle 11gリリース1もサポートされています。指示については、『Database Preparation Guidelines for an Oracle E-Business Suite Release 12.1.1 Upgrade』（Doc ID: 761570.1）を参照してください。
アップグレードのCPU要件は、次のように多数のファクタに応じて異なります。
データベースのサイズ
主要製品インストール・グループのデータ量
このリリースの製品に関連付けられている長時間実行プロセスの数と継続期間
注意: アップグレード中に使用するワーカーの数に関する推奨事項については、『Oracle Applicationsメンテナンス・ユーティリティ』を参照してください。
例:
最大のOracle本番システム（oraprod）のテスト・アップグレードでは、次のCPUを使用しました。
データベース層のマシン: 24 CPU（900 MHz SUNW、UltraSPARC-III+）
アプリケーション層のマシン: 4 CPU（3.05 GHz Intel Xeon）
Visionデータベースおよびアプリケーション層のマシンのテスト・アップグレードでは、4 CPU（3.05 GHz Intel Xeon）を使用しました。
注意: これらの本番システムのアップグレードに関する統計については、『E-Business Suite Release 12 Upgrade Sizing and Best Practices』（Doc ID: 399362.1）を参照してください。
アップグレードのメモリー要件を計算する際には、次のことを考慮してください。
同時ユーザー数
複数層アーキテクチャのインフラストラクチャ要件
例
最大のOracle本番システム（oraprod）のテスト・アップグレードでは、次のメモリーを使用しました。
データベース層のマシン: 48 GBのメモリー
アプリケーション層のマシン: 12 GBのメモリー
Visionデータベースおよびアプリケーション層のマシンのテスト・アップグレードには、6 GBのメモリーを使用しました。
注意: これらの本番システムのアップグレードに関する統計については、『E-Business Suite Release 12 Upgrade Sizing and Best Practices』（Doc ID: 399362.1）を参照してください。
アップグレード中のパフォーマンスは、Oracleデータベース・システムの入出力（I/O）サブシステムの速度に大きく依存します。パフォーマンス向上のために、10から15ミリ秒未満の平均ディスク応答時間（平均サービス時間）をお薦めします。詳細（IOPの計算など）は、『E-Business Suite Release 12 Upgrade Tablespace Sizing and Best Practices』（Doc ID: 399362.1）を参照してください。
I/Oパフォーマンスをモニターするには、テスト・アップグレード中にiostatまたはsar（Unix）などのOSツールを使用する必要があります。他のオペレーティング・システムの場合も、同様のツール（Windowsの場合はパフォーマンス・モニターなど）を使用します。また、負荷ピーク中に本番システムのI/Oパフォーマンスをモニターして、アップグレード前にI/Oサブシステムのパフォーマンス情報を取得することもできます。ただし、既存のアプリケーションにおけるI/O負荷と平均サービス時間がアップグレード時とは異なることに注意する必要があります。
I/Oパフォーマンスのモニター中は、平均サービス時間（ディスク・ドライブでI/O要求が完了するまでの平均ミリ秒数）と平均待機（要求が未処理になっている平均時間）に焦点を絞る必要があります。この2つの指標の平均値が大きくなる場合は、I/Oボトルネックがあることを示します。平均サービス時間が50ミリ秒を超える場合は、継続時間が長すぎるかどうかや高レベルの状態が続くかどうかに注意する必要があります。平均サービス時間が長くなっている間隔が短ければ、問題はありません。
注意: 『Oracle Databaseパフォーマンス・チューニング・ガイド 10g リリース2（10.2）』または『Oracle Databaseパフォーマンス・チューニング・ガイド 11g リリース1（11.1）』を参照してください。
アップグレードに必要なディスク領域の追加分を見積もるために、製品、インストールする言語の数およびデータ・モデルの変更を考慮します。
例
最大のOracle本番システム（oraprod）のテスト・アップグレードでは、データベースが10から20 %大きくなりました。また、Visionデータベースは5 %大きくなりました。Oracle本番システム（oraprod）のアップグレードに基づくガイドラインについては、『E-Business Suite Release 12 Upgrade Sizing and Best Practices』（Doc ID: 399362.1）を参照してください。
十分な表領域を割り当てる必要があります。Oracle本番システム（oraprod）のアップグレードに基づくガイドラインについては、『E-Business Suite Release 12 Upgrade Sizing and Best Practices』（Doc ID: 399362.1）を参照してください。
このリリースでは、8KのRDBMSブロック・サイズが必要です。この設定により、パフォーマンスが大幅に向上するのみでなく、このブロック・サイズを必要とするOracle Applications索引に対応できます。
アップグレード・プロセスは、システム・アーキテクチャと、アップグレード後のOracle Applications製品の使用方法に影響します。このリリースのアーキテクチャの詳細（Oracle Applications複数層アーキテクチャ、拡張機能、言語サポート、ファイル・システム構造および基本データ・モデルなど）については、『Oracle Applications概要』を参照してください。
このリリースでは、製品提携ではなくデータベース・オブジェクト・タイプに基づいたOracle Applications表領域モデル（OATM）を使用します。OATMでは、すべての製品に12のローカル管理表領域（一時表領域、システム表領域、システム管理のUNDO（SMU）表領域など）を使用します。各データベース・オブジェクトは、入出力特性（オブジェクト・サイズ、存続期間、アクセス方法、ロックの粒度など）に基づいて、表領域にマップされます。
システム・テストは、小規模システム（100 GBのデータベース）の場合はエクステント・サイズ128 KB、大規模な数TBのデータベース・システムの場合は、エクステント・サイズ4から10 MBで正常に完了しています。
アップグレード・プロセスには、すべての新製品用の表領域を作成し、新規表領域モデル用にデータベースを構成するためのスクリプトが用意されています。そこで、アップグレード・プロセスでは新規オブジェクトが作成されます。ただし、既存のオブジェクトが自動的に移行するわけではありません。アップグレードの完了後に既存のオブジェクトを移行することをお薦めします。このタスクの実行には、表領域移行ユーティリティ（リリース11iで導入）を使用します。
注意: 『Oracle Applicationsシステム管理者ガイド - 構成』を参照してください。また、『Oracle Applications概要』も参照してください。
複数組織アーキテクチャでは、E-Business Suite全体のパフォーマンス向上をサポートしています。また、複数組織アクセス管理もサポートしており、必要に応じてアプリケーションの職責で複数の営業単位にアクセスできます。アップグレードでは、すべての単一組織アーキテクチャ・システムを複数組織に変換する必要があります。少なくとも1つの営業単位を定義し、「MO: 営業単位」プロファイル・オプションに割り当てる必要があります。
複数組織に変換しても複数営業単位または会計帳簿を使用する必要はありませんが、これらの機能が必要な場合は使用できます。複数組織への変換によって動作が大きく変わることはありません。複数営業単位や会計帳簿を定義しない場合は、ユーザーは変換を認識しません。
注意: 『Oracle Applications Multiple Organizations Implementation Guide』を参照してください。また、『Use of Multiple Organizations (Multi-Org) in Release 11i』（Doc ID: 210193.1）も参照してください。
Oracle Subledger Accountingには、様々な補助元帳の既存の会計処理を置き換える共通会計エンジンが用意されています。そのため、Oracle Subledger Accountingのアップグレードは、2つのリリース間で業務を継続できるように、既存の会計データを移行する作業で構成されています。ビジネスおよび特定の要件によっては、既存の会計データが顧客ごとに異なる意味を持つ場合があります。
注意: Subledger Accountingアップグレードの詳細は、付録A「Financials製品のアップグレードの影響」を参照してください。SLAのアップグレードが他の製品に及ぼす影響の詳細は、付録G「要求時アップグレード」の「FinancialsおよびProcurementタスク」も参照してください。
複数報告通貨機能は、Oracle Subledger Accountingモデルで報告通貨機能に移行しています。Oracle Subledger Accountingには、報告通貨で金額を表示できる単一リポジトリが用意されています。
注意: 詳細は、このマニュアルの付録A「Financials製品のアップグレードの影響」の「General Ledger」および「Subledger Accounting」を参照してください。
アップグレードの場合、重大なシステム停止時間とは、ユーザーがシステムにログオンできなかったり、Oracle Applicationsを使用できない期間を指します。この停止時間を短縮するために実行できる処理がいくつかあります。たとえば、アップグレード前に特定の製品固有のタスクを実行しておくと、停止時間を大幅に短縮できます。同様に、Oracleのクローニング方法論とテスト・ファイル・システムを使用して本番システムをアップグレードすると、停止時間を大幅に短縮できます。
この項では、アップグレードに必要な停止時間に影響する問題と、停止時間を短縮するための推奨処理の概要を説明します。
アップグレードを開始する前に、システム全体のバックアップを作成することをお薦めします。
アップグレードの各ステージで必要となる初期化パラメータは、データベースをアップグレードするタイミングに応じて異なる場合があります。開始前に、これらのパラメータの要件を確認してください。『Database Initialization Parameters for Oracle Applications Release 12』（Doc ID: 396009.1）を参照してください。
一部のアップグレード・スクリプトのパフォーマンスは、次に示すアップグレード継続期間のデータベース設定を変更すると大幅に向上できます。この項に示すパラメータは指定どおりに設定する必要があり、特に明記しないかぎりアップグレード・プロセスの完了後に必要に応じて再設定できます。
順次スキャン中に1回のI/O操作で読み取る最大ブロック数を指定します。このパラメータをinit.oraファイルから永久に削除してください。いずれかの値に設定されていると、_db_file_optimizer_read_countのデフォルト設定が上書きされます。このパラメータはアップグレード後にリストアしないでください。
この文書化されていないパラメータは、コストベース・オプティマイザで使用されます。全表スキャンや高速全索引スキャンなどの操作の原価を計算する目的で、順次スキャン中に1回のI/O操作で読み取る最大ブロック数を表します。順次スキャン中に1回のI/O操作で実際に読み取るブロック数は、このパラメータで独立して制御されます。デフォルト設定は8です。このパラメータは変更しないでください。
ジョブの実行用に作成できる最大プロセス数を指定します。CPUと同数の値に設定することをお薦めします。
データベースで実行中のパラレル問合せサーバー・プロセスの最大数を制御します。CPU数の2倍の値に設定することをお薦めします。
推奨値については、『Database Initialization Parameters for Oracle Applications Release 12』（Doc ID: 396009.1）を参照してください。
12.1.1へのアップグレードプロセス時に、顧客が11gR1を実行している場合、次のエラーが発生する可能性があります。
ORA-04030: out of process memory when trying to allocate 822904 bytes (pga heap,kco buffer)ORA-07445: exception encountered: core dump [dbgtfdFileWrite()+48] [SIGSEGV] [ADDR:0xFFFFFFFF7FFC1C88] [PC:0x1063BD2D0] [Address not mapped to object] []このエラーは11gR1を実行している顧客にのみ影響します。このエラーは、データベースプロセスメモリーが使い切られたため、プロセスを再起動する必要があることを示しています。このエラーは、大量の索引の作成時にのみ発生し、12.1.1へのアップグレードにのみ影響します。このエラーを受信した場合、次に示すように、_pga_max_sizeパラメータを大きな値に設定する必要があります。
_pga_max_size=104857600
この値を設定した後、データベースを再起動する必要があります。修正が有効になると、My Oracle SupportのNote番号735276.1はそれに応じて更新されます。
フラッシュバック・ドロップ機能をオンにするかどうかの制御に使用します。このパラメータをOFFに設定すると、削除された表はごみ箱に置かれません。ONに設定すると、削除された表はごみ箱に置かれ、リカバリできます。
テンポラリ・ファイル・オプションで均一割当サイズを指定し、表領域（通常はTEMP）をローカル管理表領域として作成します。この方法で一時表領域が定義されていない場合は、その表領域を削除し、次の例をテンプレートとして使用して再作成してください。
SQL> drop tablespace TEMP;
SQL> create TEMPORARY tablespace TEMP
tempfile ’ts_p_temp1.dbf’ size 2048M
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 1M;一時表領域が作成されたことを確認するには、次のコマンドを実行します。
SQL> select CONTENTS,EXTENT_MANAGEMENT,ALLOCATION_TYPE
from dba_tablespaces
where tablespace_name=’TEMP’;問合せの出力は次のようになります。
| Contents | EXTENT_MANAGEMENT | ALLOCATION_TYPE |
|---|---|---|
| TEMPORARY | LOCAL | UNIFORM |
アップグレード後に、一時表領域に関する前の格納パラメータをリストアし、一時表領域のエクステント・サイズを1 MB未満（128 KBなど）の値に縮小します。
注意: 『Database Initialization Parameters for Oracle Applications Release 12』（Doc ID: 396009.1）を参照してください。
この項では、システムの検査とシステムに適用するアップグレード・ステップの決定に使用できるツールを説明します。
手動アップグレード・スクリプト（TUMS）により現行の構成が検査され、システムに該当しないアップグレード・タスクを示すレポートが作成されます。このレポートにはシステム構成に固有の情報が含まれているため、出力は個別のアップグレードに関連するものになります。TUMSレポートに示されたステップを省略すると、アップグレードに伴う停止時間を大幅に短縮できます。
TUMSレポートを作成するには、リリース11iのパッチを適用します。このパッチにより、TUMSでOracle Applications構成の検査に使用されるAPPSスキーマにオブジェクトがロードされます。現行のOracle Applications環境は影響を受けません。パッチでは、このマニュアルで説明するTUMSステップ・キーを使用して各タスクが一意に識別されます。生成されたレポートでは、アップグレード・タスクごとにステップのタイプ（事前アップグレードなど）とステップ番号、ステップ・キーが示されます。
第2章でアップグレードの準備を行う際に、TUMSを実行するように指示されます。
保守ウィザードは、Oracleサポートから提供されるツールで、表示される指示に従ってアップグレードおよびコード行の保守プロセスを進めることができます。多数のマニュアルや他の文書（このマニュアル、『Oracle Applicationsインストレーション・ガイド: Rapid Installの使用方法』、『Oracle Applications リリース・ノート』など）から指示が採用されており、アップグレードに必要なアクティビティの全容が提供されます。
保守ウィザードを使用すると、Oracle Applications環境から取得した基準に基づいて必要なステップを動的にフィルタし、アップグレード・タスク数を削減できます。結果のレポートは、システムに必要な重要パッチなど、特定のアップグレードを完了するための一連の必須手順を正確に示すものです。また、多数のタスクが自動的に実行されるため、エラーの可能性や重要なタスクを意図せずに省略する可能性が減少します。
保守ウィザードの特長は、次のとおりです。
連結されパーソナライズされた一連の手順が表示されます。
重要なアクティビティが検証可能になり、ダウンストリームでの問題発生が防止されます。
すべてのタスクのログおよびステータス情報が保守されます。
プロジェクト管理者は、様々なアップグレード・タスク・グループを異なるユーザーに割り当てることができます。
多数の必須パッチが自動的にダウンロード、マージ、インストールされます。
プロジェクト管理ユーティリティが用意されており、各タスクの所要時間と完了ステータスが記録されます。
注意: 保守ウィザードの設定と使用については、『Master Issue List for the Maintenance Wizard』（Doc ID: 215527.1）を参照してください。
パッチの適用時に最適なパフォーマンスを確保して停止時間を短縮するには、AutoPatchセッションを開始する前に、ワークフロー・ビジネス・イベント・システムを停止して機能セキュリティを設定する必要があります。これにより、必要なセキュリティが提供され、パッチ適用中はユーザーがOracle Applications機能を使用できなくなります。保守モード機能により、Oracle Applicationsの通常のランタイム操作と保守に伴うシステム停止時間が明確に分離されます。
注意: 『Oracle Applicationsメンテナンス・ユーティリティ』の保守モードの変更に関する項を参照してください。『Oracle Applicationsパッチ・プロシージャ』のパッチ適用ツールに関する項も参照してください。
アップグレード・プロセス中、Oracle RDBMSのDROP COLUMNコマンドによりOracle Applications列がデータ・ディクショナリ内で未使用とマーク付けられ、データベース管理者が列を削除して関連領域を再生できるようになっています。プロセスにより関連表がロックされるため、この再生を早めに計画することをお薦めします。領域が再生されると、アップグレード済データ・モデルがフレッシュ・インストールにさらに近付きます（カスタマイズを除く）。DROP COLUMNコマンドは、カスタム列には無効であることに注意してください。
アップグレード実行時間のベースラインを提供してアップグレードの問題を事前に処理するには、既存システムのコピー（クローン）と本番システムと類似したハードウェアを使用して、テスト・アップグレードを実行することをお薦めします。システムがカスタマイズされている場合は、テスト・アップグレードが特に重要になります。
ユーザー優先タイムゾーンがサポートされている製品では、特別なアップグレード・ステップは不要です。
注意: 『User Preferred Time Zone Support in the Oracle E-Business Suite Release 12』（Doc ID: 402650.1）を参照してください。
一部のOracle Applications製品の場合、アップグレード計画にはアップグレード処理に最も有効なデータのセットを選択する作業が含まれます。これにより、アップグレードから省略された履歴データを、後日または必要になった時点でアップグレードできます。たとえば、リリース12.1.1へのアップグレードには最終会計年度のみを含めておき、残りのデータは12.1.1へのアップグレードに伴う停止時間ウィンドウ外にアップグレードできます。
注意: 詳細は、付録Gを参照してください。
この項では、アップグレード中の翻訳、言語およびキャラクタ・セットの管理に関する重要な考慮事項を説明します。
アップグレードを完了するには、データベースにアメリカ英語以外の言語用に追加領域が必要になります。領域はデータベース・キャラクタ・セットやアメリカ英語以外に有効な言語の数などに応じて異なり、顧客がシステムに作成したデータ量によっても大きく異なるため、システムに必要な追加領域は予測できません。
言語用の追加領域は、アップグレード・プロセスを通じて使用可能である必要があることに注意してください。
注意: APPL_TOPで各有効言語に必要な推奨最小領域については、使用しているリリース・レベルの『Oracle Applications NLSリリース・ノート』を参照してください。
アップグレード後ステップおよび終了ステップを含めてアップグレード・プロセス全体が完了するまでは、既存のOracle Applicationsリリース11iの言語ステータスを保持する必要があります。ベース言語も同一に保つ必要があり、新規言語は有効化できません。
アップグレード・プロセスの完了後に、必要に応じて言語ステータスを変更し、新規言語を有効化できます。
注意: 『Oracle Applicationsメンテナンス・プロシージャ』のNLS言語の追加と保守に関する項を参照してください。
アップグレード中はデータベース・キャラクタ・セットを変更できません。
Oracle Applicationsシステムがアップグレード・プロセス中にデータベースに接続するかどうかによっては、Rapid Installウィザードのアップグレード画面でリリース12のAPPL_TOP用に新規キャラクタ・セットを選択できます。ただし、その場合、新規キャラクタ・セットは既存のデータベース・キャラクタ・セットと同一であるか互換性を持つ必要があります。
注意: APPL_TOPのキャラクタ・セットを現行のデータベース・キャラクタ・セットと互換性のないキャラクタ・セットに変更すると、アップグレード後のシステムが破損します。
注意: 『Oracle Applicationsシステム管理者ガイド - メンテナンス』のライセンス・マネージャに関する項を参照してください。また、『Migrating an Applications Installation to a New Character Set』（Doc ID: 124721.1）も参照してください。
カスタマイズされた環境の場合、アップグレード中に特に注意する必要があります。このマニュアルに記載されている手順は、『Oracle Applications開発者ガイド』と『Oracle Applicationsフォーム・ベース製品のユーザー・インタフェース標準』に記載されているとおり、Oracle Applicationsのカスタマイズ標準に正確に従ったことを前提としています。
注意: 『Preparing Custom Development for the Next Oracle Applications E-Business Suite Release』（Doc ID: 374398.1）も参照してください。
カスタマイズを保持し、アップグレード中の影響を最小限に抑えるには、次の操作を実行します。
『Oracle Applications開発者ガイド』の指示に従って、システムをカスタマイズし、カスタマイズをアップグレードします。
カスタマイズに関する詳細文書を保守します。
アップグレード前にカスタマイズのバックアップを作成します。
注意: コンカレント・プログラム定義、メニュー、値セットまたはOracle Applicationsで提供される他のシード・データのカスタマイズはサポートされていません。これらのカスタマイズはアップグレード・プロセスにより上書きされます。
ファイルは様々な理由で名称変更されるため、アップグレード中は意図せずに上書きされないように、保護しておくことをお薦めします。したがって、「<ファイル名>old」、「<ファイル名>new」または他の汎用指定を使用してファイルを名称変更した場合は、アップグレード開始前に意味のある名称に再度変更してください。
このリリースのヘルプ・ファイルはHTML形式で、市販のWebブラウザやエディタを使用して容易に変更できます。前にカスタマイズしたヘルプ・ファイルをアップグレード後のシステムに再適用することはできません。そのため、アップグレード前のカスタマイズ済ヘルプ・ファイルを参照用に保存しておくことが重要です。
注意: 『Oracle Applicationsシステム管理者ガイド - 構成』のOracle Applicationsヘルプのカスタマイズに関する項を参照してください。
この項で説明する内容は、このリリースの特定のOracle Applications製品に該当します。システムで有効な他の製品については、リリース内容文書を参照してください。
注意: このリリースのOracle Applications製品の変更については、付録AからDを参照してください。製品固有のマニュアルについては、付録H「製品マニュアル一覧」も参照してください。
この項で説明する製品に対する変更は、多数のOracle Applications製品に影響します。アップグレード開始前に、アプリケーション専門家は、関連する変更内容に対応できるように計画を作成する必要があります。
Oracle Legal Entity Configuratorは、リリース12で導入された新しいモジュールです。このモジュールには、リリース11iの多数のソースから移行するデータが移入されます。その目的は、企業の法的体系について一貫した定義を提供し、Oracle E-Business Suite内の他の体系に関連付けることです。
Oracle Legal Entity Configuratorを使用すると、企業の法的体系を管理し、法律面からデータを追跡できます。これにより、法的エンティティ、報告組織および登録の各レベルで詳細レポートを作成できます。
法的エンティティの概念は、人事管理モデルを使用して法的エンティティを定義する全顧客に影響します。法的エンティティは、法的エンティティ（XLE）データ・モデルに法的情報が格納されているTrading Community Architecture（TCA）のパーティとして存在します。法的エンティティの子会社は報告組織として定義され、報告組織も法的エンティティ・データ・モデルに法的情報が格納されているパーティとして定義されます。
注意: 詳細は、『Oracle Financials Concepts』を参照してください。『Oracle Financialsインプリメンテーション・ガイド』も参照してください。
GRE/法的エンティティに分類され、会計情報（会計帳簿など）が割り当てられているHRMS組織は、このリリースの新しい法的エンティティに移行します。移行する法的エンティティごとに、同じデータを使用して「報告組織」タイプ（主要報告組織）が作成されます。
営業単位または在庫組織に分類されているHRMS組織は、新しい法的エンティティ・モデルで報告組織に移行します。営業単位または在庫組織の分類を除き、組織の他の分類は報告組織として移行されません。
一部の国（アルゼンチン、ギリシャ、韓国、チリ、イタリア、コロンビア、台湾など）の場合、リリース11iではHuman Resourcesの「組織の定義」フォームを通じてVAT台帳番号を入力するか、国固有の設定フィールドに登録番号を入力していました。これらの値は、法的エンティティ識別用管轄区域登録番号に移行します。有効な登録番号が存在しない場合は、ダミー値であるSys + <順序番号>が登録番号としてアップグレードされ、シード済の識別用管轄区域に関連付けられます。
注意: 詳細は、『Oracle Financials and Oracle Procurement Upgrade Guide: Release 11i to Release 12』を参照してください。
既存のパラメータに基づいて税を計算できるように、GRE/法的エンティティと営業単位、在庫組織、出荷先事業所、請求先事業所との関連付けが移行されます。アップグレード後は、Legal Entity Configuratorを介してこれらの関連を保守する必要があります。
このリリースでは、複数組織アクセス管理（MOAC）によりリリース11iで使用されていた複数組織アーキテクチャが大幅に拡張されています。会社で共有サービス運用モデルを実装している場合は、複数組織アクセス管理を使用すると、ビジネス取引を効率的に処理できます。データのセキュリティやシステム・パフォーマンスを損なうことなく、1つの職責で複数の営業単位にまたがるデータにアクセスし、処理してレポートを作成できます。
複数組織セキュリティ・プロファイルにより、1つのアプリケーション職責で無制限な数の営業単位データにアクセスし、処理してレポートを作成できます。複数組織アクセス管理を利用するには、次のプロファイル・オプションを設定する必要があります。
MO: セキュリティ・プロファイル: アプリケーションの職責ごとに、このプロファイル・オプションにセキュリティ・プロファイルを割り当てると、その職責で複数の営業単位にアクセスできます。
MO: デフォルト営業単位: 「MO: セキュリティ・プロファイル」を設定した場合は、デフォルト設定のためにデフォルト営業単位を割り当てることができます。
「MO: セキュリティ・プロファイル」を設定しないと、リリース11iの「MO: 営業単位」プロファイル・オプションの設定が保持され、適用されます。
組織間レポート機能が拡張され、新しい複数組織アクセス管理との一貫性が向上しています。同じ元帳を共有するユーザーのセキュリティ・プロファイルに属する複数の営業単位間でレポートを実行できます。また、ユーザーのセキュリティ・プロファイルに属する全営業単位についてもレポートを実行できます。
営業単位の設定は、General Ledgerの新機能である会計設定マネージャとの統合により合理化されます。これにより、法的エンティティ、営業単位および元帳など、共通会計コンポーネントの設定と保守が1つの会計設定内で集中化されます。
営業単位として分類されているリリース11iの全HR組織は、アップグレード中に保持されます。営業単位が会計帳簿に割り当てられている場合は、会計設定で主要元帳に関連付けられます。これにより、アップグレード後の主要元帳に割当済の営業単位をすべて会計設定マネージャで表示できるようになります。
重要: Oracle Student System（IGS）とOracle Student Recruiting（IGR）は、このリリースでは機能しません。IGSとIGRを使用している顧客は、このリリースにアップグレードしないでください。IGSとIGRについて、リリース11iからリリース12のアップグレードが提供される予定はありません。
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.