11.2.0.3以前のデータベースでOracle DMUを使用するには、データベース・パッチをインストールして、Oracle DMUに必要なサーバー側移行機能をインストールする必要があります。このパッチは、サポートされる構成に対してのみ提供されます。お使いのデータベース・バージョンが一覧にない場合は、サポートされるいずれかのリリースにアップグレードすることを検討してください。11.2.0.3以降のすべてのデータベース・リリースが、IBM z/OSとFujitsu BS2000を除くすべてのプラットフォームでサポートされます。

Oracle DMU 19.1にはJDK 8が必要です。Oracle DMU 2.1にはJDK 6またはJDK 7が必要です。

Oracle DMUは別のマシンからリモートで実行できますが、移行をより迅速に実行してネットワーク・オーバーヘッドを軽減するために、データベース・サーバーと同じホストでローカルに実行することが強く推奨されます。移行中はデータベースを専用サーバー・モードで実行することも推奨されます。

Unicodeへの移行は、特に大規模なデータベースを移行する場合は、非常に多くのリソースを必要とします。十分な構成のハードウェアで移行を実施して、移行のスループットを最大化することが推奨されます。正確なハードウェア要件はデータベースのサイズや目標とする停止時間枠によって異なりますが、100 GB以上のデータベースを移行する場合は、最低でも8つのCPUコアと16 GBのメモリを備えていることが望ましいでしょう。

オラクルでは、ネットワークのオーバーヘッドを最小限に抑えるために、移行するデータベース・サーバーと同じホストでOracle DMUクライアントを実行することを推奨しています。別のホストでOracle DMUクライアントを実行する必要がある場合、CPU速度2 GHz、メモリ4 GBが最低限のハードウェア要件です。システム・リソースを著しく消費する他のジョブを同じ環境で実行しないようにしてください。

Unixベースのプラットフォームでは、~/.dmu_jdkに実行可能ファイルjavaのパスが保存されます。このファイルを削除すると、完全なパスの入力を再度求められます。実行可能ファイルjavaがPATHにある場合、またはJAVA_HOMEが定義されている場合、ユーザーはパスの入力を促されません。Microsoft Windowsでは、Oracle DMUインストール・フォルダにあるファイルdmu\dmu\bin\dmu32.conf（32ビットのJDKの場合）、またはdmu\dmu\bin\dmu64.conf（64ビットのJDKの場合）でJDKのロケーションを編集できます。キーワードSetJavaHomeを検索してください。

無効なデータは通常、クライアント/サーバーのキャラクタ・セット変換を介さないパススルー構成を使用して、データベースのキャラクタ・セットと異なるエンコーティングでデータが保存された結果です。そのようなデータを正しく移行するには、データに使用された実際のエンコーディングを特定する必要があります。Oracle DMUのキャラクタ・セット・タグ付け機能を使用すると、無効なデータを含む列を異なるキャラクタ・セットに再度レンダリングすることによって分析できます。実際のキャラクタ・セットが確定され、列にタグ付けされたら、そのキャラクタ・セットはその後のすべてのデータ・スキャンとデータ変換操作で使用されます。データベースのすべてのデータが別のキャラクタ・セットで保管されていることを確信している場合は、そのキャラクタ・セットをデータ・プロパティ・タブの"Assumed Database Character Set"フィールドに設定できます（WE8MSWIN1252データをWE8ISO8859P1データベースに保管するなど）。

無効なデータは、アプリケーションのバグや、バイナリ・データを文字の列に保管することで生じる可能性もあります。クレンジングのシナリオについて詳しくは、ユーザー・ガイドの第6章を参照してください。

非ASCIIデータをUnicodeに移行する場合、Unicodeはマルチバイトで表現されるため、結果データのサイズが大きくなる場合があります。データの拡張問題は、列制限の超過問題またはデータタイプ制限の超過問題として現れる可能性があります。

• 列のサイズを拡張する
• 列の長さセマンティクスをバイトからキャラクタに変更する
• 保管された値を手作業で短くする
• 変換中にOracle DMUが値を切り捨てることを許可する
• 変換で拡張されるキャラクタを置き換えるように値を編集する
• 大きいデータタイプに移行する

"データタイプ制限の超過"問題には次の選択肢があります。

• 大きいデータタイプに移行する
• Oracle Database 12cでは、拡張データタイプ（VARCHAR2(32767)など）を有効にする
• 保管された値を手作業で短くする
• 変換中にOracle DMUが値を切り捨てることを許可する
• 変換で拡張されるキャラクタを置き換えるように値を編集する

