Oracle E-Business SuiteをOATM(Oracle Applications Tablespace Model)へ移行する方法:移行ユーティリティ完全ガイド
本記事では、OATM(Oracle® Applications Tablespace Model)移行ユーティリティを使用して、バージョン11iのデータベースを、全製品共通の12個のローカル管理テーブルスペースを持つOATM構成へ変換する手順について解説します。
はじめに
OATMはOracle Applicationsで導入されたモデルで、「統合型テーブルスペースモデル」とも呼ばれます。12個の統合テーブルスペース(一時用・システム用・UNDOセグメント用の3つのシステムテーブルスペースを含む)を活用し、ローカル管理テーブルスペースをサポートします。OATMはRelease 11i.10で導入されました。11iより前のOracle E-Business Suiteでは、各製品ごとに2つのテーブルスペース(データ用とインデックス用)が割り当てられていました。
移行ユーティリティは、メニューベースのPERLプログラムと一連のサイジング見積レポートで構成されています。これにより、Oracle E-Business Suiteのアプリケーションスキーマを、単発の一括移行または段階的なスキーマごとの移行のいずれかの方法で変換できます。Oracleは一括移行を推奨していますが、この方法には大幅なダウンタイムと十分なディスク容量が必要です。なお、部分移行(一部のテーブルスペースのみの移行)はサポートされていません。スキーマごとの段階的移行を実施する場合でも、最終的にすべてのスキーマを移行する必要があります。
OATMの主なメリットは以下のとおりです。
- テーブルスペースの数が減り、管理が統合される
- ローカル管理テーブルスペースを利用できる
- オブジェクトのI/O特性に応じた配置が可能
- 移行後に未使用領域を回収できる
- Real Application Cluster(RAC)をサポートする
以降のセクションでは、移行の前提条件、OATM移行ユーティリティのインストール、および移行の実行手順について説明します。
OATM移行の前提条件
OATM移行を開始する前に、以下の作業を行ってください。
OracleデータベースのバージョンがRDBMS 9.2.0.4以上であることを確認します。
データベースのバージョンが9.2.0.6の場合は、次のコマンドを実行します。
$FND_TOP/patch/115/sql/fndupglb.sql移行対象外のカスタムスキーマ(Oracle Applicationsに登録されている非Oracle製スキーマなど)がある場合は、該当スキーマを無効化して登録解除します。無効化を検討すべきスキーマには、
XXBOLやXXCONなどがあります。CTXSYSスキーマはAPPSスキーマではないため、以下の手順で登録します。
- メニューから System Administrator Responsibility -> Security -> ORACLE -> Register を選択します。
Schema CTXSYSを選択し、権限をEnabledに設定します。
OATM移行ユーティリティのインストール
このセクションでは、インストールの手順を説明します。
ステップ1:パッチと設定の適用
まず、以下の手順を実行してインストールを開始します。
パッチ
3942506を適用し、OATM移行用スクリプト$FND_TOP/bin/fndtsmig.plを取得・保存します。Oracle Note 404954.1 に記載されている必要なパラメータを確認・取得します。
データベースを
no archive logモードに設定します。
ステップ2:データベースパラメータの更新
OATM移行を開始する前に、以下のパラメータ値を引き上げます。
- undo_retention=10200
- job_queue_processes=0
- aq_tm_processes=0
- db_files=1500(OATMで必須)
具体的には、次のコマンドを実行します。
$ sqlplus '/as sysdba'
SQL> alter system set undo_retention=10200 scope=spfile;
SQL> alter system set job_queue_processes=0 scope=spfile;
SQL> alter system set aq_tm_processes=0 scope=spfile;
SQL> alter system set db_files=1500 scope=spfile;
その後、データベースをシャットダウンして再起動し、パラメータ設定が反映されていることを確認します。
ステップ3:一時テーブルスペースのリサイズとデータベースのクリーンアップ
インストールを完了させるために、一時(temp)テーブルスペースを50GB以上にリサイズします。さらに、tools表領域やundo表領域なども含めてデータベースをクリーンアップしておきましょう。
ステップ4:OATM移行ユーティリティの起動
ここからは、実際の移行作業に入ります。
Step 1:移行スクリプトの実行
移行を開始するには、次のコマンドを実行します。
$FND_TOP/bin> perl fndtsmig.pl
Main Menu
1. Migration Sizing Reports
2. Create New Tablespaces
3. Generate Migration Commands
4. Execute Migration Commands
5. Run Migration Status Reports
6. Run Post Migration Steps
7. Run Customization Steps
8. Run Migration in Batch Mode
Please enter your option -
Step 2:新規テーブルスペースに必要な容量の確認
メインメニューから 1. Migration Sizing Reports を選択し、OATM移行の完了に必要なディスク容量を確認します。
1. Generate a Report with the list of all the Oracle
Application product schemas that can be migrated
2. Calculate total space required by each new tablespace to
Migrate all Oracle Application product schemas (relevant
for a complete migration)
3. Calculate total space required by each new tablespace to
migrate each Oracle Application product schema (relevant
for a schema-by-schema migration)
4. Calculate total space required by each Oracle Applications
schema, with details for each object
5. Display Sizing Exception report
Please enter your option -
Press Return key to continue...
このメニューから 2. Calculate total space required ... を選択すると、必要な容量が算出されます。サイジングレポートの結果に基づいて、必要なストレージ容量を確保してから作業を続行してください。
これらのレポートは、新しいテーブルスペースに必要な容量を見積もるためだけでなく、どの移行アプローチが自社の環境に最適かを判断する際にも役立ちます。
Step 3:テーブルスペース作成スクリプトの生成
メインメニューから 2. Create New Tablespaces を選択して、新しいテーブルスペースを作成します。
Create New Tablespaces
1. Generate new tablespace creation script
2. Create new tablespaces
Please enter your option -
Press Return key to continue...
このメニューでは、まず 1. Generate new tablespace creation script を選択してスクリプトを生成します。
Step 4:Invalid Indexesレポートの生成
Invalid Indexesレポートを生成するには、まずメインメニューから 3. Generate Migration Commands を選択します。
Generate Migration Commands
Generation of Migration commands including disable/enable
commands for triggers, constraints, policies, stop/start for queues.
1. Invalid Indexes Report. Please correct/drop these before
generating migration commands
2. Generate migration commands for all schemas
3. Generate migration commands for a list of schemas
[Q]uit [B]ack [N]ext
Please enter your option -
Press Return key to continue.
次に 1. Invalid Indexes Report. を選択すると、無効なインデックスのレポートが出力されます。
Report created /oracldb/oracledbappl/admin/oracldb/log/fndinvld.txt
Step 5:カスタムスキーマの無効化とCTXSYSスキーマの有効化
前述の「前提条件」セクションで説明したカスタムスキーマの無効化とCTXSYSスキーマの有効化をまだ実施していない場合は、この時点で実行してください。
Step 6:全スキーマ向け移行スクリプトの生成
Generate Migration Commands メニューから 2. Generate migration commands for all schemas を選択し、移行スクリプトを生成します。
Generating Migration commands for all schemas. This may take upto 30min. Please wait...
Press Return key to continue...
Step 7:CTXSYS向け移行コマンドの生成
Generate Migration Commands メニューから 3. Generate migration commands for a list of schemas を選択し、CTXSYSスキーマ用の移行コマンドを生成します。プロンプトが表示されたら CTXSYS と入力してください。
Please enter your option - 3
Enter a comma separated list of Schema names: CTXSYS
Step 8:autoextendオプションの設定
移行時の問題を回避するため、新しく作成されたすべてのファイルに対してautoextendを ON に設定します。以下のコマンドを実行してください。
SQL> spool autoextend_ts.sql
SQL> select 'alter database datafile ''' || file_name || ''' ' || ' autoextend on;' from dba_data_files;
SQL> spool off
$ autoextend_ts.sql
Step 9:移行コマンドの実行とステータス確認
メインメニューから 4. Execute Migration Commands を選択し、移行コマンドを実行します。
Execute Migration Commands
Execution of Migration commands including disable
commands for triggers constraints, stop/start for queues.
PLEASE TAKE A COMPLETE BACKUP OF THE DATABASE BEFORE MIGRATION
1. Migrate all Schemas
2. Migrate a list of Schemas
3. Migrate CTXSYS Schema
Note: Migrate CTXSYS schema when no other migration process is in progress.
Please enter your option -
Press Return key to return to the menu...
このメニューから 1. Migrate all Schemas を選択します。プロンプトが表示されたら、全スキーマを移行するために Y を入力し、並列プロセス数として 8 を入力します。
Are you sure you want to migrate all schemas[N]: Y
Enter the maximum number of parallel processes for oracledb[8]: 8
Starting the Migration process for all schemas. Please wait...
なお、移行実行前に必ずデータベースの完全バックアップを取得してください。これは画面上にも警告として表示されます。
まとめ
OATMはテーブルスペースの数が少なく管理が容易であるうえ、効率的な空間利用といったメリットをもたらします。この効率性は、他の移行モデルで採用されている辞書管理テーブルスペースではなく、ローカル管理テーブルスペースをサポートしていることに由来します。
OATMはR12バージョンでは必須となりますが、R12へのアップグレード前にOATMへ移行しておくことを推奨します。
また、Real Application Clusters(RAC)を導入する場合、OATMはさらなるメリットをもたらします。
OATM移行ユーティリティの詳細については、Note 248857.1 - OATM Release 11i - Tablespace Migration Utility を参照してください。
コメントやご質問がある場合は、フィードバックタブをご利用ください。
-
Oracle Autonomous Database DedicatedとExadataクラウドインフラストラクチャの徹底解説
本記事では、Oracle® Autonomous Database DedicatedおよびExadata®クラウドインフラストラクチャに関する情報を、複数の公式資料をもとにわかりやすく解説します。 はじめに Oracle Autonomous Database Technical Overviewによると、「Oracle Autonomous Databaseは、クラウドの柔軟性と機械学習の力を組み合わせ、データ管理をサービスとして提供します」とされています。さらに同ドキュメントには、「Oracle Autonomous Databaseには、Oracle ExadataおよびExadata
-
OracleのSQLプロファイルとSQLプラン・ベースラインの違いと活用方法
本記事では、Oracle®におけるSQLプロファイルとSQLプラン・ベースラインの違いを解説し、クエリチューニング時にそれぞれがどのように機能するのかを詳しく説明します。オプティマイザ、プロファイル、ベースラインの関係これら3つの要素は、大まかに以下のように連携して動作します。クエリオプティマイザは、システム統計、バインド変数、コンパイル情報などを基に、クエリ実行に最適なプランを導き出します。しかし、入力情報に不備があると、必ずしも最適とは言えないプランを選択してしまうことがあります。SQLプロファイルには、こうした問題を緩和するための補助情報が含まれています。これによりオプティマイザの判断ミ