| Oracle® Database Migration Assistant for Unicodeガイド リリース2.0 E59465-03 |
|
 前 |
 次 |
この章では、Database Migration Assistant for Unicode (DMU)の概要を示し、このユーティリティを使用してキャラクタ・セットを移行する際の基本的なワークフローについて説明します。
この章は次の項で構成されています。
Database Migration Assistant for Unicodeを使用する手順は、次のとおりです。
要件を確認します。
環境がDMUを正常に使用するための要件を満たしていることを確認します。
「データベース要件の概要」、「Javaランタイム要件の概要」および「DMUセキュリティの考慮事項の概要」を参照してください。
DMUのインストール、メイン・ユーザー・インタフェースの確認、データベース接続の作成、ユーザー・インタフェースの確認、DMUリポジトリのインストールなど、基本的な準備タスクを実行します。
「DMUのインストール」、「データベース接続の作成」、「移行リポジトリのインストール」および「DMUユーザー・インタフェースの概要」を参照してください。
データベースをスキャンして、Unicodeへの正常な移行を妨げる可能性のある問題を検出します。
「データベースのスキャン」を参照してください。
スキャン・フェーズ中に検出した潜在的な問題のあるデータベースをクレンジングします。
「データのクレンジング」を参照してください。
データベースをUnicodeに変換します。
「データベースの変換」を参照してください。
データベースを検証して、キャラクタ・セットがUnicodeとなったこと、および例外データが含まれていないことを確認します。
「Unicodeとしてのデータの検証」を参照してください。
DMUのホームページから、データベースをUnicodeに移行する際の基本タスクを実行できます。
DMUホームページ
このページは、DMUアイコンをクリックするとロードされます。「DMUユーザー・インタフェースの概要」を参照してください。
オンライン・ヘルプ
各ページ上部に表示されている「ヘルプ」リンクをクリックすると、状況依存のオンライン・ヘルプにアクセスできます。任意のヘルプ・ページで「ヘルプ」をクリックするか、[F1]キーを押します。
ナビゲーション
DMUには次のようなナビゲーション機能があります。
サブページのリンクはページの最上部にあります。これらのリンクから、管理タスクが個々のカテゴリに分類された様々なサブページに移動できます。
詳細の増加レベルを提供するドリルダウン・リンク。
この項では、Database Migration Assistant for Unicodeを使用する際に考慮する必要のある要件と制約事項、およびこのユーティリティを開始するために実行する必要のある最初の手順について説明します。
DMUでサポートされるデータベースは、特定の要件を満たしている必要があります。要件は次のとおりです。
Oracle Databaseのリリースは10.2.0.4、10.2.0.5、11.1.0.7、11.2.0.1またはそれ以上である必要があります。最新バージョンのDMUリリース・ノートで、データベースにインストールする必要のある追加のパッチがないか確認します。また、リリース・ノートには、サポートされている追加のデータベース・リリースが適切なパッチとともにリストされています。
データベース・キャラクタ・セットはASCIIベースである必要があるため、たとえば、EBCDICベースのプラットフォームIBM z/OSおよびFujitsu BS2000で実行されているデータベースはサポートされません。
SYS.DBMS_DUMA_INTERNALパッケージをデータベースにインストールする必要があります。
このパッケージは、データベース・インストールの一部として使用可能です。これは、データベースのOracleホームからスクリプト?/rdbms/admin/prvtdumi.plbを実行することにより、手動で作成する必要があります。このスクリプトを実行するには、SYSDBAとしてログインする必要があります。
Oracle Database Vaultが有効になっている状態でのDMUの動作は保証されていないため、移行プロセスの開始前にOracle Database Vaultを無効化する必要があります。
データベースは読取り/書込みモードで開く必要があります。
この他に、DMUで変換するデータベースに関連する要件もあります。これらの要件を満たしていなくても、DMUを使用してデータベースのスキャンとクレンジングを行うことはできます。要件は次のとおりです。
DBMS_RULE、DBMS_DATA_MINING、DBMS_WMなどの標準のPL/SQLパッケージにより作成されたオブジェクトを含むすべてのデータベース・オブジェクトは、ASCIIキャラクタ・セットの標準文字のみを使用した名前を付ける必要があります。同様に、CHECK制約の式、仮想列およびその他のデータベース機能はそれらの文字のみを使用して指定する必要があります。つまり、データベースのデータ・ディクショナリに非ASCII文字を含めることはできません。ただし、データ・ディクショナリの文字データの中には非ASCII文字が許可されているデータもあります。
詳細は、「データ・ディクショナリ表の変換」を参照してください。
事前定義済システム・ワークスペースおよび特定の事前定義済Oracle Applicationsワークスペースを除くOLAPアナリティック・ワークスペースをデータベースに含めることはできません。
フラッシュバック・データ・アーカイブをデータベースに含めることはできません。
変換するデータを読取り専用またはオフラインの表領域に格納することはできません。
クラスタ・キー列とパーティション化キー列はいずれも、文字長セマンティクスを使用して定義できません。
ごみ箱の中の表に変換可能データを含めることはできません。
参照パーティション化キー列に変換可能データを含めることはできません。
DMUのこのリリースは、Oracle Database 12cでのプラガブル・データベース(PDB)の移行をサポートします。コンテナ・データベース(CDB)内でDMUを使用してPDBを変換するには、ルート・コンテナのキャラクタ・セットが移行対象のキャラクタ・セットと同じである必要があります(AL32UTF8またはUTF8)。この要件を満たしていない場合でも、PDBのスキャンおよびクレンジングにDMUを使用できますが、変換操作はできません。
DMUのこのリリースでは、Oracle E-Business SuiteデータベースおよびPeopleSoftデータベースのUnicodeへの移行もサポートします。移行ワークフローは、標準データベース・インスタンスのワークフローとほとんど同じです。OracleではOracle E-Business SuiteまたはPeopleSoftアプリケーションのデータベース・スキーマの変更をサポートしていないため、そのような変更を必要とするデータ・クレンジング・アクションは実行しないように注意してください。さらに、DMUのこのリリースでは、PeopleSoftアプリケーションの9.0より古いバージョンまたはPeopleToolsの8.48より古いバージョンでのデータベースの移行はサポートしません。
DMUを実行しているホスト上で、Java JDK 1.6以降が使用可能になっている必要があります。DMUの起動時に、Javaランタイム実行可能ファイル(プラットフォームによってjava.exeの場合とjavaの場合があります)の場所を指定するように求められます。
Java SEダウンロード・ページ(http://www.oracle.com)から、Intel x86、Intel x64、Intel ItaniumおよびSPARCプロセッサに対応する、Linux、SolarisおよびMicrosoft Windowsオペレーティング・システム用の最新のJava JDKをダウンロードできます。ご使用のプラットフォームに対するインストール手順については、Oracle Technology Networkの関連ドキュメント・ページ(http://www.oracle.com/technetwork/java/javase/downloads/index.html)を参照してください。
これ以外のプラットフォーム(Hewlett-Packard HP/USやIBM AIXなど)については、ベンダーのWebサイトを参照してください。
このリリースのDatabase Migration Assistant for Unicodeでは、データベースに接続するデータベース・ユーザーにSYSDBA権限があることが必要です。
このため、ユーザーは移行リポジトリ・データベース・オブジェクトに対する権限を他のデータベース・ユーザーに付与してはいけません。これは、名前がDUM$またはDBMS_DUMAで始まるすべてのオブジェクトに適用されます。
DMUが共有ワークステーションまたはサーバーにインストールされている場合、所有しているオペレーティング・システム・ユーザーのみがインストール済ファイルを変更できるようにします。このセキュリティ手段は、DMUとデータベースの接続にSYSDBA権を使用することにより、悪質なユーザーによる実行可能ファイルの変更を未然に防ぐものです。変更されたユーティリティでは、管理権限を使用して予期しないSQL文が実行されると、データベース・セキュリティが損われることがあります。
移行プロセスを開始する前に、DMUを適切に設定できるように、データベースおよびアプリケーションによるデータベースの使用に関連する次の情報を収集します。
データベースはDMUでサポートされているか。
データベース・ソフトウェアのバージョンがDMUによりサポートされていることを確認します(「データベース要件の概要」を参照)。データベースがインストールされているプラットフォームは、ASCIIベースのプラットフォームである(IBM z/OSまたはFujitsu BS2000ではない)必要があります。データベースにOracle Database Vaultがインストールされていない必要があります。
ターゲット・キャラクタ・セットは何か。
移行のターゲット・キャラクタ・セットをAL32UTF8にするかUTF8にするかを決定する必要があります。Unicode規格のUTF-8エンコーディング・フォームの適切な実装であるAL32UTF8を選択することをお薦めします。DMUでは、Oracle 8i Clientライブラリに基づいてデータベース・クライアント・ソフトウェアをサポートする必要のあるデータベース、またはUTF8での動作は保証されているがAL32UTF8での動作は保証されていないアプリケーション(Oracle Applicationsリリース11iなど)をサポートする必要のあるデータベースを、古いキャラクタ・セットUTF8に移行することをサポートしています。UTF8キャラクタ・セットは、その名に反し、Unicode規格のCESU-8互換性エンコーディング・フォームの実装です。CESU-8とUTF-8の違いは、補助文字(Unicodeコード・ポイントU+010000以上の文字)の格納方法のみです。Oracleでは一般に、UTF8の定義は新しいUnicode規格バージョンにあわせて更新されませんが、AL32UTF8の定義は更新されます。
データベースに格納できる言語およびキャラクタ・セットは何か。
キャラクタ・セット・エンコーディングおよびOracleデータベース内の文字記憶域の性質上、列値の特定のバイト・シーケンスがどの言語のどのキャラクタ・セットを表すかを自動的かつ正確に認識することは不可能です。DMUスキャン・プロセスによって、この値の宣言済キャラクタ・セットの文字値に無効なバイトがあるかどうかがわかります。宣言済キャラクタ・セットのほぼすべてのバイトが、0x98以外のすべてのバイトを定義するなんらかの文字(CL8MSWIN1251のケースなど)のシングルバイト・コードに割り当てられている場合、スキャン・プロセスでは、このキャラクタ・セットでエンコードされていると宣言されたバイト・シーケンスはほぼすべて有効であると判断されます。このため、アプリケーションがパススルー構成を使用してデータベース・キャラクタ・セットとは異なるキャラクタ・セットのデータと解釈されたデータをデータベースに格納していても(「データの無効なバイナリ記憶域表現」を参照)、DMUでは無効なコードが検出されず、データの実際の(アプリケーション)キャラクタ・セットと宣言済データベース・キャラクタ・セットが一致していないことが通知されない可能性があります。このため、アプリケーション開発者やアプリケーション管理者に問い合せるなどして、データベースに格納される可能性が高い言語またはキャラクタ・セットを調査することが非常に重要になります。これは、必要に応じてDMUによる自動分析を補完する目的でデータベースの内容を手動で分析する際に役立ちます。
どの列に外国語のデータが含まれる可能性があるか。
データベースには主に1言語のみのデータが含まれ、外国の顧客名や住所など数個の表列にのみ他言語が含まれる場合、前述のリスト項目で収集した情報の分析後にパススルー構成で格納される無効なデータが存在する可能性が高いと判断したら、このような列をすべてリストしておくと、無効なデータを手動で検索することが容易になります。
どの文字列にバイナリ・データが含まれる可能性があるか。
アプリケーションによっては、パススルー構成でデータベースに接続し、バイナリの性質を持つデータ(データベースの透過的データ暗号化機能を使用せずに暗号化されたテキスト、イメージ、ワープロのバイナリ形式のテキストなど)を文字列に格納する場合があります。このようなアプリケーションのリストをアプリケーション開発者または管理者から取得すると、データベースの内容を分析する際に役立ちます。
収集した情報を使用して無効なバイナリ表現の問題を解決する方法は、「クレンジング・シナリオ3: 無効な表現の問題のクレンジング」を参照してください。
データベースの実際のキャラクタ・セットは何か。
データベースのキャラクタ・セットが実際に、宣言済データベース・キャラクタ・セットではなくデータベースに接続するクライアントの特定の共通キャラクタ・セットで解釈されるかどうかを判断します。これにより、データベースをUnicodeに変換できるかを確認するためにDMUで実行する分析の効率と精度を高めることができます。
データベースの実際のキャラクタ・セットが宣言済データベース・キャラクタ・セットと異なるかどうかを判断する1つの方法は、次の特性を探すことです。
データベース(宣言済)キャラクタ・セットは、US7ASCII、WE8ISO8859P1またはWE8ISO8859P15です。
NLS_LANGクライアント設定で宣言されているクライアント・キャラクタ・セットは、データベース・キャラクタ・セットと同じです。NLS_LANGが指定されていない場合、クライアント・キャラクタ・セットはデフォルトでUS7ASCIIに設定されます。NLS_LANGは、OCI APIを介して接続するCまたはC++クライアントにのみ影響を与えます。JDBC APIを介して接続するJavaクライアントは、常にUTF8クライアントになります。
すべてのデータベース・クライアント・ソフトウェアはMicrosoft Windowsプラットフォーム上で実行され、ANSIコード・ページとも呼ばれるWindowsキャラクタ・セットの1つで動作します。このキャラクタ・セットは、米国および西ヨーロッパ・バージョンにはWE8MSWIN1252、中央ヨーロッパ・バージョン(ポーランド語など)にはEE8MSWIN1250、キリル・バージョン(ロシア語など)にはCL8MSWIN1251、アラビア・バージョンにはAR8MSWIN1256のように、Windowsの言語バージョンに依存します。
すべてのクライアントに共通するこのMicrosoft Windowsキャラクタ・セットが、特定された実際のデータベース・キャラクタ・セットです。
データベースが適切なキャラクタ・セット構成で使用されている場合、つまりNLS_LANG設定が常にデータベース・クライアントの実際のキャラクタ・セットに正しく一致している場合、データベースの実際のキャラクタ・セットはその宣言済キャラクタ・セットです。
データベースの接続情報は何か。
DMUを使用してデータベースを移行するには、SYSDBA権限および必要な接続資格証明(ユーザー名とパスワード)が必要です。移行するデータベースがOracle Database 12cのプラガブル・データベース(PDB)の場合は、ローカルPDBでSYSDBA権限のあるユーザーとして接続することで、スキャン操作およびクレンジング操作をできますが、データベースをUnicodeに変換するには、SYSユーザーまたはローカルPDBおよびCDBの両方でSYSDBA権限のある共通ユーザーで接続する必要があります。
データベース・サーバーのホスト名またはIPアドレス、データベース・リスナーが接続リクエストをリスニングするポート番号、およびデータベースのサービス名を知っている必要があります。パフォーマンス上の理由で、共有サーバー機能を使用しない専用接続が構成されているサービスに接続することをお薦めします。
前述の情報の収集が完了したら、DMUをインストールできます。
|
関連項目: セキュリティの考慮事項の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
基本的な準備手順は次のとおりです。
DMUのインストール前には必ず、使用するDMUバージョンに使用可能な現行リリース・ノートをダウンロードしてください。DMUは、データベース・サーバー・ホストか、信頼できる高速なローカル・エリア・ネットワークでデータベース・サーバー・ホストに接続されたワークステーションで実行することをお薦めします。
DMUをインストールする手順は、次のとおりです。
DMUにはインストーラは付属していません。インストール・ファイルを任意のディレクトリ内に解凍して、ユーティリティをインストールします。
DMUをインストールするには、ダウンロードしたアーカイブ・ファイルを、DMUを実行するホスト上の任意のディレクトリに解凍します。
アーカイブ・ファイルを解凍した後、DMUファイルへの書込みが自分と他の認可済オペレーティング・システム・ユーザーにのみ許可されていることを確認してください。DMUホストへのアクセス権を持つ非特権ユーザーがDMUファイルを変更して、後からSYSDBA資格証明でDMUが起動されたときに任意のSQL文が実行される可能性があるため、このことは非常に重要です。このようなSQL文はデータベース・セキュリティを損う可能性があります。
DMUのインストール後、DMUで移行プロセスを行うデータベースを初期化します。
分析または移行するデータベースへの接続を作成する必要があります。
データベース接続を作成する手順は、次のとおりです。
DMUを使用してデータベース移行を開始するには、あらかじめこのツールにデータベース接続の詳細を提供する必要があります。このためには、ナビゲータ・ペインで「データベース」ノードを右クリックしてコンテキスト・メニューを開くか、メニュー・バーから「ファイル」メニューを開き、「データベース接続の作成」を選択します。図2-1に示すような新規データベース接続の作成ダイアログ・ボックスが表示されます。このダイアログで、ログインID、パスワード、ホスト名、ポート番号、データベース・サービス名などの接続詳細を入力します。
接続を定義する次の情報を入力します。
接続名
接続に、DMUの接続先のデータベースを簡単に特定できるようなわかりやすい名前を付けます。
ユーザー名
データベースでの認証に使用するデータベース・ユーザー名を指定します。このリリースのDMUでは、ユーザーがSYSDBA権限を持っている必要があります。
パスワード
データベース・ユーザーのパスワードを指定します。
ロール
このDMUリリースでは、SYSDBAロールのみがサポートされています。
ホスト名
データベース・ホストのDNS名またはIPアドレスを指定します。
ポート
Net Services (TNS)リスナーがデータベース接続リクエストをリスニングするTCP/IPポートを指定します。
サービス名
接続先のデータベース・インスタンスのサービス名を指定します。
パスワードの保存チェック・ボックスを選択すると、指定したパスワードが他の接続詳細とともに、ユーザー・ディレクトリ内の構成ファイルに不明瞭化されて保存されます。不明瞭化は元に戻せる操作なので、この機能は、本番データを含まないテスト・データベースや非常に保護の度合が高いホストに対するパスワードのみ使用してください。プリファレンスと接続情報が格納された構成ファイルの読取りが自分のみに許可されていることを確認してください。UNIXプラットフォームの場合、これらのファイルは$HOME/.dmu/ディレクトリにあります。Microsoft Windowsの場合、これらのファイルは%USERPROFILE%\Application Data\DMU\ディレクトリにあります。そうでない場合、データベースのセキュリティが損われることがあります。パスワードの保存チェック・ボックスを選択しない場合、接続を開くたびにパスワードを入力するように求められます。
「接続のテスト」をクリックすると、接続をテストできます。接続を確立できる場合、「ステータス」ボックスに「成功」と表示されます。それ以外の場合、接続の問題を説明するエラー・メッセージが表示されます。「保存」をクリックすると、接続が作成されて、ダイアログ・ボックスが閉じます。
接続が作成されると、その接続名の新しいデータベース・ノードがナビゲータ・ペインに追加されます。ノードを開いてデータベースに接続するには、ノードを右クリックしてコンテキスト・メニューから「接続」を選択します。DMUでは一度に1つの接続しか開くことができないため、新しい接続を開く前に、DMUによって現在開いている接続を閉じる許可を求められます。
ユーザー名やホスト名などの既存の接続の詳細を変更するには、対応するデータベース・ノードを右クリックして、コンテキスト・メニューから「接続の詳細」を選択します。表示されるデータベース接続の変更ダイアログ・ボックスの要素は、データベース接続の作成ダイアログ・ボックスの要素と同じです。
接続の名前を変更するには、「接続の名前の変更」を選択し、接続を削除するには、対応するデータベース・ノードのコンテキスト・メニューから「削除」を選択します。データベース・ノードのコンテキスト・メニューで「接続の詳細」、「接続の名前の変更」および「削除」メニュー項目が使用可能になるのは、ノードが現在接続されていない場合のみです。
DMUでは、リポジトリを使用して移行の各ステップに必要な情報を管理します。リポジトリの内容には、処理対象のオブジェクト、エラーのフラグが付いたデータの詳細、スキャンや変換の進行状況などの項目が含まれます。データベースに移行リポジトリがない場合、そのデータベースに接続するたびに自動リポジトリ作成ウィザードが開始されます。このウィザードはDMUユーザー・インタフェースから開始することもできます。
移行リポジトリをインストールする手順は、次のとおりです。
初めてデータベースに接続すると、DMUではリポジトリをインストールするように要求されます。リポジトリのインストールを要求されない場合は、使用するデータベースを右クリックして「DMUリポジトリの構成」を選択することにより、リポジトリをインストールできます。また、移行メニューから「DMUリポジトリの構成」を選択することもできます。いずれの場合も、リポジトリ構成ウィザードが表示されます。図2-2に、その表示画面を示します。
ウィザードの最初のページで選択できる項目は、「移行モードでリポジトリをインストールする」のみです。これを選択した後、「次へ」をクリックします。
「次へ」をクリックすると、リポジトリ構成ウィザードの2番目のページが表示されます。図2-3「リポジトリ構成ウィザード - タスクの詳細」に、このページの例を示します。
ここでは、移行のターゲット・キャラクタ・セットを選択します。通常推奨されるキャラクタ・セットであるAL32UTF8か、Oracle Applications 11iなどの特定のアプリケーションとの互換性のために必要になることがあるUTF8のいずれかを選択できます。キャラクタ・セットを選択した後、「次へ」をクリックします。図2-4「リポジトリ構成ウィザード - 表領域の選択」が表示されます。
3ページ目で、リポジトリをインストールする表領域を選択できます。デフォルトの表領域はSYSAUXです。移行リポジトリには個別の空の表領域を使用することをお薦めします。これにより、本番表領域のフラグメンテーションを回避できます。選択した表領域の使用可能な空き領域が、リポジトリの内容を格納するのに十分な大きさであることを確認します。リポジトリに必要な領域の大きさは、スキャンで選択した行識別子収集レベルと、データベース内の変換が必要な文字データや変換可能性の問題がある文字データの量によって大きく変わるため、リポジトリに必要な領域を見積もることは困難です。このため、必要に応じて表領域が拡大されるように、リポジトリ表領域のデータ・ファイルの自動拡張オプションを有効にすることをお薦めします。ディスク領域全部が使用されることがないように、データ・ファイルの最大サイズ制約を定義します。
DMUリポジトリをインストールするためには、表領域に8K以上のブロック・サイズが必要です。
「完了」をクリックして、リポジトリをインストールします。
リポジトリをインストールした後は、データの作業を開始できます。
データベース接続が確立されると、DMUメイン・ウィンドウのクライアント・ペインに移行ステータス・タブが表示されます。移行プロセスの進行状況は、このタブの情報を参照して追跡できます。このタブには、リポジトリのインストール、データベースの問題のスキャン、検出された問題の解決、およびデータの変換といったDMUプロセスの重要なマイルストンが表示されます。移行ステータス・タブには、各マイルストンの完了ステータスが表示され、推奨される次のアクションが示され、正常な変換を妨げていた問題が一覧表示されます。この情報はすべて、ワークフローの進行状況を示すものです。定期的に移行ステータス・タブに戻って、Database Migration Assistant for Unicodeによる移行プロセスの説明を参照してください。
図2-5に、移行ステータス・タブの内容の例を示します。移行ステータス・タブには、移行リポジトリのインストール、データベースのスキャン、移行問題の解決、およびデータベースの変換という主要な4つの移行ステップがそれぞれ説明されます。このタブには各ステップのステータスが表示され、推奨される次のアクションが示されます。「詳細」リンクをクリックすると、表示された情報を拡張するヘルプ・ページが開きます。
ステップ1: 移行リポジトリのインストール・セクションの「ステータス」領域に、接続されたデータベースに移行リポジトリが含まれているかどうかが示されます。また、インストールされているリポジトリが互換性のないバージョンであることも報告されます。適切なバージョンのリポジトリをインストールするまでは、以降の移行プロセス・ステップを続行できません。次のアクション領域に示されたアドバイスに従います。この領域のテキストがリンクになっている場合、リンクをクリックすると推奨アクションが開始されます。「移行リポジトリのインストール」を参照してください。
「ステップ2: データベースのスキャン」の「ステータス」領域では、データベースのスキャン・ステータスが報告されます。データベースの状況は次のいずれかです。
未スキャン - 移行リポジトリの作成後もスキャンはまだ実行されていません
スキャン中 - 現在、データベースのスキャンが実行されています
一部スキャン済 - データベースの一部のみのスキャンが完了しています
すべてスキャン済 -データベース内のすべての表に有効なスキャン結果が存在しています
無効化された結果を含む - 最後のスキャン以降に表の構造が変更されたため、一部の表のスキャン結果が無効化されています
データベースの一部がスキャンされていない場合、「データベースのスキャン」を参照し、スキャン結果が存在しないか無効であるすべての表をスキャンします。
ステップ3: 移行問題の解決セクションの「ステータス」領域に示された情報に、データベースの内容の実際の変換を開始する前に解決する必要のある問題のリストが含まれている場合があります。「未解決の変換可能性の問題が見つかりました」というテキストの左側にあるプラス(+)アイコンをクリックすると、問題が表示されます。これらの問題は、警告として、または障害となっている問題として分類されます。
黄色のマークが付いた警告は、場合によって変換中に問題が発生するデータベースの特徴および構成の詳細を説明するものです。DMUでは、これらの問題が発生する確率を自動的に分析することはできません。データベース変換のパフォーマンスを低下させる可能性があるが、他の影響が現れる可能性があるためにDMUで変更できないデータベースの構成詳細を説明する警告もあります。表示される可能性のある警告は次のとおりです。
データベース内にユーザー定義のOLAPアナリティック・ワークスペースが存在します。
データベースはスタンバイ・データベースです。
データベース内に変換可能データを含む外部表が存在します。
データベース内に変換可能な主キー・ベースのオブジェクト識別子(OID)が存在します。
現在の設定では、行の移動が無効になっている表に対してCTAS変換方法を使用することはできません。
データベースまたは表領域のFORCE LOGGINGモードをオフにすると、変換のパフォーマンスが向上する可能性がありますが、それによってメディア・リカバリを実行できなくなることがあります。
表の行移動オプションが有効になっていないため、一部のパーティション表の変換がエラーORA-14402により失敗しました。
一部の表が変換から除外されました。
一部の列にある変換可能性の問題は無視され、結果のデータにかかわらず列は変換されます。
一部の警告を無視して変換を開始することもできますが、必ずすべての警告の意味を理解してください。
赤色で示された障害となっている問題は、DMUでの変換フェーズの開始を妨げている問題です。これらを無視すると、データベース内に問題が発生することがわかっています。障害となっている問題をすべて解決しないと、データベースの変換に進むことはできません。すべての問題が解決されると、ステップ3: 移行問題の解決セクションの「ステータス」領域に「未解決の変換可能性の問題は見つかりませんでした」と表示され、変換を続行しても問題ないとみなされます。
ステップ4: データベースの変換セクションの「ステータス」領域に、データベース変換が開始されたかどうかが示され、続いて正常に完了したかどうかが示されます。
移行のステータスを表示する手順は、次のとおりです。
クライアント・ペインの移行ステータス・タブをクリックします。
DMU外部でデータベースを変更して変換可能性の問題の一部を解決した場合は、「再テスト」をクリックすると、DMUでデータベースが再チェックされてステータス情報が更新されます。
このタブを開くには、移行メニューから「移行ステータス・パネル」を選択します。
図2-6に、DMUユーザー・インタフェースのメイン・ウィンドウのデフォルト・レイアウトを示します。ウィンドウの一番上にメニュー・バーとツールバーが表示され、一番下にステータス・バーが表示されます。これ以外のウィンドウ領域は、複数のペインに分かれています。
ウィンドウの左上隅のナビゲータ・ペインには、DMUで処理されるデータベース・オブジェクトのツリーが表示されます。ツリー内のノードの最初のレベルは、DMUが接続可能なデータベースを表しています。開いている接続に1つのみのデータベース・ノードを関連付けることができます。接続の詳細は、「データベース接続の作成」を参照してください。
現在接続が開いているデータベース・ノードを展開すると、移行プロセスに関連するデータベースに含まれるスキーマ、表および列のサブツリーが表示されます。関連する列とは、文字データが含まれるためにUnicodeキャラクタ・セットへの変換時にキャラクタ・セット変換が必要となる列のことです。DMUでの処理方法が違うため、データ・ディクショナリを構成する事前定義済Oracleスキーマは1つにまとめられ、それぞれデータ・ディクショナリ・グループ・ノードの下に表示されます。その他のスキーマは、アプリケーション・スキーマ・グループ・ノードの下に表示されます。同様に、スキーマ内の表はマテリアライズド・ビューとして「マテリアライズド・ビュー」グループ・ノードの下にまとめられ、それ以外の表は「表」グループ・ノードの下にまとめられます。
ナビゲータ・ツリーのノード名の左側にステータス・アイコンが表示されることがあります。表2-1に、特定のノード・タイプに使用できるアイコンとその意味を示します。
ウィンドウの右上隅にあるクライアント・ペインは、移行プロセスで様々なタブが開かれる領域です。これらのタブには、オブジェクトのプロパティ、スキャン結果、クレンジング・ツール、およびタスクの進行状況ステータスが表示されます。この章の以降の各項で、すべてのタブについて説明します。DMUの起動後、データベースに接続するまでは、クライアント・ペインにはDMUの関連情報の様々なソースへのリンクが集まった「開始ページ」のみが表示されます。
ウィンドウの左下部分にある「プロパティ」ペインには、ナビゲータ・ペインまたはデータベース・スキャン・レポートで最後にクリックしたノードの選択済プロパティが表示されます(「データベースのスキャン」を参照)。表示されるプロパティは、ノードのタイプによって異なります。
ウィンドウの右下部分にあるログ・ペインには、移行プロセス中にDMUによって報告されたエラー・メッセージおよび警告メッセージが表示されます。
DMUのメイン・ウィンドウのレイアウトは、ペインおよびタブを新しい位置にドラッグすることでカスタマイズできますが、カスタマイズしたレイアウトが次のプログラム実行時まで保持されることはありません。
表2-1 Database Migration Assistant for Unicodeのアイコン
| アイコン | 列ノード | 表、スキーマ、データベースおよびグループ・ノード |
|---|---|---|
|
アイコンなし |
列は一度もスキャンされていません。 |
表/スキーマ/データベース/グループ内の列はいずれも一度もスキャンされていません。 |
|
チェック・マーク  図dumag001f.gifの説明 |
列が正常にスキャンされ、問題は見つかりませんでした。 |
表/スキーマ/データベース/グループ内のすべての列が正常にスキャンされ、問題は見つかりませんでした。 |
|
赤い円の中の白いX  図dumag001d.gifの説明 |
列をスキャンするための最新の試行に失敗しました。 |
表/スキーマ/データベース/グループの1つ以上の列をスキャンするための最新の試行に失敗しました。 |
|
警告を示す黄色い三角形  図dumag001a.gifの説明 |
列は正常にスキャンされましたが、いくつかの変換可能性の問題が見つかりました。 |
表/スキーマ/データベース/グループ内のすべての列は、正常にスキャンされたか、一度もスキャンされていないか、またはスキャンされた列に変換可能性の問題が見つかったためにスキャン結果が無効化されています。 |
|
斜線入りの赤い円  図dumag001e.gifの説明 |
列はすでにスキャンされていますが、その列を含む表が変更されたか、クレンジング・アクションが適用されたために、スキャン結果が無効化されています。 |
表/スキーマ/データベース/グループ内の1つ以上の列のスキャン結果が無効化されており、この表/スキーマ/データベース/グループ内のその他の列はいずれも一度もスキャンされていません。 |
|
拡大鏡  図dumag001b.gifの説明 |
適用されません。 |
表/スキーマ/データベース/グループ内の一部の列は正常にスキャンされ、問題は見つかりませんでしたが、他の列が一度もスキャンされていないか、そのスキャン結果が無効になっています。 |
|
動く拡大鏡  図dumag001c.gifの説明 |
列はスキャン中です。このステータスは他のすべてのステータスを上書きします。 |
表/スキーマ/データベース/グループ内の1つ以上の列はスキャン中です。このステータスは他のすべてのステータスを上書きします。 |
データ準備を行うことで、実際の変換中または変換後に移行対象のデータベース・データに問題が発生することを回避します。データ準備の要素は、スキャンとクレンジングです。
このステップでは、表をスキャンして各種の問題がないか調べます。このスキャンによって、データのUnicodeへの移行の実行可能性が査定されます。最もよくあるタイプは、変換中に値が拡張されて列またはデータ型の制限を超える、データのキャラクタ・セットに不正なラベルが付く、バイナリ・データが文字データ型に格納されるなど、データに関する問題です。
スキャン中、DMUによって指定された文字列が読み取られ、各列値のターゲット・キャラクタ・セット(AL32UTF8またはUTF8)へのテスト変換が実行されます。この変換の結果に応じて、DMUによってデータが次のように分類されます。
変換の必要なし
変換によってデータのバイナリ表現は変更されないため、データに問題はありません。
変換の必要あり
データのバイナリ表現は変更されるが、その他のデータ問題は見つからなかったため、データを変換する必要があります。
無効なバイナリ表現
現在のデータベース・キャラクタ・セットでは、データのバイナリ表現は無効です。この状態で変換を実行しても、結果のデータは通常、アプリケーションおよびユーザーにとって無意味です。
列制限超過
移行後にデータが列に収まらなくなります。
データ型制限超過
移行後にデータがデータ型制限を超えます。
各列値には、前述のカテゴリのいずれか1つのみが割り当てられます。無効なバイナリ表現を持つ値は、変換後にその長さが列制限またはデータ型制限を超える場合でも、無効なバイナリ表現として分類されます。無効な文字コードを変換すると通常は(AL32UTF8およびUTF8では3バイト表現の)デフォルト置換文字が生成されるため、無効な表現を持つ値に長さ拡張の問題が発生することは珍しくありません。DMUでは無効な表現の問題を無視して列を強制的に変換できるため(「変換可能性の問題の無視」を参照)、無効なバイナリ表現を含む値を強制的に変換した場合、さらに切捨てが行われる可能性があることに注意してください。列の変換後の最大長プロパティの値と列およびデータ型の長さ制限とを比較して、切捨てが行われるかどうかを確認できます。このプロパティの詳細は、「列プロパティ: スキャン」を参照してください。
DMUのこのリリースは、VARCHAR2の最大サイズ制限が32767バイトまで増えたOracle Database 12cの拡張データ型制限をサポートします。拡張型制限では、元の型制限の4000バイトまでは以前のリリースで作成されたVARCHAR2データが、データ型制限超過拡張例外なしで、Database 12.1のUnicodeに移行できることを保障します。
スキャンの実行が完了すると、DMUによってデータベース・スキャン・レポートが作成されます(移行ドロップダウン・メニューの下にあります)。このスキャン・レポートには、前述の各カテゴリで現在のデータの統計が表示されます。各文字データ型列の値の件数が表示され、さらに表レベル、スキーマ・レベルおよびデータベース・レベルで合計されます。スキャン・レポートでは、たとえば選択した潜在的な問題(列制限の超過など)のある列のみが表示されるように、出力をフィルタリングおよびカスタマイズできます。
また、このレポートを使用すると、クリーンでないデータを取得する、クレンジング・エディタでこのデータを確認する、即時または後からデータを修正する、再スキャンによってデータがクリーンになったことを確認するという一連のステップを対話的に実行できます。
次のオブジェクトに対してスキャンを実行できます。
データベース内のすべての表
データベースのデータ・ディクショナリ内のすべての表
データベース内のすべてのアプリケーション・スキーマ表
アプリケーション・スキーマ内のすべての表
アプリケーション・スキーマ内の表列
データベース内のアプリケーション・スキーマの表および列の任意のセット
「キャラクタ・セット移行の考慮事項の概要」で説明されているように、自動的に検出されない特定のデータ問題もあることに注意してください。たとえば、DMUではバイナリ・データ型の文字データは分析されません。また、一部のシングルバイト・キャラクタ・セットはほぼすべてのバイト値を有効なコードとして定義します。たとえば、有効なCL8MSWIN1251文字コードではないバイト値は、0x98のみです。このため、間違って格納されたデータに未定義のバイト値が含まれていない場合、スキャン中のテスト変換で無効なバイナリ表現の問題は検出されない可能性があります。データベース・スキャンで問題が報告されていなくても、データベース変換の試行前にアプリケーションによるデータベース使用に関する情報を収集して分析し、このような隠れた問題を特定するように努めてください。データベースのテスト・コピーを作成してそれをUnicodeに移行し、アプリケーションを使用して綿密にテストすることも、多くの問題を検出するための方法の1つです。
このステップでは、特定された問題に基づいて表内のデータをクレンジングします。クレンジング・アクションは即時に実行または後から実行するように定義できます(即時クレンジング・モードとスケジュール・クレンジング・モード)。クレンジングのタイプによって、アプリケーションに影響を与えることなく本番環境で実行できることもあれば、メタデータが変更されるためにアプリケーションをこれらの変更に適応させる必要があることもあります。スケジュール・モードを使用すると、任意の時間にクレンジング・アクションを定義し、その実行を移行プロセスの変換フェーズまで遅らせることができます。これがメタデータ変更の適用のタイミングとして通常最も適している理由は、データベースは本番では使用されないこと、および新しいアプリケーション・バージョンを同時に簡単にデプロイできることです。
メタデータの即時変更は、列の変更ダイアログ・ボックスおよび属性の変更ダイアログ・ボックスで定義します。変更のスケジュールは、列変更のスケジュール・ダイアログ・ボックスおよび属性変更のスケジュール・ダイアログ・ボックスで定義します。これらのダイアログ・ボックスはいずれも、クレンジング・エディタの列または属性のコンテキスト・メニューから開くことができます。ユーザー・データの変更の即時編集は、クレンジング・エディタで直接実行します。
即時モードでは、入力したすべての変更内容は、適切な「保存」ボタンを選択するとすぐに実行されます。この場合、すべてのSQL文がデータベースに対して発行され、トランザクションがコミットされます。
スケジュール・モードでは、「保存」をクリックすると、クレンジング・アクションがDMUリポジトリに格納されます。対応する文は変換ステップ中に実行されます。変換ステップがまだ開始されていなければ、列変更のスケジュール・ダイアログ・ボックスまたは属性変更のスケジュール・ダイアログ・ボックスを再び開いて「変更なし」を選択することにより、スケジュール・アクションを変更または削除できます。
クレンジング・エディタ・タブの「保存」をクリックすると、クレンジング・エディタで表データに対して実行した変更の編集がデータベースに適用されます。「元に戻す」ボタンをクリックすると、まだ保存されていない変更を元に戻すことができます。
クレンジング・エディタは、列の想定キャラクタ・セットを設定する場合にも使用できます。このプロパティは、データベース・キャラクタ・セットとは異なるキャラクタ・セットで列の内容を解釈するようにDMUに指定するものです。選択したキャラクタ・セットがスキャン中のテスト変換に適用されて、実際の変換は変換ステップで行われ、クレンジング・エディタで表示されるデータの解釈にはこのセットが使用されます。クレンジング・エディタの列データが判読できない場合、列のキャラクタ・セットが適切に選択されていない可能性があります。
クレンジング後、データベースを再スキャンして、変更によって問題が正常に解決されたことを確認します。変換フェーズに進む前に、変換の問題がなくなるまでこのプロセスを繰り返してスキャンとクレンジングを行います。
データ変換フェーズでは、データベースの内容が実際に変更されます。変換が完了すると、データベース・キャラクタ・セットはUnicodeになります。変換は次のステップで構成されます。
移行メニューで「データベースの変換」を選択して変換フェーズを開始するようにDMUで指定すると、DMUではまず変換実行可能性テストが実行されます。このテストでは、次のことがチェックされます。
「データベース要件の概要」に一覧表示されているすべてのデータベース変換可能性要件が満たされていること
データベース内のすべてのデータのスキャンが完了し、有効なスキャン結果が存在していること
クレンジング・アクションを行うと結果が無効になることがあるため、その場合はクレンジングした表を再スキャンする必要があります。
データベース内にバイナリ表現や長さの問題のあるデータが存在していないこと
テストが成功すると、DMUによって変換の計画が表示されます。この計画には、索引、制約、トリガーなどの補助オブジェクトを処理する文を含め、データベースを変換するために実行されるすべてのSQL文が表示されます。この計画は、必要に応じてカスタマイズできます。DMUでのデータベースの変換方法は、データベース・レベルおよび表レベルの様々なオプションを使用して指定できます。たとえば、特定の表に対する変換方法を設定したり、変換ステップに関与するプロセス数を設定できます。変換計画が生成され、変換の進行状況タブに表示されます。これで、「表変換計画の編集」または「データベース変換パラメータの編集」をクリックして、使用可能なオプションを変更できるようになります。
次の手順は、実際にデータをUnicodeに変換することです。変換の進行状況タブの変換ボタンをクリックすることにより、変換計画を受け入れて変換を開始します。DMUによって変換実行可能性テストが繰り返され、変換計画の作業によって新たに問題が発生していないか確認されます。また、データベースに他のセッションが接続されていないことと、データベースが排他的モードでマウントされていることも確認されます。その後、DMUによってデータの移行が開始され、変換計画に基づいて文が実行されます。
変換の進行状況タブで、変換の進行状況を監視できます。
DMUでデータの変換に使用されるプロセスの概要は次のとおりです。
データベースが制限付きモードになります。
様々なジョブ・キュー・プロセスが無効化されます。
選択した索引が削除または無効化されます。
選択したトリガーおよび制約が無効化されます。
ユーザー表および選択したデータ・ディクショナリ表のデータがUnicodeに変換されます。
データ・ディクショナリ内のCLOB列が変換されます。
ALTER DATABASE CHARACTER SET文が発行されます。
トリガーと制約が有効化され、索引と制約が再作成されます。
データベース・インスタンス・パラメータがリストアされます。
表の変換を実行するには、UPDATE文を使用して表の列を更新するか、CREATE TABLE AS SELECT文を使用して表の再作成中に列を変換します。表の行の大部分を変換する必要がある場合は、表を更新するよりも再作成するほうが高速です。
変換が完了すると、DMUによって、先に削除または無効化されたすべてのオブジェクトが再作成または再有効化されます。ログ・ペインを参照して、エラーが生成されていないか確認できます。