列定義の変更を伴うクレンジング作業は、通常はアプリケーション・コード・ロジックで適切な更新を行う必要があるため、本番環境で実施するのに適していない場合があります。Oracle DMUでは、そのような場合にクレンジング作業をスケジューリングできるため、変更をOracle DMUリポジトリに保存しておき、停止時間枠の変換フェーズ中に実行できます。スケジューリングされたクレンジング作業を定義するには、対象の列の「Cleansing Editor Context」メニューで「Schedule Column Modification…」を選択します。

通常、このリリースのOracle DMUでは、データ・ディクショナリ表に変換可能なデータが存在しても、データ・ディクショナリの変換はサポートされません。ただし、以下は例外です。

• CLOB列 – シングルバイト・データベースでのみ変換が必要です
• XDB.X$QN%、XDB.X$NM%といった名前のバイナリXMLトークン・マネージャ表
• PL/SQLソース・コード：CREATE PROCEDURE、CREATE FUNCTION、CREATE PACKAGE、CREATE PACKAGE BODY、CREATE TYPE BODY、CREATE TRIGGER、およびCREATE LIBRARYのテキスト。タイプ指定（CREATE TYPE）は変換されません
• ビュー定義：CREATE VIEWのテキスト
• 以下の列：
  • SYS.SCHEDULER$_JOB.NLS_ENV – データベース・スケジューラ・ジョブ（DBMS_SCHEDULER）のNLS環境
  • SYS.SCHEDULER$_PROGRAM.NLS_ENV – データベース・スケジューラ・ジョブ・プログラム（DBMS_SCHEDULER）のNLS環境
  • SYS.JOB$.NLS_ENV – レガシー・ジョブ（DBMS_JOB）のNLS環境
  • CTXSYS.DR$INDEX_VALUE.IXV_VALUE – Oracle Textポリシーの属性値
  • 種々のデータベース・オブジェクトに対するユーザー・コメントを含むSYS、SYSTEM、およびCTXSYSスキーマの50以上のさまざまな列

PL/SQLソース・コードとビュー・ソース・テキストは複数の表に保存されます。Oracle DMUでは、ソース・コードとビュー定義の処理中に以下の列がチェックされます。

• SYS.VIEW$.TEXT – ビュー定義テキスト
• SYS.SOURCE$.SOURCE – PL/SQLおよびJavaのソース・コード
• SYS.ARGUMENT$.PROCEDURE$ – PL/SQL引数の定義：プロシージャ名
• SYS.ARGUMENT$.ARGUMENT – PL/SQL引数の定義：引数名
• SYS.ARGUMENT.DEFAULT$ – PL/SQL引数の定義：デフォルト値
• SYS.PROCEDUREINFO$.PROCEDURENAME – パッケージで宣言されたプロシージャと関数の名前
• SYS.IDL_CHAR$.PIECE – PL/SQLの内部表現
• SYS.PLSCOPE_IDENTIFIER$.SYMREP – PL/SQLの内部表現：Oracle Database 11gで新たに導入された表

上記の表と列にある変換可能な文字データは、Oracle DMUでは変換に関する問題として報告されません。データ・ディクショナリの残りの表と列にある変換可能なデータはすべて、スキャン・レポートとMigration Statusタブにおいて変換に関する問題としてフラグ付けされます。フラグ付けされたデータが削除されるまで、データベース変換手順は開始できません。クレンジング操作はデータ・ディクショナリ表では許可されません。

SYSスキーマには、WRI$、WRH$%、WRR$_で始まる名前の表が数多く含まれ、これらが自動ワークロード・リポジトリ（AWR）を構成しています。このリポジトリには、履歴オブジェクト統計に加えて、V$SYSSTAT、V$SQLAREAなど、さまざまな固定ビューに表示される重要なシステム統計のスナップショットが保管されます。

非ASCII文字がオブジェクト名またはSQL文（文字リテラルやコメントなど）で使用される場合、AWR表に取り込まれる場合があります。Oracle DMUスキャンでは、そのような文字は変換可能なデータ・ディクショナリ・コンテンツとして報告されるため、データベースの変換が妨げられます。このデータを完全に取り除くには、SYSDBA権限でSQL*Plusにログインし、以下を実行して自動ワークロード・リポジトリを再作成します。

   SQL> @?/rdbms/admin/catnoawr.sql

   SQL> @?/rdbms/admin/catawr.sql
   SQL> execute dbms_swrf_internal.register_local_dbid;

catawr.sqlスクリプトはバージョン10.2.0.4以前のOracle Databaseには存在しないため、オラクルでは、Oracle Databaseのパッチセット10.2.0.5をインストールしてからAWRコンテンツをパージすることを推奨しています。

Oracle E-Business Suiteスキーマの構造体の変更は、Oracleアプリケーションの不具合を引き起こす可能性があるため、サポートされていません。そのような列は、影響を受ける表が自身の作成したカスタム表である場合、またはOracle Supportに勧められた場合に限り、変更するべきです。

これは予想通りの結果です。クライアント側の大規模なデータタイプを再スキャンするには非常に費用がかかる可能性があるためです。クレンジング・エディタにおけるCLOB、LONG、XMLType列のフィルタリングと強調表示は、表に対する最新のスキャン結果に基づいており、表/列を再スキャンするまでは変更されません。

Oracle DMUでは、各データ・セルは1つのスキャン結果カテゴリにのみ分類されます。無効なバイナリ表現問題がある値は、変換後の長さが列やデータタイプの制限を超える場合でも、1つのカテゴリにのみ分類されます。ユーザーは通常、無効なデータ問題を解決し、データを再スキャンしてから変換を試みると思われています。しかしながら、Oracle DMUを使用すると、無効なデータ問題を無視して列の変換を強行することもできるため、強制的に変換された無効なバイナリ表現を持つ値がさらに切り捨てられる可能性があることに留意する必要があります。列の変換後の最大長プロパティの値と、列とデータタイプ長の制限を比較することで、切捨てが行われたかどうかを確認できます。

Oracle DMUでは、移行リポジトリに収集された行IDを使用して、またはデータベースからフェッチされたときに列値をクライアントで動的に分析して、特定の種類の変換問題がある行を特定できます。後者の方法では、表のごく一部の行のみがフィルタ基準を満たす場合、クレンジング・エディタに表示する十分な行を見つけるには、Oracle DMUは多くの行をフェッチして分析しなければならない可能性があります。パフォーマンスの観点から、表をスキャンして行ID情報をあらかじめ収集し、クレンジング・ツールバーの「User Scan Log to Filter Data」ボタンを有効にしてから、フィルタを適用することが推奨されます。

変換可能なデータの割合が比較的多い表では、Oracle DMUは"CREATE TABLE AS SELECT（CTAS）を使用してデータをコピーする"変換方式を割り当てることができ、これによりパフォーマンスが著しく向上します。CTAS変換方式は、行の行IDが表に保存されない場合があるため、デフォルトでは有効化されていません。アプリケーションによって行IDが保管されない場合、データベース・プロパティ・タブで"Consider CTAS with Row Movement Disabled:"パラメータを"Yes"に設定できます。このように設定すると、最適な変換パフォーマンスを実現するために、Oracle DMUではCTAS変換方式が割り当てられます。

表レベルの変換の進捗状況は、Conversion Progressタブの"View Table Conversion Progress"リンクで監視できます。V$SESSION_LONGOPSビューのステータスと個々のSQL文の実行ステータスに基づき、各表の変換が完了した割合が表示されます。

Oracle DMUが変換フェーズで使用するSQL文のALTER DATABASE CHARACTER SETは、文を実行しているセッションがデータベースにログインしている唯一のユーザー・セッションである場合に限り、正常に終了します。そのため、データベースにログインしている、Oracle DMU自身によって開かれていないユーザー・セッションがある場合は、Oracle DMUは変換を開始する前に警告を発します。SQL*PlusまたはSQL Developerで以下のSQL文を使用して、問題のセッションの詳細について知ることができます。

   SELECT sid, serial#, username, status,

          osuser, machine, process, program
     FROM v$session
    WHERE username IS NOT NULL
      AND program <> 'Database Migration Assistant for Unicode';

まだこの時点では、問題のセッションから切断して変換を再開できます。

このエラーは、Oracle DMUが外部表を読み取ることができなかったことを示しています。外部表のデータファイルが予想されるロケーションで利用できない場合、または誤った形式の場合に発生するエラーです。外部表が使用されるのは、通常は特定の時点に外部ソースからデータをロードする場合に限られるため、データファイルが利用できないのは珍しいことではありません。データファイルが存在することを確認してスキャンを再試行できます。あるいは、このエラーが後続の移行操作を妨げることはないため、エラーを無視しても構いません。

Database PropertiesタブのScanningサブタブにあるプロパティ"Report U+FFFD as an invalid character"の値によって、Unicodeのデフォルト置換文字U+FFFD（AL32UTF8とUTF8のバイト・シーケンス0xEF 0xBF 0xBD）がOracle DMUでどのように解釈されるかが決定されます。プロパティ値が"Yes"の場合、文字は無効なデータとして扱われます。これはデフォルトの動作です。データにこの文字が存在するということは、通常はこのデータが、本当のキャラクタ・セットに適切にタグ付けされなかった一部の入力値のキャラクタ・セットを変換した結果であることを示しているためです。文字U+FFFDを内部処理のために使用しており、Oracle DMUに無効と報告して欲しくない場合は、プロパティ値を"No"に変更します。

Oracle DMUでは、最新のスキャン結果に基づきデータの準備状況ステータスが決定されます。クレンジング作業の適用後、影響を受けるデータベース・オブジェクトを必ず再スキャンして、変更の影響を確認し、データ問題が適切に解決されたことを検証してください。

Oracle DMUの外部で表のクレンジングを行い（SQL DeveloperまたはSQL*Plusで列のサイズを拡張するなど）、その変更がOracle DMUに反映されていない場合、「Migration」メニューで「Refresh DMU Repository...」をクリックしてOracle DMUリポジトリをリフレッシュします。

Oracle DMUには変換のロールバック機能そのものはありませんが、変換エラー処理機能が組み込まれているため、変換プロセスがエラー状態によって中断されても、問題を解決し、変換を再開できます。データベースを変換前の状態にロールバックする必要がある場合は、バックアップからリストアするか、フラッシュバック・データベース機能を使用します。

注：フラッシュバック・データベース機能は、ALTER DATABASE CHARACTER SET（ADBCS）文で機能するかどうかはテストされていません。この機能の設計はADBCSと競合しないはずですが、変換プロセスでADBCSがすでに実行されている場合、つまり、問合せSELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET'によってターゲット・キャラクタ・セットが表示される場合は、バックアップからのリストアを選択することが推奨されます。利用できるバックアップがなく、ADBCS後にフラッシュバック・データベースを試さざるを得ない場合は、フラッシュバック・コマンドの後、直ちにインスタンスを再起動してください。フラッシュバック・データベース、および変換プロセスを開始する前の要件について詳しくは、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

リポジトリのリフレッシュやスキャン前の分割しきい値の計算など、通常は速いOracle DMU操作が異常に時間がかかったり、ハングしたりする場合、データベース初期化パラメータoptimizer_features_enableが古いデータベース・バージョンに設定されていないことを確認します。たとえば、このパラメータが9.2.0に設定されていると、Oracle DMUの特定の内部問合せで最適ではない実行計画が使用されることが分かっています。

Oracle DMUはUnix系オペレーティング・システムで起動されると、順に以下のロケーションでJDKを検索します。

• ファイルdmu/dmu/bin/dmu.confのSetJavaHomeディレクティブで指定されたロケーション
• $APP_JAVA_HOME
• $OIDE_JAVA_HOME
• dmu/jdk
• dmu/../jdk
• $JAVA_HOME
• /usr/java/jdk1.6.*（最新バージョンを使用）
• 以前ユーザーが指定し、ファイル$HOME/.dmu_jdkに保存されたロケーション
• ユーザーがリクエストしたロケーション

Oracle DMUはMicrosoft Windowsオペレーティング・システムで起動されると、順に以下のロケーションでJDKを検索します。

• ファイルdmu\dmu\bin\dmu32.conf（dmu32.exeまたはdmuW32.exeから起動された場合）、もしくはファイルdmu\dmu\bin\dmu64.conf（dmu64.exeまたはdmuW64.exeから起動された場合）のSetJavaHomeディレクティブで指定されたロケーション
• dmu\..\jdk
• ユーザーがリクエストしたロケーション（dmu32.confまたはdmu64.confのSetJavaHomeの下に保存されます）

Oracle DMUは各ロケーションで、ファイルbin/javaおよびjre/bin/java（Windowsの場合はjava.exe）が存在するかどうかを確認します。

上記のロケーションのいずれかに誤ったバージョンのJDKがあり、そのバージョンがOracle DMUによって選択されると、エラーが発生します。この問題を解決するには、ファイルdmu/dmu/bin/dmu[32|64].confを変更し、正しいJDKインストールのパスをSetJavaHomeディレクティブに追加します。

データベースのサイズのみに基づき移行の停止時間枠を推定することは通常は不可能です。その他の重要な要素として、データの変換準備状況、変換が必要なデータの割合（文字以外のデータタイプと非CLOB列の7ビットASCIIデータは変換が不要です）、CLOB列のサイズ（CLOBは通常はCHAR/VARCHAR2よりも変換費用が高くなります）などが挙げられます。

変換時間をより正確に見積もる最適な方法は、移行するデータベースのクローンを作成し、そのクローンを制御されたテスト環境でエンド・ツー・エンドのプロセスから実行することです。この方法により、どのようなデータ変換問題に対処する必要があるか、および見込まれる変換時間枠をデータ変換前に把握できます。

この問題はバグ#19533216で報告されています。Oracle Database 12.1.0.2のPDBでは、バイナリ・データがある行がデータ・ディクショナリ列SYS.BOOTSTRAP$.SQL_TEXTに含まれている場合があります。Oracle DMU 2.0では、このデータは無効な表現があると報告されるため、PDBのキャラクタ・セット変換が妨げられます。このデータの存在は、Oracle Database側からはバグと認識されません。

この問題を解決するには、Oracle DMUを最新バージョンにアップグレードします。Oracle DMU 2.1以降にこの問題の修正が含まれています。