Oracle® Database

Migration Assistant for Unicodeガイド

リリース2.0

E59465-03(原本部品番号:E48475-07)

2015年8月

Oracle Database Migration Assistant for Unicodeガイド, リリース2.0

E59465-03

Copyright © 2011, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者:  Rajesh Bhatiya

原本協力者: Sergiusz Wolicki、Weiran Zhang

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

1 データベースのUnicodeへの移行の概要

- データベース・キャラクタ・セットの概要

- キャラクタ・セット移行の概要

- Unicodeが推奨される理由

- キャラクタ・セット移行ツールの概要

- Database Character Set Scannerに関する移行問題の特定

- CSALTERスクリプトを使用したキャラクタ・セット・メタデータの変更

- エクスポート/インポートおよびデータ・ポンプ・ユーティリティを使用した文字データの変換

- 全体エクスポート/インポートと選択的エクスポート/インポート

- データ・ポンプ・ユーティリティ

- 変換の問題

- Database Migration Assistant for Unicodeを使用したデータベースの移行

- キャラクタ・セット移行の考慮事項の概要

- キャラクタ・セット移行: データ整合性

- データの拡張

- データの無効なバイナリ記憶域表現

- パーティション化

- 最大索引キー・サイズ

- 一意キーおよび主キー

- 導出または暗号化されたデータ

- バイナリ・データ型に格納された文字データ

- キャラクタ・セット移行: 依存オブジェクト

- キャラクタ・セット移行: 読取り専用およびアクセス不能オブジェクト

- キャラクタ・セット移行: 停止時間

- キャラクタ・セット移行: 障害リカバリ

- キャラクタ・セット移行: アプリケーションへの影響

2 DMU入門

- Database Migration Assistant for Unicodeの使用: ロードマップ

- DMUのインタフェースおよびナビゲーションの概要

- 要件およびセキュリティの考慮事項の概要

- データベース要件の概要

- Javaランタイム要件の概要

- DMUセキュリティの考慮事項の概要

- 移行の準備の確認

- DMUに関する最初のタスクの実行

- DMUのインストール

- データベース接続の作成

- 移行リポジトリのインストール

- 移行ステータスの追跡

- DMUユーザー・インタフェースの概要

- データ準備の概要

- データ準備: スキャン

- データ準備: クレンジング

- データ変換の概要

- 変換の準備

- データの変換

3 DMUでのオブジェクト・プロパティの表示および設定

- データベース・プロパティの表示および設定

- データベース・プロパティ: 一般

- データベース・プロパティ: スキャン

- データベース・プロパティ: 準備状況

- データベース・プロパティ: 変換

- スキーマ・プロパティの表示および設定

- スキーマ・プロパティ: 一般

- スキーマ・プロパティ: スキャン

- スキーマ・プロパティ: 準備状況

- 表プロパティの表示および設定

- 表プロパティ: 一般

- 表プロパティ: スキャン

- 表プロパティ: 準備状況

- 表プロパティ: 変換

- 列プロパティの表示および設定

- 列プロパティ: 一般

- 列プロパティ: スキャン

- 列プロパティ: 準備状況

- 列プロパティ: 変換

4 DMUの基本タスクの実行

- データベースの初期化

- 必要なパッチのインストール

- サポート・パッケージのインストール

- 移行リポジトリの表領域の作成

- データベース接続の作成

- 移行リポジトリのリフレッシュまたは再インストール

- 移行リポジトリのアンインストール

- データベースのスキャン

- データベース・プロパティの設定

- スキャン・ウィザードを使用したデータベースのスキャン

- スキャンの進行状況の監視

- データベース・スキャン・レポートの表示

- データベース・スキャン・レポートの概要

- データベース・スキャン・レポート: 結果グリッド

- データベース・スキャン・レポート: ステータス・アイコンによるナビゲート

- データベース・スキャン・レポート: フィルタリング

- データベース・スキャン・レポート: 検索

- データベース・スキャン・レポート: HTMLへのエクスポート

- データベース・スキャン・レポート: スキャンの停止

- データのクレンジング

- データベースの変換

- 変換の詳細タブ

- 表変換計画の詳細の編集ダイアログ

- 変換の停止

- Unicodeとしてのデータの検証

- 検証モードのユーザー・インタフェースの概要

- データの検証方法

- 診断パッケージの作成

5 DMUに関する高度なトピック

- 移行からの列および表の除外

- アクセス不能データの処理

- 読取り専用表の考慮事項

- 読取り専用表領域の考慮事項

- オフラインの表領域およびデータ・ファイルの考慮事項

- 外部表の使用

- 外部表のクレンジング

- 長さの問題のクレンジング

- ORACLE_LOADERファイルのキャラクタ・セット宣言の修正

- ORACLE_DATAPUMPファイルのキャラクタ・セット宣言の修正

- 破損した文字コードの修正

- バイナリ・データの処理

- ORACLE_LOADERファイルのパフォーマンスの考慮事項

- データ・ディクショナリの内容の移行

- データ・ディクショナリ表のスキャン

- データ・ディクショナリ表のクレンジング

- データ長の問題のクレンジング

- 無効なバイナリ表現の問題のクレンジング

- メタデータの特定

- データ・ディクショナリ表の変換

- 無視されるデータ・ディクショナリ表

- 自動ワークロード・リポジトリ表の処理

- 多言語列の使用

- 高度な変換可能性の問題

- 変換可能性の問題: 一意性の検証

- 変換可能性の問題: 索引サイズ

- 変換可能性の問題: パーティション範囲の整合性

- 変換可能性の問題: ごみ箱内のオブジェクト

- 変換可能性の問題: 30バイトを超えるPL/SQLローカル識別子

- Unicodeへの移行に対するアプリケーションの適用

- レガシー・アプリケーションを変更せずに実行

- SQLおよびPL/SQLコードの変更

- データベース・キャラクタ・セット・メタデータの修復

- 例: CSREPAIRの使用

- DMUバージョンの更新

- DMUのアクセシビリティについて

- DMUでのスクリーン・リーダーおよびJava Access Bridgeの使用方法

6 DMUを使用したデータのクレンジング

- データのクレンジング

- データのクレンジング: ツールバーの使用

- データのクレンジング: 色の強調表示

- データのフィルタリング

- 変換可能性ステータスに基づくフィルタリング

- SQL条件に基づくフィルタリング

- 想定キャラクタ・セットの設定

- データの表示

- データの編集

- データの表示

- 列の変更

- 列変更のスケジュール

- 属性の変更

- 属性変更のスケジュール

- 変換可能性の問題の無視

- 一括クレンジング

- クレンジング・シナリオ1: 問題のないデータベース

- クレンジング・シナリオ2: 拡張の問題のクレンジング

- 「列制限超過」の問題

- 列の長さの調整

- 長さセマンティクスの変更

- 手動での文字値の短縮

- 変換中の列値の切捨て

- 拡張する文字の置換

- より大きなデータ型への移行

- 「型制限超過」の問題の処理

- スキャン結果のリフレッシュ

- スケジュール済クレンジング・アクションの取消し

- クレンジング・シナリオ3: 無効な表現の問題のクレンジング

- 文字列内のバイナリ値のクレンジング

- 不適切なキャラクタ・セット宣言のクレンジング

- 破損した文字値のクレンジング

用語集

索引

はじめに

このガイドでは、Oracle Database Migration Assistant for Unicodeの概要を示します。

対象読者

このガイドは、次のタスクを実行するデータベース管理者を対象にしています。

- キャラクタ・セットのUnicodeへの移行

- 現在のUnicodeデータベースにキャラクタ・セットのデータ問題がないことの確認

このガイドを使用するには、Oracleデータベースに関する知識が必要です。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- Oracle Databaseグローバリゼーション・サポート・ガイド

このガイドでは、サンプル・スキーマを例として多用していますが、これらのサンプル・スキーマは、Oracle Databaseのインストール時に「基本インストール」オプションを選択した場合に、デフォルトでインストールされています。これらのスキーマの作成方法および使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OHC (Oracle Help Center)から無償でダウンロードできます。OHCを使用するには、オンラインでの登録が必要です。登録は、次のWebサイトから無償で行えます。

http://docs.oracle.com

1 データベースのUnicodeへの移行の概要

この章では、データベース・キャラクタ・セットの移行プロセスについて説明します。まず、データベース・キャラクタ・セットの概要およびそれを移行する意味について説明します。また、移行プロセスに関連する基本的な問題と、これらのタスクに役立つツールについて説明します。

この章は次の項で構成されています。

- データベース・キャラクタ・セットの概要

- キャラクタ・セット移行の概要

- Unicodeが推奨される理由

- キャラクタ・セット移行ツールの概要

- キャラクタ・セット移行の考慮事項の概要

データベース・キャラクタ・セットの概要

Oracleにおけるデータベース・キャラクタ・セットとは、データベースに格納できる文字のセットを定義し、それぞれの文字を表現するためにメモリーやディスクに格納された特定のバイト・シーケンスにマップする方法を定義したものです。Oracleで言うところのキャラクタ・セットは業界では文字エンコーディングとも呼ばれ、文字のセットにエンコーディング(バイト)を加えたものと考えることができます。

データベース・キャラクタ・セットは、VARCHAR2、CHAR、LONGおよびCLOBデータや、データベース内のSQL、PL/SQLおよびJavaストアド・コードに使用されます。CLOBデータは、キャラクタ・セットがシングルバイトの場合にのみデータベース・キャラクタ・セットに格納されます。それ以外の場合は、AL16UTF16(ビッグ・エンディアン形式のUnicode UTF-16エンコーディングで、UTF-16BEと略記される)に格納されます。

データベース・キャラクタ・セットは、各文字が1バイトであるシングルバイトの場合と、各文字が1、2、3または4バイトであるマルチバイト可変幅(最大値はキャラクタ・セットによって異なる)の場合があります。シングルバイト・キャラクタ・セットのほうが処理が簡単で高速ですが、コードが256種類とヨーロッパ諸国言語でも足りないほどしかないため、機能が大きく制限されています。マルチバイト・キャラクタ・セットではより複雑な文字処理が必要になりますが、数千種類の文字に対応できます。

Unicodeを除くほとんどのすべてのキャラクタ・セット(レガシー・キャラクタ・セットとも呼ばれる)は、それぞれ特定の言語または言語グループに対して設計されたものです。シングルバイト・キャラクタ・セットの場合、使用可能なコードの数が限られているため、これは必然的でした。マルチバイト・キャラクタ・セットの場合はおそらく、ローカル・データベースを分離する必要性があまりないこと、文字コードの最大必須幅を制限する必要があること、または関連しない複数の言語グループに対するキャラクタ・セットを設計するための専門知識が必要なことがその理由でした。

キャラクタ・セットを使用する際に重要な概念の1つは、サブセットとスーパーセットの概念です。キャラクタ・セットAがキャラクタ・セットBのすべての文字に加え他の文字も含んでいる、またはそれらを定義している場合、キャラクタ・セットAはキャラクタ・セットBのスーパーセットであり、キャラクタ・セットBはキャラクタ・セットAのサブセットであると言います。キャラクタ・セットAがキャラクタ・セットBのすべての文字を含んでいるかそれらを定義しており、AとBでこれらの各文字のバイト表記が同じである場合、キャラクタ・セットAはキャラクタ・セットBの完全なスーパーセットまたはバイナリ・スーパーセットであると言います。バイナリ・サブセットまたはバイナリ・スーパーセットは、完全なサブセットまたは完全なスーパーセットとも呼ばれます。

異なるキャラクタ・セットでエンコードされている環境の間で文字データを送信する場合、たとえばデータベースから別のデータベースに、またはクライアントからサーバーに送信する場合は、データにキャラクタ・セット変換処理を実行する必要があります。つまり、ソース・キャラクタ・セットの文字コードをターゲット・キャラクタ・セットの同じ文字のコードで置換する必要があります。ターゲット・キャラクタ・セットで使用できない文字は、置換文字に変換されます。特定のソース文字の置換文字は、ターゲット・キャラクタ・セットで明示的に定義できます。たとえば、ä (ウムラウト付きのa)は、キャラクタ・セットUS7ASCIIに変換されるときにaで置換されます。明示的な置換文字を定義しない場合、ターゲット・キャラクタ・セットのデフォルトの置換文字が使用されます。この文字は通常、疑問符(?)または反転した疑問符(¿)です。Unicodeキャラクタ・セットのデフォルトの置換文字は、文字U+FFFDです。

定義上は、データがキャラクタ・セットからそのスーパーセットに変換される場合、すべての文字がスーパーセットで使用可能なので、置換文字は使用されません。また定義上、データがキャラクタ・セットからそのバイナリ・スーパーセット(完全なスーパーセット)に変換される場合、実際に変更される文字コードはありません。Oracle Databaseは通常、バイナリ・スーパーセットへの変換までも実行するため、変換対象のテキストにソース・キャラクタ・セットで有効な文字コードにならないバイト・シーケンスが含まれている場合、これらのシーケンスはターゲット・キャラクタ・セットで置換文字に変換されます。

キャラクタ・セット移行の概要

レガシー・キャラクタ・セットで定義されているデータベースは、そのキャラクタ・セットで指定されている1つまたは数種類の言語のみでデータを格納できます。このデータベースに他の言語のデータを格納する必要が生じた場合、データベースのキャラクタ・セットを、既存の文字と新しく必要になった文字の両方を定義するスーパーセットに変更する必要があります。インターネット販売モデルに移行して操作を国際化したり、海外の支社の複数のデータベースや買収企業と被買収企業を1つのデータベースに統合する場合、このような必要が生じる可能性があります。

特定されたスーパーセットがバイナリ・スーパーセットでもある場合、データ・ディクショナリ内のメタデータ(スキーマ情報)でのみデータベース・キャラクタ・セット宣言を変更すればすみます。定義上、既存のデータはすべてバイナリ・スーパーセット内でも有効になります。変更は簡単であり、短時間で完了します。特定されたスーパーセットがバイナリ・スーパーセットでない場合、バイナリ文字コード(バイト表現)を古いキャラクタ・セットの表現から新しいキャラクタ・セットの表現に変更(再エンコード)する必要があります。

既存のデータに変換が必要かどうかを判断する際には、古いデータベース・キャラクタ・セットが新しいデータベース・キャラクタ・セットのバイナリ・サブセットでない場合でも、多くの文字のバイナリ・コードが両方のキャラクタ・セットで実際には同じになる可能性があることに注意してください。具体的には、0から127までのコードを含む標準のASCII文字はすべて、ASCIIベースのプラットフォーム(つまり、EBCDICベースのIBM z/OSおよびFujitsu BS2000を除くすべてのプラットフォーム)でサポートされている各Oracleデータベース・キャラクタ・セットのバイナリ・サブセットを構成します。したがって、データベース・キャラクタ・セットをたとえば(バイナリ・サブセットとバイナリ・スーパーセットの関係にはない)WE8ISO8859P1からAL32UTF8に変更する場合でも、データベース内のすべての文字に0から127までのコードが含まれていれば、すべての文字のコードは変更後も同じになるため、実際に変換が必要な文字はありません。

データベース内の変換対象の文字データを変換が不要なデータ(このガイドでは不変と呼びます)と変換が必要なデータ(変換可能と呼びます)に分類できれば、不変データの変換を省略できるため、多くのリソースを節約できます。

文字コードが変換されるとき、様々な問題が発生する可能性があります。最もよくある問題は、新しい表現のバイト数が増えることによって、変換後の値がそれを含む列の長さ制約またはそのデータ型の最大長を超えることです。変換を正常に行うためには、まずこれらの問題を特定し、列の長さ調整、テキストの短縮、より大きなデータ型への移行などを行って問題を解決する必要があります。

適切なスーパーセットを特定する、文字データを不変または変換可能として分類する、問題や変換の要件がないか確認する、問題を解決する、データ・ディクショナリ内の宣言を変更する、およびデータを必要に応じて変換するという一連のプロセスを、キャラクタ・セット移行と呼びます。データベース内の既存のデータの問題およびサブセット/スーパーセット関係は、Database Character Set Scannerユーティリティ(『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照)またはDatabase Migration Assistant for Unicodeを使用すると特定できます。

移行プロセスの実行形態としては、AからBへの移行(データがソース・データベースからターゲット・キャラクタ・セットで定義された新しいデータベースにコピーされる)とインライン移行(データがデータベース内部で変換され、データベースのキャラクタ・セット情報が変換される)があります。

キャラクタ・セット移行と、データベース・キャラクタ・セット宣言をデータベース内のデータのエンコーディングと一致するように更新する修復プロセスとを混同しないでください。Oracleクライアント・ソフトウェアがパススルー構成またはGIGO構成と呼ばれる不適切な構成になっている場合、アプリケーションによってデータベース内の文字データが、データベースに宣言されているキャラクタ・セットと異なるキャラクタ・セットで解釈される可能性があります。修復プロセスの目的は、データベース・キャラクタ・セット宣言をアプリケーションの予測と一致させることです。定義上、このような修復プロセスで文字コードの変換が行われることはありません。

Unicodeが推奨される理由

キャラクタ・セット移行プロセスの重要な手順の1つは、要件を収集することです。たとえば、よくある状況として、会社がその運営を国際化する場合、既存のデータベース・キャラクタ・セットでは使用できない言語のデータ格納をサポートする必要が生じます。従来のコンピュータ・システムの多くは当初は1種類か数種類の言語のみをサポートすればよかったため、当初選択したキャラクタ・セットではサポートできる文字のレパートリーが限られている可能性があります。たとえば、アメリカでは、英語のデータのみをサポートするには7ビットのASCIIを使用すれば十分でした。またヨーロッパでは、各種の8ビット・キャラクタ・セットでヨーロッパ諸国語と英語をサポートできました。これらの選択は合理的であり、経済性とパフォーマンスのバランスも取れていました。しかし現在では、これらの選択がグローバル・マーケットをサポートするための障壁となっており、そのためにキャラクタ・セット移行が必要となっています。複数のサーバーのキャラクタ・セットがそれぞれ異なる場合、それらのサーバーを1つのインスタンスに統合する必要があります。このような場合、Unicodeを規格として選択することが理に適っています。

Unicode Standardで定義されているキャラクタ・セットは、現在広く使用されているすべての記述言語およびいくつかの履歴スクリプトをサポートしています。また、たとえば、技術表記、科学表記および音楽表記で使用される各種の記号もサポートしています。これは、Java、Windows、HTML、XMLなどの多くの技術のネイティブ・キャラクタ・セットまたは推奨キャラクタ・セットです。これほどの普遍性を持つキャラクタ・セットは他にありません。さらに、業界からの多大な支持を受けて、Unicodeを採用する企業も急速に増加しています。

Oracleでは、データベース・キャラクタ・セットとして2つのUnicodeエンコーディング(AL32UTF8キャラクタ・セットを介するUTF-8と、UTF8キャラクタ・セットを介するCESU-8)をサポートしています。(Unicodeエンコーディングの名前にはハイフンがありますが、Oracleキャラクタ・セットの名前にはハイフンがないことに注意してください。この違いはOracleドキュメント全体にわたって適用されています。)UTF-8は、各文字に1バイトから4バイトまでを使用するマルチバイト可変幅Unicodeエンコーディングです。CESU-8は互換性のみのエンコーディングであり、Unicode規格では情報交換での使用は推奨されていません。CESU-8はUTF-8と似ていますが、UTF-8ではいわゆる補助文字が4バイトでエンコードされるのに対し、CESU-8では3バイト・コードのペアとしてエンコードされます。UTF8キャラクタ・セットはOracle Databaseで非推奨となったため、Oracle E-Business Suiteリリース11iなどのアプリケーションで明示的に必要となる場合を除き、データベース・キャラクタ・セットとして使用しないでください。

AL32UTF8はASCII文字を1バイトで、ヨーロッパ言語と中東言語の文字を2バイトで、南アジア言語と東アジア言語の文字を3バイトでエンコードします。このため、Unicodeの記憶要件は通常、同じ言語のレガシー・キャラクタ・セットの記憶要件よりも大きくなります。これは、ASCIIのみを必要とする言語(英語、ドイツ語、インドネシア語、スワヒリ語など)以外のすべての言語に当てはまります。

ビジネス要件を満たすスーパーセットを探すときに、レガシー・キャラクタ・セットがこれらの要件を満たしていることがあります。たとえば、データベースが英語を格納するUS7ASCIIであり(これは他のどのOracleデータベース・キャラクタ・セットにも格納できます)、データベースに追加される新しい言語がすべてレガシー・キャラクタ・セットでサポートされている互換的な1つの言語グループに属する場合は、これに該当します。たとえば、すべての新しい言語が西ヨーロッパ語であり、WE8MSWIN252に格納できる場合などです。また、ユーロ記号やスマート引用符(")などの新しいいくつかの文字をデータベースに格納する必要があり、それらの新しい文字が既存のデータベース・キャラクタ・セットの拡張バリアントでサポートされている場合などもあります。このような拡張バリアントには、たとえばWE8ISO8859P1のシングルバイト・バイナリ・スーパーセットであるWE8MSWIN1252があります。

複数の言語グループを格納する必要がある場合は、必ずUnicodeを選択する必要があります。

Unicodeには普遍性があり、現在および将来のテクノロジや言語要件との互換性もあるため、Unicodeへの移行をお薦めします。移行する環境が次の説明すべてに該当する場合のみ、レガシー・キャラクタ・セットを別のレガシー・キャラクタ・セットに移行することを考慮してください。

- 新しいキャラクタ・セットが古いキャラクタ・セットのバイナリ・スーパーセットであるため、データ変換は必要なく、簡単な宣言変更のみですみます。

- 新しいキャラクタ・セットがシングルバイトであるため、Unicodeよりもパフォーマンスに優れ、記憶域も小規模になります。

- 予測可能な将来、新しいキャラクタ・セットと互換性のない言語要件が発生することがありません。

- AL32UTF8に移行する場合、可用性や互換性の要件のために多大なリソースが必要になります。

新しいキャラクタ・セットを選択する際は、この他に次の2つの理由を考慮する必要があります。

- データベースが急速に拡大する場合、将来の変換には現在よりもはるかに多くのコストがかかります。したがって、Unicodeが業界における究極的な目標であることを考慮すると、できるだけ早い時期にUnicodeに移行することがベストです。

- アプリケーションがインターネット・アプリケーションである場合、またはJavaやその他のUnicodeベースのテクノロジを使用している場合、データベース・キャラクタ・セットとしてUnicodeを使用すると、アプリケーションからの予期しない文字をシステムが格納できないためにデータが失われることがなく、キャラクタ・セット変換はUnicode文字エンコーディング間の効率的な変換に限られるため、環境の整合性、安全性および効率が向上します。

もう1つのUnicodeエンコーディングであるUTF-16BE (Oracle DatabaseではAL16UTF16)は、NCHAR、NVARCHAR2およびNCLOBデータ型に対する各国語キャラクタ・セットとして使用されます。Unicodeキャラクタ・セットを必要とするデータは、データベース・キャラクタ・セットをAL32UTF8に移行しなくても、これらのデータ型の列に格納できます。ただし、これらのデータ型には、Oracle Textでサポートされていないことや、クライアントAPIコール(Oracle Call Interface (OCI)またはJava Database Connectivity (JDBC))に変更する必要があることなど、いくつかの制約があります。各国語キャラクタ・セット・データ型の使用は推奨されず、このガイドではNCHARデータ型については説明しません。

関連項目:
NCHARの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

キャラクタ・セット移行ツールの概要

既存のデータベースのデータベース・キャラクタ・セットを変更できます。次の各項で、この実施方法について説明します。

- Database Character Set Scannerに関する移行問題の特定

- CSALTERスクリプトを使用したキャラクタ・セット・メタデータの変更

- エクスポート/インポートおよびデータ・ポンプ・ユーティリティを使用した文字データの変換

- Database Migration Assistant for Unicodeを使用したデータベースの移行

Database Character Set Scannerに関する移行問題の特定

Database Character Set Scanner (CSSCAN)は、Oracleデータベースから新しいデータベース・キャラクタ・セットへの移行の実行可能性を査定するコマンドライン・ユーティリティです。Database Character Set Scannerにより、データベースのすべての文字データがチェックされ、キャラクタ・セット・エンコーディングの変更による影響と問題点がテストされます。スキャンの終了時には、データベースを新規キャラクタ・セットに変換するために必要な作業の範囲を示すサマリー・レポートが生成されます。

Database Character Set Scannerは、Express Editionを除くすべてのデータベース・エディションで使用可能です。そのスキャン機能のほとんどは、このガイドで説明しているDatabase Migration Assistant for Unicodeに組み込まれていますが、次のいずれかに該当する場合はDatabase Character Set Scannerを使用する必要があります。

- レガシー・キャラクタ・セットに移行する場合。

- 各国語(NCHAR)キャラクタ・セットを移行する場合。

- CSALTERスクリプトでスキャン結果が必要な場合。

注意:
CSSCANはOracle Database 12cでは使用できません。

CSALTERスクリプトを使用したキャラクタ・セット・メタデータの変更

CSALTERスクリプトは、Database Character Set Scannerユーティリティに付属しています。このスクリプトにより、次の2つのタスクが行われます。

1. データ・ディクショナリ内の様々なシステム表に格納されているキャラクタ・セット・メタデータ情報を新しいキャラクタ・セットに変更します。

2. データベース・キャラクタ・セットをシングルバイトからマルチバイトに変更する場合、またはマルチバイトからシングルバイトに変更する場合に、データ・ディクショナリ表内のCLOB列の文字データを変換します。

CSALTERスクリプトでデータ・ディクショナリとしてみなされるのは、SYSが所有している表に限られません。Oracle Databaseソフトウェアのインストール中に作成された、デフォルトのテンプレート・データベースに存在するスキーマの大部分も、データ・ディクショナリとしてみなされます。

CSALTERスクリプトを実行できるのは、新しいキャラクタ・セットで有効になるために再エンコーディングが必要な文字データ(データ・ディクショナリ表のCLOBデータを除く)がデータベース内に存在しない場合のみです。データベースの整合性を保つために、CSALTERスクリプトでは、まずDatabase Character Set Scannerを実行して、変換が必要なデータがないこと、つまりターゲット・キャラクタ・セットがデータベース内のデータのバイナリ・スーパーセットであることを確認する必要があります。データベースのどこかに例外的なデータがあったり、データ・ディクショナリのCLOB列の外部に変換可能データがあるという情報がスキャン結果に含まれていると、CSALTERはエラー・メッセージとともに中断されます。

データ・ディクショナリのCLOB列が処理される理由は、CLOBデータをマルチバイト・データベースに格納するために使用されるAL16UTF16が、どのシングルバイト・キャラクタ・セットのバイナリ・スーパーセットまたはバイナリ・サブセットにもならないためです。このため、ターゲット・キャラクタ・セットがスーパーセットであっても、CLOBは変換する必要があります。データ・ディクショナリ表は削除も切捨てもできないため、CSALTERによってデータ・ディクショナリCLOBを変換しなければ、シングルバイト・データベース・キャラクタ・セットをマルチバイト・キャラクタ・セットに変更することはできません。

キャラクタ・セットをシングルバイトからマルチバイトに変更する際にユーザー表にCLOBデータが存在すると、CSALTERスクリプトは実行されないため、ユーザー表のCLOB列はCSALTERによって変換されません。

CSALTERの機能のほとんどは、このガイドで説明しているDatabase Migration Assistant for Unicodeに組み込まれていますが、次のいずれかに該当する場合はCSALTERを使用する必要があります。

- レガシー・キャラクタ・セットに移行する場合

- 各国語(NCHAR)キャラクタ・セットを移行する場合

注意:
CSALTERはOracle Database 12cでは使用できません。

エクスポート/インポートおよびデータ・ポンプ・ユーティリティを使用した文字データの変換

Database Character Set Scannerによって変換が必要なデータがデータベース内に見つかった場合、CSALTERスクリプトでデータベース・キャラクタ・セットを変更することはできません。これ以外のなんらかの方法を適用してデータを変換する必要があります。文字データを変換する一般的な方法の1つは、エクスポート・ユーティリティを使用してデータベースからデータベース・オブジェクトをエクスポートしてから、インポート・ユーティリティを使用してこれらのオブジェクトを同じデータベースまたは別のデータベースにインポートする方法です。エクスポート時のデータベース・キャラクタ・セットがインポート時のデータベース・キャラクタ・セットと異なる場合、インポート・ユーティリティによって必要に応じてデータが自動的に変換されます。エクスポートおよびインポート・ユーティリティを使用してデータを変換すると、データをスプールしてSQL*Loaderで再びロードするなどの他の方法に比べて、エクスポートされたオブジェクトを元の形式に再作成するために必要なほとんどのステップが自動的に実行されるという利点があります。

関連項目:
全体エクスポートおよび全体インポート・プロセスを使用してデータベース・キャラクタ・セットを変更する方法の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

全体エクスポート/インポートと選択的エクスポート/インポート

エクスポートとインポートは、次の2つのキャラクタ・セット移行方法におけるステップとして適用できます。

- 全体データベース・エクスポートおよびインポートによる移行
この方法では、最初にターゲット・キャラクタ・セット内に空のデータベースが作成されます。次に、データベースのすべての内容がソース・データベースからエクスポートされて、ターゲット・データベースにインポートされます。作成された元のデータベースのコピーには、必要に応じて変換されたすべての文字データが含まれています。ソース・データベースが削除され、コピーが本番データベースになります。

- 選択的エクスポートおよびインポートによる移行
この方法では、Database Character Set Scannerユーティリティによって変換可能データが含まれていることが特定されたすべての表のみがエクスポートされ、その後切り捨てられます。Database Character Set Scannerが再び実行されますが、今度は変換可能データは検出されません。これで、CSALTERスクリプトを実行してデータベース・キャラクタ・セットを変更できるようになります。次に、すでにエクスポートされたデータが再びデータベースにインポートされ、必要なキャラクタ・セット変換が実行されます。

次のような状況では、全体エクスポート/インポートが適しています。

- データベースのデータ・ディクショナリに変換可能データが含まれています。たとえば、表または列(あるいはその両方)の名前(識別子)に変換が必要な非ASCII文字が含まれている場合などです。データ・ディクショナリ表は切り捨てられないため、選択的エクスポート/インポートの方法は使用できません。

- 変換が必要な表の数が多いため、表を手動で選択してエクスポートと切捨てを行うとコストが高くつきます。

- キャラクタ・セット移行プロセスを上位リリースや別のプラットフォームへのデータベース・アップグレードとあわせて行います。

- データベース内の多数の表が断片化されており、デフラグメンテーションおよびクリーンアップを実行する手段としてキャラクタ・セット移行プロセスを行います。

これに対し、次の状況では選択的エクスポート/インポートが適しています。

- 全体エクスポート/インポートを行うとテキスト以外のデータもすべて挿入する必要があるために、不要なテキストも含めてデータベース内のすべてのテキストが変換されます。このため、大規模な本番データベースを短いメンテナンス期間で行うには、全体エクスポート/インポート方法では通常は遅すぎます。

- 選択的エクスポート/インポート方法では、エクスポートされた表の一時表領域のみが必要です。全体の方法では、データベース・コピーとデータベース・エクスポート・ファイル全体の一時記憶域が必要です。この場合、ソース・データベース・サイズのほぼ2倍の追加領域が必要となります。

データ・ポンプ・ユーティリティ

エクスポートおよびインポート・ユーティリティには、オリジナルのエクスポート(exp)およびインポート(imp)と、データ・ポンプ・エクスポート(expdp)およびインポート(impdp)という2つのバージョンがあります。データ・ポンプ・バージョンは、Oracle Databaseリリース10gで導入されたものです。オリジナルのバージョンの一般的な使用は、Oracle Database 11g以降サポートされなくなりました。どちらのバージョンもコマンドライン・ツールであり、ここで説明している目的で使用できるものです。

オリジナルのユーティリティは、データ・ポンプ・ユーティリティとの互換性がありません。expで生成されたファイルをimpdpでインポートすることはできず、expdpで生成されたファイルをimpでインポートすることはできません。

オリジナルのエクスポートおよびインポートは、純粋なクライアント側ユーティリティです。エクスポート・ユーティリティでは、Oracle Netネットワーク接続を介してデータが取得され、クライアント側にエクスポート・ファイルが作成されます。データ・ポンプ・エクスポートには小型のクライアント制御ユーティリティが含まれていますが、実際のエクスポート・ジョブはデータベース・サーバー・プロセスによって実行され、エクスポート・ファイルはデータベース・サーバー・ホスト上に生成されます。同様に、オリジナルのインポート・ユーティリティではクライアント側のエクスポート・ファイルが読み取られ、Oracle Netネットワーク接続を介してデータがターゲット・データベースに挿入されるのに対し、データ・ポンプ・ユーティリティでは直接データベース・サーバー・ホストのエクスポート・ファイルが読み取られます。データ・ポンプ・アーキテクチャでは、データ・ポンプ・ユーティリティのエクスポートおよびインポート・プロセスが大幅に速くなりますが、エクスポート・ファイルをソース・データベース・ホスト以外のコンピュータ上に作成したり読み取る場合は、ターゲット・システムにダミーのデータベースをインストールしておく必要があります。

関連項目:
オリジナルのエクスポート/インポート・ユーティリティおよびデータ・ポンプ・エクスポート/インポート・ユーティリティの詳細は、『Oracle Databaseユーティリティ』を参照してください。

変換の問題

「キャラクタ・セット移行の概要」および「キャラクタ・セット移行: データ整合性」で説明されているように、変換では主に長さ問題に関連する問題が発生する可能性があります。これらの問題は、Database Character Set Scannerによって特定し、インポートの前にユーザーが解決する必要があります。そうしない場合、いずれの方法でもインポート・プロセスは失敗する可能性があります。

エクスポート/インポート・ユーティリティを使用する場合は、特定のユーティリティ・バージョンではサポートされていないオブジェクトに関する制約についても考慮する必要があります。たとえば、Oracle Data Pumpリリース10gではXMLスキーマのエクスポートをサポートしていません。このようなオブジェクトは手動で移動する必要がある場合があります。

関連項目:
エクスポート/インポート・ユーティリティを使用したデータベース移行プロセスの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

Database Migration Assistant for Unicodeを使用したデータベースの移行

DMUには、インタフェースを介して移行プロセスを合理化する直覚的でユーザーフレンドリなGUIが備わっており、これによりワークロードを軽減し、すべての移行問題を確実に解決し、データ変換を適切かつ効率的に実行できます。

DMUの利点は次のとおりです。

- ワークフローが順を追って説明されます。
DMUの大きな利点は、論理的なワークフローによってキャラクタ・セット移行プロセス全体が順を追って説明されることです。

- 特定の問題に対処するための推奨方法が示されます。
DMUは、データのスキャンやクレンジング中にエラーや障害などの特定の問題が発生したときに役立ちます。

- データの選択的変換がサポートされています。
DMUを使用すると、表レベル、列レベルおよび行レベルで変換が必要なデータのみを変換できます。

- 進行状況モニターが提供されます。
DMUには、ステップの進行状況を表示するGUIが備わっています。

- 対話的な表示機能が提供されます。
DMUを使用すると、データを分析し、GUIで対話形式で結果を確認できます。また、GUIでデータそのものを確認して、特定された移行問題のあるデータを対話形式でクレンジングできます。

- インライン変換専用にサポートされたツールが提供されます。
DMUを使用すると、Oracle Databaseでデータベースの内容のインライン変換がサポートされます。これは、パフォーマンスおよびセキュリティに関して、他の既存の変換方法よりも優れています。

- 変換ステップ中に、クレンジング・アクションを後で実行するようにスケジュールできます。
データ型移行などのクレンジング・アクションを延期すると、本番データベースおよびアプリケーションは、実際の停止期間に入るまでは影響を受けません。

このリリースのDatabase Migration Assistantには、変換できるデータベースに関するいくつかの制限事項があります。たとえば、ほとんどの場合、データ・ディクショナリに変換可能データの存在するデータベースは変換されません。エクスポート/インポート移行方法を使用する場合、これらの制限事項はありません。

関連項目:
詳細は、第4章「DMUの基本タスクの実行」を参照してください。

キャラクタ・セット移行の考慮事項の概要

次の各項では、Database Migration Assistant for Unicodeを使用して現在のキャラクタ・セットを移行する前に考慮する必要のある事項について説明します。

- キャラクタ・セット移行: データ整合性

- キャラクタ・セット移行: 依存オブジェクト

- キャラクタ・セット移行: 読取り専用およびアクセス不能オブジェクト

- キャラクタ・セット移行: 停止時間

- キャラクタ・セット移行: 障害リカバリ

- キャラクタ・セット移行: アプリケーションへの影響

キャラクタ・セット移行: データ整合性

データベース内の文字データを再エンコーディングすると、次のようなデータ整合性の問題が発生する可能性があります。

- データの拡張

- データの無効なバイナリ記憶域表現

- パーティション化

- 最大索引キー・サイズ

- 一意キーおよび主キー

- 導出または暗号化されたデータ

- バイナリ・データ型に格納された文字データ

データの拡張

レガシー・エンコーディングからUnicodeに移行する場合、Unicodeのエンコーディングのほうがバイト数が多いため、通常は変換で文字の値が拡張されます。その結果、データベースの領域要件が大きくなります。さらに、キャラクタ・セットをUnicodeに移行した後にCHAR列およびVARCHAR2列の幅が不足する可能性もあります。この場合、データが切り捨てられる危険があります。列の長さ制約を拡大したり、または、すでにデータ型の制限に達している場合は、列をCLOBデータ型に移行する必要があることもあります。

これに関連して、(通常は30バイトの制限がある)非ASCIIオブジェクト名に関する問題もあります。非ASCIIオブジェクト名の制限を拡大することは不可能なので、データベースと影響を受けるアプリケーションの両方で、このようなオブジェクトの名前をASCII文字のみを含むように手動で切り捨てるか変更する必要があります。

データの無効なバイナリ記憶域表現

ユーザー・データでよくある問題は、列のデータが実際には宣言済データベース・キャラクタ・セットのデータでないことです。実際には別のキャラクタ・セットのデータであったり、バイナリ・データであったり(たとえば、イメージ、固有のワード・プロセッサ形式のドキュメント、またはカスタムの方法で暗号化されたテキストが含まれている)、1つの列に複数のキャラクタ・セットが存在している場合があります。

前述の状況は、パススルー構成で発生する可能性があります。この構成においては、(通常はNLS_LANGクライアント設定を介して)クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されています。これらのキャラクタ・セットが同じであるため、Oracle通信プロトコルでは変換が必要でないと判断され、クライアント・キャラクタ・セットからサーバー・キャラクタ・セットへの変換が行われません。クライアント・アプリケーションからのデータが実際に宣言済キャラクタ・セットのデータであるかぎり、この構成でも問題はありません。しかし、データのキャラクタ・セット変換も文字検証も実行されないため、どのようなバイト・シーケンスも実際にデータベースに格納され、そのままの状態で取得される可能性があります。クライアント・アプリケーションのみでデータが解釈されるかぎり、格納されたバイト・シーケンスがデータベース・キャラクタ・セットとは異なる文字エンコーディングに一致する場合や、読取り可能なテキストにまったく一致しない場合があります。

移行時にこのような不適切なデータにデフォルトのキャラクタ・セット変換が適用されると、変換中にデータの一部が消失し、ガベージが生成されます。これは、古いデータベース・キャラクタ・セットから新しいキャラクタ・セットへのコード・マッピングのデフォルトの適用によって、格納されているバイト・シーケンスが変換されることが原因です。バイナリ・データは変更できないため、バイナリ・データに対してこのマッピングを行うことは明らかに不適切であり、さらにアプリケーションにより古いデータベース・キャラクタ・セットとは別のキャラクタ・セットのデータであると解釈されたデータに対してこのマッピングを行うことも通常は不適切です。

この問題を回避するためには、いくつかの方法があります。1つは、列のデータ型をRAWまたはLONG RAWに変更する方法です。バイナリ・データの場合はこの方法が推奨されます。また、問題があると疑われる列の変換をスキップし、クライアント・キャラクタ・セット宣言を新しいデータベース・キャラクタ・セットに更新した後も、アプリケーションで引き続きパススルー構成を使用する方法もあります。この方法は一般的には推奨されませんが、1つの列のデータが実際に複数のキャラクタ・セットに格納されており、これらのキャラクタ・セットの自動検出が不可能な場合は、この方法を選択するしかないこともあります。最後に、DMUでは、任意の列の実際のキャラクタ・セットをソース・データベース・キャラクタ・セットとは別のキャラクタ・セットとして宣言できます。これにより、列内のデータの適切なコード・マッピングに従って変換が実行されるようにDMUを設定できます。

パーティション化

レンジによるパーティション化を行うと、パーティション化キーの値がパーティション境界値と比較されて、行が複数のパーティションに配分されます。この比較では、文字値のバイナリ記憶域表現が参照されます。順序を保持しない方法でUnicodeに変換する場合、キーと境界の両方の値のバイナリ記憶域表現が変更される可能性があります。その結果、次の3つの問題が発生する可能性があります。

1. 特定のパーティション化キーが、そのキーが属するパーティションの下限と上限の範囲をソートしないことがあります。

2. パーティションの内部で境界値の順序と同じ順序の番号が付けられます。Unicodeへの変換時に境界値によってそのソート順序が変更された場合、内部の番号付けが無効になります。

3. 一部のマルチバイト東アジア・キャラクタ・セットでは、2つの異なる文字が同じUnicode文字にマップされることがあるため、まれに2つのパーティション境界が同じになることがあります。Unicodeでは、レガシー・キャラクタ・セットでエンコードされる特定の中国語文字の特定の形状のバリアントが個別にエンコードされません。

パーティション表のパーティション化境界で非ASCII文字が使用されている場合、変更したDDLを使用してそのパーティション表を再作成する必要がないことがあります。パーティション化キーの値が影響を受ける場合のみ、行を複数のパーティション間で移動する必要があるため、表に対する行移動を有効にする必要があります。

最大索引キー・サイズ

索引のキー・サイズは、キー列の最大長を使用して計算されます。サポートされる最大索引キー・サイズは、データベース・ブロック・サイズにより制限されます。Unicodeへの変換後、拡張された列データが特定の列に確実に格納されるように、ユーザーは列のバイト長を拡張するか、列の長さセマンティクスをBYTEからCHARに変更できます。このような列に対して索引を作成すると、結果として大きくなった索引キーが、サポートされる最大索引キー・サイズを超えることがあります。

この問題を解決するには、次の方法があります。

- ブロック・サイズを拡大します。

- 索引を削除します。

- 複合索引からいくつかの列を削除します。

一意キーおよび主キー

次の2つの状況では、キーの値をUnicodeに変換した後、変換前のキーの値が制約に違反していなくても、一意制約または主キー制約のキー値の一意性が失われることがあります。

- 一部のキャラクタ・セットの一部の文字が同じUnicodeコード・ポイントにマップされるために、AL32UTF8への変換後に2つの異なるテキスト値が同じ値になることがあります。たとえば、0xED40と0xFA5Cの2つのJA16SJISコード・ポイントは、U+7E8Aにマップされます。

- 最後の部分のみが異なる2つのテキスト値は、変換時に変換後の長さが列の最大長を超えたために切り捨てられた場合、同じになることがあります。

通常、これらの問題を解決するためには、キーの値を手動で変更する必要があります。

導出または暗号化されたデータ

アプリケーションには、文字データから導出された情報が、そのデータのバイナリ記憶域表現に依存する方法で格納される場合があります。たとえば、アプリケーションに数値列のテキストとは別にテキスト長が格納される場合などです。このテキストが拡張された場合、このような列は自動的には更新されません。あるいは、アプリケーションでチェックサムや暗号化形式の文字値が計算および格納される場合もあります。チェックサムまたは暗号テキストは、データベース・キャラクタ・セット内のバイナリ記憶域表現に基づいている場合、キャラクタ・セット変換によって表現が変わると無効になります。

このような導出された値は、移行後に再同期する必要があります。暗号化されたテキストの場合、通常は、テキストを変換直前に復号化してから変換し、その後すぐに再暗号化する必要があります。セキュリティ上の理由から、テキストが復号化される時間は最小限に抑える必要があり、またセキュリティ違反を未然に防ぐためにデータベース・サーバーに追加の保護を適用する必要がある場合があります。

Oracle Transparent Data Encryption機能は通常、移行プロセスに対しても透過的であり、手動での復号化や再暗号化は必要ありません。

バイナリ・データ型に格納された文字データ

アプリケーションには、RAW、LONG RAW、BLOBなどのバイナリ・データ型の文字データが格納される場合があります。このようなアプリケーションでは、データベース・キャラクタ・セットを使用してこのデータを解釈および処理することがあります。データベース・キャラクタ・セットを移行するが、新しいデータベース・キャラクタ・セットに一致させるためにバイナリ・データ型の文字データを再エンコードしない場合、アプリケーションに障害が発生します。このガイドで説明しているDatabase Migration Assistant for Unicodeのような自動移行ツールは、どのバイナリ列に文字データが含まれているか、またその列にキャラクタ・セット変換が必要であるかを認識しません。さらに、文字データがバイナリ構造のバイナリ・データと混在している場合、単に列値全体を変換することもできません。このため、必要な場合は、バイナリ・データ型の文字データを手動で検出して変換する必要があります。

キャラクタ・セット移行: 依存オブジェクト

変換プロセス中に表のデータが変更されると、索引(標準索引、ファンクション索引およびドメイン索引)やマテリアライズド・ビューなど、このデータのコピーが格納されるすべてのオブジェクトがこの変更の影響を受けます。変換方法によっては、これらのオブジェクトを削除してから再作成する必要があることも、データベースにより自動的に同期化されることもあります。パフォーマンス上の理由で、自動同期を行うよりも、依存オブジェクトを削除してから変換後に再作成するほうが効率的な場合があります。

トリガーも、変更に対してビジネス要件上許容されないような反応をすることがあるため、影響を受けます。たとえば、ビジネス・ルールではユーザーが開始した変更のみが監査されればよいのに、トリガーによって最終変更日付および変更ユーザーIDが移行プロセスの日付およびIDに設定される場合などです。このため、基礎となる表を変換する前に、トリガーを無効化する必要があります。

前述の問題のほとんどは、DMUによって自動的に処理されます。

キャラクタ・セット移行: 読取り専用およびアクセス不能オブジェクト

明示的に読取り専用とマークされた表、外部表、読取り専用表領域に格納された表などの表は、読取り専用です。このような表は、読取り/書込みにしないと変換できません。表が明示的に読取り専用とマークされている場合を除き(この場合は移行プロセスにより一時的に削除できます)、これ以外の前述の理由には、手動で対処する必要があります。

通常、外部表は変換の必要がありません。外部表(SQL*Loaderまたはデータ・ポンプ)のソース・ファイルのキャラクタ・セットが適切に宣言されていれば、データがファイルからフェッチされるたびにデータベースは自動的に文字データを新しいデータベース・キャラクタ・セットに変換します。パフォーマンス上の理由で、この変換が行われないようにファイルを完全に変換することも考慮してください。ソース・ファイルのキャラクタ・セットが適切に定義されていないが、パススルー構成のみが原因でファイルの内容をフェッチできる場合(「データの無効なバイナリ記憶域表現」の説明を参照)、ファイルのキャラクタ・セット宣言を修正する必要があります。データ・ポンプ・ファイルの場合、これは軽微な作業です。

読取り専用の表領域は、CD-ROMやDVD-ROMなどの読取り専用媒体に格納される場合があります。このような表領域に変換可能データが存在している場合、この表領域を標準のディスク記憶域に移動して読取り/書込みにし、データベースを変換した後、表領域を再び読取り専用にしてから、読取り専用媒体に再びコピーします。たとえば、アーカイブに使用するデータベースにこのような表領域が多数存在し、これらを変換前にすべて読取り/書込みにすることがディスク記憶域の要件上適切でない場合は、アーカイブ専用のデータベースを古いデータベース・キャラクタ・セットで作成してから、トランスポータブル表領域機能を使用して読取り専用の表領域を1つずつこの新しいデータベースに移動することを考慮してください。これで、元のデータベースを移行できるようになります。アーカイブ用データベース内の読取り専用データには、データの取得時に必要なキャラクタ・セット変換を取り扱うデータベース・リンクを介してアクセスできます。

表は、オフライン状態になっている表領域またはデータ・ファイルに格納できます。このような表のデータにはアクセスできません。データをスキャンして移行の問題を検出することも、データを実際に変換することもできません。文字の列が存在する表を含むオフラインの表領域およびデータ・ファイルは、キャラクタ・セット移行プロセスを開始する前にオンラインにしておく必要があります。

キャラクタ・セット移行: 停止時間

停止期間とは、本番データベースにアクセスするすべてのアプリケーションが停止され、移行ツールからしかデータベースにアクセスできない時間です。停止期間は、データベースの実際の変換を実行するために必要です。問題のスキャンとクレンジングの大部分は、ピーク時間帯を避けて標準の生産作業と並行して実行できます。

移行プロセス中の停止期間はできるだけ最小限に抑えてください。実際の移行にかかる時間に加え、なんらかの問題が発生する可能性およびその解決にかかる時間も考慮してください。許容される停止時間は、ミッションクリティカルなアプリケーションの場合は数時間、一般的なデータ・ソースの場合は数日にわたるなど、様々に異なります。

この移行方法では通常、データ問題の最終スキャンからデータベースの実際の変換までかかる許容時間に関して、ある程度の柔軟性があります。停止期間の開始前に本番データベースで最終スキャンを実行すると、停止期間はその分短くなりますが、最終スキャンから停止期間までの間に新しい問題が発生する可能性があります。停止時間の要件とデータベース・アクセス・パターンを分析して、データ整合性の問題が発生する可能性と、本番使用でデータベースにアクセスできなくなる状態を比較考量する必要があります。

DMUには、選択した表のみをスキャンする柔軟性があるため、新しい問題が発生する可能性が大きい表のみを停止期間内にスキャンできます。

キャラクタ・セットの移行: 障害リカバリ

移行を実行する場合、ソフトウェアの欠陥やハードウェアの障害といった多くの理由により、プロセスが突然中断することがあります。その場合、データベースが不整合な状態で残る可能性があります。移行ユーティリティにより移行を再開できない場合、通常はバックアップからリカバリするか、フラッシュバック・データベース機能を使用するかして、データベースを整合した状態に戻す必要があります。移行プロセス中の障害に対処することは、移行計画に不可欠な作業です。

関連項目:
データベースのリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

キャラクタ・セット移行: アプリケーションへの影響

データベースのキャラクタ・セットを移行する場合、特にシングルバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットに移行する場合、このデータベースを使用するアプリケーションに大きな影響を与える可能性があります。アプリケーションは次のような影響を受ける可能性があります。

- 長さ拡張の問題を解決するために表列の長さの調整や他のデータ型への移行を行った場合、アプリケーション・コード内のバッファ変数を拡大し、CLOBデータを処理するようにアプリケーション・ロジックを適応させる必要があることがあります。

- アプリケーションがデータベース・キャラクタ・セットの文字コードの最大バイト幅を想定することがあります。

- アプリケーションが文字値の特定のバイナリ順序に依存していることがあります。Unicodeでは、非ASCII値の順序がレガシー・キャラクタ・セットの順序と異なることがよくあります。

- 新しいマルチバイト・データベース・キャラクタ・セットを最大限に活用するために、マルチバイト・テキストが正しく処理されるようにシングルバイト・アプリケーションを適応させる必要があることがあります。これは軽微な変更ではありません。

通常、前述のアプリケーション問題にすべて手動で対処する必要があります。アプリケーション開発者は、移行後の本番データベースのテスト・コピーを使用してアプリケーションを確認およびテストする必要があります。

2 DMU入門

この章では、Database Migration Assistant for Unicode (DMU)の概要を示し、このユーティリティを使用してキャラクタ・セットを移行する際の基本的なワークフローについて説明します。

この章は次の項で構成されています。

- Database Migration Assistant for Unicodeの使用: ロードマップ

- DMUのインタフェースおよびナビゲーションの概要

- 要件およびセキュリティの考慮事項の概要

- DMUに関する最初のタスクの実行

- DMUユーザー・インタフェースの概要

- データ準備の概要

- データ変換の概要

Database Migration Assistant for Unicodeの使用: ロードマップ

この項では、DMUの使用に関連するタスクの概要を示します。

Database Migration Assistant for Unicodeを使用する手順は、次のとおりです。

1. 要件を確認します。
環境がDMUを正常に使用するための要件を満たしていることを確認します。

「データベース要件の概要」、「Javaランタイム要件の概要」および「DMUセキュリティの考慮事項の概要」を参照してください。

2. DMUのインストール、メイン・ユーザー・インタフェースの確認、データベース接続の作成、ユーザー・インタフェースの確認、DMUリポジトリのインストールなど、基本的な準備タスクを実行します。
「DMUのインストール」、「データベース接続の作成」、「移行リポジトリのインストール」および「DMUユーザー・インタフェースの概要」を参照してください。

3. データベースをスキャンして、Unicodeへの正常な移行を妨げる可能性のある問題を検出します。
「データベースのスキャン」を参照してください。

4. スキャン・フェーズ中に検出した潜在的な問題のあるデータベースをクレンジングします。
「データのクレンジング」を参照してください。

5. データベースをUnicodeに変換します。
「データベースの変換」を参照してください。

6. データベースを検証して、キャラクタ・セットがUnicodeとなったこと、および例外データが含まれていないことを確認します。
「Unicodeとしてのデータの検証」を参照してください。

DMUのインタフェースおよびナビゲーションの概要

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より古いバージョンでのデータベースの移行はサポートしません。

Javaランタイム要件の概要

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サイトを参照してください。

DMUセキュリティの考慮事項の概要

このリリースの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にはインストーラは付属していません。インストール・ファイルを任意のディレクトリ内に解凍して、ユーティリティをインストールします。

1. DMUをインストールするには、ダウンロードしたアーカイブ・ファイルを、DMUを実行するホスト上の任意のディレクトリに解凍します。

2. アーカイブ・ファイルを解凍した後、DMUファイルへの書込みが自分と他の認可済オペレーティング・システム・ユーザーにのみ許可されていることを確認してください。DMUホストへのアクセス権を持つ非特権ユーザーがDMUファイルを変更して、後からSYSDBA資格証明でDMUが起動されたときに任意のSQL文が実行される可能性があるため、このことは非常に重要です。このようなSQL文はデータベース・セキュリティを損う可能性があります。

3. DMUのインストール後、DMUで移行プロセスを行うデータベースを初期化します。

データベース接続の作成

分析または移行するデータベースへの接続を作成する必要があります。

データベース接続を作成する手順は、次のとおりです。

1. DMUを使用してデータベース移行を開始するには、あらかじめこのツールにデータベース接続の詳細を提供する必要があります。このためには、ナビゲータ・ペインで「データベース」ノードを右クリックしてコンテキスト・メニューを開くか、メニュー・バーから「ファイル」メニューを開き、「データベース接続の作成」を選択します。図2-1に示すような新規データベース接続の作成ダイアログ・ボックスが表示されます。このダイアログで、ログインID、パスワード、ホスト名、ポート番号、データベース・サービス名などの接続詳細を入力します。

図2-1 データベース接続の作成

2. 接続を定義する次の情報を入力します。

- 接続名
接続に、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ユーザー・インタフェースから開始することもできます。

移行リポジトリをインストールする手順は、次のとおりです。

1. 初めてデータベースに接続すると、DMUではリポジトリをインストールするように要求されます。リポジトリのインストールを要求されない場合は、使用するデータベースを右クリックして「DMUリポジトリの構成」を選択することにより、リポジトリをインストールできます。また、移行メニューから「DMUリポジトリの構成」を選択することもできます。いずれの場合も、リポジトリ構成ウィザードが表示されます。図2-2に、その表示画面を示します。

図2-2 リポジトリ構成ウィザード - タスクの選択

2. ウィザードの最初のページで選択できる項目は、「移行モードでリポジトリをインストールする」のみです。これを選択した後、「次へ」をクリックします。
「次へ」をクリックすると、リポジトリ構成ウィザードの2番目のページが表示されます。図2-3「リポジトリ構成ウィザード - タスクの詳細」に、このページの例を示します。

図2-3 リポジトリ構成ウィザード - タスクの詳細

3. ここでは、移行のターゲット・キャラクタ・セットを選択します。通常推奨されるキャラクタ・セットであるAL32UTF8か、Oracle Applications 11iなどの特定のアプリケーションとの互換性のために必要になることがあるUTF8のいずれかを選択できます。キャラクタ・セットを選択した後、「次へ」をクリックします。図2-4「リポジトリ構成ウィザード - 表領域の選択」が表示されます。

図2-4 リポジトリ構成ウィザード - 表領域の選択

4. 3ページ目で、リポジトリをインストールする表領域を選択できます。デフォルトの表領域はSYSAUXです。移行リポジトリには個別の空の表領域を使用することをお薦めします。これにより、本番表領域のフラグメンテーションを回避できます。選択した表領域の使用可能な空き領域が、リポジトリの内容を格納するのに十分な大きさであることを確認します。リポジトリに必要な領域の大きさは、スキャンで選択した行識別子収集レベルと、データベース内の変換が必要な文字データや変換可能性の問題がある文字データの量によって大きく変わるため、リポジトリに必要な領域を見積もることは困難です。このため、必要に応じて表領域が拡大されるように、リポジトリ表領域のデータ・ファイルの自動拡張オプションを有効にすることをお薦めします。ディスク領域全部が使用されることがないように、データ・ファイルの最大サイズ制約を定義します。
DMUリポジトリをインストールするためには、表領域に8K以上のブロック・サイズが必要です。

「完了」をクリックして、リポジトリをインストールします。

リポジトリをインストールした後は、データの作業を開始できます。

移行ステータスの追跡

データベース接続が確立されると、DMUメイン・ウィンドウのクライアント・ペインに移行ステータス・タブが表示されます。移行プロセスの進行状況は、このタブの情報を参照して追跡できます。このタブには、リポジトリのインストール、データベースの問題のスキャン、検出された問題の解決、およびデータの変換といったDMUプロセスの重要なマイルストンが表示されます。移行ステータス・タブには、各マイルストンの完了ステータスが表示され、推奨される次のアクションが示され、正常な変換を妨げていた問題が一覧表示されます。この情報はすべて、ワークフローの進行状況を示すものです。定期的に移行ステータス・タブに戻って、Database Migration Assistant for Unicodeによる移行プロセスの説明を参照してください。

図2-5に、移行ステータス・タブの内容の例を示します。移行ステータス・タブには、移行リポジトリのインストール、データベースのスキャン、移行問題の解決、およびデータベースの変換という主要な4つの移行ステップがそれぞれ説明されます。このタブには各ステップのステータスが表示され、推奨される次のアクションが示されます。「詳細」リンクをクリックすると、表示された情報を拡張するヘルプ・ページが開きます。

ステップ1: 移行リポジトリのインストール・セクションの「ステータス」領域に、接続されたデータベースに移行リポジトリが含まれているかどうかが示されます。また、インストールされているリポジトリが互換性のないバージョンであることも報告されます。適切なバージョンのリポジトリをインストールするまでは、以降の移行プロセス・ステップを続行できません。次のアクション領域に示されたアドバイスに従います。この領域のテキストがリンクになっている場合、リンクをクリックすると推奨アクションが開始されます。「移行リポジトリのインストール」を参照してください。

「ステップ2: データベースのスキャン」の「ステータス」領域では、データベースのスキャン・ステータスが報告されます。データベースの状況は次のいずれかです。

- 未スキャン - 移行リポジトリの作成後もスキャンはまだ実行されていません

- スキャン中 - 現在、データベースのスキャンが実行されています

- 一部スキャン済 - データベースの一部のみのスキャンが完了しています

- すべてスキャン済 -データベース内のすべての表に有効なスキャン結果が存在しています

- 無効化された結果を含む - 最後のスキャン以降に表の構造が変更されたため、一部の表のスキャン結果が無効化されています

データベースの一部がスキャンされていない場合、「データベースのスキャン」を参照し、スキャン結果が存在しないか無効であるすべての表をスキャンします。

図2-5 移行ステータス・タブ

ステップ3: 移行問題の解決セクションの「ステータス」領域に示された情報に、データベースの内容の実際の変換を開始する前に解決する必要のある問題のリストが含まれている場合があります。「未解決の変換可能性の問題が見つかりました」というテキストの左側にあるプラス(+)アイコンをクリックすると、問題が表示されます。これらの問題は、警告として、または障害となっている問題として分類されます。

黄色のマークが付いた警告は、場合によって変換中に問題が発生するデータベースの特徴および構成の詳細を説明するものです。DMUでは、これらの問題が発生する確率を自動的に分析することはできません。データベース変換のパフォーマンスを低下させる可能性があるが、他の影響が現れる可能性があるためにDMUで変更できないデータベースの構成詳細を説明する警告もあります。表示される可能性のある警告は次のとおりです。

- データベース内にユーザー定義のOLAPアナリティック・ワークスペースが存在します。

- データベースはスタンバイ・データベースです。

- データベース内に変換可能データを含む外部表が存在します。

- データベース内に変換可能な主キー・ベースのオブジェクト識別子(OID)が存在します。

- 現在の設定では、行の移動が無効になっている表に対してCTAS変換方法を使用することはできません。

- データベースまたは表領域のFORCE LOGGINGモードをオフにすると、変換のパフォーマンスが向上する可能性がありますが、それによってメディア・リカバリを実行できなくなることがあります。

- 表の行移動オプションが有効になっていないため、一部のパーティション表の変換がエラーORA-14402により失敗しました。

- 一部の表が変換から除外されました。

- 一部の列にある変換可能性の問題は無視され、結果のデータにかかわらず列は変換されます。

一部の警告を無視して変換を開始することもできますが、必ずすべての警告の意味を理解してください。

赤色で示された障害となっている問題は、DMUでの変換フェーズの開始を妨げている問題です。これらを無視すると、データベース内に問題が発生することがわかっています。障害となっている問題をすべて解決しないと、データベースの変換に進むことはできません。すべての問題が解決されると、ステップ3: 移行問題の解決セクションの「ステータス」領域に「未解決の変換可能性の問題は見つかりませんでした」と表示され、変換を続行しても問題ないとみなされます。

ステップ4: データベースの変換セクションの「ステータス」領域に、データベース変換が開始されたかどうかが示され、続いて正常に完了したかどうかが示されます。

移行のステータスを表示する手順は、次のとおりです。

1. クライアント・ペインの移行ステータス・タブをクリックします。

2. DMU外部でデータベースを変更して変換可能性の問題の一部を解決した場合は、「再テスト」をクリックすると、DMUでデータベースが再チェックされてステータス情報が更新されます。

3. このタブを開くには、移行メニューから「移行ステータス・パネル」を選択します。

DMUユーザー・インタフェースの概要

図2-6に、DMUユーザー・インタフェースのメイン・ウィンドウのデフォルト・レイアウトを示します。ウィンドウの一番上にメニュー・バーとツールバーが表示され、一番下にステータス・バーが表示されます。これ以外のウィンドウ領域は、複数のペインに分かれています。

ウィンドウの左上隅のナビゲータ・ペインには、DMUで処理されるデータベース・オブジェクトのツリーが表示されます。ツリー内のノードの最初のレベルは、DMUが接続可能なデータベースを表しています。開いている接続に1つのみのデータベース・ノードを関連付けることができます。接続の詳細は、「データベース接続の作成」を参照してください。

現在接続が開いているデータベース・ノードを展開すると、移行プロセスに関連するデータベースに含まれるスキーマ、表および列のサブツリーが表示されます。関連する列とは、文字データが含まれるためにUnicodeキャラクタ・セットへの変換時にキャラクタ・セット変換が必要となる列のことです。DMUでの処理方法が違うため、データ・ディクショナリを構成する事前定義済Oracleスキーマは1つにまとめられ、それぞれデータ・ディクショナリ・グループ・ノードの下に表示されます。その他のスキーマは、アプリケーション・スキーマ・グループ・ノードの下に表示されます。同様に、スキーマ内の表はマテリアライズド・ビューとして「マテリアライズド・ビュー」グループ・ノードの下にまとめられ、それ以外の表は「表」グループ・ノードの下にまとめられます。

ナビゲータ・ツリーのノード名の左側にステータス・アイコンが表示されることがあります。表2-1に、特定のノード・タイプに使用できるアイコンとその意味を示します。

ウィンドウの右上隅にあるクライアント・ペインは、移行プロセスで様々なタブが開かれる領域です。これらのタブには、オブジェクトのプロパティ、スキャン結果、クレンジング・ツール、およびタスクの進行状況ステータスが表示されます。この章の以降の各項で、すべてのタブについて説明します。DMUの起動後、データベースに接続するまでは、クライアント・ペインにはDMUの関連情報の様々なソースへのリンクが集まった「開始ページ」のみが表示されます。

ウィンドウの左下部分にある「プロパティ」ペインには、ナビゲータ・ペインまたはデータベース・スキャン・レポートで最後にクリックしたノードの選択済プロパティが表示されます(「データベースのスキャン」を参照)。表示されるプロパティは、ノードのタイプによって異なります。

ウィンドウの右下部分にあるログ・ペインには、移行プロセス中にDMUによって報告されたエラー・メッセージおよび警告メッセージが表示されます。

図2-6 DMUユーザー・インタフェース

DMUのメイン・ウィンドウのレイアウトは、ペインおよびタブを新しい位置にドラッグすることでカスタマイズできますが、カスタマイズしたレイアウトが次のプログラム実行時まで保持されることはありません。

表2-1 Database Migration Assistant for Unicodeのアイコン

アイコン

列ノード

表、スキーマ、データベースおよびグループ・ノード

アイコンなし

列は一度もスキャンされていません。

表/スキーマ/データベース/グループ内の列はいずれも一度もスキャンされていません。

チェック・マーク

列が正常にスキャンされ、問題は見つかりませんでした。

表/スキーマ/データベース/グループ内のすべての列が正常にスキャンされ、問題は見つかりませんでした。

赤い円の中の白いX

列をスキャンするための最新の試行に失敗しました。

表/スキーマ/データベース/グループの1つ以上の列をスキャンするための最新の試行に失敗しました。

警告を示す黄色い三角形

列は正常にスキャンされましたが、いくつかの変換可能性の問題が見つかりました。

表/スキーマ/データベース/グループ内のすべての列は、正常にスキャンされたか、一度もスキャンされていないか、またはスキャンされた列に変換可能性の問題が見つかったためにスキャン結果が無効化されています。

斜線入りの赤い円

列はすでにスキャンされていますが、その列を含む表が変更されたか、クレンジング・アクションが適用されたために、スキャン結果が無効化されています。

表/スキーマ/データベース/グループ内の1つ以上の列のスキャン結果が無効化されており、この表/スキーマ/データベース/グループ内のその他の列はいずれも一度もスキャンされていません。

拡大鏡

適用されません。

表/スキーマ/データベース/グループ内の一部の列は正常にスキャンされ、問題は見つかりませんでしたが、他の列が一度もスキャンされていないか、そのスキャン結果が無効になっています。

動く拡大鏡

列はスキャン中です。このステータスは他のすべてのステータスを上書きします。

表/スキーマ/データベース/グループ内の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に指定するものです。選択したキャラクタ・セットがスキャン中のテスト変換に適用されて、実際の変換は変換ステップで行われ、クレンジング・エディタで表示されるデータの解釈にはこのセットが使用されます。クレンジング・エディタの列データが判読できない場合、列のキャラクタ・セットが適切に選択されていない可能性があります。

クレンジング後、データベースを再スキャンして、変更によって問題が正常に解決されたことを確認します。変換フェーズに進む前に、変換の問題がなくなるまでこのプロセスを繰り返してスキャンとクレンジングを行います。

関連項目:
詳細は、第6章「DMUを使用したデータのクレンジング」を参照してください。

データ変換の概要

データ変換フェーズでは、データベースの内容が実際に変更されます。変換が完了すると、データベース・キャラクタ・セットはUnicodeになります。変換は次のステップで構成されます。

- 変換の準備

- データの変換

変換の準備

移行メニューで「データベースの変換」を選択して変換フェーズを開始するようにDMUで指定すると、DMUではまず変換実行可能性テストが実行されます。このテストでは、次のことがチェックされます。

- 「データベース要件の概要」に一覧表示されているすべてのデータベース変換可能性要件が満たされていること

- データベース内のすべてのデータのスキャンが完了し、有効なスキャン結果が存在していること
クレンジング・アクションを行うと結果が無効になることがあるため、その場合はクレンジングした表を再スキャンする必要があります。

- データベース内にバイナリ表現や長さの問題のあるデータが存在していないこと

テストが成功すると、DMUによって変換の計画が表示されます。この計画には、索引、制約、トリガーなどの補助オブジェクトを処理する文を含め、データベースを変換するために実行されるすべてのSQL文が表示されます。この計画は、必要に応じてカスタマイズできます。DMUでのデータベースの変換方法は、データベース・レベルおよび表レベルの様々なオプションを使用して指定できます。たとえば、特定の表に対する変換方法を設定したり、変換ステップに関与するプロセス数を設定できます。変換計画が生成され、変換の進行状況タブに表示されます。これで、「表変換計画の編集」または「データベース変換パラメータの編集」をクリックして、使用可能なオプションを変更できるようになります。

データの変換

次の手順は、実際にデータをUnicodeに変換することです。変換の進行状況タブの変換ボタンをクリックすることにより、変換計画を受け入れて変換を開始します。DMUによって変換実行可能性テストが繰り返され、変換計画の作業によって新たに問題が発生していないか確認されます。また、データベースに他のセッションが接続されていないことと、データベースが排他的モードでマウントされていることも確認されます。その後、DMUによってデータの移行が開始され、変換計画に基づいて文が実行されます。

変換の進行状況タブで、変換の進行状況を監視できます。

DMUでデータの変換に使用されるプロセスの概要は次のとおりです。

1. データベースが制限付きモードになります。

2. 様々なジョブ・キュー・プロセスが無効化されます。

3. 選択した索引が削除または無効化されます。

4. 選択したトリガーおよび制約が無効化されます。

5. ユーザー表および選択したデータ・ディクショナリ表のデータがUnicodeに変換されます。

6. データ・ディクショナリ内のCLOB列が変換されます。

7. ALTER DATABASE CHARACTER SET文が発行されます。

8. トリガーと制約が有効化され、索引と制約が再作成されます。

9. データベース・インスタンス・パラメータがリストアされます。

表の変換を実行するには、UPDATE文を使用して表の列を更新するか、CREATE TABLE AS SELECT文を使用して表の再作成中に列を変換します。表の行の大部分を変換する必要がある場合は、表を更新するよりも再作成するほうが高速です。

変換が完了すると、DMUによって、先に削除または無効化されたすべてのオブジェクトが再作成または再有効化されます。ログ・ペインを参照して、エラーが生成されていないか確認できます。

関連項目:
変換GUIの詳細は、「データベースの変換」を参照してください。

3 DMUでのオブジェクト・プロパティの表示および設定

この章では、Database Migration Assistant for Unicode (DMU)のユーザー・インタフェースの要素を示し、これらを使用して様々なオブジェクト・プロパティを表示および設定する方法について説明します。

データベース、スキーマ、表などのデータベース・オブジェクトの様々なプロパティを表示するには、ナビゲータ・ペインでオブジェクトのノードを右クリックし、コンテキスト・メニューから「プロパティ」を選択します。DMUメイン・ウィンドウのクライアント・ペインに、このタイプのオブジェクトにあわせて調整されたプロパティ・タブが表示されます。各プロパティ・タブには、最大4つのサブタブ(「一般」、「スキャン」、「準備状況」および「変換」)が含まれます。サブタブを表示するには、タブの左サイドバーでサブタブの名前をクリックします。

サブタブには、移行プロセスの特定のステップに関連するプロパティおよび情報が表示されます。「一般」サブタブには、移行のすべてのフェーズに関連するプロパティが表示されます。スキャン・サブタブには、スキャン・プロセスを制御するパラメータおよびスキャン結果が表示されます。準備状況サブタブには、オブジェクトに含まれるデータが実際の変換ステップに対して準備できているかが表示されます。データが準備できていない場合、このサブタブにその理由が表示されます。変換サブタブには、変換ステップを制御するパラメータが表示されます。次の各項で、すべてのオブジェクト・プロパティ・タブで使用可能なプロパティについて説明します。

プロパティ・タブでプロパティを変更した場合は、「適用」をクリックして変更を保存します。

この章は次の項で構成されています。

- データベース・プロパティの表示および設定

- スキーマ・プロパティの表示および設定

- 表プロパティの表示および設定

- 列プロパティの表示および設定

データベース・プロパティの表示および設定

図3-1に示すように、データベース・プロパティ・タブには4つのサブタブ(「一般」、「スキャン」、「準備状況」および「変換中」)が含まれます。

データベース・プロパティ: 一般

データベース・プロパティ・タブの「一般」サブタブには、次のプロパティが表示されます。

- ユーザー名やホスト名などの接続詳細
接続詳細は、「データベース接続の作成」を参照してください。接続詳細は、この項の説明に従って変更してください。

- データベースのキャラクタ・セットの情報
データベース・キャラクタ・セットの情報は、次の3つのプロパティで構成されます。

- 現行データベース・キャラクタ・セット
これは、データ型VARCHAR2、CHAR、LONGおよびCLOBの列に格納されたデータを解釈するために使用されるデータベースの現行の宣言済キャラクタ・セットです。

- 想定データベース・キャラクタ・セット
DMUでは、移行中に文字データをスキャンおよび変換するとき、想定データベース・キャラクタ・セットがデフォルトのソース・キャラクタ・セットとして使用されます。データベースが適切なキャラクタ・セット構成で使用されていれば、想定キャラクタ・セットはデータベース・キャラクタ・セットと同じになります。ただし、「データの無効なバイナリ記憶域表現」で説明されているように、パススルー構成においては、文字列の全部または大部分に、宣言済データベース・キャラクタ・セットとは異なるクライアント・ワークステーションのキャラクタ・セットでデータが格納されることがあります。このような場合、データベースの内容の実際のキャラクタ・セットを特定した後、これを想定データベース・キャラクタ・セット・プロパティの値として設定して、データの正しい解釈方法をDMUに指定します。

- ターゲット・データベース・キャラクタ・セット
これは移行のターゲット・キャラクタ・セットで、UTF8かAL32UTF8のいずれかです。このプロパティを変更するには、移行リポジトリをアンインストールしてから再びインストールする必要があります。

「適用」をクリックして、このサブタブで行った変更を保存します。

図3-1 データベース・プロパティ: 一般

データベース・プロパティ: スキャン

データベース・プロパティ・タブのスキャン・サブタブでは、このデータベース内のスキャン・プロセスを制御する一般的なパラメータを設定し、データベースのスキャン結果の集計を参照できます。スキャン・サブタブの図は、図3-2を参照してください。

図3-2 データベース・プロパティ: スキャン

スキャン・サブタブのプロパティは次のとおりです。

- スキャン・プロセス数
これは、データベースのスキャンに使用される同時プロセスの数を指定します。各スキャン・プロセスは、DMU内のパラレル・スレッドと、このスレッドによりサーバー上に作成されたデータベース・セッションで構成されます。このプロパティのデフォルト値は、データベース・サーバー上のCPUの数から導出されます。この値を調整するには、値を変更し、1回のデータベース・スキャンを完了するために必要な時間を測定します。少数の小さな表をスキャンするようにDMUに指定した場合、このスキャンに使用されるプロセスの数がこのプロパティの値より少なくなることがあります。

また、「スキャン・プロセス数」はスキャン・ウィザードでも変更できます。詳細は、「データベース・スキャン・レポートの概要」を参照してください。

- スキャン・バッファ・サイズ
このプロパティは、DMUで表をスキャンするために各データベース・サーバー・セッションに割り当てられるバッファのサイズ(バイト)を制御します。デフォルト値は1000KBです。1回のスキャンで使用される合計バッファ領域は、スキャン・プロセスの数にこのプロパティ値を乗算した値です。このプロパティの値を大きくすると、割り当てられたバッファ・メモリーがデータベース・サーバー上の使用可能なRAMに収まっているかぎり、スキャンの速度が上がる可能性があります。

また、「スキャン・バッファ・サイズ」はスキャン・ウィザードでも変更できます。詳細は、「スキャン・ウィザードを使用したデータベースのスキャン」を参照してください。

- スキャン・ステータス
このプロパティには、データベースのスキャン・ステータスの集計が表示されます。次の値を指定できます。

- 未スキャン
最後に移行リポジトリがインストールされてから、スキャンは実行されていません。

- 進行中
スキャンは現在進行中です。

- スキャン済
データベース内のすべての表のスキャンが完了し、有効なスキャン結果が存在しています。

- 一部スキャン済
データベース内の一部の表のスキャンが完了し、有効なスキャン結果が存在していますが、その他の表はまだスキャンされていないか、クレンジング・アクションまたはDMU外部でのその構造(メタデータ)の変更によってスキャン結果が無効化されています。

- 問題検出済
データベース内の1つ以上の表に、変換可能性の問題があるデータが含まれています。長さ制限(拡張)または無効なバイナリ表現の問題があるか、またはデータ・ディクショナリ内に変換可能データが存在する可能性があります。

- 失敗
予期しないエラーが発生したため、データベース内の1つ以上の表をスキャンできませんでした。

- 変換する表
これは、変換ステップ中に変換が必要であるとすでに特定されているデータベース内の表の数です。

- 変換する行
これは、データベース内で変換が必要なすべての表の変換する行プロパティ値の合計です。

- スキャン結果
スキャン結果には、データベース内のすべての表のすべてのスキャン済データ・セルが変換可能性の各カテゴリに分類されて表示されます。セルとは、特定の行内の特定の列の値です。カテゴリは次のとおりです。

- 無効なバイナリ表現
セル・データのバイナリ表現は、現行データベース・キャラクタ・セットでは無効です(変換された値に置換文字が含まれます)。つまり、列の想定キャラクタ・セットが不適切であるか、データがバイナリである(セルにJPEGイメージ、暗号化結果、またはバイナリ形式のテキスト・ドキュメントが格納されているなど)か、値にいくつかの破損した文字コードが含まれています。

- データ型制限超過
変換後のセル・データの長さがデータ型を超えています。

- 列制限超過
変換後のセル・データが列に収まりません。

- 変換の必要あり
ターゲット・キャラクタ・セットのバイナリ表現が現行キャラクタ・セットの表現と異なっていますが、長さ制限の問題も無効な表現の問題も見つからなかったため、セル・データを変換する必要があります。

- 変換の必要なし
変換によってデータのバイナリ表現は変更されないため、データに問題はありません。

セルは前述のカテゴリに2回割り当てられます。1つ目の分類は「現在のデータ」という見出しの下に表示され、データベース内の現在の列定義に基づいています。2つ目の分類は「スケジュール済クレンジングの結果を含める」という見出しの下に表示され、スケジュール済クレンジング・アクションを適用した結果の列定義に基づいています。変換ステップでデータが原因で発生するエラーに対応しているのは2つ目の分類のみなので、データベースの内容の変換の準備状況を判断するためにはこの分類を使用します。1つ目の分類は、すべてのスケジュール済クレンジング・アクションが削除された場合に、データベースの内容の変換可能ステータスを判断する基準として使用できます。

- データベース・サイズ
スキャン結果には、次の各表領域に関する詳細が含まれます。

- 表領域
スキャンされた表領域の名前。

- 使用済
使用された領域のサイズ(MB単位)。

- 空き
空き領域のサイズ(MB単位)。

- 合計
表領域の合計サイズ(MB単位)。

- 自動拡張
表領域がサイズ制限に達した場合に、指定したサイズまで自動拡張されるように設定するかどうか。

- 最小拡張
表が1つずつ順次に変換されるベスト・シナリオを想定した場合、変換領域要件を満たすために表領域を拡張する必要のある最小サイズ(MB単位)。変換後のデータ・サイズ拡張と、CTAS方法を使用して変換された最大表の一時領域要件を考慮して計算されます。

空の値は、その表領域がデータベース変換の影響を受けないことを示します。値がゼロの場合、その表領域に最小変換領域要件を満たす十分な未使用領域があることを示します。値がゼロより大きい場合、最小変換領域要件を満たすためにその値の分だけ表領域を拡張する必要があることを示します。表領域の自動拡張が可能であり、デバイスに拡張サイズを格納する十分な空き領域がある場合、データベース変換の開始前に拡張する必要はありません。

- 最大拡張
CTAS変換方法を使用して最大表が同時に変換される最悪のシナリオを想定した場合、変換領域要件を満たすために表領域を拡張する必要のある最大サイズ(MB単位)。変換後のデータ・サイズ拡張と、CTAS方法を使用して変換された最初のN個の最大表の一時領域要件を考慮して計算されます(Nは変換ワーカー・スレッド数)。

空の値は、その表領域がデータベース変換の影響を受けないことを示します。値がゼロの場合、その表領域に最大変換領域要件を満たす十分な未使用領域があることを示します。値がゼロより大きい場合、最大変換領域要件を満たすためにその値の分だけ表領域を拡張する必要があることを示します。表領域の自動拡張が可能であり、デバイスに拡張サイズを格納する十分な空き領域がある場合、データベース変換の開始前に拡張する必要はありません。

- 表領域の見積り
このボタンをクリックすると、DMUですべての表領域の最小表領域拡張と最大表領域拡張が計算されます。この結果を、表領域のサイズを決定するためのガイドラインとして使用してください。十分な記憶域が使用可能な場合は、表領域を最大拡張サイズ近くまで拡張すれば、変換フェーズ中の領域割当てエラーが発生する可能性が低くなります。

DMUでは、Unicodeへの変換時にインラインのままになるインラインCLOBデータの情報が考慮されませんので注意してください。DMUでは、処理を簡単にするために、変換後のセグメントのサイズを見積もる際に、すべてのCLOBデータがLOBセグメントに格納されると想定します。

「適用」をクリックして、このサブタブで行った変更を保存します。

データベース・プロパティ: 準備状況

このサブタブには、変換するデータの準備状況が表示されます。図3-3を参照してください。変換するデータの準備状況プロパティの値は、次のいずれかです。

- 変換の必要なし
データベース内のすべてのデータは変換の必要なしとして分類され、データベースは「変換の準備」で説明されているすべての変換実行可能性テストにパスしました。

- 変換準備完了
データベース内のすべてのデータは変換の必要なしまたは変換の必要ありとして分類され、データベースはすべての変換実行可能性テストにパスしました。

- 変換準備未完了
データベース内の一部のデータが無効なバイナリ表現を持つ、または長さ制限を超えるとして分類されたか、データベースがいくつかの変換実行可能性テストにパスしませんでした。

準備状況のステータスが「変換準備未完了」の場合、問題を説明する追加情報が表示されます。

図3-3 データベース・プロパティ: 準備状況

データベース・プロパティ: 変換

このサブタブのプロパティを使用すると、変換処理の特定の局面を制御できます。図3-4を参照してください。次のプロパティを設定できます。

- 並列度
DMUでCREATE TABLE AS SELECT (CTAS)文を使用して表が変換される場合、このプロパティは、データベースのパラレル実行機能で操作に使用される並列度を設定します。

- 変換プロセス数
これは、データベースの変換に使用される同時処理の数を指定します。各変換プロセスは、DMU内のパラレル・スレッドと、このスレッドによりサーバー上に作成されたデータベース・セッションで構成されます。このプロパティのデフォルト値は、データベース・サーバー上のCPUの数から導出されます。

- パーティション表の行移動を有効化
レンジ・パーティション表またはハッシュ・パーティション表内のパーティション化キー列値を変換すると、変換後のキーが現在行を含んでいるパーティション以外のパーティションを指し示す可能性があります。キー値の更新が正常に完了したら、データベースは行を古いパーティションから新しいパーティションに移動する必要があります。行移動が無効化されている場合にCTASを想定プロパティで説明されているように、行移動は、ALTER TABLE ENABLE ROW MOVEMENT文で明示的に有効化されている表でのみ許可されます。パーティション表の行移動を有効化プロパティを「はい」に設定すると、DMUでは、変換の必要なパーティション化キー列を含むパーティション表の行移動が一時的に有効化されます。

- 行移動が無効化されている場合にCTASを想定
CTAS文を使用して表を変換すると、表内の行の物理アドレス(行識別子)が変更されるため、これらのアドレスを永続的に格納するアプリケーションは、変換後に行を検出できなくなる可能性があります。このためDMUでは、ALTER TABLE ENABLE ROW MOVEMENT文で表内の行の移動が明示的に許可されている場合を除いて、デフォルトではCTAS変換方法は表に割り当てられません。これに対し、新しい表に対する行移動は、CREATE TABLE文で明示的に有効化されていないかぎり、デフォルトで無効化されています。このため、アプリケーションにより行識別子が格納されることはほとんどありませんが、ほとんどのデータベース内のほとんどの表では行の移動は許可されません(行の参照には主キーを使用することをお薦めします)。データベースに接続するアプリケーションが行識別子を格納しないとわかっている場合、行移動が無効になっている場合にCTASを想定プロパティを「はい」に設定すると、DMUによって行移動が有効になっていない表にもCTAS変換方法を割り当てることができます。

- ユーザー指定のLOBセグメントの場合にCTASを想定
デフォルトでは、LOBセグメント名はCTAS変換メソッドでは保管できないため、DMUはユーザー指定のLOBセグメントを含む表のCTAS変換メソッドを割り当てません。ユーザー指定のLOBセグメント名を保管する必要がない場合には、このプロパティを「はい」に設定することで、CTAS変換メソッドを想定できるようになり、変換にちなんで"$DMU"接尾辞をつけることによって名前が変更されます。

- 読取り専用マテリアライズド・ビューの処理
このプロパティは、マスター表の変換完了後に読取り専用マテリアライズド・ビューを処理する方法を指定します。次の選択項目があります。

- 変換後に自動的にリフレッシュする
変換後フェーズで読取り専用マテリアライズド・ビューを自動的にリフレッシュします。これがデフォルトのオプションです。

- SQLスクリプトの生成
マテリアライズド・ビューを自動的にリフレッシュせず、DMU外部で後から実行できる、読取り専用マテリアライズド・ビューをリフレッシュするための文を含むSQLスクリプトを生成します。

- 何もしない
読取り専用マテリアライズド・ビューに対して何もアクションを実行しません。

- 更新可能マテリアライズド・ビューの処理
このプロパティは、マスター表の変換完了後に更新可能マテリアライズド・ビューを処理する方法を指定します。次の選択項目があります。

- 変換後に自動的にリフレッシュする
変換後フェーズで更新専用マテリアライズド・ビューを自動的にリフレッシュします。

- SQLスクリプトの生成
マテリアライズド・ビューを自動的にリフレッシュせず、DMU外部で後から実行できる、更新可能マテリアライズド・ビューをリフレッシュするための文を含むSQLスクリプトを生成します。

- 何もしない
更新可能マテリアライズド・ビューに対して何もアクションを実行しません。これがデフォルトです。

- マテリアライズド・ビューのリフレッシュ中のエラー・ハンドリング
このプロパティは、マテリアライズド・ビューのリフレッシュ中のエラーに対処する方法を指定します。次の選択項目があります。

- 変換を一時停止して問合せ
失敗したSQL文を一時停止し、ユーザーが適切な処理を選択できるようにします。これがデフォルトのオプションです。ユーザーは失敗したSQL文を再試行するか、SQL文を外部スクリプトにエクスポートして続行するか、またはエクスポートせずにスキップするかを選択できます。

- 失敗したSQLをスキップして続行
失敗したSQL文を自動的にスキップし、変換を続行します。

- 失敗したSQLをスクリプトにエクスポートして続行
失敗したSQL文をDMU外で実行できる外部スクリプトに自動的にエクスポートし、変換を続行します。

- 削除されたドメイン索引の処理
このプロパティは、削除されたドメイン索引を処理する方法を指定します。次の選択項目があります。

- 変換後に自動的に再作成する
変換後フェーズで、削除されたドメイン索引を自動的に再作成します。これがデフォルトのオプションです。

- SQLスクリプトの生成
削除されたドメイン索引を再作成せずに、DMU外部で後から実行できる、削除されたドメイン索引を再作成するための文を含むSQLスクリプトを生成します。

- 何もしない
削除されたドメイン索引に対して何もアクションを実行しません。

- ドメイン索引の再作成中のエラー・ハンドリング
このプロパティは、ドメイン索引の再作成中のエラーに対処する方法を指定します。次の選択項目があります。

- 変換を一時停止して問合せ
失敗したSQL文を一時停止し、ユーザーが適切な処理を選択できるようにします。これがデフォルトのオプションです。ユーザーは失敗したSQL文を再試行するか、SQL文を外部スクリプトにエクスポートして続行するか、またはエクスポートせずにスキップするかを選択できます。

- 失敗したSQLをスキップして続行
失敗したSQL文を自動的にスキップし、変換を続行します。

- 失敗したSQLをスクリプトにエクスポートして続行
失敗したSQL文をDMU外で実行できる外部スクリプトに自動的にエクスポートし、変換を続行します。

- その他の索引の再作成中のエラー・ハンドリング
このプロパティは、その他の索引の再作成中のエラーに対処する方法を指定します。次の選択項目があります。

- 変換を一時停止して問合せ
失敗したSQL文を一時停止し、ユーザーが適切な処理を選択できるようにします。これがデフォルトのオプションです。ユーザーは失敗したSQL文を再試行するか、SQL文を外部スクリプトにエクスポートして続行するか、またはエクスポートせずにスキップするかを選択できます。

- 失敗したSQLをスキップして続行
失敗したSQL文を自動的にスキップし、変換を続行します。

- 失敗したSQLをスクリプトにエクスポートして続行
失敗したSQL文をDMU外で実行できる外部スクリプトに自動的にエクスポートし、変換を続行します。

- SQLスクリプトのディレクトリおよびその場所(「参照」ボタン)
出力されたSQLスクリプトを格納する場所、およびその場所にナビゲートするための「参照」ボタンを表示します。

読取り専用マテリアライズド・ビューのリフレッシュ・スクリプトのデフォルト名は次のようになります。

- RefreshMV_connectionName_timestamp.sql

更新可能マテリアライズド・ビューのリフレッシュ・スクリプトのデフォルト名は次のようになります。

- RefreshUpdMV_connectionName_timestamp.sql

ドメイン索引再作成スクリプトのデフォルト名は次のようになります。

- DomainIndexDDL_connectionName_timestamp.sql

失敗したマテリアライズド・ビューのリフレッシュSQL文のスクリプトのデフォルト名は次のようになります。

- FailedMVRefresh_connectionName_timestamp.sql

失敗したドメイン索引再作成SQL文のスクリプトのデフォルト名は次のようになります。

- FailedDomainIndex_connectionName_timestamp.sql

失敗したその他の索引再作成SQL文のスクリプトのデフォルト名は次のようになります。

- FailedOtherIndex_connectionName_timestamp.sql

変換中にスクリプト・ディレクトリ位置を変更すると、その変更は次に作成されるSQLスクリプトから有効になることに注意してください。

図3-4 データベース・プロパティ: 変換

「適用」をクリックして、このサブタブで行った変更を保存します。

スキーマ・プロパティの表示および設定

スキーマ・プロパティ・タブには、3つのサブタブ(「一般」、「スキャン」および「準備状況」)が含まれます。変換に関連するスキーマ・レベル・プロパティはありません。

スキーマ・プロパティ: 一般

スキーマ・プロパティ・タブの「一般」サブタブには、スキーマの名前と、このスキーマ内に作成された表などの記憶域オブジェクトのデフォルト表領域が表示されます。これらのプロパティは読取り専用です。

スキーマ・プロパティ: スキャン

スキーマ・プロパティ・タブのスキャン・サブタブには、このスキーマ内のオブジェクトのスキャン結果の集計が表示されます。

スキャン・サブタブのプロパティは次のとおりです。

- スキャン・ステータス
このプロパティには、スキーマのスキャン・ステータスの集計が表示されます。次の値を指定できます。

- 未スキャン
最後に移行リポジトリがインストールされてから、このスキーマ内の表はスキャンされていません。

- 進行中
スキーマ内の表は現在スキャン中です。

- スキャン済
スキーマ内のすべての表のスキャンが完了し、有効なスキャン結果が存在しています。

- 一部スキャン済
スキーマ内の一部の表のスキャンが完了し、有効なスキャン結果が存在していますが、その他の表はまだスキャンされていないか、クレンジング・アクションまたはDMU外部でのその構造(メタデータ)の変更によってスキャン結果が無効化されています。

- 結果が無効化済
スキーマ内のすべての表のスキャン結果は、クレンジング・アクションまたはDMU外部での表構造(メタデータ)の変更によって無効化されています。

- 問題検出済
データベース内の1つ以上の表に、変換可能性の問題があるデータが含まれています。長さ制限(拡張)または無効なバイナリ表現の問題があるか、データ・ディクショナリ・スキーマの場合は変換可能データが存在する可能性があります。

- 失敗
予期しないエラーが発生したため、スキーマ内の1つ以上の表をスキャンできませんでした。

- 変換する表
これは、変換ステップで変換が必要であるとすでに特定されているスキーマ内の表の数です。

- 変換する行
これは、スキーマ内で変換が必要なすべての表の変換する行プロパティ値の合計です。

- スキャン結果
スキャン結果には、スキーマの表のすべてのスキャン済データ・セルが各変換カテゴリに分類されて表示されます。セルとは、特定の行内の特定の列の値です。この分類はデータベースの分類と似ていますが、結果がデータベース内のすべての表に対してでなくスキーマ内のすべての表に対して集計される点が異なります(「データベースのスキャン」を参照)。

前述のプロパティはすべて読取り専用です。

スキーマ・プロパティ: 準備状況

このサブタブには、変換するデータの準備状況が表示されます。変換するデータの準備状況プロパティの値は、次のいずれかです。

- 変換の必要なし
スキーマ内のすべてのデータは、変換の必要なしとして分類されています。

- 変換準備完了
スキーマ内のすべてのデータが変換の必要なし、または変換の必要ありとして分類されています。データに変換の問題はありません。

- 変換準備未完了
スキーマ内の一部のデータが無効なバイナリ表現を持つ、または長さ制限を超えるとして分類されているか、欠落しているスキャン結果があります。

準備状況のステータスが「変換準備未完了」の場合、問題を説明する追加情報が表示されます。

表プロパティの表示および設定

表プロパティ・タブには、4つのサブタブ(「一般」、「スキャン」、「準備状況」および「変換中」)が含まれます。表の変換準備ができていない場合、または表に変換の必要がない場合、変換サブタブは表示されないことがあります。

表プロパティ: 一般

表プロパティ・タブの「一般」サブタブには、次の表プロパティが表示されます。

- 表名
これは表の名前です。

- スキーマ名
これは、表が属するスキーマの名前です。

- 表領域
これは、表を含む表領域の名前です。パーティション表の場合、このプロパティには新しいパーティションのデフォルト表領域が表示されます。

- 表サイズ
これは、最高水位標で指定された表のサイズです。

- テキストを含む可能性のある列
これは、データベース・キャラクタ・セットで文字データを含む可能性があり、そのために変換が必要な可能性のある表の列のリストです。このリストには、列の名前、列のデータ型、長さ制約、NOT NULL制約の有無、および列が表の主キーに属するかどうかの情報が表示されます。

これらのプロパティは読取り専用です。

表プロパティ: スキャン

表プロパティ・タブのスキャン・サブタブでは、表のスキャンを制御し、この表の列のスキャン結果の集計を参照できます。

スキャン・サブタブのプロパティは次のとおりです。

- 使用可能な行識別子
このプロパティは、最後の表スキャンで特定タイプのセル・データを含む行を識別する行識別子が収集されたかどうかを示します。値は次のとおりです。

- なし
この表の行識別子は収集されていません。

- 変換対象すべて
変換が必要な1つ以上の列値を含むすべての行の行識別子が収集されました。これらの行識別子は、変換方法「変換可能な行のみを更新」を使用する場合に必要です。

- 問題あり
変換の問題がある列値を1つ以上含む行の行識別子のみが収集されました。これらの行識別子によって、クレンジング・エディタの操作効率が向上することがあります。第6章「DMUを使用したデータのクレンジング」を参照してください。

- 収集する行識別子
このプロパティを設定して、次回の表スキャンで収集する行識別子をDMUに指定できます。このプロパティの使用可能な値は、使用可能な行識別子プロパティと同じです。

このプロパティの値は、スキャン・ウィザードで上書きできます。「データベースのスキャン」を参照してください。

- しきい値を超えた場合に分割
このプロパティを「はい」に設定すると、DMUでは表が複数のチャンクに分割され、これらのチャンクが複数のスキャン・プロセスでパラレルにスキャンされます。DMUでは、表は内部計算されたしきい値を超えた場合にのみ分割されます。

- 分割して完了
このプロパティの値は、最後の表スキャンが複数のチャンクに対してパラレルに実行されたかどうかを示します。

- スキャン・ステータス
このプロパティには、表のスキャン・ステータスの集計が表示されます。次の値を指定できます。

- 未スキャン
最後に移行リポジトリがインストールされてから、この表の列はスキャンされていません。

- 進行中
表は現在スキャン中です。

- スキャン済
表内のすべての列のスキャンが完了し、有効なスキャン結果が存在しています。

- 一部スキャン済
表内の一部の列のスキャンが完了し、有効なスキャン結果が存在していますが、その他の列はまだスキャンされていないか、クレンジング・アクションまたはDMU外部でのその構造(メタデータ)の変更によってスキャン結果が無効化されています。

- 結果が無効化済
表のすべての列のスキャン結果は、クレンジング・アクションまたはDMU外部での表構造(メタデータ)の変更によって無効化されています。

- 問題検出済
表内の1つ以上の列に、変換の問題があるデータが含まれています。長さ制限(拡張)または無効なバイナリ表現の問題があるか、データ・ディクショナリ表の場合は変換可能データが存在する可能性があります。

- 失敗
予期しないエラーが発生したため、この表の列の最後のスキャンは失敗しました。

- 変換する行
これは、変換が必要な列値を1つ以上含む表の行の数です。

- スキャン結果
スキャン結果には、表のすべてのスキャン済データ・セルが各変換カテゴリに分類されて表示されます。セルとは、特定の行内の特定の列の値です。この分類はデータベースの分類と似ていますが、結果がデータベース内のすべての表に対してでなく表のすべての列に対して集計される点が異なります。「データベースのスキャン」を参照してください。

データ型がネストした表である列のスキャン結果は、列を含む表の結果に追加されません。DMUでは、ネストした表の列の記憶表が個別の表として表示されます。

「適用」をクリックして、このサブタブで行った変更を保存します。

表プロパティ: 準備状況

このサブタブには、変換する表データの準備状況が表示されます。変換するデータの準備状況プロパティの値は、次のいずれかです。

- 変換の必要なし
表内のすべてのデータは、変換の必要なしとして分類されています。

- 変換準備完了
表内のすべてのデータが変換の必要なし、または変換の必要ありとして分類されています。データに変換の問題はありません。

- 変換準備未完了
表内の一部のデータが無効なバイナリ表現を持つ、または長さ制限を超えるとして分類されているか、欠落しているスキャン結果があります。

準備状況のステータスが「変換準備未完了」の場合、問題を説明する追加情報が表示されます。

表プロパティ: 変換

このサブタブのプロパティを使用すると、表の変換の特定の局面を制御できます。次のプロパティを設定できます。

- 変換方法
このプロパティでは、DMUで表のデータを更新してターゲット・キャラクタ・セットに変換する方法を指定します。値は次のとおりです。

- 変換から除外
表は変換されません。スケジュール済のクレンジング・アクションのみを適用できます。

- CREATE TABLE AS SELECTを使用してデータをコピー
CTAS文によって表のコピーが作成され、元の表は削除されます。列の値は、この文に含まれる問合せによって変換されます。

- すべての行を更新
表のすべての行を更新する場合は、WHERE句なしのUPDATE文を使用します。

- 変換可能な行のみを更新
UPDATE文によって、最後の表スキャンで行識別子が収集された行のみが更新されます。

- 変換で変更される行のみをスキャンして更新
UPDATE文によって、文のWHERE句に含まれる内部スキャン関数で指定されている変換可能な列値を含む表の行のみが更新されます。

DMUでは、スキャン済の各表に前述の変換方法のいずれかが自動的に割り当てられます。前述のいずれの方法が表に有効であるかは、その表の様々な機能や、表のデータが変換可能かどうかによって決まります。有効な方法が複数あり、テストでそれらの方法の効率に違いがあることがわかった場合は、このプロパティの値を変更して自動割当てを変更できます。

- ユーザーの優先変換方法
このプロパティを使用すると、DMUの推奨変換方法を必要に応じて上書きできます。ユーザーがこれを明示的に特定の変換方法に設定した場合、選択したその変換方法を現在の表に適用できない場合を除いて、その設定が優先されます。デフォルト値は「プリファレンスなし」であり、DMUの推奨変換方法が使用されます。

- ターゲット表領域
表の変換方法を「CREATE TABLE AS SELECTを使用してデータをコピー」にした場合、このドロップダウン・リストから表領域を選択して、変換された表コピーを作成する表領域を指定できます。このプロパティのデフォルト値は、表が含まれる表領域です。

- LONG列の位置を保持
CTAS文の制約により、表の変換方法が「CREATE TABLE AS SELECTを使用してデータをコピー」の場合、表のLONG列はいずれも表の他の列とは別に変換してコピーする必要があります。このような場合にDMUで適用されるデフォルトの処理によって、表のLONG列の位置が変更される可能性があります。この場合、アスタリスク構文(SELECT * FROM)を使用して表から列を選択するアプリケーションは壊れる可能性があります。このようなアプリケーションがわかっていれば、このプロパティを「はい」に設定して、効率は悪くてもLONG列の位置が保持されるような方法をDMUで適用できます。

「適用」をクリックして、このサブタブで行った変更を保存します。

列プロパティの表示および設定

列プロパティ・タブには、4つのサブタブ(「一般」、「スキャン」、「準備状況」および「変換中」)が含まれます。列の変換準備ができていない場合、または列に変換の必要がない場合、変換サブタブは表示されないことがあります。

列プロパティ: 一般

列プロパティ・タブの「一般」サブタブには、次の表プロパティが表示されます。

- 列名
これは列の名前です。

- 列の型
これは列のデータ型です。

- 列の長さ
これは列の長さ制約です。長さ制約が発生する可能性があるのは、VARCHAR2列とCHAR列のみです。

- NULLを許可
このプロパティの値が「はい」の場合、列にNULL値を含めることができます。それ以外の場合、NOT NULL制約またはPRIMARY KEY制約により、列内のNULL値は許可されません。

- 主キーに属する
このプロパティの値が「はい」の場合、列はPRIMARY KEY制約に属します。

これらのプロパティは読取り専用です。

列プロパティ: スキャン

列プロパティ・タブのスキャン・サブタブには、この列のスキャン結果が表示されます。スキャン・サブタブのプロパティは次のとおりです。

- 想定列キャラクタ・セット
このプロパティの値には、クレンジング・エディタで設定されている列の想定キャラクタ・セットが表示されます。第6章「DMUを使用したデータのクレンジング」を参照してください。

- スキャン・ステータス
このプロパティには、列のスキャン・ステータスが表示されます。次の値を指定できます。

- 未スキャン
最後に移行リポジトリがインストールされてから、この表の列はスキャンされていません。

- 進行中
表は現在スキャン中です。

- スキャン済
表内のすべての列のスキャンが完了し、有効なスキャン結果が存在しています。

- 結果が無効化済
列のスキャン結果は、クレンジング・アクションまたはDMU外部での表構造(メタデータ)の変更によって無効化されています。

- 問題検出済
列に、変換の問題があるデータが含まれています。長さ制限(拡張)または無効なバイナリ表現の問題があるか、データ・ディクショナリ表の場合は変換可能データが存在する可能性があります。

- 失敗
予期しないエラーが発生したため、この列の最後のスキャンは失敗しました。

- 変換前の最大長
このプロパティには、列の現在の最長値(バイト)が表示されます。

- 変換後の最大長
このプロパティには、ターゲット・キャラクタ・セットへの変換後の列の最長値(バイト)が表示されます。

- スキャン結果
スキャン結果には、すべてのスキャン済データ・セル(行の値)が各変換カテゴリに分類されて表示されます。この分類はデータベースの分類と似ていますが、結果がデータベース内のすべての表に対してでなく単一の列に対して提供される点が異なります。「データベース・プロパティの表示および設定」を参照してください。

このサブタブのプロパティは読取り専用です。

列プロパティ: 準備状況

列プロパティ・タブの準備状況サブタブには、次のプロパティが表示されます。

- スケジュール済クレンジング・アクション
このプロパティには、クレンジング・エディタで列に定義されているスケジュール済クレンジング・アクションが表示されます。第6章「DMUを使用したデータのクレンジング」を参照してください。

- データの変換の準備状況
このプロパティは、列内のデータの変換の準備ができているかどうかを示します。値は次のいずれかです。

- 変換の必要なし
列内のすべてのデータは、変換の必要なしとして分類されています。

- 変換準備完了
表内のすべてのデータが変換の必要なし、または変換の必要ありとして分類されています。データに変換の問題はありません。

- 例外データあり
スキーマ内の一部のデータが、無効なバイナリ表現を持つ、または長さ制限を超えるとして分類されています。

準備状況のステータスが「変換準備未完了」の場合、問題を説明する追加情報が表示されます。

列プロパティ: 変換

このサブタブのプロパティを使用すると、列の変換の特定の局面を制御できます。次のプロパティを設定できます。

- 変換から除外する
このプロパティを「はい」に設定すると、DMUではこの列のデータが更新されません。

- 問題のあるデータの変換を許可する
このプロパティを「はい」に設定すると、列のスキャン結果でいくつかの値に変換の問題がある、つまり変換後の値に置換文字が含まれるか、変換後の値が切り捨てられる問題があることが示された場合でも、DMUでデータの変換を実行できます。列またはデータ型の制限を超えたデータを自動的に切り捨てる場合や、破損した値があってもこのデータを使用するアプリケーションにとって大きな影響はないような場合には、これを使用すると便利です。データのクレンジング・プロセスを回避するのみの目的でこのプロパティを「はい」に設定しないように注意してください。

「適用」をクリックして、このサブタブで行った変更を保存します。

4 DMUの基本タスクの実行

この章では、キャラクタ・セット移行プロセスの一般的なシナリオにおけるDatabase Migration Assistant for Unicodeの使用手順を示します。ここに示されている例に従えば、このツールを使用してデータベースを移行できます。この章で示す手順のほとんどは、すべてのシナリオに共通です。

この章は次の項で構成されています。

- データベースの初期化

- 移行リポジトリのリフレッシュまたは再インストール

- 移行リポジトリのアンインストール

- データベースのスキャン

- データのクレンジング

- データベースの変換

- Unicodeとしてのデータの検証

- 診断パッケージの作成

データベースの初期化

DMUで使用できるようにデータベースを初期化する場合、次のタスクを実行します。

- 必要なパッチのインストール

- サポート・パッケージのインストール

- 移行リポジトリの表領域の作成

- データベース接続の作成

必要なパッチのインストール

必要なパッチをインストールする手順は、次のとおりです。

1. ダウンロードした最新のDMUリリース・ノートで、ご使用のデータベースでDMUを使用するために必要なデータベース・パッチがあるかどうかを確認します。次に、opatchユーティリティを使用して、必要なパッチがすでにインストールされているかどうかを確認します。最後に、ORACLE_HOME環境変数をデータベースのOracleホーム・ディレクトリに設定し、現在のディレクトリをOracleホームのOPatchサブディレクトリに変更して、次の文を発行します。

opatch lsinventory –patch

opatchユーティリティで有効なoraInst.locファイルが存在しないことが特定された場合、データベースのOracleホーム内でそのファイルを見つけて、次の例に示すようにその位置を-invPtrLocパラメータに渡します。

opatch lsinventory –patch –invPtrLoc ../oraInst.loc

opatchユーティリティの出力は次のようになります。

Invoking OPatch 10.2.0.5.0

Oracle interim Patch Installer version 10.2.0.5.0
Copyright (c) 2005, Oracle Corporation.  All rights reserved..

Oracle Home       : C:\oracle\product\10.2.0\db_1
Central Inventory : C:\Program Files\Oracle\Inventory
from           : n/a
OPatch version    : 10.2.0.5.0
OUI version       : 10.2.0.5.0
OUI location      : C:\oracle\product\10.2.0\db_1\oui
Log file location : C:\oracle\product\10.2.0\db_1\cfgtoollogs\opatch\opatch2010-05-17_22-50-28PM.log

Lsinventory Output file location : C:\oracle\product\10.2.0\db_1\cfgtoollogs\opatch\lsinv\lsinventory2010-05-17_22-50-28PM.txt

--------------------------------------------------------------------------

Interim patches (2) :

Patch  5556081      : applied on Mon Feb 08 15:50:52 CET 2010
Created on 9 Nov 2006, 22:20:50 hrs PST8PDT
Bugs fixed:
5556081

Patch  5557962      : applied on Mon Feb 08 15:50:45 CET 2010
Created on 9 Nov 2006, 23:23:06 hrs PST8PDT
Bugs fixed:
4269423, 5557962, 5528974

--------------------------------------------------------------------------

OPatch succeeded.

2. 個別パッチの中に必要なデータベース・パッチが一覧表示されているかどうかを確認します。欠落しているパッチがあれば、My Oracle Supportサイトからダウンロードしてインストールします。次に、パッチに含まれているドキュメントでインストール手順を確認します。これらのパッチは次の場所にあります。
https://support.oracle.com

サポート・パッケージのインストール

DMUで使用できるようにデータベースが初期化されていない場合、専用のデータベース・カーネル関数にアクセスするために必要なPL/SQLサポート・パッケージをそのデータベースに含めることはできません。

サポート・パッケージをインストールする手順は、次のとおりです。

1. データベースのOracleホーム・ディレクトリから、SQL*Plusユーティリティを実行できるオペレーティング・システム・ユーザーとしてデータベース・サーバー・ホストに接続します。

2. SQL*Plusユーティリティを起動し、SYSDBA権限を持つユーザーとして接続します。たとえば、LinuxまたはMicrosoft Windowsでは、次のコマンドを入力します。

sqlplus / as sysdba

3. ログイン後、次のコマンドを実行します。

SQL> @?/rdbms/admin/prvtdumi.plb

スクリプトからの出力は次のようになります。

Library created.

Package created.

No errors.

Package body created.

No errors.

さらに、インストールしたデータベース・パッチのインストール・ドキュメントで指示されていれば、前述の手順を実行する必要があります。

移行リポジトリの表領域の作成

メンテナンスを容易にするために、また他の本番表領域のフラグメンテーションを回避するために、DMUの移行リポジトリを構成するデータベース・オブジェクト(表および索引)には個別の表領域を使用することをお薦めします。この推奨事項に従うには、以降の手順で移行リポジトリに選択できる適切な表領域を作成しておきます。表領域の作成手順は、『Oracle Database 2日でデータベース管理者』または『Oracle Database管理者ガイド』を参照してください。

移行リポジトリに表領域を作成する手順は、次のとおりです。

デフォルトのエクステント割当てポリシーを使用し、自動拡張機能をオンにして、表領域をローカルで管理することをお薦めします。

1. (SYSDBAとして実行した)次のSQL問合せの結果を表領域の初期サイズとして使用します。

SELECT CEIL((t.cnt*300+c.cnt*1000)/1048576)||' MB'
"Initial Size"
FROM (SELECT COUNT(*) cnt FROM sys.tab$) t,
(SELECT COUNT(*) cnt
FROM sys.col$
WHERE obj# IN (SELECT obj# FROM sys.tab$)
AND BITAND(property,65536)=0
AND type# IN (1,8,58,96,112)
AND charsetform=1) c

クレンジング・エディタで使用する行識別子を多数収集した場合や、多数の変換可能セルを含む多数の表に対して変換方法「更新可能な行のみを変換」を適用した場合、表領域のサイズが非常に拡大する可能性があります。このため、表領域が必要なだけ大きくなるように自動拡張機能をオンにすることをお薦めします。

データベース接続の作成

「データベース接続の作成」を参照してください。

移行リポジトリのリフレッシュまたは再インストール

リポジトリのインストールが完了すると、DMUワークフローの事前定義済のポイントで、データベースで追加、変更または削除された可能性のある文字データを含むオブジェクトが考慮されるようにリポジトリが自動的にリフレッシュされます。また、移行メニューから選択してリポジトリをリフレッシュまたは再インストールできます。

移行リポジトリをリフレッシュする手順は、次のとおりです。

1. リポジトリを明示的にリフレッシュしてデータベース・オブジェクトへの最新の変更を即時に適用するには、移行メニューまたはナビゲータ・ペインのデータベース・ノードのコンテキスト・メニューから「DMUリポジトリのリフレッシュ」を選択します。リフレッシュが完了すると、リポジトリが正常にリフレッシュされたことを示す確認メッセージが表示されます。

移行リポジトリを再インストールする手順は、次のとおりです。

1. リポジトリを明示的に再インストールするには、移行メニューまたは「検証」メニューから「DMUリポジトリの構成」を選択します。図4-1「リポジトリ構成ウィザード - 再インストール」が表示されます。

図4-1 リポジトリ構成ウィザード - 再インストール

2. 移行モードまたは検証モードのいずれかを選択します。「次へ」をクリックします。図4-2「リポジトリ構成ウィザード - 再インストール/アーカイブ」が表示されます。

図4-2 リポジトリ構成ウィザード - 再インストール/アーカイブ

3. 「診断目的で既存のリポジトリをアーカイブする」が選択されていることを確認し、「次へ」をクリックします。図4-3「リポジトリ構成ウィザード - 表の選択」が表示されます。

図4-3 リポジトリ構成ウィザード - 表の選択

4. 「完了」をクリックします。リポジトリが再インストールされます。

移行リポジトリのアンインストール

移行リポジトリをアンインストールする手順は、次のとおりです。

1. リポジトリを削除するために、「移行」メニューまたは「ナビゲータ」ペインのデータベース・ノードのコンテキスト・メニューから「DMUリポジトリの構成」を選択します。リポジトリのアンインストールを選択できるダイアログ・ボックスが表示されます。「リポジトリのアンインストール」を選択して「次へ」をクリックすると、リポジトリがアンインストールされます。リポジトリのアンインストールが完了すると、操作の成功を確認する確認メッセージが表示されます。

データベースのスキャン

次の手順は、現行のデータのスキャンです。一般に、この手順の目的は、問題の原因を分析し、データの問題を解決するためのクレンジング方針を選択することです。

スキャンは、データベースから文字値を読み取ってターゲット・キャラクタ・セットに変換し、変換で変更される値、列に収まらない値、データ型に収まらない値、または無効な文字コードが含まれる値の数をカウントするプロセスです。列内の値の変換後の最大長など、追加の統計も計算されます。DMUでは、計算されたカウントおよび統計がスキャン結果として移行リポジトリに格納されます。テスト変換の結果の文字値自体は削除されます。これらは永続的にデータベースに格納されません。

データベースをUnicodeに変換する前に、表のVARCHAR2列、CHAR列、LONG列およびCLOB列の文字データを分析して、データの破損なく変換が正常に完了することを妨げる可能性のある問題がないかどうか査定する必要があります。DMUではデータの分析中に、データベース内の文字列値が宣言済キャラクタ・セットからターゲットのUnicodeキャラクタ・セットに変換され、各値がチェックされて次のことが判別されます。

- 変換結果が元の値と異なるかどうか

- 変換結果がその列の長さ制限に収まるかどうか

- 変換結果がそのデータ型に収まるかどうか

- 変換結果に置換文字は含まれないか、つまり、変換後の各ソース文字コードが列の宣言済キャラクタ・セットで有効かどうか

この項の内容は次のとおりです。

- データベース・プロパティの設定

- スキャン・ウィザードを使用したデータベースのスキャン

- スキャンの進行状況の監視

- データベース・スキャン・レポートの表示

- データベース・スキャン・レポートの概要

データベース・プロパティの設定

データベースのスキャンを開始する前に、移行プロセスの準備中に「移行の準備の確認」の説明に従って収集した言語およびキャラクタ・セットの情報をDMUに指定する必要があります。

データベース・プロパティを設定する手順は、次のとおりです。

1. データベース・プロパティ・タブ(図4-4を参照)を開きます。このタブは、データベースに接続すると、DMUウィンドウのクライアント・ペイン内に自動的に開きます。このタブのタイトルは、接続の名前です。
また、このタブは、ナビゲータ・ペインでデータベース・ノードを右クリックし、コンテキスト・メニューから「プロパティ」を選択しても表示されます。このタブの左サイドバーから、「一般」サブタブを選択します。このサブタブで、想定データベース・キャラクタ・セット・プロパティを、データベース内のデータの特定された実際のキャラクタ・セットに設定します。パススルー構成の場合とは異なり、データベースが適切なキャラクタ・セット構成で使用されていれば、このプロパティは現行データベース・キャラクタ・セット・プロパティと同じです。

図4-4 データベース・プロパティ・タブ: 一般

関連項目:
データベースおよびその他のプロパティの詳細は、第3章「DMUでのオブジェクト・プロパティの表示および設定」を参照してください。

スキャン・ウィザードを使用したデータベースのスキャン

これで、データベースの内容の最初のスキャンを実行する準備ができました。このプロセスは、スキャン・ウィザードを使用して開始します。スキャン結果に、データの損失なくデータを完全に変換するためにクレンジングの必要なデータがあるかどうかが示されます。また、DMUでは、スキャン結果を使用して各表に最も効率的な変換方法が選択されます。

DMUユーザー・インタフェースの3つの要素を使用して、スキャン・プロセスを制御し、スキャン結果を参照できます。スキャン・プロセスの開始にはスキャン・ウィザードを使用し、このプロセスの監視にはスキャンの進行状況タブを使用し(「スキャンの進行状況の監視」を参照)、スキャン結果の表示にはデータベース・スキャン・レポート・タブを使用します(「データベース・スキャン・レポートの概要」を参照)。

DMUでは、スキャン中に、変換可能な値、または拡張の問題や無効なバイナリ表現の問題のある値を含む列セルの行識別子アドレスが収集されることがあります。

マルチバイト・データベースでは、CLOB列はスキャンされず、ナビゲータ・ペインにも表示されません。マルチバイト・データベース(AL32UTF8キャラクタ・セットおよびUTF8キャラクタ・セットのデータベースを含む)はいずれも、同じ内部記憶域キャラクタ・セット(Unicode UTF-16)でCLOB値を格納するため、あるマルチバイト・キャラクタ・セットから別のマルチバイト・キャラクタ・セットにデータベース・キャラクタ・セットを移行する場合にCLOB値を変換する必要はありません。

列値のテスト変換に使用されたソース・キャラクタ・セットが、列の想定キャラクタ・セットです。「データのクレンジング」を参照してください。

スキャン・ウィザードを使用してデータベースをスキャンする手順は、次のとおりです。

1. 「スキャン」ウィザードを開くには、「移行」メニューから「データベースのスキャン」を選択するか、「ナビゲータ」ペインで対応するオブジェクト・ノードのコンテキスト・メニューから「データベースのスキャン」、「スキーマのスキャン」、「表のスキャン」または「列のスキャン」を選択します。図4-5「スキャン・ウィザード - ようこそ」に示すようなスキャン・ウィザードが表示されます。

図4-5 スキャン・ウィザード - ようこそ

また、変換の詳細タブから変換プロセスを開始した後、DMUでスキャン・ウィザードが開かれることもあります。変換方法「変換可能な行のみを更新」を使用してデータベース内の1つ以上の表を変換する場合、DMUではこのウィザードが開かれます。追加のスキャンによって、この変換方法で必要な行識別子アドレスが収集されます。変換フェーズ中に開かれるスキャン・ウィザードでは、図4-6「スキャン・ウィザード - ようこそ: 行識別子の収集」に示すように第一画面が異なります。また、オブジェクト選択ページがありません。変換フェーズの詳細は、「データベースの変換」を参照してください。

図4-6 スキャン・ウィザード - ようこそ: 行識別子の収集

2. 「次へ」をクリックして、「ようこそ」ページをスキップします。

3. 図4-7「スキャン・ウィザード - パラメータの設定」に示すようなウィザードの2番目のページでは、スキャン・プロセスの一般的なパラメータを設定できます。
「スキャン・プロセス数」は、スキャン・プロセスを実行するためにDMUで生成されるスレッドの数です。スレッドごとに個別のデータベース接続が開かれます。DMUによって各スレッドに表のセットが割り当てられて、個別にスキャンされます。サイズの大きい表はチャンクに分割されて、複数のスレッドによりスキャンされることがあります。サイズの小さい表は、すべて1つのスレッドによりスキャンされます。このパラメータのデフォルト値は、データベースのCPU_COUNT初期化パラメータの値です。このパラメータを大きくして、データベース・サーバーのCPUおよびディスクのパラレル処理を活用することによってスキャンの回数が減るかどうかを確認したり、パラメータを小さくして、スキャン・プロセスがビジー状態の本番データベースのパフォーマンスに与える影響を小さくすることができます。

図4-7 スキャン・ウィザード - パラメータの設定

スキャン・バッファ・サイズ・パラメータは、DMUで表をスキャンするために各データベース・サーバー・セッションに割り当てられるバッファのサイズ(バイト)を制御します。デフォルト値は1000KBです。1回のスキャンで使用される合計バッファ領域は、スキャン・プロセスの数にこのプロパティ値を乗算した値です。このプロパティの値を大きくすると、割り当てられたバッファ・メモリーがデータベース・サーバー上の使用可能なRAMに収まっているかぎり、スキャンの速度が上がる可能性があります。

3つのラジオ・ボタンを使用して、このスキャンに選択した表に対して初期の行識別子収集レベルを定義できます。この初期レベルは、後からウィザードのスキャンの詳細ページ(手順5を参照)で変更できます。表プロパティ「収集する行識別子」のみに基づいて行IDを収集するオプションは、各表の初期の行識別子収集レベルとして表プロパティ収集する行識別子の値を使用するようにDMUに指定します。このプロパティの詳細は、「表プロパティ: スキャン」を参照してください。

変換方法が「変換可能な行を更新」の場合に行識別子も収集するオプションを選択すると、DMUでは変換方法が変換可能な行のみを更新」の場合に行識別子アドレスが事前に収集されます。このオプションを指定すると、この変換方法が割り当てられているすべての選択済表に対して初期の行識別子収集レベルが「すべて変換」に設定され、それ以外の選択済表に対しては収集する行識別子プロパティの値に設定されます。通常、この変換方法の行識別子は、変換フェーズの開始時に自動的に開始される前述の追加スキャンによって収集されます。

行識別子を事前収集すると、この追加スキャンの必要がなくなるため、必要な停止期間を短縮し、業務に対してデータベースを閉じる時間も短縮できます。ただし、表の行識別子を事前収集した最後のスキャンが実行された後で、他の変換可能な行が追加された場合、これらの行は変換フェーズ中に変換されず、移行後は不適切にエンコードされたデータになります。このため、事前収集機能は、内容が静的であることが確認されている大きな表に対してのみ使用してください。表の最初のスキャン中にはまだ変換メソッドが表に割り当てられていないため、変換方法が「変換可能な行を更新」の場合に行識別子も収集するオプションは適用されません。

最後のオプション「行識別子を収集しない」を使用すると、現在のスキャン中の行識別子収集をオフに切り替えることができます。これは、変換可能なセルおよび変換可能性の問題を含むセルをカウントするが、スキャン済のいずれの表に対してもクレンジング・エディタのフィルタリング・オプションを使用する必要はない場合に便利です。収集する行識別子プロパティが「すべて変換」に固定されているSYSスキーマ内の特殊なデータ・ディクショナリ表に対して行識別子収集をオフにすることはできません。

変換フェーズ中にDMUで行識別子の収集のために開かれるスキャン・ウィザードでは、図4-8「スキャン・ウィザード - パラメータの設定: 行識別子収集」に示すようにスキャン・パラメータ・ページが変わります。このページでは、変換方法が「変換可能な行を更新」の場合に行識別子も収集するチェック・ボックスが自動的に選択され、追加のパラメータ「最大保持時間」があります。このパラメータを使用すると、最近の最大保持時間中に行識別子が事前収集された表の再スキャンをスキップできます。また、古いと思われる事前収集済の行識別子を削除できます。

図4-8 スキャン・ウィザード - パラメータの設定: 行識別子収集

変換プロセスの詳細は、「データベースの変換」を参照してください。

「次へ」をクリックしてスキャン・パラメータを受け入れ、オブジェクト選択ページを開きます。

4. 最初のスキャンでは通常、移行メニューからスキャン・ウィザードを開くことによりデータベース内のすべての表を選択します。それ以降のスキャンでは、たとえば、クレンジング・アクションによりスキャン結果が無効化された場合や、オブジェクトに対する最新のDMLアクティビティを、新たに発生した可能性のある変換問題のコンテキストで分析するなどの理由で、スキャン結果をリフレッシュするデータベース・オブジェクトのサブセットを選択できます。
無効化されたスキャン結果のみを再計算する場合、データベース・ノードを選択してデータベース内のすべての列を選択してから、「スキャン済を除外」をクリックします。このオプションを選択すると、DMUによって有効なスキャン結果がすでに存在するすべての列が自動的に選択解除されます。この後、既存のスキャン結果をリフレッシュする追加の表および列を手動で選択できます。

変換方法が「変換可能な行を更新」の場合に行識別子も収集するオプションを選択した場合、スキャン済を除外オプションを使用しても、以前のスキャンで必要な業識別子が収集されていない表は除外されません。

変換の開始前、できれば新しいデータがデータベースに追加されることのない停止期間中に、データベース内のすべてのスキャン結果をリフレッシュすることを強くお薦めします。これにより、変換の必要なすべてのデータが考慮されます。

図4-9 スキャン・ウィザード - スキャン・オブジェクトの選択

「次へ」をクリックしてオブジェクト選択を受け入れ、スキャンの詳細ページを開きます。ウィザードではすべての選択済オブジェクトに対してスキャン計画を準備する必要があるため、このページが表示されるまでに時間がかかることがあります。

5. 図4-10「スキャン・ウィザード - スキャンの詳細」に示すスキャンの詳細ページで、スキャン対象として選択したすべてのオブジェクトが含まれていることを確認できます。また、収集する行識別子列でフィールドを選択すると開かれるドロップダウン・リストで行識別子収集レベルを設定することもできます。行識別子レベルとして選択できる項目は、「なし」(収集を実行しない)、「すべて変換」(変換の必要なしとして分類されていないすべてのデータに対して行識別子を収集する)および「問題あり」(変換問題のあるデータに対してのみ行識別子を収集する)です。問題のあるデータ・セルの行識別子がスキャン中に収集された場合は、クレンジング・エディタのフィルタリング機能と検索機能を使用してクレンジングが必要なデータを検索するほうが時間がかかりません。クレンジング・エディタの詳細は、第6章「DMUを使用したデータのクレンジング」を参照してください。
スキャン・ウィザードで設定した行識別子収集レベルは、現在のスキャンに対してのみ有効です。表プロパティ「収集する行識別子」は変更されず、スキャン・ウィザードの次の起動時まで保持されることはありません。

DMUでは、サイズの大きい表は自動的にチャンクに分割され、複数のスキャン・プロセスによりパラレル・スキャンが実行されます。ただし、必要な場合は、分割列の対応するチェック・ボックスを選択解除して表の分割を回避できます。

「完了」をクリックすると、スキャンが開始されます。

図4-10 スキャン・ウィザード - スキャンの詳細

スキャンの進行状況の監視

スキャンが開始されると、DMUによって図4-11に示すようなスキャンの進行状況タブが自動的に開きます。このタブを使用して、スキャン・タスクの進行状況を監視できます。

図4-11 スキャンの進行状況タブ

スキャンの進行状況タブには、スキャンされたセット内のすべての表のスキャン情報を表示するグリッドが含まれています。タブ・グリッドの列は次のとおりです。

- 名前
この列には、グリッドの対応する行で説明されている表の名前が表示されます。名前の左側にあるアイコンは、スキャン・ステータスを示します。緑色のチェック・マークは、表のスキャンが完了していることを示します。緑色のスプロケット形状のアイコンは、現在スキャン中の表を示します。時計は、スキャンを待機している表を示します。

表が複数のチャンクに分割されている場合、ステータス・アイコンの左側にあるプラス記号をクリックすると、表が分割されたすべてのチャンクの情報が表示されます。

注意:
緑色のチェック・マーク・アイコンの意味は、スキャンの進行状況タブとナビゲータ・ペイン/スキャン・レポート・タブとでは異なります(「データベース・スキャン・レポートの概要」を参照)。スキャンの進行状況タブのこのアイコンは、表のスキャンが正常に完了したことを示しますが、表に問題のあるデータが含まれているかどうかを示しません。ナビゲータ・ペインまたはスキャン・レポート・タブのこのアイコンは、表、スキーマまたはデータベースのスキャンが完了したこと、また表の内容にUnicodeへの正常な変換を妨げる可能性のある問題が含まれていないことを意味します。

- 分割
表示される数字は、対応する表が分割されたときのチャンクの数です。チャンク情報を示すグリッド行では、この列は空になります。

- サイズ
この列には、対応する表または表チャンクのサイズが示されます。グリッドの一番上の行には、スキャンされたセット内のすべての表の追加されたサイズが示されます。

- 最小ROWID
チャンクの場合、この列にはチャンク内の最初の行の行識別子が示されます。表の場合は空になります。

- 最大ROWID
チャンクの場合、この列にはチャンク内の最後の行の行識別子が示されます。表の場合は空になります。

- スレッドID
この列に示される数字は、対応する表または表チャンクをスキャンしている、またはそのスキャンを完了した特定のスレッドのIDです。

- 開始時間
この列には、対応する表または表チャンクのスキャンが開始された時間が示されます。表が分割されている場合、その行にすべてのチャンクの最早(最小)開始時間が示されます。グリッドの一番上の行には、スキャン・タスク全体の開始時間が示されます。

- 終了時間
この列には、対応する表または表チャンクのスキャンが完了した時間が示されます。表が分割されている場合、その行にすべてのチャンクの最後の(最大)開始時間が示されます。グリッドの一番上の行には、スキャン・タスク全体の終了時間が示されます。

- 進行状況
この列には、進行状況バーと、対応する表または表チャンクのスキャンが完了している割合が表示されます。グリッドの一番上の行には、スキャン・タスクの全体的な進行状況が示されます。

表のスキャン中にデータベース・エラーが発生した場合、表に対応するグリッド行のこの列に、報告されたエラー・メッセージの最初の部分が表示されます。最初の部分をクリックすると、メッセージ・テキスト全部を表示するダイアログ・ボックスが開きます。

対応する表がスキャン・スレッドに割り当てられている場合、DMUではタブ・グリッドが自動的に下にスクロールして新しいグリッド行が表示されます。自動スクロールを一時停止するには、スキャンの進行状況タブの右上隅にあるスクロール・ロック・アイコンをクリックします。これにより、グリッドの一番上の行にある進行状況インジケータを参照して、スキャンの全体的な進行状況を監視できます。自動スクロールを再開するには、スクロール・ロック・アイコンを再度クリックします。

スキャン・プロセスを一時停止するには、スキャンの進行状況タブの一番下にある「停止」をクリックします。ボタンが「続行」に変わります。「続行」をクリックすると、スキャンが再開されます。詳細は、「データベース・スキャン・レポート: スキャンの停止」を参照してください。

スキャンが完了すると、DMUで情報ダイアログ・ボックスが表示されます。これで、データベース・スキャン・レポート・タブでスキャン結果を分析できるようになります。

データベース・スキャン・レポートの表示

スキャンの完了後、最新のスキャン結果は、第3章「DMUでのオブジェクト・プロパティの表示および設定」で説明されている各種プロパティ・タブのスキャン・サブタブで参照するか、もっと便利にデータベース・スキャン・レポート・タブで参照できます。

スキャン結果の内容に応じて、「クレンジング・シナリオ1: 問題のないデータベース」、「クレンジング・シナリオ2: 拡張の問題のクレンジング」または「クレンジング・シナリオ3: 無効な表現の問題のクレンジング」で説明されている移行シナリオのいずれかに従う必要があります。

データベース・スキャン・レポートを表示する手順は、次のとおりです。

1. 移行メニューから「データベース・スキャン・レポート」を選択して、データベース全体のスキャン結果が含まれるデータベース・スキャン・レポート・タブを開きます。1つのスキーマ内の表、1つの表、または1つの列に対してデータベース・スキャン・レポート・タブを開くには、ナビゲータ・ペインで対応するスキーマ・ノード、表ノードまたは列ノードのコンテキスト・メニューから「スキャン・レポート」を選択します。
図4-12「データベース・スキャン・レポート」に、データベース全体のデータベース・スキャン・レポート・タブを示します。

データベース・スキャン・レポートの概要

データベース・スキャン・レポート・タブには一番上にツールバーがあり、そのツールバーの下に結果グリッドがあります。次の3つの方法を使用して、データベース・スキャン・レポートで目的のスキャン結果をすばやく見つけ、さらにレポートをエクスポートできます。

- データベース・スキャン・レポート: ステータス・アイコンによるナビゲート

- データベース・スキャン・レポート: フィルタリング

- データベース・スキャン・レポート: 検索

- データベース・スキャン・レポート: HTMLへのエクスポート

- データベース・スキャン・レポート: スキャンの停止

図4-12 データベース・スキャン・レポート

データベース・スキャン・レポート: 結果グリッド

結果グリッドは、ツリー表形式のユーザー・インタフェース項目であり、スキャン結果およびオプションでその他のデータベース・オブジェクト・プロパティを表示します。グリッドの最初の列には、ナビゲータ・ペインのツリーと同じ外観のデータベース・オブジェクト・ツリーが含まれます(「DMUユーザー・インタフェースの概要」を参照)。ツリーのルートは、データベース・スキャン・レポートが開かれたデータベース、スキーマ、表または列です。ツリーの各ノードは、グリッドの行に関連付けられています。この行には、ノードに対応するデータベース・オブジェクトの様々なプロパティが表示されます。

ノード名の左側にあるステータス・アイコンは、ノードで説明されているデータベース・オブジェクトの変換可能性ステータスを示します。アイコンの意味は、表2-1「Database Migration Assistant for Unicodeのアイコン」で定義されています。

ノードの左側のプラス・アイコンをクリックすると、ノードを開いてその子ノードの結果を表示したり、ノードを閉じて子ノードの結果を非表示にすることができます。ノードのすべての下位ノードを一度に開くには、そのノードを含む行を選択して「すべて開く」(ツールバーの2番目のアイコン)をクリックします(表2-1「Database Migration Assistant for Unicodeのアイコン」を参照)。すべての下位ノードを一度に閉じるには、ノードを選択して「すべて閉じる」(ツールバーの3番目のアイコン)をクリックします。

データベース・スキャン・レポート・タブが開いたときにデフォルトでグリッド内に表示される列は、「変更の必要なし(スケジュール済)」、「変換が必要(スケジュール済)」、「無効なバイナリ表現(スケジュール済)」、「列制限超過(スケジュール済)」および「型制限超過(スケジュール済)」です。これらの列に表示される値は、対応するノードのプロパティ・タブのスキャン・サブタブで「スケジュール済クレンジングの結果を含める」という見出しの下に表示されるスキャン結果と同じです。これらのスキャン結果については、第3章「DMUでのオブジェクト・プロパティの表示および設定」を参照してください。

「レポートのカスタマイズ」(ツールバーの4番目のアイコン)をクリックすると、スキャン・レポートのカスタマイズ・ダイアログ・ボックスが開きます。このダイアログ・ボックスでは、デフォルトのプロパティ列とともに表示する追加のプロパティ列を選択できます。デフォルトの列を非表示にすることもできます。使用可能な列は、第3章「DMUでのオブジェクト・プロパティの表示および設定」で説明されているプロパティに対応しています。変更の必要なし列、変換が必要列、無効なバイナリ表現列、列制限超過列および型制限超過列(最後に「(スケジュール済)」が付かない)は、スキャン・サブタブの「現在のデータ」という見出しの下に表示されるスキャン結果に対応しています。

データベース・スキャン・レポートのグリッド列に表示されるプロパティが特定のノード・タイプにのみ有効である場合、そのグリッド列の他のノード・タイプに対応する行には何もテキストが表示されません。たとえば、変換方法プロパティは表にのみ有効です。これがデータベース・スキャン・レポート・タブに追加された場合、データベース、スキーマおよび列に対するグリッド行の変換方法列には何も表示されません。

データベース・スキャン・レポートのグリッド行を右クリックすると、コンテキスト・メニューから「スキャン」、「クレンジング・エディタ」または「プロパティ」を選択できます。スキャン・メニュー項目を選択すると、現在のグリッド行で説明されているオブジェクトのみがスキャン対象として選択されたスキャン・ウィザードが開きます。これにより、このオブジェクトのスキャン結果をリフレッシュするようにDMUにすばやく指定できます。クレンジング・エディタでは、選択した表または表列に対してクレンジング・エディタ・タブが開きます。クレンジング・エディタ・タブの詳細は、第6章「DMUを使用したデータのクレンジング」を参照してください。「プロパティ」をクリックすると、選択したグリッド行で説明されているオブジェクトのプロパティ・タブが開きます(第3章「DMUでのオブジェクト・プロパティの表示および設定」を参照)。

データ・ディクショナリ表のコンテキスト・メニューには、「クレンジング・エディタ」ではなく「データ・ビューア」が表示されます。「データ・ビューア」をクリックすると開くデータ・ビューア・タブは、クレンジング・エディタの読取り専用バージョンです。

データベース・スキャン・レポート: ステータス・アイコンによるナビゲート

変換可能性の問題があるデータを含むデータベース列を見つけるには、黄色い三角形のアイコンが付いたデータベース・スキャン・レポート・ノードを開きます。このアイコンは、そのノードの下位にある1つ以上の列に変換可能性の問題があることを示します。このようなアイコンが付いたノードを開き、そのノードの子を調べて同じアイコンの付いた子ノードを見つけ、それらのノードを開くという操作を、列ノードに達するまで行います。黄色い三角形のアイコンが付いた列ノードは、クレンジングが必要なデータベース列を表しています。グリッドの無効なバイナリ表現(スケジュール済)列、列制限超過(スケジュール済)列および型制限超過(スケジュール済)列のゼロでない値は、特定のデータベース列で見つかった各タイプの問題の数を示します。これらのカウンタはリンクとして表示され、クリックするとクレンジング・エディタ・タブまたはデータ・ビューア・タブが直接開いて、問題を詳しく調べることができます。

データベース・スキャン・レポート: フィルタリング

データベース・スキャン・レポート・タブの便利な機能の1つに、フィルタリング機能があります。図4-13「データベース・スキャン・レポート: フィルタリング」に示すように、タブのツールバーのドロップダウン・フィルタ・リストを開いて、レポートに表示する結果タイプを選択できます。

図4-13 データベース・スキャン・レポート: フィルタリング

使用可能なフィルタは次のとおりです。

- すべて
フィルタリングをオフに切り替えます。すべてのオブジェクトが表示されます。

- スキャン済
有効なスキャン結果を持つオブジェクトのみを表示します。

- スキャン失敗
データベース・エラーが報告されたためにスキャンできなかったオブジェクトを表示します。

- 未スキャン
有効なスキャン結果を持たないオブジェクトを表示します。オブジェクトに有効なスキャン結果が存在しない場合、オブジェクトがまだスキャンされていない、クレンジング・アクションやDDLによってスキャン結果が無効化された、またはオブジェクトの最後のスキャンが失敗したことが理由です。

- 変換の必要なし
有効なスキャン結果を持ち、変換の必要のない不変データを含むオブジェクトを表示します。

- 変換の必要あり、問題なし
有効なスキャン結果を持ち、変換の必要のない不変データと変換の必要がある変換可能データが混在しているオブジェクトを表示します。これらのオブジェクトの変換中に問題の発生は予期されません。

- 変換をブロック
データベースを変換するために事前に解決する必要のある未解決の変換可能性問題を持つオブジェクトを表示します。

- 無効な表現あり
有効なスキャン結果を持ち、無効なバイナリ表現(つまり、宣言済列キャラクタ・セットで有効でない文字コード)を持つデータを含むオブジェクトを表示します。

- データ型制限超過
有効なスキャン結果を持ち、変換後にデータ型制限を超えるデータを含むオブジェクトを表示します。

- 列制限超過
有効なスキャン結果を持ち、変換後にその列制限を超えるデータを含むオブジェクトを表示します。

- 長さの問題あり
有効なスキャン結果を持ち、変換後にその列制限またはデータ型制限を超えるデータを含むオブジェクトを表示します。

- 不変でない
有効なスキャン結果を持ち、変換が必要なデータを含むオブジェクトを表示します。データには変換可能性の問題がある場合とない場合があります。つまり、「変換が必要」、「無効な表現」、「列制限超過」および「型制限超過」のいずれかのカテゴリに属します。

- 問題あり
有効なスキャン結果を持ち、DMUで検索する潜在的な問題のあるデータを含むオブジェクトを表示します。データ・ディクショナリ・スキーマの場合、これにはDMUで変換できない列内の変換可能データも含まれます。

フィルタを選択すると、データベース列のすべてのノードおよび関連するグリッド行のうち、スキャン結果がフィルタリング条件を満たしていないものは非表示になります。ノードのすべての子が非表示の場合、そのノードも非表示になります。ただし、レポートのルート・ノードは例外で、非表示になることはありません。

データベース・スキャン・レポート・タブが1つのデータベース列に対して開かれた場合、フィルタリングは無意味なので、無効になっています。

また、ツールバーの最初のアイコン(フィルタリング済オブジェクトの再スキャン・ボタン)を選択して、スキャン・レポートでフィルタリングされたオブジェクトを再スキャンすることもできます。たとえば、スキャン・レポートで列制限超過フィルタを設定した場合、フィルタリング済オブジェクトの再スキャン・ボタンを選択すると、列制限超過の問題が存在するすべての表が再スキャン対象として選択されます。

データベース・スキャン・レポート: 検索

データベース・スキャン・レポート・タブには、サイズの大きいスキャン・レポートでのスキャン結果を簡単に分析するための検索機能もあります。検索を開始するには、次のいずれかのツールバー・ボタンをクリックします。

- 検索
ツールバーの5番目のボタンを選択すると、オブジェクトの検索基準を指定できるダイアログ・ボックスが開きます。

- 前を検索
ツールバーの6番目のボタンをクリックすると、最初に検索された項目の前のインスタンスが強調表示されます。

- 次を検索
ツールバーの6番目のボタンをクリックすると、最初に検索された項目の次のインスタンスが強調表示されます。

「検索」を選択すると、図4-14「データベース・スキャン・レポート: 検索」に示すようなダイアログ・ボックスが表示されます。

図4-14 データベース・スキャン・レポート: 検索

このダイアログ・ボックスでは、検出するオブジェクトを説明する次の検索基準を指定できます。

- 名前
オブジェクトの名前に含まれる文字列を(大/小文字を区別して)指定します。

- スキャン・ステータス
オブジェクトのスキャン・ステータスを指定します。

- オブジェクト・タイプ
スキーマ、表また列のいずれを検索するかを指定します。1つのタイプのみを選択できます。

- スケジュール済クレンジングの結果を含める
検索の結果にスケジュール済クレンジング・アクションの結果を含める場合は、このオプションを選択します。このオプションを選択した場合、見出しに「(スケジュール済)」という語が付くグリッド列に比較対象の結果が表示されます。

- 変換の必要なし
比較演算子を選択し、「変更の必要なし」の結果と比較する値を選択します。

- 変換の必要あり
比較演算子を選択し、「変換の必要あり」の結果と比較する値を選択します。

- 無効な表現あり
比較演算子を選択し、「無効なバイナリ表現」の結果と比較する値を選択します。

- 列制限超過
比較演算子を選択し、「列制限超過」の結果と比較する値を選択します。

- データ型制限超過
比較演算子を選択し、「型制限超過」の結果と比較する値を選択します。

「OK」を選択すると、「オブジェクト・タイプ」で選択した最初のスキーマ、表または列のグリッド行のうち、指定した基準のすべてを満たすものが、スキャン・レポートで強調表示されます。「前を検索」または「次を検索」ツールバー・ボタンを選択すると、基準を満たす同じタイプの前の行または次の行が強調表示されます。

データベース・スキャン・レポート: HTMLへのエクスポート

将来の参照用にスキャン結果を保存する場合は、スキャン結果をHTMLファイルにエクスポートできます。「HTMLとしてエクスポート」(ツールバーの最後のボタン)を選択します。これにより、図4-15「スキャン・レポートのエクスポート」に示すようなスキャン・レポートのエクスポート・ダイアログ・ボックスが開きます。

図4-15 スキャン・レポートのエクスポート

HTMLファイルの名前およびディレクトリ(フォルダ)を指定します。エクスポート・タイプ・グループ内のいずれかのオプションを選択すると、それに応じて次のいずれかの内容がエクスポートされます。

- 変換が必要であるか、または変換可能性の問題のあるデータを含む列およびその親オブジェクトのグリッド行のみ

- スキャン・レポートの内容全部

- レポート・タブに表示されている(非表示になっても閉じてもいない)結果グリッドの行および列のみ

「エクスポート」をクリックして、HTMLレポートを作成します。

データベース・スキャン・レポート: スキャンの停止

「停止」をクリックすると処理中のスキャンを停止することができ、その場合には警告ダイアログが表示されます。「はい」を選択してスキャンをただちに強制終了するか、「いいえ」を選択して現行プロセスが終了してからスキャン・プロセスを停止するか、または「取消」を選択してスキャンに戻るかを選択できます。

図4-16 スキャンの停止

データのクレンジング

スキャン・プロセスで特定されたデータ問題は、データベースを変換する前に解決する必要があります。DMUでは、すべての問題が解決されるか、無視できるとして明示的にマークされるまで、変換プロセスを開始できません。変換可能性の問題を解決するために実行できるアクションを、クレンジング・アクションと呼びます。

関連項目:

- クレンジングの詳細は、第6章「DMUを使用したデータのクレンジング」を参照してください。

- Oracle E-Business SuiteデータベースをUnicodeに移行するデータ・クレンジングの手順は、My Oracle Support ノート番号124721.1を参照してください。

データベースの変換

最後の手順はデータベース・キャラクタ・セットを実際に変換することであり、これはデータベース内のすべての問題を解決した後で実行できます(移行ステータスタブの画面を「図4-17 移行ステータス - 未解決の問題なし」に示します)。

図4-17 移行ステータス・タブ - 未解決の問題なし

データベースを変換する手順は、次のとおりです。

1. 変換プロセスを開始するために、移行メニューまたはナビゲータ・ペインのデータベース・ノードのコンテキスト・メニューから「データベースの変換」を選択します。DMUでは、変換フェーズで実行するSQL文のリストが変換計画として生成され、DMUウィンドウのクライアント・ペインに、図4-18「変換の詳細タブ」に示すような変換の詳細タブが表示されます。このタブの変換ステップ領域に、変換プロセスの一連のステップが表示されます。リスト内のステップをクリックすると、ステップの詳細領域に、ステップの一部として実行されるSQL文のリストが表示されます。このタブの機能の詳細は、「変換の詳細タブ」を参照してください。

図4-18 変換の詳細タブ

2. 「データベース変換パラメータの編集」をクリックして、データベース・プロパティ・タブの変換サブタブを表示します。このサブタブで設定できるパラメータの詳細は、「データベース・プロパティの表示および設定」を参照してください。

3. 「表変換計画の編集」をクリックして、アプリケーション表の変換計画の詳細を表示します。表示されたダイアログ・ボックスの上半分には、変換中に処理されるすべての表のリストが含まれます。リストから表を選択すると、下半分に、表およびその依存オブジェクトの処理に使用されるSQL文が表示されます。このリストは、プロパティ「変換方法」、「ターゲット表領域」、「LONG位置の保持」および「パラレル実行」を設定することでカスタマイズできます。これらのパラメータの詳細は、「データベース・プロパティの表示および設定」を参照してください。

図4-19 表変換計画の詳細の編集: 例1

4. 変換の詳細タブの変換ボタンをクリックして、変換プロセスを開始します。DMUによって、データベースに存在する予期しないセッションや、最も古いスキャン結果の経過時間に関して警告が表示されることがあります。以下の説明に従って警告を確認します。警告メッセージを受け入れて続行します。

DMUの変換フェーズで使用されるSQL文ALTER DATABASE CHARACTER SETは、文を実行しているセッションが、データベースにログインしている唯一のユーザー・セッションである場合にのみ成功します。このため、変換の開始前に、DMU自体によって開かれていないデータベースにログインしているユーザー・セッションがあれば、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';

前述の問合せにより戻された行内の列V$SESSION.PROGRAMに、オペレーティング・システムに依存する形式(Jnnn: nnnは小数点桁数3桁、例: "ORACLE.EXE (J000)")のOracle Database実行可能ファイル名が含まれている場合、その行で説明されているユーザー・セッションは、PL/SQLパッケージDBMS_JOBまたはDBMS_SCHEDULERを介して送信されたジョブを実行するためにデータベース・サーバー自体によって作成されたものです。データベース内で現在実行されているジョブを特定するには、データ・ディクショナリ・ビューDBA_JOBS_RUNNINGおよびDBA_SCHEDULER_RUNNING_JOBSを問い合せることができます。変換を開始する前に、すべてのジョブで作業が完了していること、およびそのセッションがV$SESSIONにもう表示されていないことを確認してください。

新たに別のジョブが開始されることがないように、次のSQL文を発行します。

ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY

すでに実行中のDBMS_SCHEDULERジョブを停止するには、プロシージャDBMS_SCHEDULER.STOP_JOBを使用します。DBMS_JOBジョブは、データベースを即時モードで停止しないかぎり停止できません。

セッションを切断せずに予期しないセッションに関する警告メッセージを受け入れると、変換は開始されますが、ステップALTER DATABASE CHARACTER SET TO target_character_setは失敗し、「ORA-12721: この操作は他のセッションがアクティブなときには実行できません」と報告されます。この時点でも、障害となっているセッションを切断し、次の項の説明に従って変換を再開できます。

データベースに最も古いスキャン結果が存在するという警告メッセージによって、スキャン結果の失効を評価できます。DMUでは、表データに対するDML変更は監視されず、データの変換可能性の問題があるかどうかや、既存のスキャン結果で特定されたもの以外に新たに変換の必要な列がデータベースに存在しているかは判断されません。スキャン結果が古すぎる場合、最近追加されたデータが変換されないまま残ったり、不適切に変換される可能性があります。全体データベース・スキャンは、移行の停止期間に入ってから、すべてのアプリケーションが停止され、新しいデータがデータベースに取り込まれることがない状態で、変換開始直前に実行することをお薦めします。データベースが非常に大きいために全体データベース・スキャンに時間がかかる場合は、常に不変データのみ含まれることがわかっているすべての大きな表を特定し、スキャン・ウィザードでそれらの表を選択解除できます。

すべての警告を受け入れた後、変換方法「変換可能な行のみを更新」を使用して変換する表がデータベースに存在していれば、DMUでスキャン・ウィザードが開かれ、これらの表が再スキャンされます。これは、表の必要な行識別子情報が使用可能であり、最新の状態になっていることを確認するために行われます。停止期間中に全体データベース・スキャンを実行したばかりの場合、または影響を受けるすべての表を、表識別子の収集レベルを「すべて変換」として最適な時間スケジュールで個別にスキャンした場合は、表の既存の行識別子情報を受け入れることもできます。スキャン・ウィザードのスキャン・パラメータ・ページの最長期間パラメータを使用して、使用可能な行識別子情報のうち指定した時間値を経過していないもののみを受け入れるようにDMUに指定します。スキャンが完了すると、変換プロセスが開始されます。

変換が開始されると、変換の詳細タブの形式が変わり、変換プロセスの進行状況情報が表示されます。表変換計画の編集リンクは表変換進行状況の表示リンクになります。「表変換進行状況の表示」をクリックすると、表変換進行状況ダイアログ・ボックスが開いて、アプリケーション表の詳細な変換進行状況を参照できます。

変換が完了すると、DMUで確認メッセージが表示されます。いずれかの変換SQL文で発生したエラーがある場合、変換ステップ・リストのステップ名の隣と、ステップの詳細リスト内の影響を受けるSQL文の隣にそのことを示す赤いアイコンが付きます。エラーが発生した文をクリックすると、変換の詳細タブの一番下にエラーの詳細が表示されます。

変換の詳細タブ

変換の詳細タブは、2つのモードで動作します。「データベースの変換」を選択してこのタブを開くと、最初はタブは計画モードで動作します。このタブには、DMUでデータベースをターゲット・キャラクタ・セットに変換するために実行するように計画されているSQL文のリストが含まれます。これらの文は、変換ステップ領域に一覧表示されたステップに分類されています。変換ステップをクリックすると、DMUによって、ステップの詳細領域に、そのステップに関連付けられているSQL文が表示されます。SQL文の左側にプラス・アイコンが表示されている場合、このアイコンをクリックすると、領域を開いて文のテキスト全部を表示できます。

図4-20 変換の詳細タブ: 計画モード

データベース変換パラメータの編集リンクをクリックすると、データベース・プロパティ・タブの変換サブタブがダイアログ・ボックス内に開きます。使用可能なパラメータの詳細は、「列プロパティ: 変換」を参照してください。

表変換計画の編集リンクをクリックすると、DMUによって、「表変換計画の詳細の編集ダイアログ」で説明されている表変換計画の詳細の編集ダイアログ・ボックスが開きます。

変換を開始する準備ができたら、タブの一番下にある「変換」をクリックします。変換の詳細タブが、図4-21「変換の詳細タブ: 監視モード」に示すような監視モードに切り替わります。

図4-21 変換の詳細タブ: 監視モード

監視モードでは、「変換」ボタンのかわりに「停止」ボタンが表示されます。「停止」をクリックすると、警告ダイアログが表示されます。このダイアログでは、ただちに変換プロセスを強制終了するか(「はい」)、現行稼働プロセスが終了した後に停止するか(「いいえ」)、または変換操作に戻るかの選択肢があります(「取消」)。

監視モードでは、表変換計画の編集リンクは表変換進行状況の表示リンクに変わります。このリンクをクリックすると、表変換進捗の表示ダイアログ・ボックスが監視モードで開きます。

緑色のチェック・マークは、すでに実行が正常に完了しているステップおよびSQL文を示します。アニメーションの円アイコンは現在実行されているステップを示し、スプロケット形状のアイコンは現在実行されているSQL文を示します。

データベースの変換プロセス中にエラーが報告された場合、図4-22「変換エラー・タブ」に示すように、現在実行されているステップおよびエラーの原因となった文に赤色のXエラー・アイコンが付きます。変換プロセスは一時停止されます。

図4-22 変換エラー・タブ

エラーの発生した文をクリックすると、報告されたデータベース・エラー・メッセージが文実行ステータス・フィールドに表示されます。文を再試行またはスキップするようにDMUに指定するには、「SQL文」領域の「アクション」列にあるドロップダウン・リストから対応するオプションを選択します。文を変換プロセスから除外するとデータベースが整合しない状態になる可能性があるため、スキップ・オプションは非常に慎重に使用してください。エラーの発生した文の処理方法を選択した後、「続行」をクリックして変換プロセスを再開します。

変換プロセスが完了すると、DMUによって確認ダイアログ・ボックスが表示されます。ナビゲータ・ペインからステータス・アイコンが削除されます。「移行」メニューから「DMUリポジトリの構成」を選択すると、Unicode検証モードでリポジトリを再インストールできるようになりました。

表変換計画の詳細の編集ダイアログ

図4-23に示す表変換計画の詳細の編集ダイアログ・ボックスでは、個々の表の変換パラメータを変更できます。表のパラメータを変更するには、ダイアログ・ボックスの上部グリッド内の対応するセルをクリックします。その表の変換方法で編集が許可されていれば、セルを編集できるようになります。ダイアログ・ボックスの上部グリッド内の表の行をクリックすると、表の変換に関連付けられているSQL文が下部グリッドに表示されます。

図4-23 表変換計画の詳細の編集: 例2

個々の表に設定できる変換パラメータは、次のとおりです。

- 変換方法

- ターゲット表領域

- LONG位置の保持

- パラレル実行

最初の3つのパラメータについては、「表プロパティ: 変換」を参照してください。パラレル実行パラメータでは、特定の表に対するSQL文に、データベースのパラレルDDL機能およびパラレルDML機能を使用するためのパラレル・ヒントを追加するかどうかを指定します。

ダイアログ・ボックスの一番上にある検索ツールバーを使用すると、名前に特定の部分文字列を含む表をすばやく見つけることができます。検索ボックスに部分文字列を入力して、[Enter]を押します。複数の名前で部分文字列が見つかった場合、これらの名前をナビゲートできる矢印アイコンが有効になります。マーカー・ペンのアイコンをクリックすると、一致する表が強調表示されます。

準備が完了したら、「OK」をクリックしてパラメータ変更を受け入れ、ダイアログ・ボックスを閉じます。ダイアログ・ボックスを閉じずに変更を受け入れる場合は、「適用」をクリックします。「適用」または「OK」をクリックすると、変更した表のSQL文が再生成されます。

表変換計画の詳細の編集ダイアログ・ボックスを監視モードで開くには、変換プロセス中に表変換の進行状況の表示リンクをクリックする方法もあります。監視モードでは、ダイアログ・ボックスの上部グリッドに、個々の表の変換に使用された時間を示す「経過時間」と、すでに処理された表データの割合を報告する「進行状況」という2つの追加の列が表示されます。また下部グリッドにも、個々のSQL文の実行に使用された時間を示す「経過時間」と、文が失敗した場合に選択するアクション(「再試行」または「スキップ」)を示す「アクション」という2つの追加の列が表示されます。

変換の停止

「停止」をクリックすることによって処理中に変換を停止することができ、その場合には警告ダイアログが表示されます。このダイアログでは、ただちに変換プロセスを強制終了するか(「はい」)、現行稼働プロセスが終了した後に停止するか(「いいえ」)、または変換操作に戻るかの選択肢があります(「取消」)。

図4-24 変換の停止

Unicodeとしてのデータの検証

DMUでは、データベースをUnicodeに移行するのみでなく、既存のAL32UTF8またはUTF8データベースの内容を検証することもできます。このようなデータベースは過去に変換されていたり、最初はUnicodeキャラクタ・セットで作成されたものである可能性があります。どちらの場合も、DMUを使用して現在のデータを確認できます。

すでにAL32UTF8またはUTF8に変換されたデータベースや、これらのキャラクタ・セットでの新規データベースに対してDatabase Migration Assistant for Unicodeを使用して、すべてのデータが実際に宣言済データベース・キャラクタ・セットになることを確認できます。データの検証プロセスと移行プロセスは異なるため、DMUユーザー・インタフェースも2つの使用タイプでは異なります。DMUで表示されるユーザー・インタフェースのタイプは、リポジトリのインストール時に決定されます。現行データベース・キャラクタ・セットがAL32UTF8でもUTF8でもない場合、DMUでは自動的に移行モードがアクティブになります。現行データベース・キャラクタ・セットがAL32UTF8の場合、検証モードがアクティブになります。現行データベース・キャラクタ・セットがUTF8の場合、リポジトリ構成ウィザード(「移行リポジトリのインストール」を参照)の最初のページで、(推奨されるUnicodeキャラクタ・セットである)AL32UTF8に移行するか、または検証モードをアクティブにするかを選択できます。データベースをUnicodeに移行した後で検証モードをアクティブにするには、移行リポジトリを再インストールします。

スキャンを実行して現在の文字データの検証を実行し、データベース・スキャン・レポートで問題が発生していないか確認できます。このレポートには、有効なUTF-8文字コードにならないバイト・シーケンスがどの表列に含まれているかが示されます。無効なデータが報告された場合、GUIでこのデータを表示し、問題の場所を分析できます。また、DMUではクレンジング・エディタでデータを修正することもできます。無効なデータが報告されなくなるまで、問題のスキャンと解決のプロセスを繰り返すことができます。

通常、データを修正するには、無効なデータをデータベースに格納しているアプリケーションの構成問題を解決する必要があります。エンコードされた文字データが間違ってAL32UTF8またはUTF8データベースに格納される場合、その原因として最も一般的なのは、クライアント構成の問題(通常はパススルー構成の問題)です。AL32UTF8およびUTF8データベースを検証モードで定期的にスキャンして、できるだけ早期にエンコーディングの問題を検出する必要があります。

検証モードのユーザー・インタフェースの概要

検証モードと移行モードのDMUユーザー・インタフェースは似ています。主な相違点は次のとおりです。

- 図4-25に示すように、移行ステータス・タブが検証ステータス・タブになります。

- 移行メニューが「検証」メニューになります。

- 移行メニューのデータベースの変換項目は、「検証」メニューでは無効な列の変換項目になります。この項目をクリックすると、列を想定キャラクタ・セットからデータベース・キャラクタ・セットに変換する手順が開始されます。

- データベース・スキャン・レポートには、データベース・オブジェクト名、現在のデータベース内容のスキャン結果、および想定キャラクタ・セット・プロパティのみが表示されます。これ以外のレポート列は使用できません。

図4-25 検証ステータス・タブ

- クレンジング・エディタ・タブのコンテキスト・メニューには、列変更のスケジュール・ダイアログ・ボックスおよび属性変更のスケジュール・ダイアログ・ボックスを開くためのオプションはありません。即時の操作である「列の変更」および「属性の変更」のみが実行可能です。

- クレンジング・エディタのツールバーには、スケジュール済クレンジングの影響を表示ボタンはありません。

- 無効な列の変換プロセスの変換の詳細タブは、変換ステップの数が少ないことを除いて、移行モードの変換ステップのユーザー・インタフェースとほぼ同じです。

- 表変換計画ダイアログ・ボックスは、移行モードよりも簡略的です。これには変換される表と列および関連付けられたSQL文が表示されますが、表レベルの変換パラメータを設定することはできません。また、このバージョンのダイアログ・ボックスに変換の進行状況は表示されません。変換の進行状況は、変換の詳細タブでのみ監視できます。

- 無効な列の変換を妨げている問題が残っている場合は、検証ステータス・パネルにある手順3の「ステータス」フィールドの下に表示されます。ステータスで解決されていない変換問題が存在しないことが示されるまで、報告された問題を確認して解決する必要があり、解決後に想定キャラクタ・セットにタグ付けされている列のUnicodeへの変換を続行できます。

データの検証方法

Unicodeとしてのデータを検証する手順は、次のとおりです。

1. リポジトリをインストールします。
前述のように、DMUリポジトリは検証モードでインストールされます。インストール後のリポジトリは繰り返し使用して、検証プロセスを何度でも適用できます。リポジトリを再インストールする必要があるのは、データベースまたはDMUをアップグレードする場合のみです。

2. データベースをスキャンします。
データベース全部または選択したスキーマ、表または列がスキャンされ、不正なコードが検出されます。データベース全部をスキャンすることを強くお薦めしますが、データベースが大きすぎて定期的にスキャンすると本番の作業への影響を避けられない場合や、以前の移行プロセスで実際には小さな表セットにのみASCIIデータが含まれていることが判明した場合は、オブジェクトのサブセットのみをスキャンするように選択することもできます。

スキャン結果に変換の必要がないデータを含む列のみが示された場合、データベースの内容は適正であり、検証プロセスのこの部分は完了です。

データベース・プロパティ・タブのスキャン・サブタブにあるU+FFFDを無効な文字として報告するプロパティの値は、DMUでのUnicodeデフォルト置換文字U+FFFD (AL32UTF8およびUTF8ではバイト・シーケンス0xEF 0xBF 0xBD)の解釈方法を指定します。このプロパティ値が「はい」の場合、この文字は無効なデータとして処理されます。これはデフォルトの動作であり、その理由は、データにこの文字が存在していると、通常は、実際のキャラクタ・セットで正しくタグ付けされていない入力のキャラクタ・セット変換の結果としてこのデータが生成されたことを意味するためです。なんらかの内部処理の目的で文字U+FFFDを使用する必要があり、DMUでそれを無効と報告されないようにする場合は、このプロパティ値を「いいえ」に変更します。

移行モードの場合と同じように、スキャンを開始し、結果を参照します。詳細は、「データベースのスキャン」を参照してください。

3. データをクレンジングします。
スキャン結果でいずれかの列に無効なバイナリ表現のあるデータが含まれることが示された場合、このデータのソースを診断し、関連付けられたアプリケーションまたは構成の問題を解決する必要があります。無効なバイナリ表現を含むデータの考えられる理由は、「クレンジング・シナリオ3: 無効な表現の問題のクレンジング」を参照してください。

無効な表現の問題をクレンジングするには、2つのオプションがあります。列の内容がバイナリの場合は列をバイナリ・データ型に移行し、列が他のキャラクタ・セットでエンコードされている場合は列をデータベース・キャラクタ・セットで変換します。列データを変換する最初の手順は、列の想定キャラクタ・セット・プロパティを設定して、適切なキャラクタ・セットでデータにタグ付けすることです。詳細は、「クレンジング・シナリオ3: 無効な表現の問題のクレンジング」および「想定キャラクタ・セットの設定」を参照してください。

いずれの列の想定キャラクタ・セット・プロパティも変更されていない場合、スキャン結果にデータ長の問題は表示されません。ただし、列のこのプロパティを変更して列を再スキャンした場合、列制限またはデータ型制限を超えるセルが報告されることがあります。次の手順に進む前に、長さの問題を解決する必要があります。即時モードでの列の長さ調整または別のデータ型への移行は、移行モードと同じ方法で実行できます。詳細は、第6章「DMUを使用したデータのクレンジング」(特に「列の変更」)を参照してください。

検証モードでのクレンジング・アクションは、すべて即時アクションです。新しい値がスキャン結果およびデータ表示に即時に適用されるという点で、想定キャラクタ・セット・プロパティの設定は即時性のある操作ですが、設定時にキャラクタ・セット変換は実行されません。キャラクタ・セット変換は、個別の変換ステップで実行する必要があります。列の「想定キャラクタ・セット」が適切に設定されていれば、スキャンで列は無効なバイナリ表現の問題がないとして報告されます。検証ステータス・タブを選択して、列を想定キャラクタ・セットからデータベース・キャラクタ・セットに変換するための変換ステップが必要かどうかを確認します。変換ステップを実行するまでは、データベースはまだクリーンになっていません。

クレンジング・アクションを実行すると、影響を受ける表のスキャン結果が無効化されます。表を再スキャンして、クレンジング・アクションが正常に完了したことを確認します。列の想定キャラクタ・セット・プロパティを設定した場合、再スキャンを行うと、データの切捨ての問題なく列データを想定キャラクタ・セットからデータベース・キャラクタ・セットに変換できるかどうかがわかります。

4. 間違ってエンコードされたデータを変換します。
クレンジング中、いずれかの列に想定キャラクタ・セット・プロパティが設定されている場合、この手順を実行して、列の内容を想定キャラクタ・セットからデータベース・キャラクタ・セットに変換する必要があります。この手順では、データベース・キャラクタ・セットとは異なる想定キャラクタ・セットでマークされているすべての列が、データベース・キャラクタ・セットに物理的に変換されます。変換はSQL UPDATE文を使用して実行されます。このプロセスを開始するには、「検証」メニューまたはナビゲータ・ペインのデータベース・ノードのコンテキスト・メニューから「無効な列の変換」を選択し、表示される変換の詳細タブで「変換」をクリックします。

列の内容が変換されると、想定キャラクタ・セット・プロパティがデータベース・キャラクタ・セットに再設定されます。変換された列を再スキャンして、変換が正常に完了したことを確認できます。

検証プロセスは定期的に行い、システムの構成に変更(たとえば、アプリケーションやデータベースのアップグレード、新規アプリケーションの追加、新規の国からの新規アプリケーション・ユーザーの追加など)を行った後には必ず再適用してください。新しい構成になったデータベースにはスキャン済データが格納されている可能性が高いため、構成変更後、ある程度の時間が経過してからスキャンを実行してください。

データベース・キャラクタ・セットがUTF8の場合、DMUリポジトリは検証モードでインストールされるため、データベースをAL32UTF8に移行する場合は、このリポジトリをアンインストールしてから、移行モードを選択して再びインストールする必要があります。

診断パッケージの作成

DMUの使用中に問題が発生した場合、その後の分析に使用する診断パッケージを作成すると、オラクル社がその問題を解決する際に役立ちます。このパッケージは、プロジェクト・ログ・ファイル、スキャン・レポート、およびDMUの現行リポジトリ表とアーカイブ済リポジトリ表が入ったデータ・ポンプ・ダンプ・ファイルを含むjarファイルです。

診断パッケージを作成する手順は、次のとおりです。

1. 移行メニューから「診断パッケージの作成」をクリックします。図4-26「診断パッケージ・ウィザード」が表示されます。

図4-26 診断パッケージ・ウィザード

2. 「次へ」をクリックします。図4-27「診断パッケージ・ウィザード - パッケージの内容」が表示されます。

図4-27 診断パッケージ・ウィザード - パッケージの内容

3. 「次へ」をクリックします。図4-28「診断パッケージ・ウィザード - パッケージ・ファイル」が表示されます。

図4-28 診断パッケージ・ウィザード - パッケージ・ファイル

4. 「完了」をクリックすると、選択したパスで診断jarファイルが作成されます。

5 DMUに関する高度なトピック

この章では、Database Migration Assistant for Unicodeを使用する際に考慮する必要のある様々な高度なトピックを扱います。内容は次のとおりです。

- 移行からの列および表の除外

- アクセス不能データの処理

- データ・ディクショナリの内容の移行

- 多言語列の使用

- 高度な変換可能性の問題

- Unicodeへの移行に対するアプリケーションの適用

- データベース・キャラクタ・セット・メタデータの修復

- DMUバージョンの更新

- DMUのアクセシビリティについて

移行からの列および表の除外

状況によっては、選択した列または表を移行プロセスのスキャン・ステップまたは変換ステップから除外します。これに該当する状況は次のとおりです。

- 1つの列に複数のキャラクタ・セットが存在する問題を解決する必要があります(「多言語列の使用」を参照)。

- データベースにバイナリ・データを含む文字列が存在しています。アプリケーションが社内で開発されていないなどの理由で、データベースにアクセスするアプリケーションを変更することができないため、列をバイナリ・データ型(RAW、LONG RAWまたはBLOB)に移行することができません。アプリケーションがこれまでどおりパススルー構成でデータにアクセスできるように、列の変換は回避する必要があります。

- データベースに数TBものデータを含む非常に大きな表が存在しますが、それには変換可能なデータが含まれていないことがわかっています。このような表には次のような制約があります。

- 現行データベース・キャラクタ・セットがマルチバイトの場合を除いて、CLOB列を含むことはできません。

- 内部アプリケーション・コード、「はい」/「いいえ」のフラグ、クレジット・カード番号、または基本のASCII文字のみ使用することがわかっているその他のデータを含む文字列のみを含むことができます。

- エンド・ユーザーが英語のテキストのみを入力することが予測されていても、非ASCII文字をサポートするキーボードからユーザーが入力したデータを含むことはできません。Microsoft Windowsが実行されているコンピュータの標準的なキーボードでは、常にこのような文字の入力が許可されます。

このような大きな表をスキャンから除外すると、データベース全部のスキャン時間を短縮できます。非常に大きな表であっても、少なくとも1回はスキャンすることを強くお薦めします。

- DVD-ROMジュークボックスなどの低速ストレージ・デバイスの読取り専用表領域に格納されたアーカイブ・データは、非常に大きな表の場合と同様に、スキャンから除外できます。この場合も、表に変換の必要なデータが含まれていないことを確認する必要があります。

- なんらかの重要な理由で読取り/書込みに変更できない読取り専用表領域または読取り専用表があります。DMUで変換できない変換可能データが表領域または表に含まれていても、データベースのそれ以外の部分はUnicodeに変換できます。表領域でそのデータを受け入れます(そうしない場合、適切な回避策を実行するか、DMUで後から検証モードでデータを変換するかしないかぎり、表は変換後に読取り不可になります)。

- オンラインに戻すことができないオフラインの表領域またはオフラインのデータ・ファイルがある場合、読取り専用表領域の場合と同様に、DMUではこの表領域またはデータ・ファイル内のデータのスキャンまたは変換を実行できません。データベースのこれ以外の部分は変換する必要があるため、後で表領域またはデータ・ファイルをオンラインに戻したときに表領域またはデータ・ファイルの内容が読取り不可になる可能性があることを承諾します。DMUを検証モードで使用して、後からこのデータを変換できます。

読取り専用モードおよびオフライン・モードのデータベース・オブジェクトの詳細は、「アクセス不能データの処理」を参照してください。

表をスキャンから除外するには、スキャン・ウィザードのオブジェクト選択ページで、単にその表を選択解除します。

列を変換から除外するには、その列プロパティ・タブを開いて(「列プロパティの表示および設定」を参照)、変換サブタブの変換から除外するプロパティを「はい」に設定します。DMUでは、変換ステップの開始を妨げている変換可能性の問題をチェックする際に、変換から除外される列を考慮しません。表を変換から除外するには、その変換可能列をすべて除外します。

アクセス不能データの処理

データベース内の特定のタイプのデータは、アプリケーションからアクセスできないことがあります。データは更新不能であったり、読取りすらできない場合もあります。DMUでは更新不能データは変換できず、読取り不能データは変換もスキャンもできません。アクセス制限のあるデータは、次のいずれかのデータベース・オブジェクトに含まれるデータです。

- 読取り専用表の考慮事項

- 読取り専用表領域の考慮事項

- オフラインの表領域およびデータ・ファイルの考慮事項

- 外部表の使用

読取り専用表の考慮事項

リリース11.1以降のすべてのOracle Databaseでは、データベース表の読取り専用モードをサポートしています。このため、表の内容が更新されないように保護する場合、ユーザーは表を読取り専用モードに変更できます。読取り専用表に対して問合せ、制約の変更、セグメントの移動、縮小または拡大を行うことはできますが、その列値はどのような方法でも変更できず、新しい行を追加することもできません。ユーザーは、必要に応じて何度でも、表を読取り/書込みモードに変更してから読取り専用モードに戻すことができます。

読取り専用表は更新できないため、DMUで変換が必要となることがあっても、その内容は変換できません。このため、DMUでは、変換の試行前に読取り専用表が読取り/書込みモードに自動的に変更されます。変換後、モードは読取り専用に戻ります。

変換方法として「CREATE TABLE AS SELECTを使用してデータをコピー」を使用して読取り専用表を変換する場合、読取り専用表を再作成することもできます。

読取り専用表領域の考慮事項

表領域は読取り専用モードに設定できます。これにより、それに格納されているデータの更新が禁止されます。読取り専用表領域のデータ・ファイルは、DVD-ROMなどの読取り専用媒体に格納し、ほとんどアクセスされないアーカイブ・データ用の安価なストレージとして使用されるジュークボックスに移動できます。また、データ・ファイルを標準的な読取り/書込みディスク・ストレージ・デバイスに残すこともできます。たとえば、非常に大きなデータベース内の履歴データを頻繁に読取り専用表領域に移動するとします。このような表領域は、読取り専用モードに設定した直後に1回のみバックアップします。読取り専用表領域は変更できないため、それ以降のバックアップは必要ありません。これにより、非常に大きなデータベースのバックアップ時間を大幅に短縮できます。

表のいずれかのセグメント(パーティション、CLOB、VARRAYおよびIOTオーバーフロー・セグメントを含む)に変換の必要なデータが含まれ、そのセグメントが読取り専用表領域に属している場合、DMUでは正常に表を変換できません。DMUによって移行ステータス・タブにこれが変換可能性の問題として報告され、問題を解決するまで変換手順を開始できません。

この変換可能性の問題を解決する方法は、問題のある表領域が読取り専用モードにされた理由によって異なります。バックアップ時間を短縮することが理由であった場合、データがまだ標準的なディスク・デバイスにあれば、表領域を読取り/書込みモードにして、データベースの残りの部分とともに変換し、再び読取り専用モードに設定してからバックアップをリフレッシュします。

表領域が読取り専用モードに設定されて、読取り専用媒体に移動された場合、実行できる解決方法は次のとおりです。

- 変換可能データを含むすべての読取り専用表領域を格納するのに十分なディスク・ストレージを(永続的または一時的に)配置できる場合、表領域をこのストレージにコピーして読取り/書込みに設定し、データベースの残りの部分とともに変換してから、再び読取り専用にし、その後はディスク・ストレージに残すか、読取り専用媒体に戻します。変換可能データを含む読取り専用表領域の数が多い場合、この解決方法は実行できないことがあります。

- メイン・データベース(移行するデータベース)と同じキャラクタ・セットで補助データベースを作成します。トランスポータブル表領域機能を使用して読取り専用表領域を新しいデータベースに移動し、データ・ファイルは物理的に現在の場所に残します。メイン・データベース内に新しいデータベースへのデータベース・リンクを作成します。補助ビューを作成するか、アプリケーションを変更することによって、メイン・データベースに接続するアプリケーションに補助データベース内の読取り専用データが表示されるようにします。データは、データベース・リンクを介してトランスポートされる間に変換されます。

オフラインの表領域およびデータ・ファイルの考慮事項

表領域または表領域内の選択済データ・ファイルがオフライン・モードに設定されていることがあります。オフラインの表領域またはデータ・ファイルに含まれるデータには、読取りアクセスも書込みアクセスもできません。オフライン・モードは、名前変更やストレージ・デバイス間での移動など、データ・ファイルの様々な管理操作で必要となります。

表のいずれかのセグメント(パーティション、CLOB、VARRAYおよびIOTオーバーフロー・セグメントを含む)に変換の必要なデータが含まれ、そのセグメントがオフラインの表領域またはデータ・ファイルに属している場合、DMUでは表のスキャンも変換もできません。このような表領域またはデータ・ファイルは、影響を受ける表をスキャンまたは変換する前に、オンライン・モードに戻す必要があります。そうしない場合、スキャン・ステップおよび変換ステップでORA-00376のようなエラーが報告されます。

オフラインのデータ・ファイル内に変換可能データが見つかると、DMUの移行ステータス・タブにエラーが報告され、変換ステップを開始できません。

外部表の使用

外部表とは、データがデータベース外部のファイルにある表のことです。データベースには表の列の定義(メタデータ)が含まれますが、表を参照する問合せが発行されると、表の行が外部ファイルからフェッチされます。Oracle Databaseでは、外部ファイルを読み取る2つのアクセス・ドライバ(ORACLE_LOADERおよびORACLE_DATAPUMP)をサポートしています。ORACLE_LOADERは、SQL*Loaderでサポートされる形式のテキスト・ファイルを読み取ります。ORACLE_DATAPUMPは、データ・ポンプ・エクスポート・ユーティリティ(expdp)およびデータ・ポンプ・インポート・ユーティリティ(impdp)と互換性のあるバイナリ・ファイルをサポートしています。

外部表を変更するDML文はサポートされていません。CREATE TABLE … ORGANIZATION EXTERNAL … AS SELECT文を使用して外部表を作成すると、外部ファイルORACLE_DATAPUMPが作成されてデータが挿入されますが、データベース内部から後でこれを変更することはできません。ORACLE_LOADERファイルは、データベース外部で作成および変更する必要があります。DMUでは、データベースの内容とともに外部ファイルが変換されることはありません。

外部表が作成されると、そのデータ・ファイルのキャラクタ・セットが次のように設定されます。

- ORACLE_DATAPUMPドライバまたはデータ・ポンプ・エクスポート・ユーティリティによってファイルが作成されると、ORACLE_DATAPUMPファイルのキャラクタ・セットがデータ・ファイル自体に格納されます。

- ORACLE_LOADERファイルのキャラクタ・セットは、外部表定義のアクセス・パラメータ句のCHARACTERSETパラメータで指定できます。このパラメータを指定しない場合、データベース・キャラクタ・セットを使用してファイルの内容が解釈されます。

外部ファイルの宣言済キャラクタ・セットがデータベース・キャラクタ・セットと異なる場合、データベースはデータの読取り中に自動的にデータを変換します。データベース・キャラクタ・セットは変更されるが、外部ファイルのキャラクタ・セットは変更されない場合、データベースは自動的に新しい構成に適応し、外部ファイルが新しいデータベース・キャラクタ・セットに変換されます。

注意:
ORACLE_LOADERファイルのキャラクタ・セットが外部表定義のアクセス・パラメータ句で明示的に宣言されていない場合、データベース・キャラクタ・セットが変更されると、外部ファイルのキャラクタ・セットの暗黙的な宣言も変更されます。ファイル自体が新しいデータベース・キャラクタ・セットに変換されない場合、外部ファイル宣言はファイルの実際のキャラクタ・セットに一致しなくなり、外部表を正しく読み取ることができなくなります。
データベースをUnicodeに移行する前に、欠落している明示的なキャラクタ・セット宣言をすべての外部表定義に追加するか、ファイルの内容を新しいデータベース・キャラクタ・セットに変換する必要があります。

外部表のクレンジング

DMUでは、外部表は変換されませんが、移行プロセスのスキャン・ステップには含められます。スキャン結果には、新しいUnicodeデータベース・キャラクタ・セットへの変換後にデータが拡張しても、移行後にもファイルの内容が宣言済の列の長さに収まるかどうかが示されます。また、外部ファイルに不正な文字コードが存在する場合は結果に警告が表示されます。ファイルの内容をオンザフライで変換する必要がある場合、これらのコードは読取り不可になります。

スキャン・レポートに無効なバイナリ表現の問題が示されている場合、「データの無効なバイナリ記憶域表現」および「クレンジング・シナリオ3: 無効な表現の問題のクレンジング」の説明に従って、無効なコードのソースを特定する必要があります。

次の各項で、報告された様々な問題から外部表をクレンジングするために実行できるアクションについて説明します。

長さの問題のクレンジング

スキャン・レポートに外部表の内容の長さの問題が示されている場合、表を変更して影響を受ける列の長さを調整するか、それらをキャラクタ・セマンティクスに移行できます。DMUでは外部表に対するクレンジング・アクションをサポートしていないため、これはSQL*PlusやSQL Developerなどの別のツールで行う必要があります。データが拡張して4000バイトを超える場合、VARCHAR2列をCLOBに変更する必要があることがあります。列データ型をCLOBに変更するには、外部表を再作成する必要があります。これはメタデータのみの変更が行われる操作なので短時間ですみますが、許可などの依存オブジェクトは再作成する必要があることに注意してください。

ORACLE_LOADERファイルのキャラクタ・セット宣言の修正

パススルー構成でORACLE_LOADERドライバによって外部表の文字値が読み取られる場合、つまりデータ・ファイルの宣言済キャラクタ・セットとデータベース・キャラクタ・セットが同じであるのに、データの内容の実際のキャラクタ・セットは異なる場合、外部表定義のアクセス・パラメータ句で実際のキャラクタ・セットを宣言することにより、この構成を修復できます。データベースを変換する前に本番データベース内の宣言を変更すると、パススルー構成が壊れて表が読取り不可になるため、これは行わないでください。

データベースの変換前に、「想定キャラクタ・セットの設定」の説明に従って、影響を受ける外部表の列の想定キャラクタ・セット・プロパティをデータ・ファイルの特定された実際のキャラクタ・セットに変更してから、表を再スキャンして、データ・ファイル・キャラクタ・セット宣言の修正後に新たに発生した可能性のある長さの問題や無効なバイナリ表現の問題を特定する必要があります。

データベース内の影響を受けるすべてのアクセス・パラメータ句を変更するスクリプトを作成し、DMUの変換フェーズが正常に完了した後で直接それを実行することをお薦めします。

ORACLE_DATAPUMPファイルのキャラクタ・セット宣言の修正

パススルー構成でORACLE_DATAPUMPドライバによって外部表の文字値が読み取られる場合、つまり前の項で説明したキャラクタ・セット構成においては、データベースがUnicodeに変換された後で、データ・ポンプ入力ファイルが実際のキャラクタ・セットで適切に再びタグ付けされていることを確認する必要があります。

キャラクタ・セット宣言はデータ・ポンプ・ファイルに内部的に格納されているため、簡単には変更できません。宣言を修正するには、より複雑な手順を実行する必要があります。あるいは、ORACLE_LOADER形式で提供されるように外部表ファイルを調整して、外部表のアクセス・パラメータ句のキャラクタ・セット宣言を完全に制御できます。

データ・ポンプ・ファイルがパススルー構成で使用されている場合、そのソース(エクスポートされた)データベースもこの構成で使用されます(そうでなければ、間違ってタグ付けされたファイルが生成されることはありません)。このため、データ・ポンプ・ファイルのキャラクタ・セット宣言を修正する場合は、そのソース・データベースのデータベース・キャラクタ・セットを修正する方法が推奨されます。

ソース・データのキャラクタ・セットを制御できない場合は、次の操作を実行する必要があります。

- データ・ポンプ・ファイルのキャラクタ・セットで空の補助データベースを作成します。

- ファイルをインポートします。これはパススルー構成で行われます。

- データベース・キャラクタ・セットをファイルの実際のキャラクタ・セットに変更します。

- ファイルをエクスポートして、(Unicodeへの移行後に)メイン・データベース内の外部表にそれらのファイルを使用します。

Character Set Scannerユーティリティ(csscan)およびcsalter.plbスクリプトを使用してデータベース・キャラクタ・セットを変更することによりパススルー構成を修正する方法の詳細は、Oracleサポートに問い合せてください。

次のPL/SQLコードを使用すると、データ・ポンプ・ファイルのキャラクタ・セットを特定できます。

DECLARE
et_directory_name VARCHAR2(30) := '<directory object name>';
-- for example, 'DATA_PUMP_DIR'
et_file_name       VARCHAR2(4000) := '<file name>';
-- for example, 'EXPDAT.DMP'
et_file_info       ku$_dumpfile_info;
et_file_type       NUMBER;
BEGIN
dbms_datapump.get_dumpfile_info
( filename => et_file_name
, directory => et_directory_name
, info_table => et_file_info
, filetype => et_file_type );
FOR i IN et_file_info.FIRST..et_file_info.LAST LOOP
IF et_file_info.EXISTS(i) THEN
IF et_file_info(i).item_code = 11 THEN
dbms_output.put_line( 'Character set of the file is ' ||
et_file_info(i).value );
END IF;
END IF;
END LOOP;
END;

破損した文字コードの修正

外部表内の無効なバイナリ表現の問題の分析で、いくつかの文字値に破損した文字コードが含まれることが示された場合(通常は、ユーザー・エラー、アプリケーションの欠陥、または一時的な構成の問題が原因です)、再度エクスポートまたはアンロードされたソース・データベースおよび影響を受けるファイル内で値を修正する必要があります。

ORACLE_LOADERファイルを使用すると、テキスト・エディタで直接ファイル内の無効なコードを修正できます。ただし、この解決方法を適用できるのは、同じソース・データベース内容から生成された新しいバージョンでファイルが定期的に置換されない場合のみです。

バイナリ・データの処理

外部表内の無効なバイナリ表現の問題は、バイナリ・データが外部表ドライバによって文字データとして宣言およびフェッチされている場合にも起こります。このタイプの問題をクレンジングするには、影響を受ける列に対してRAWやBLOBなどのバイナリ・データ型を使用するように外部表を再定義する必要があります。

パススルー構成を引き続き使用して、UTF8やAL32UTF8などのマルチバイト・キャラクタ・セットを使用するデータベースにバイナリ・データをフェッチすることはお薦めしません。このような構成は、現在または将来に予期しない問題を引き起こす可能性があります。

ORACLE_LOADERファイルのパフォーマンスの考慮事項

Oracle Databaseユーティリティ・ガイドに、ORACLE_LOADERドライバのパフォーマンス・ヒントがいくつか示されています。Unicodeへのキャラクタ・セット移行のコンテキストでは、特に次のヒントが関連します。

- シングルバイト・キャラクタ・セットは、最も速く処理される。

- 固定幅キャラクタ・セットは、可変幅キャラクタ・セットより速く処理される。

- 可変幅キャラクタ・セットのバイト長セマンティクスは、文字長セマンティクスより早く処理される。

- キャラクタ・セットを変換するより、データ・ファイルのキャラクタ・セットをデータベースのキャラクタ・セットに一致させる方が速く処理される。

ORACLE_LOADERファイルを現行キャラクタ・セットのままにするか、新しいUnicodeデータベース・キャラクタ・セットでファイルが提供されるように調整するかを選択できる場合は、前述のヒントから導かれる次の結果を考慮する必要があります。

- ファイルの現行キャラクタ・セットがマルチバイトの場合、ファイルにUTF8またはAL32UTF8データベース・キャラクタ・セットを使用しても、解析時間(ファイルをレコードおよびフィールドに分割するために必要な時間)に大きな影響はありませんが、変換時間は短縮されます。パフォーマンスは、外部表を参照する問合せのほうがよくなります。

- ファイルの現行キャラクタ・セットがシングルバイトの場合、ファイルにUTF8またはAL32UTF8データベース・キャラクタ・セットを使用すると解析の速度は遅くなりますが、変換時間は短縮されます。どちらがより効率的かを判断するために、両方の構成を比較テストする必要があります。

- ファイルをシングルバイト・キャラクタ・セットからUTF8またはAL32UTF8に変換する場合、問合せパフォーマンスを最大にすることが重要であれば、フィールドの長さおよび位置を文字でなくバイトで表現するよう試みてください。

データ・ディクショナリの内容の移行

DMUでは、データ・ディクショナリに属する表は、それを所有するスキーマに基づいて分類されます。DMUでデータ・ディクショナリ内にあるとみなされるスキーマは、ナビゲータ・パネルのデータ・ディクショナリ・ノードの下に表示されたスキーマです(「DMUのインタフェースおよびナビゲーションの概要」を参照)。データ・ディクショナリ・スキーマ内にSYSやSYSTEMなどの独自の表を作成すると、DMUではこれが他のデータ・ディクショナリ表として処理されます。ユーザー表をデータ・ディクショナリ・スキーマ内に作成することはお薦めしません。このリリースのDMUでは、データ・ディクショナリ表に保持されているメタデータ・サブセットのみのキャラクタ・セット変換がサポートされています。したがって、次の各項で説明するように、DMUではデータ・ディクショナリ表はデータベース内の他の表とは異なる方法で処理されます。

データ・ディクショナリ表のスキャン

ほとんどのデータ・ディクショナリ表は、ユーザー定義表と同じ方法でスキャンされます。データが列制限を超える、データがデータ型制限を超える、データに無効なバイナリ表現があるといった通常の変換可能性の問題も、同様の方法で報告されます。ただし、ターゲットのUnicodeキャラクタ・セットに変換する必要のあるデータが報告される方法が異なります。このリリースのDMUでは、いくつかの例外を除いてデータ・ディクショナリの内容の変換はサポートされていないため、変換の必要なデータを含む変換不可能な列には黄色い三角形の警告アイコンが付き、データベース変換ステップの開始を妨げる変換可能性の問題があるとみなされます。データベース・スキャン・レポートのフィルタリング条件「問題あり」にも、これらの列が含まれています(「データベース・スキャン・レポート: フィルタリング」を参照)。

「データの表示」タブ(「データの表示」を参照)は、データ・ディクショナリやその他の変更不可能な表に対するクレンジング・エディタの読取り専用バージョンであり、変換不可能なデータ・ディクショナリ列に、「プリファレンス」ダイアログ・ボックスのクレンジング・エディタ・タブで構成されている専用の色で(デフォルトではオレンジ色の背景に黒色で)変換可能な値が表示されます。

DMUにより変換されるいくつかの列の変換可能データ(「データ・ディクショナリ表の変換」に一覧表示されています)は、問題として報告されません。

実装上の理由で、表SYS.SOURCE$、SYS.ARGUMENT$、SYS.IDL_CHAR$、SYS.VIEW$、SYS.PROCEDUREINFO$およびSYS.PLSCOPE_IDENTIFIER$は常に、収集する行識別子パラメータを「すべて変換」に設定してスキャンされます。詳細は、「データ・ディクショナリ表の変換」を参照してください。

データ・ディクショナリ表のクレンジング

Oracleではデータ・ディクショナリ表の構造を変更することも、その内容を更新することもサポートされていないため、DMUではこのような表に対するクレンジング・アクションは実行できません。データ・ディクショナリ表の列に想定キャラクタ・セットを設定できますが、選択したキャラクタ・セットは、「データの表示」タブに列が表示されるときにのみ考慮されます。変換に使用されるソース・キャラクタ・セットは常に、想定データベース・キャラクタ・セットです。

データ長の問題のクレンジング

データ・ディクショナリの内容(メタデータ)についてデータ長の問題が報告された場合、この問題をクレンジングするには、メタデータを短いバージョンで置換する必要があります。同じ長さ問題は、DMUを使用する移行のみでなくすべてのキャラクタ・セット移行方法に影響を与えるため、別の変換方法を使用する場合(データ・ポンプ・ユーティリティを使用してデータを移動する場合など)でも、これらの問題はクレンジングする必要があります。

最もよくある長さ問題は、変換後にオブジェクト名が許容される長さを超えることです。識別子の通常の長さ制限は30バイトしかないため、非ASCII文字を含むそれより長い識別子(特に非Latinスクリプトで記述された識別子)は簡単に制限を超えてしまいます。たとえば、15文字を超えるギリシャ語またはロシア語の識別子は、EL8MSWIN1253またはCL8MSWIN1251からUTF8またはAL32UTF8に変換されると、30バイトの制限を超えます。中国語、日本語および韓国語の文字は通常、2バイトから3バイトに拡張されるため、10文字を超える識別子は問題となります。

識別子を短くするには、適切なSQL文またはPL/SQLパッケージ・コールを使用して、対応するデータベース・オブジェクトの名前を変更する必要があります。名前変更のみで済むオブジェクトもありますが、ほとんどのオブジェクトは削除してから新しい名前で再作成する必要があります。オブジェクトを削除すると、一部の依存オブジェクトも一緒に削除されます。これらも同様に再作成する必要があります。

たとえば、表、ビュー、順序またはプライベート・シノニムの名前を変更するには、SQL文RENAMEを使用します。表の列の名前を変更するには、SQL文ALTER TABLE RENAME COLUMNを使用します。ただし、クラスタについては名前変更のみ行うことはできません。一度削除してから別の名前で再作成する必要があります。ただし、クラスタを削除する前に、クラスタに格納されているすべての表を削除する必要があります。権限、索引、トリガー、行レベルのセキュリティ・ポリシー、アウトラインなど、表に作成された補助オブジェクトが多数存在する可能性があるため、最終的に多数のオブジェクトを再作成することになる可能性があります。このような場合は、データ・ポンプ・ユーティリティおよびメタデータAPIを使用すると便利です。

関連項目:
データ・ポンプ・ユーティリティおよびメタデータAPIの詳細は、『Oracle Databaseユーティリティ』を参照してください。

データベース・オブジェクトの名前を変更した後、このオブジェクトを参照するすべてのアプリケーション・コードを、新しい名前を使用するように変更する必要があります。これには、データベース内のPL/SQLとJavaコード、および影響を受けるすべてのクライアント・アプリケーションも含まれます。

拡張されて最大許容長を超えることが多いメタデータ・タイプには他に、様々なデータベース・オブジェクトのフリー・テキスト・コメントがあります。同様に、長さの問題が報告されていれば、コメントを短いバージョンで更新して問題をクレンジングする必要があります。ほとんどのコメントは、適切なSQL文またはPL/SQLパッケージ・コールを使用して更新できます。

データ・ディクショナリの問題をクレンジングする適切な文を特定するための推奨方法は、「メタデータの特定」を参照してください。

無効なバイナリ表現の問題のクレンジング

データの無効なバイナリ表現の一般的な原因は、「データの無効なバイナリ記憶域表現」で説明されているパススルー・シナリオです。このような構成においてSQL文またはPL/SQLコールが発行されると、データベース・キャラクタ・セットで無効な文字または不適切な意味の文字を使用した名前のデータベース・オブジェクトが作成され、使用される可能性があります。たとえば、WE8MSWIN1252データベースでは意味のない表名が日本語のJA16SJISクライアントでは正しく表示されるとして解釈される場合や、データベース・キャラクタ・セットでは判読できないのに、別のキャラクタ・セットで表示すると適切に表示されるコメントがPL/SQLモジュールに含まれる場合があります。

引用符なしの識別子で許可される文字制約によってデータベース・オブジェクト名は最初から表示可能になっているため、データベース・オブジェクト名の無効なバイナリ表現の問題が発生することはほとんどありません。オブジェクト・コメントの無効なバイナリ表現のほうが発生する可能性は高くなりますが、修正するのも簡単です。

パススルー構成が原因で起こる無効なバイナリ表現の問題がアプリケーション・データにも共通の問題である場合、このような問題をクレンジングするには、データベースの想定データベース・キャラクタ・セット・プロパティをデータベースの内容の実際のキャラクタ・セットに設定します(「データベース・プロパティ: 一般」を参照)。あるいは、「データ・ディクショナリ表のクレンジング」で説明されている方法を使用して、影響を受けるメタデータを変換可能性の問題のないバージョンで更新します。

PL/SQLおよびJavaソース・コードまたはビュー定義における無効な表現の問題を解決するには、メタデータAPIを使用して、オブジェクトを作成するDDL文を取得し、文のテキスト内の問題のある文字を修正して、オブジェクトを再作成する文を実行します。オブジェクト名が影響を受けない場合は、権限などの関連オブジェクトを再作成ずに、CREATE OR REPLACE構文を使用してコードを変更します。

メタデータの特定

データ・ディクショナリの変換可能性の問題を解決するプロセスで難しいのは、データベース・スキャン・レポートで示された問題を、影響を受ける表および列に格納されているメタデータのタイプにマップする手順です。DMUインタフェースに表示されるデータ・ディクショナリ表は通常、ドキュメント化されていません。その内容を表示するためのドキュメント化された方法は、DBA_TABLES、DBA_TAB_COLUMNS、DBA_RULES、DBA_SCHEDULER_JOBSなどのデータ・ディクショナリを介する方法です。

変換可能性の問題のあるメタデータのタイプを特定するには、次の方法をこの順序どおりに試行してください。

- 「データの表示」タブで、問題のある文字値を確認します(「データの表示」を参照)。値そのものが、それが属するメタデータをすでに示している場合もあります。たとえば、値が「This column keeps customer e-mail」であればそれが列コメントであることがわかり、値が「HR_EMPLOYEE_V」であれば名前のビューの一般的な規則に一致するため、この値がビュー名であることがわかります。

- cat*.sqlおよびcd*.sqlというSQLスクリプト・ファイル内に問題が報告されていて、データベースのOracleホーム・ディレクトリのrdbms/admin/サブディレクトリ内にある表の名前を検索します。これらのスクリプトは、『Oracle Databaseリファレンス』でドキュメント化されているデータ・ディクショナリ・ビューを定義するものです。表およびその列をドキュメント化された適切なビューにマップすると、報告された問題がどのメタデータに含まれるかがわかります。

- Oracleサポートに問い合せるか、Oracle Technology Network Webサイトのグローバリゼーション・フォーラムで質問を投稿してください。

変換可能性の問題が報告されているメタデータを特定した後は、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ポリシーの属性値

- CTXSYS.DR$STOPWORD.SPW_WORD - Oracleのすべてのストップリスト内のすべてのストップワード

- SYS、SYSTEMおよびCTXSYSスキーマ内の、様々なデータベース・オブジェクトに対するユーザー・コメントを含む50種類を超える列

PL/SQLソース・コードおよびビュー・ソース・テキストは、複数の表で保持されます。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バージョン11.1以前は存在していませんでした)

DMUでは、前述の表および列内の変換可能な文字データは変換可能性の問題として報告されません。データ・ディクショナリのその他の表および列内の変換可能データにはいずれも、スキャン・レポートおよび移行ステータス・タブで変換可能性の問題があることを示すフラグが付きます。フラグの付いたデータが削除されるまでは、データベース変換ステップを開始できません。

無視されるデータ・ディクショナリ表

DMUでは、次の表はスキャンされません。

- 列ヒストグラム統計が含まれるSYS.HISTGRM$

- SYS.WRI$_OPTSTAT_OPRやSYS.WRI$_OPTSTAT_%_HISTORYのような名前の表で保持されている自動ワークロード・リポジトリ・オブジェクト統計履歴

- SYSTEMスキーマ内のDMUリポジトリ表

- CSMIGスキーマ内のCSSCANリポジトリ表

これらの表の内容も、DMUでデータベース変換を開始できるかどうかを決定する際には考慮されません。

SYS.HISTGRM$表は、(エンドポイント値を格納する)EPVALUE列にバイナリ・データが含まれる可能性があるため、スキャンされません。ヒストグラムおよびその他の表統計は文字列内のデータのバイナリ表現に依存するため、移行後にデータベース内のすべての変換済表の統計を再収集する必要があります。統計を収集すると、SYS.HISTGRM$表の内容がリフレッシュされ、新しいデータベース・キャラクタ・セットで再検証されます。統計をリフレッシュしない場合、オプティマイザが不適切な動作をする可能性があります。

同様に、自動ワークロード・リポジトリで保持されている履歴オブジェクト統計も、文字データのバイナリ表現に依存しているため、移行後に失効します。DMUでは、これらの統計は移行されません。これらは、移行後にDBMS_STATS.PURGE_STATS(SYSTIMESTAMP)をコールして手動でパージする必要があります。

関連項目:

- パッケージDBMS_STATSおよびプロシージャPURGE_STATSの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

- オプティマイザ統計の詳細は、『Oracle Database概要』を参照してください。

DMUおよびCSSCANリポジトリのデータは、データベースが新しいデータベース・キャラクタ・セットに移行されると無効になります。したがって、これをデータベースとともに移行しても無意味です。移行後にリポジトリを削除し、まだ必要であれば再作成する必要があります。移行後にDMUリポジトリを再作成する場合は、検証モードを選択してください(「Unicodeとしてのデータの検証」を参照)。

自動ワークロード・リポジトリ表の処理

SYSスキーマには、自動ワークロード・リポジトリ(AWR)を構成するWRI$、WRH$%およびWRR$_で始まる名前の表が多数含まれています。このリポジトリには、「無視されるデータ・ディクショナリ表」で説明されている履歴オブジェクト統計に加えて、重要なシステム統計(V$SYSSTATやV$SQLAREAなどの様々な固定ビューで表示される統計など)のスナップショットが格納されます。

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

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

Oracle Databaseバージョン10.2.0.4以上ではcatawr.sqlスクリプトは存在しないため、AWRの内容をパージする前にOracle Databaseパッチ・セット10.2.0.5をインストールすることをお薦めします。

多言語列の使用

「不適切なキャラクタ・セット宣言のクレンジング」で説明されているように、クレンジング・エディタで列の内容を分析中に、列内のすべての値を同時に正しく表示する列の想定キャラクタ・セットはないが、それぞれの値はいずれかの選択済キャラクタ・セットで正しく表示されることがわかる場合があります。これは、その列に異なるキャラクタ・セットのデータが混在しているということです。この情報は、データベースのデータ・ソースの分析により収集されることもあります。

パススルー・シナリオにおいては、各種のキャラクタ・セットを使用するクライアントがデータをすべてこの列に格納すると、1つの列に複数のキャラクタ・セットが含まれる可能性があります。

このリリースのDMUには、このタイプの変換可能性の問題をクレンジングするための機能は含まれていません。1つのCHAR列またはVARCHAR2列で複数のキャラクタ・セットを処理する必要がある場合は、次の手順が推奨されます。

1つのCHAR列またはVARCHAR2列で複数のキャラクタ・セットを使用する手順は、次のとおりです。

1. 影響を受ける列の1つの値の実際のキャラクタ・セットを特定するのに役立つ補助データを探します。たとえば、次のようなデータがあります。

- 値に関連付けられた国コード

- 値を入力したオペレータの識別子

- 値を入力する責任のある子会社の識別子

2. 補助データを値の有効なキャラクタ・セットにマップするマッピング表を作成します。会社のワークステーションが特定のタイプに統一されている場合、通常は、分析された値のソース国によって、値の入力に使用されるクライアント・キャラクタ・セットが定義されます。

3. 複数のキャラクタ・セットのデータを含む列を、変換から除外されるようにマークします(「列プロパティ: 変換」を参照)。

4. 列に長さの問題がないことを確認します。必要な場合、問題のある値を拡張または短縮してクレンジングします。CLOBには移行しないでください。長さの問題を確認する方法の詳細は、次の例5-1を参照してください。

5. データベースを変換します。

6. マッピング表を使用して、SQL関数CONVERTで2番目の引数にターゲットのUnicodeキャラクタ・セット、3番目の引数に特定済の値キャラクタ・セットを指定して、影響を受ける列を変換します。

例5-1 多言語列の考慮事項

データベースに、CUSTOMER_NAME_ORIGINAL列とCREATED_BY列を持つ表CUSTOMERSが含まれているとします。VARCHAR2(80 BYTE)として定義された列CUSTOMER_NAME_ORIGINALには、母国語の顧客名が複数のキャラクタ・セットで含まれています。列CREATED_BYには、顧客データを入力した従業員のシステムIDが含まれています。このデータベースをキャラクタ・セットAL32UTF8に移行するとします。

CUSTOMER_NAME_ORIGINAL列に複数のキャラクタ・セットが存在するという問題を解決するために、まず、従業員のシステムIDを従業員のワークステーションのクライアント・キャラクタ・セットにマップするマッピング表を作成します。アプリケーション内のシステムIDを定義する表を使用すると、従業員が勤務している国を特定し、その従業員が使用しているクライアント・ワークステーションのキャラクタ・セットを判別できる場合があります。さらに、作成したマッピング表はCREATED_BY_TO_CHARSET_MAPPINGという名前であり、それにCREATED_BY列およびCHARACTER_SET列が含まれるとします。このような表の内容の例を次に示します。

CREATED_BY    CHARACTER_SET
----------    -------------
...
JSMITH        WE8MSWIN1252
JKOWALSKI     EE8MSWIN1250
SKUZNETSOV    CL8MSWIN1251
WLI           ZHS16GBK
...

ここで、データベースの他の部分の変換中にデータが破損するのを回避するために、CUSTOMER_NAME_ORIGINAL列の変換から除外するプロパティを「はい」に設定します。

次のSQLを実行して、CUSTOMER_NAME_ORIGINALに長さの問題がないか確認します。

SELECT c.ROWID
FROM customers c, created_by_to_charset_mapping csm
WHERE VSIZE(CONVERT(c.customer_name_original,
'AL32UTF8',
csm.character_set)) > 80
AND c.created_by = csm.created_by

何も行が戻されない場合、長さの問題はありません。それ以外の場合、戻された行識別子を参照して、問題のある値を見つけます。

データベースの準備ができたら、AL32UTF8に変換します。新しいデータベース・キャラクタ・セットでの必要に応じて、アプリケーション構成を変更します。

データベース変換後、次の更新文を実行します。

UPDATE customers c
SET c.customer_name_original =
(SELECT CONVERT(c.customer_name_original,
'AL32UTF8',
csm.character_set)
FROM created_by_to_charset_mapping csm
WHERE csm.created_by = c.created_by)

これにより、想定キャラクタ・セットに従って列の各値が変換されます。顧客データを入力した従業員、または関連する言語を話す従業員に、変換後の値が正しいかどうかの検証を依頼します。

高度な変換可能性の問題

この項で説明する変換可能性の問題は、それほど頻繁には発生しませんが、現在DMUでは自動的には処理されないため、ツール外部から追加のスキャン・ステップおよびクレンジング・ステップを実行する必要がある場合があります。

この項の内容は、次のとおりです。

- 変換可能性の問題: 一意性の検証

- 変換可能性の問題: 索引サイズ

- 変換可能性の問題: パーティション範囲の整合性

- 変換可能性の問題: ごみ箱内のオブジェクト

- 変換可能性の問題: 30バイトを超えるPL/SQLローカル識別子

変換可能性の問題: 一意性の検証

次の2つの状況では、データベースの内容がUnicodeに変換された後に、表のいくつかの行が一意キーまたは主キーの制約を満たさなくなる可能性があります。

- 一意キーまたは主キーの列に長さの問題がある(変換で一部の値が列またはデータ型の長さ制限を超える)のに、この列の問題のあるデータの変換を許可するプロパティを「はい」に設定しました。この場合、DMUで変換ステップ中に、既存の長さ制約に収まるように自動的に列が切り捨てられます。ただし、切り捨てられた末尾の部分のみ異なっていたため、切捨て後の値が列にすでに存在する別の値と同じになることがあります。

- 各種のOracleキャラクタ・セットにおいて、1つのUnicodeコード・ポイントにマップされる文字コードは複数存在します。これは通常、次のことが原因です。

- キャラクタ・セット定義または様々なベンダーによるその解釈への変更履歴に対して、互換性マッピングを提供しようとしたこと。

- 実際のマッピングが一連のUnicodeコードで構成されるなどの理由でUnicodeに正確にマップできないコードに対して、簡易マッピングを提供しようとしたこと(これはOracleの変換アーキテクチャではサポートされていません)。

- Unicode規格の統合ルールにより、特定の漢字(中国語)文字グループ内の文字がレガシーの東アジア・キャラクタ・セットで別々にエンコードされていても、このようなグループには1つのコード・ポイントが割り当てられます。

1つの列内の2つの文字値が、その列の想定キャラクタ・セットでUnicodeの同一ポイントにマップされる文字部分だけ異なっている場合、それらはUnicodeへの変換後に同じになります。

DMUでサポートされる次のキャラクタ・セットには、Unicodeの同一コード・ポイントにマップされるコードが複数あります。

- BG8PC437S

- IW8MACHEBREW

- IW8MACHEBREWS

- JA16EUCTILDE

- JA16MACSJIS

- JA16SJIS

- JA16SJISTILDE

- JA16SJISYEN

- JA16VMS

- KO16KSCCS

- LA8ISO6937

- ZHS16MACCGB231280

- ZHT16BIG5

- ZHT16CCDC

- ZHT16HKSCS

- ZHT16HKSCS31

- ZHT16MSWIN950

影響を受ける文字コードを確認するには、Oracle Locale Builderユーティリティを使用できます。このユーティリティの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

前述の2つの問題のいずれかによって一意キーまたは主キーの制約が影響を受ける可能性がある場合、適切な一意ファンクション索引を作成することにより、実際に問題があるかどうかを確認できます。たとえば、文字列tab1.col1およびtab1.col2と数字列tab1.col3に一意キーまたは主キーの制約がある場合は、次のような索引の作成を試行します。

CREATE UNIQUE INDEX i_test
ON tab1(SYS_OP_CSCONV(col1,'AL32UTF8','<assumed character set of col1>'),
SYS_OP_CSCONV(col2,'AL32UTF8','<assumed character set of col2>'),
col3)
TABLESPACE ...

UTF8が実際のターゲット・キャラクタ・セットの場合、'AL32UTF8'を'UTF8'で置き換えてください。列の想定キャラクタ・セットがデータベース・キャラクタ・セットと同じであれば(デフォルト)、SYS_OP_CSCONVの3番目のパラメータは省略できます。「ORA-01452: CREATE UNIQUE INDEXは実行できません。重複するキーがあります」と報告されて文が失敗した場合、列には一意性の問題があります。

上のCREATE INDEX文では、列の長さ調整スケジュールが計画されていないこと、および文字長セマンティクスを使用して列が定義されていないことが前提となっています。col1をn1バイトに、col2をn2バイトに拡張する場合は、次の文を使用します。

CREATE UNIQUE INDEX i_test
ON tab1(SYS_OP_CSCONV(SUBSTRB(RPAD(col1,n1,' '),1,n1),
'AL32UTF8','<assumed character set of col1>'),
SYS_OP_CSCONV(SUBSTRB(RPAD(col2,n2,' '),1,n2),
'AL32UTF8','<assumed character set of col2>'),
col3)
TABLESPACE ...;

ターゲット・キャラクタ・セットがUTF8の場合、'AL32UTF8'を'UTF8'で置き換えてください。

col1およびcol2が文字長セマンティクスを使用して定義されており、その文字長がそれぞれn1とn2である場合は、次の文を使用します。

CREATE UNIQUE INDEX i_test
ON tab1(SYS_OP_CSCONV(SUBSTRB(RPAD(col1,4*n1,' '),1,4*n1),
'AL32UTF8','<assumed character set of col1>'),
SYS_OP_CSCONV(SUBSTRB(RPAD(col2,4*n2,' '),1,4*n2),
'AL32UTF8','<assumed character set of col2>'),
col3)
TABLESPACE ...;

ターゲット・キャラクタ・セットがUTF8の場合、'AL32UTF8'を'UTF8'で置き換えてください。

変換可能性の問題: 索引サイズ

Oracleデータベース索引内の索引キーの最大サイズ(つまり、すべてのキー列の最大バイト長に行識別子の長さと長さバイト数を足した値)は、索引の表領域内のデータ・ブロック・サイズから約25%のオーバーヘッドを引いた値以下にする必要があります。

データベース変換中に索引キーに属する文字列の最大バイト長が拡大する場合、次のいずれかが原因です。

- 新しいデータベース・キャラクタ・セットの列の文字長に基づいてこれが再計算されています。
または

- 列に対して長さ調整のクレンジング・アクションが定義されています。

最大バイト長に達すると、索引キーがその最大許容長を超えることがあります。

このリリースのDMUでは、変換ステップで変更される索引キーの長さは事前に確認されません。したがって、ALTER TABLE, CREATE INDEX文またはALTER DATABASE CHARACTER SET文からの変換中に、「ORA-01450: キーが最大長(最大値)を超えました」または「ORA-01404: ALTER COLUMNによる索引が大きすぎます」が報告される可能性があります。

変換の試行前に、長さ調整のクレンジング・アクションがスケジュールされている、または文字長セマンティクスを使用するVARCHAR2列とCHAR列に定義されているすべての索引を確認して、それらがこの問題による影響を受けないことを確認する必要があります。最も簡単な方法は、元のデータベースのコピーで移行をテストすることです。コピーには、計画されているすべてのクレンジング・アクションとともにDMUリポジトリを含める必要があります。実際のアプリケーション・データがテストに影響を与えることはないので、テスト時間を短縮するためにサイズの大きい変換可能表はすべて切り捨てることができます。

変換可能性の問題: パーティション範囲の整合性

DMUではパーティション・バウンドの変換が必要なデータベースの変換はサポートされていませんが、このようなデータベースはデータ・ポンプ・ユーティリティを使用して移行できます。移行プロセスの準備中に、パーティションの整合性に関連する次の潜在的な問題を考慮する必要があります。

Oracle Databaseでは、パーティション化キー列の値をパーティション・バウンドと比較することにより、表の行をレンジ・パーティション間に分散します。この比較では、バイナリ・ソート順序が使用されるため、ディスクに格納されているとおりの値のバイト表現がバイトごとに比較されます。文字列の場合、表現はデータベース・キャラクタ・セットに依存し、Unicodeへの変換中に変更される可能性があります。パーティション・バウンドのバイナリ表現が変更されると、パーティションの順序が変更され、パーティション間の行の分散が大きく変更される可能性があります。

パーティション化列に変換可能なデータが含まれるすべてのレンジ・パーティション表を分析し、さらに必要に応じて、データベースをUnicodeに移行した後も適切に行が分散されるようにパーティション定義を調整する必要があります。

まれですが、パーティション・レンジ・バウンドとパーティション・リスト値に、「変換可能性の問題: 一意性の検証」で説明されている一意性の問題が発生することもあります。パーティション表にこのような問題が発生した場合、パーティション定義を適宜調整しないと、表を正常にインポートできません。

変換可能性の問題: ごみ箱内のオブジェクト

DMUでは、削除されてごみ箱の中にある表の文字列も、通常の表と同様にスキャンされます。そのスキャン結果はデータベース・スキャン・レポートに含められます。通常のアプリケーション表とは異なり、ごみ箱内の削除済の表に変換の必要なデータを含めることはできません。変換可能データを含む表をごみ箱から削除するまでは、変換ステップを開始できません。

削除済の表に対するクレンジング・アクションはサポートされていません。

変換可能性の問題: 30バイトを超えるPL/SQLローカル識別子

DMUでは、PL/SQLストアド・モジュール(ストアド・プロシージャ、ストアド・ファンクションおよびパッケージ)の名前の変換はサポートされていませんが、次の要素内に非ASCII文字を含むPL/SQLソース・コードおよびビュー定義は自動的に変換されます。

- パッケージ内で宣言されているプロシージャ、ファンクションおよびタイプの名前

- 変数名や型名などのローカル識別子

- 文字リテラル

- コメント

DMUでは、変換ステップでデータ・ディクショナリから関連するCREATE OR REPLACE PACKAGE|PACKAGE BODY|PROCEDURE|FUNCTION|TYPE|TYPE BODY|VIEW文がフェッチされてターゲット・キャラクタ・セットに変換され、データベース・キャラクタ・セットがUTF8またはAL32UTF8に変更された後で実行されます。

DMUでは、変換された識別子がその長さ制約(通常は30バイト)を超えるかどうかはチェックされません。Unicodeへの変換後に識別子が許容値よりも長くなった場合、結果のPL/SQLモジュールが作成されますが、そのコンパイルは失敗し、通常は「PLS-00114: 識別子'<identifier>'が長すぎます。」と報告されます。このモジュールのステータスは「無効」になります。

データベース変換後に、すべてのPL/SQLストアド・モジュールのステータスを確認する必要があります。識別子が長すぎるためにいずれかのモジュールが無効な状態になっている場合は、その識別子の定義および識別子が参照されるすべての場所において、その識別子を手動で短縮する必要があります。

Unicodeへの移行に対するアプリケーションの適用

データベースをUnicodeに移行すると必ず、このデータベースに接続するアプリケーションは影響を受けます。影響の程度は、次のようないくつかの要因によって決まります。

- アプリケーションで、データベースに格納できるようになった新しい言語の処理を行うか。
新しい言語をサポートするには、通常、Unicodeデータを処理できるようにアプリケーションを適応させる必要があります。シングルバイト・キャラクタ・セットのみを処理するようにプログラミングされているアプリケーションを、Unicode文字の全レパートリーを処理できるようにするには、大規模な変更が必要となります。これに対し、アプリケーションにこれまでと同じ文字数制限を使用する場合は、Oracleクライアント/サーバーのキャラクタ・セット変換を利用して最小限の変更を行うのみで済むことがあります。

- 複雑なスクリプトを使用する言語には、アプリケーションからのGUIサポートが必要か。
アラビア系文字やインド系文字などの複雑なスクリプトで記述されたテキストを表示および受け入れるためには、複雑なスクリプト・レンダリング機能が必要です。複雑なレンダリングとは、たとえば、隣接する文字を結合したり(右から左に読むフラグメントと左から右に読むフラグメントが混在している場合)、ワード内の文字の位置に応じて文字の形状を変更することなどです。

- アプリケーションの構築に使用されているテクノロジは何か。
アプリケーションの開発に使用された開発フレームワークによって、新しい言語を受け入れるようにアプリケーションを変更することは比較的簡単な場合もあれば、非常に難しい場合もあります。幸い、JavaやMicrosoft Windowsなど、現在使用されているほとんどの環境では、複雑なスクリプト・レンダリングおよびUnicode処理に対する組込みサポートまたはインストール可能なサポートが提供されています。このサポートを利用すると、アプリケーションを適応させるプロセスは簡略になりますが、プロセスを省略できるわけではありません。

- アプリケーションは社内で開発されたものか、それともサードパーティ・ベンダーによって開発されたものか。
ソース・コードが利用できるアプリケーションしか適応させることはできません。ベンダーが開発したアプリケーションは、そのベンダーが適応させる必要があります。これが不可能であれば、アプリケーションを別のソフトウェア・ソリューションで置換する必要がある場合もあります。

次の場合は、これらの考慮事項に加えて、移行に関連する変更をアプリケーションに加える必要があります。

- クレンジング・アクションによって表構造が変更された、列の長さが調整された、または別のデータ型に移行された場合。

- 文字の最大バイト幅が拡大されたなど、データベース・キャラクタ・セットの特性が変更された場合。

- 新しく処理対象となった言語に追加の要件がある場合。これには、新しいソート・ルール、新しい日付または数字フォーマット・ルール、非グレゴリオ暦のサポートなどが含まれます。

- 古いレガシー・キャラクタ・セットからUnicodeに変更され、文字列のバイナリ・ソート順序が変更された場合。

アプリケーションを新しい言語に適応させる方法の詳細はこのガイドでは取り扱いませんが、次の各項で、移行済データベースで引き続き既存のアプリケーションを実行するために必要となる可能性のある最小限の変更について説明します。

レガシー・アプリケーションを変更せずに実行

バックエンド・データベースをUnicodeに移行した後も、既存のアプリケーションの一部は変更せずに実行する場合があります。たとえば、アプリケーションをUnicodeに適応させるためにソース・コードにアクセスできない場合や、経済的な理由でアプリケーションを変更できない場合などです。

バックエンド・データベースをUnicodeに移行した後もアプリケーションを変更せずに実行するためには、そのアプリケーションでこれから使用される可能性のあるすべてのUnicode文字が、そのアプリケーションが最初に記述されたレガシー・キャラクタ・セットにも存在していることが必要になります。つまり、アプリケーションがたとえばISO 8859-1規格のキャラクタ・セット(WE8ISO8859P1)のみを処理するように記述されていた場合、このアプリケーションがアクセスするデータベース内容のサブセット内で使用できるのは、それに対応するUnicode文字であるU+0000 - U+007FおよびU+00A0 - U+00FFのみです。

この要件が満たされていれば、NLS_LANG環境設定で指定されているアプリケーションのクライアント・キャラクタ・セットは前述のレガシー・キャラクタ・セットに設定される(移行の前後で実際にNLS_LANGは変わらない)はずであり、アプリケーションで使用されるレガシー・エンコーディングとデータベースで使用されるUnicodeエンコーディングの間の文字データ変換はクライアント/サーバー通信プロトコルによって処理されます。

アプリケーションにより処理される文字が標準のUS7ASCII文字のみの場合、すべてのASCII文字のUTF8およびAL32UTF8バイナリ・コードはUS7ASCIIと同じになるため、アプリケーションの変更は必要ありません。したがって、処理されるバイトはデータベース・キャラクタ・セットの移行前と移行後で変わりません。

ASCII範囲外の文字(アクセント付きラテン文字など)のバイナリ・コードは、データベース・キャラクタ・セットの変更後、クライアント側では変わりませんが、データベース側では変更されます。最も重要な違いは通常は、文字コード内のバイト数です。アクセント付きラテン文字およびキリル文字やギリシャ文字は、WE8MSWIN1252やCL8MSWIN1251などのシングルバイト・レガシー・キャラクタ・セットではそれぞれ1バイトを使用しますが、UTF8およびAL32UTF8では2バイトを使用します。ユーロ通貨記号などの特定の特殊文字は、3バイトを使用します。したがって、長さがバイトで表現される影響を受ける列、PL/SQL変数およびユーザー定義データ型属性がデータベース側にあれば、アプリケーションからデータがデータベースに入力されるときにクライアント/サーバー・キャラクタ・セット変換で追加されるバイトに対応できるように、これらを調整する必要があります。

データ長の制御をデータベースに依存せずにアプリケーション自らが長さ制限を制御している場合、およびアプリケーションで処理されるすべてのデータがそのアプリケーションを介してのみデータベースに入力される場合、影響を受ける列、PL/SQL変数およびユーザー定義データ型の属性のバイト長は、通常は3を掛けて適宜拡大することにより調整できます。戻されたエラー(ORA-12899など)の処理によるデータ長の制御をアプリケーションがデータベースに依存している場合、またはアプリケーションのデータが外部ソースから入力される場合、SQLおよびPL/SQLで長さを調整する方法として、元の絶対的な長さの数値は保持し、長さセマンティクスをバイトから文字に変更することをお薦めします。つまり、VARCHAR2(10 [BYTE])列またはPL/SQL変数をVARCHAR2(10 CHAR)列または変数に変更する必要があります。

前述の長さ問題は既存のデータベース内容にも影響を与えることは明らかなので、通常は、データベース・キャラクタ・セット移行プロセスのクレンジング・ステップで列および属性の長さを事前に拡大しておく必要があります。データ型が%TYPE属性で表現されている場合を除いて、PL/SQL変数は個別に調整する必要があります。

基本の文字データ型には絶対的な長さ制限があるため、大きな問題が存在します。データベースに格納されるVARCHAR2値は4000バイトを超えることができず、CHAR値は200タイプを超えることができません。したがって、データ型の制限に違反せずに該当する数のランダム文字コードを実際に格納できるようにするには、VARCHAR2列および属性は1333文字(UTF8の場合)または1000文字(AL32UTF8の場合)までしか拡張できません。アプリケーションでこれより長い値がすでに通常処理されている場合、アプリケーションを引き続き実行するには、たとえば、VARCHAR2データ型でなくCLOBデータ型を使用するように変更する必要がある可能性があります。

前述の長さ問題とは別に、一部のアプリケーションはデータベースからの問合せされた文字値の特定のバイナリ・ソート順序に依存していることがあります。US7ASCIIおよびWE8ISO8859P1キャラクタ・セットの文字はUTF8とAL32UTF8で順序は同じですが、これ以外のキャラクタ・セットの文字の順序は同じではありません。UTF8またはAL32UTF8データベース内のレガシー・キャラクタ・セットのバイナリ順序をシミュレートするために、Oracle Local Builderユーティリティを使用してカスタムの言語定義を作成する必要がある場合があります。一般に、カスタムの言語定義を作成すると、データベース管理が複雑になるうえそのコストも高くなり、問合せのパフォーマンスに影響を与える可能性があるため、アプリケーションを特定のバイナリ・ソート順序に依存しないように変更する方法をお薦めします。

次の項で説明するように、これらの変更に加えて、アプリケーション・コードのデータベース側で新しいUnicode文字エンコーディングに必要な変更を行う必要があります。

関連項目:
カスタムの言語定義の作成の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

SQLおよびPL/SQLコードの変更

SQLコードとPL/SQLコードはデータベース内部で実行されるため、それを処理するキャラクタ・セット、つまり処理されたデータのエンコードに使用されるキャラクタ・セット(この場合はデータベース・キャラクタ・セット)は、データベースをUnicodeに移行すると必ず変更されます。これに対し、クライアント側のアプリケーション・コードでは、NLS_LANGの設定が変わっていなければ、移行後もそれを処理するキャラクタ・セットを保持できます。

ほとんどのPL/SQL文、式、関数およびプロシージャは、データベース・キャラクタ・セットとは無関係に動作するため、適応させる必要はありません。ただし、処理するキャラクタ・セットが異なると結果が異なる関数も多数あります。次の関数を含むSQLコードおよびPL/SQLコードは、Unicodeへの移行に対応するために適宜確認して変更する必要があります。

- 特定のバイナリ文字コードに依存する関数: CHR、ASCIIおよびDUMP

- 文字コード幅(バイト)に依存する関数: LENGTHB、VSIZE

- バイト・オフセットを使用する関数: INSTRB、SUBSTRB

- キャラクタ・セット変換関数: CONVERT

- 文字列からバイナリへのキャスト: UTL_RAW.CAST_TO_VARCHAR2、UTL_RAW.CAST_TO_RAW、UTL_I18N.STRING_TO_RAW、UTL_I18N.RAW_TO_CHAR

また、標準パッケージUTL_FILEを使用すると、文字データをデータベース・キャラクタ・セットで外部ファイルに格納できます。これらのファイルのコンシューマは、新しいファイル・エンコーディングを処理できるように適応させる必要があります。

SQL式およびPL/SQL式の確認は、ビュー定義、PL/SQLストアド・モジュール、ユーザー定義データ型メソッド、トリガー、チェック制約のみでなく、イベント・ルール条件(DBMS_RULE_ADMを参照)、行レベルのセキュリティ(RLS/VPD)ポリシー(DBMS_RLSを参照)、ファイン・グレイン監査ポリシー(DBMS_FGAを参照)、またSQL式やPL/SQL式から参照されるその他の補助データベース・オブジェクト定義でも行う必要があります。

注意:
あまり一般的ではありませんが、行レベルのセキュリティまたはファイン・グレイン監査ポリシーは、文字エンコーディングに依存するSQL式を使用して定義できます。このようなポリシーをすべて確認して、データベース・キャラクタ・セットの変更により機密性の高いデータの保護が損われることがないよう確認してください。

データベース・キャラクタ・セット・メタデータの修復

データベースが、一般的にパススルー構成と呼ばれる構成になっていて、クライアントのキャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されている(通常はNLS_LANGクライアント設定になっている)場合は、データベースの文字データが、宣言されているデータベース・キャラクタ・セットとは異なるキャラクタ・セットで格納されている可能性があります。このシナリオにおいて推奨される解決策は、DMUの想定データベース・キャラクタ・セット機能でデータの実際のキャラクタ・セットを指定して、データベースをUnicodeに移行することです。業務上または技術上の制約によってUnicodeへの移行をすぐには実行できない場合も、少なくとも、データベースの内容と一致するようにデータベース・キャラクタ・セット宣言を修正することをお薦めします。

Database Migration Assistant for Unicodeリリース1.2では、このような場合にCSREPAIRスクリプトを使用してデータベース・キャラクタ・セット・メタデータを修復できます。CSREPAIRスクリプトはDMUクライアントと連携して動作し、DMUリポジトリにアクセスします。DMUで想定データベース・キャラクタ・セット・プロパティをターゲット・キャラクタ・セットに設定して全体データベース・スキャンを実行し、無効な表現の問題が報告されなくなると、データベース内のすべての既存データが想定データベース・キャラクタ・セットに従って定義されていることが確認されるため、その後でこれを使用してデータベース・キャラクタ・セット宣言をデータの実際のキャラクタ・セットに変更してください。CSREPAIRにより変更されるのはデータ・ディクショナリ・メタデータ内のデータベース・キャラクタ・セット宣言のみであり、データベース・データは変換されないことに注意してください。

CSREPAIRスクリプトは、インストールされたDMUのadminサブディレクトリにあります。CSREPAIRスクリプトを使用する際の要件は次のとおりです。

1. まず、DMUで想定データベース・キャラクタ・セット・プロパティをデータの実際のキャラクタ・セットに設定して、全体データベース・スキャンを正常に完了する必要があります。この場合、想定データベース・キャラクタ・セットは現在のデータベース・キャラクタ・セットと異なる必要があり、そうでない場合は何も行われません。DMUが無効なバイナリ表現を含むデータの存在を報告する場合は、CSREPAIRスクリプトの処理が中断されます。ただし、不変で、変換可能または長さ制限を超えるデータがスキャン結果でレポートされる場合には続行されます。

2. 想定データベース・キャラクタ・セットのターゲット・キャラクタ・セットは、US7ASCIIのバイナリ・スーパーセットである必要があります。

3. シングルバイト・キャラクタ・セットからシングルバイト・キャラクタ・セットへの修復、またはマルチバイト・キャラクタ・セットからマルチバイト・キャラクタ・セットへの修復のみが、CLOBデータの変換が試行されないために許可されます。

4. 想定キャラクタ・セットを列レベルで設定する場合、値は想定データベース・キャラクタ・セットと同じである必要があります。そうでない場合、CSREPAIRは実行されません。

5. CSREPAIRを実行するには、SYSDBA権限が必要です。Oracle Database 12cのプラガブル・データベース(PDB)でCSREPAIRを実行するには、SYSユーザーまたはローカルPDBおよびCDBの両方でSYSDBA権限を持つ共通ユーザーである必要があります。

例: CSREPAIRの使用

一般的な例は、パススルー構成を介してWE8ISO8859P1データベースにWE8MSWIN1252データを格納する場合です。データベース・キャラクタ・セットをWE8ISO8859P1からWE8MSWIN1252に修正する手順は、次のとおりです。

1. DMUを設定し、ターゲットのWE8ISO8859P1データベースに接続します。

2. DMUでデータベース・プロパティ・タブを開きます。

3. 想定データベース・キャラクタ・セット・プロパティを「WE8MSWIN1252」に設定します。

4. DMUを使用して全体データベース・スキャンを実行します。

5. データベース・スキャン・レポートを開き、無効な表現カテゴリの下に報告されているデータがないことを確認します。

6. DMUクライアントを終了します。

7. SQL*Plusユーティリティを起動し、SYSDBA権限を持つユーザーとして接続します。

8. CSREPAIRスクリプトを実行します。
SQL> @@CSREPAIR.PLB

完了すると、次のようなメッセージが表示されます。

データベース・キャラクタ・セットが正常にWE8MSWIN1252に変更されました。今すぐデータベースを再起動する必要があります。

9. データベースを停止して再起動します。

DMUバージョンの更新

DMUライブ・アップデート機能を使用すると、DMUの最新バージョンの有無を確認して、これをインストールできます。これにより、DMU更新センターから新しいバージョンのDMUが使用可能かどうかを確認できます。新しいバージョンにアップグレードすることを選択すると、ライブ・アップデート機能によってソフトウェア・パッケージがダウンロードされ、既存のインストールが自動的にアップグレードされます。

DMUでは、起動時に新しいバージョンが使用可能かどうかを検出できます。新しいバージョンが見つかると、メイン・ウィンドウの右下隅にメッセージが表示されます。

DMUバージョンの更新の有無を確認する手順は、次のとおりです。

1. ライブ・アップデート機能を起動するために、メイン・ウィンドウの一番下にあるメッセージをクリックするか、「ヘルプ」メニューの「更新の確認」を選択します。

図5-1 更新の確認ウィザード - ようこそ

更新の確認ウィザードが表示されます。このウィザードではDMU更新センターからDMU更新が使用可能かどうかがチェックされ、自動的に更新をダウンロードしてインストールできます。

2. 「次へ」をクリックします。ウィザードで、使用可能なDMU更新が表示されます。現在インストールされているバージョンより新しい使用可能なバージョンがない場合は、メッセージに現在のDMUバージョンが最新であることが示されます。

図5-2 更新の確認ウィザード - 使用可能なバージョン

3. 「次へ」をクリックします。ウィザードで、更新センターからの新しいDMUパッケージのダウンロードが開始されます。ダウンロードが完了するまで待ちます。

図5-3 更新の確認ウィザード - 新しいDMUバージョンのダウンロード

4. 「次へ」をクリックします。「サマリー」ページが表示されます。このページでは、DMUを終了するか、新しいバージョンを今すぐインストールするか、またはインストールを後で完了するかを選択できます。「はい」を選択すると、DMUが終了し、バックグラウンドでインストール・プロセスが開始されます。インストールの完了後、新しいバージョンのDMUが再起動されます。

図5-4 更新の確認ウィザード - サマリー

新しいDMUバージョンにアップグレードするために移行リポジトリを再インストールする必要がある場合がありますので注意してください。この場合、アップグレード後に以前のスキャン結果およびスケジュール済クレンジング・アクションは保持されません。

5. ファイアウォールを経由している場合や、プロキシを使用してWebページにアクセスする場合、DMU更新センターに接続する前に、「プリファレンス」ダイアログ・ボックスの自動更新ページでプロキシ設定を構成する必要があることがあります。
プロキシ設定を構成するには、ツール・メニューの「プリファレンス」を選択します。「Preferences」ダイアログが表示されます。

図5-5 プリファレンス: 自動更新

「HTTPプロキシ・サーバーの使用」を選択した場合、「ホスト名」フィールドとポート番号フィールドに値を入力します。

「プロキシ・サーバーでは認証が必要」を選択した場合、「ユーザー名」フィールドと「パスワード」フィールドに値を入力します。

「更新を自動的にチェックする」を選択した場合、DMUの起動時に新しいDMUバージョンがあるかどうかが確認されます。

「OK」をクリックして「プリファレンス」ダイアログを閉じ、プロキシ・サーバーの設定を完了します。

DMUのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。Oracle Database Migration Assistant for Unicodeでは、アクセシビリティ機能がサポートされます。

Oracle製品のアクセシビリティに関する追加情報は、http://www.oracle.com/accessibility/にある「Oracle Accessibility Program」を参照してください。

DMUでのスクリーン・リーダーおよびJava Access Bridgeの使用方法

スクリーン・リーダーなどの障害支援技術がJavaベースのアプリケーションやアプレットで動作するためには、Windowsベースのコンピュータに、Sun社のJava Access Bridgeをインストールしておく必要があります。

アクセシビリティ機能を最大限に活用できるように、少なくとも次の構成をお薦めします。

- Windows XP、Windows Vista

- Java J2SE 1.6.0_24

- Java Access Bridge 2.0.1

- JAWS 12.0.522

- Microsoft Internet Explorer 7.0版以上

- Mozilla Firefox 3.5以上

スクリーン・リーダーとJava Access Bridgeの設定については、次の手順を参照してください。

1. スクリーン・リーダーがインストールされていない場合は、インストールします。
インストールの詳細は、スクリーン・リーダーのマニュアルを参照してください。

2. DMUをインストールします。

3. Java Access Bridge for Windowsバージョン2.0.1をダウンロードします。ダウンロードするファイルは、accessbridge-2_0_1.zipです。次にあります。
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136191.html

インストールとJava Access Bridgeの詳細は、このWebサイトから入手可能なJava Access Bridgeマニュアルを参照してください。

4. フォルダ(accessbridge_homeなど)に内容を抽出(解凍)します。

5. <accessbridge_home>¥installerフォルダからInstall.exeを実行してJava Access Bridgeをインストールします。
インストーラによりJDKバージョンの互換性がチェックされてから、「Available Java virtual machines」ダイアログが表示されます。

6. 「Search Disks」をクリックします。次に、Program Filesディレクトリ(存在する場合)にJDKのバージョンが格納されているドライブのみを検索するように選択します。
JDKのインスタンスが多数含まれている大きいディスクの場合や、複数のディスクを検索する場合は、検索プロセスに時間がかかることがあります。ただし、ディスクの総当り検索が完了しないかぎり、Access Bridgeは最適に構成されず、システムのすべてのJava VMに正しくインストールされません。検索するディスクを選択したら、「Search」をクリックします。

7. 「Install in All」をクリックして、Java Access Bridgeをダイアログに表示されている各Java仮想マシンにインストールすることを確認します。

8. 「Installation Completed」メッセージが表示された時点で「OK」をクリックします。

9. DMUで作業するには次のファイルがシステム・パスに指定されている必要があるため、Winnt\System32ディレクトリ(あるいはWindows XPまたはVistaの同等のディレクトリ)にインストールされていることを確認し、ない場合は<accessbridge_home>\installerfilesからコピーします。

- JavaAccessBridge.dll

- JAWTAccessBridge.dll

- WindowsAccessBridge.dll

PATHシステム変数には、システム・ディレクトリが必要です。

10. 次のファイルがjdk\jre\lib\extディレクトリにインストールされていることを確認し、ない場合は<accessbridge_home>\installerfilesからコピーします。

- access-bridget.jar

- jaccess-1_4.jar

11. ファイルaccessibility.propertiesがjdk\jre\libディレクトリにインストールされていることを確認し、ない場合は\installerfilesからコピーします。

12. スクリーン・リーダーを起動します。

13. DMUを起動します。

前述の手順は、Windowsを実行中でWindowsベースのスクリーン・リーダーを使用していることを想定しています。DMUの起動後、最初にエラー情報(存在する場合)を含むコンソール・ウィンドウが開いてから、DMUのメイン・ウィンドウが表示されます。表示されるメッセージは、DMUの機能には影響しません。

6 DMUを使用したデータのクレンジング

この章では、クレンジング中に使用するDatabase Migration Assistant for Unicode (DMU)のユーザー・インタフェースの要素を示し、これらを使用して様々なタスクを実行する方法について説明します。

この章は次の項で構成されています。

- データのクレンジング

- データの表示

- データの編集

- データの表示

- 列の変更

- 列変更のスケジュール

- 属性の変更

- 属性変更のスケジュール

- 変換可能性の問題の無視

- 一括クレンジング

- クレンジング・シナリオ1: 問題のないデータベース

- クレンジング・シナリオ2: 拡張の問題のクレンジング

- クレンジング・シナリオ3: 無効な表現の問題のクレンジング

「変換可能性の問題の無視」で説明されているように、2つの列プロパティを使用して、データの問題を無視できる場合もあります。

クレンジング・アクションは、即時の場合とスケジュールの場合があります。即時アクションはデータベースの内容に対して直接実行され、その結果は即時に表示されます。スケジュール済クレンジング・アクションは移行リポジトリに登録され、移行プロセスの変換ステップで実行されます。したがって、スケジュール済アクションの結果は、変換までは仮想のものとなります。DMUでは、データベースの問題をスキャンするとき、「スケジュール済クレンジングの結果を含める」または「スケジュール済」という見出しの下に調整済のスキャン結果を表示することにより、スケジュール済のアクションを考慮に入れます。

スケジュール済クレンジング・アクションは、列変更のスケジュール・ダイアログ・ボックスおよび属性変更のスケジュール・ダイアログ・ボックスで定義します。その他のクレンジング・アクションはすべて即時アクションです。

アプリケーションでデータベースに特定のデータ依存性が適用されており、複数の表列に格納されているデータ値の整合性を保持する必要がある場合、DMUではこのようなユーザー・アプリケーション・スキーマの依存性は認識されないため、データ・クレンジング・プロセス中にデータ依存性を手動で維持する必要があります。

データのクレンジング

表に対するほとんどのクレンジング・アクションは、クレンジング・エディタ・タブから開始します。このタブを開くには、ナビゲータ・ペインの表ノードのコンテキスト・メニューから、またはデータベース・スキャン・レポートで「クレンジング・エディタ」を選択します。クレンジング・エディタは、データ・ディクショナリ表には使用できません。図6-1は、クレンジング・エディタ・タブを示しています。

クレンジング・エディタ・タブには、ツールバー、エディタ・グリッドおよび2つのボタン(「保存」と「元に戻す」)が含まれています。エディタ・グリッドには、クレンジング・エディタが開かれた対象の表の内容が表示されます。このガイドの以降の部分では、この表を編集対象表と呼びます。グリッドの列は編集対象表の文字データ型列に対応しており、グリッドの行は表の行に対応しています。

エディタ・グリッドは2つの選択モードのいずれかで動作します。1つのセルをクリックすると、そのセルが選択され、グリッドはセル選択モードに切り替わります。このモードでは、1つのセルのみを選択できます。選択したセルは、現在のセルと呼ばれます。(列の名前を含む)列見出しをクリックすると、グリッドは列選択モードに切り替わり、クリックした列が選択された列になります。[Ctrl]キーを押したままさらに列見出しをクリックすると、複数の列を追加で選択できます。図6-1「クレンジング・エディタ」では、10番目に表示された表行のJOB_ID列のセルが現在のセルとして選択されています。

グリッド内のセルは、特定されたデータ問題を示すために特定の色で強調表示されています。詳細は、「データのクレンジング: 色の強調表示」を参照してください。図6-1では、10番目に表示された表行のEMAIL列内のセルが、無効な表現の問題を表すためにライト・コーラルの背景で表示され、同じ行のLAST_NAME列内のセルが、列の長さの問題を示すために黄色の背景で表示されています。

クレンジング・エディタの編集対象表は、現在のクレンジング・アクティビティに関連する行のみがエディタ・グリッドに表示されるようにフィルタリングできます。詳細は、「データベース・スキャン・レポート: フィルタリング」を参照してください。

図6-1 クレンジング・エディタ

クレンジング・エディタを使用すると、編集対象表の内容に対して様々なクレンジング・アクションを開始できます。セルをダブルクリックするか、現在のセルのコンテキスト・メニューから「データの編集」を選択すると、データの編集ダイアログ・ボックスが開いて、そのセルに格納されている値が表示されます。「データの編集」で説明されているように、値を短縮したり、不正な文字コードを削除するなどして、値を編集できます。編集した値は、クレンジング・エディタ・タブの一番下にある「保存」をクリックするまではデータベースに格納されません。編集が完了した値は、データベースに永続的に保存されるまで、イタリック・フォント・フェイスで表示されます。図6-1で10番目に表示された表行のFIRST_NAME列のセルは、変更はされたがまだ保存されていないものです。「元に戻す」をクリックすると、すべての編集変更を取り消して、セル値をデータベースからの現在の値に戻すことができます。

セル選択モードでセルを右クリックする(これによってセルが現在のセルになる)か、列選択モードで選択された列を右クリックすると、列の変更メニュー項目および列変更のスケジュール・メニュー項目を含むコンテキスト・メニューが表示されます。現在のセルまたは選択された列がユーザー定義データ型(ADT)の属性に対応している場合、コンテキスト・メニューにはこれらのかわりに「属性の変更」および「属性変更のスケジュール」が含まれます。複数の列を選択した場合に、そのいずれかのデータ型が異なっていると、コンテキスト・メニューには前述のメニュー項目はいずれも表示されません。4つのメニュー項目のうちいずれかをクリックすると、それに対応するダイアログ・ボックスが開きます(「列の変更」、「列変更のスケジュール」、「属性の変更」または「属性変更のスケジュール」を参照)。これらのダイアログ・ボックスでは、1つ以上の列にある変換可能性の問題をクレンジングするために表構造を変更できます。CLOBデータ型の列および属性には、これらのダイアログ・ボックスは使用できません。

列の変更メニュー項目または列変更のスケジュール・メニュー項目をクリックすると、変更対象の列がOracle e-Business Suiteインストールを構成するスキーマの1つに属していることが検出された場合、DMUで警告が表示されます。一般的には、Oracle e-Business Suite表の構造の変更はサポートされていません。影響を受ける表が自分で作成したカスタム表である場合か、Oracle Supportによって表の変更を推奨された場合にのみ、この警告を受け入れて変更を続行できます。

Oracle製品またはサード・パーティ製品とともにインストールされた表の構造を変更する場合は、事前にベンダーに相談してください。このような表を変更すると、それが属するアプリケーションが機能しなくなることがあるため、変更は通常はサポートされていません。

クレンジング・エディタを使用して、列に含まれる文字コードを解釈するためにDMUで使用されるキャラクタ・セットを変更できます。「想定キャラクタ・セットの設定」を参照してください。

データのクレンジング: ツールバーの使用

以降に、クレンジング・エディタ・ツールバーの項目を、図6-1「クレンジング・エディタ」に表示されている順序で説明します。

- 表の再スキャン
編集対象表のみがスキャン対象としてマークされた状態でスキャン・ウィザード(「スキャン・ウィザードを使用したデータベースのスキャン」を参照)を開きます。これにより、その編集対象表を簡単に再スキャンできます。

- 選択した列の再スキャン
現在選択されている列のみがスキャン対象としてマークされた状態でスキャン・ウィザードを開きます。これにより、その編集対象表の一連の列を簡単に再スキャンできます。列が何も選択されていない場合、つまりエディタ・グリッドがセル選択モードになっている場合、現在のセルを含む列が再スキャン対象としてマークされます。

- データのリフレッシュ
編集対象表の最新のデータを使用してグリッドを再ロードします。

- 表示する列の選択
エディタ・グリッドに含める列を選択できるダイアログ・ボックスを表示します。画面領域を節約するため、列自身に問題がなく、他の列の問題の分析に役立つデータも含まれていない場合、その列の選択を解除できます。特殊な読取り専用列を、編集対象表の行の行識別子が表示されたグリッドに追加することもできます。行識別子を使用すると、Oracle SQL Developerなどの他のデータベース・ツールで関連する行をすばやく見つけることができます。

- スケジュール済クレンジングの影響を表示
スケジュール・クレンジング・アクションの結果を別の色で強調表示します。

「データのクレンジング: 色の強調表示」を参照してください。

- 収集された行識別子を使用してデータをフィルタリングする
スキャン中に収集された行識別子を使用してデータをフィルタリングします。

「データのフィルタリング」を参照してください。

- フィルタリング条件のカスタマイズ
フィルタリング条件をカスタマイズできるダイアログ・ボックスを表示します。「データのフィルタリング」を参照してください。

- 次の選択項目が含まれる「フィルタ」ドロップダウン・リスト:

- すべて

- 変換の必要あり

- 列制限超過

- データ型制限超過

- 無効なバイナリ表現

「すべて」以外のオプションを選択すると、クレンジング・エディタによってフィルタが適用され、対応する変換可能性の問題がある行のみが表示されます。「データのフィルタリング」を参照してください。

- 問題のある前のセル
変換可能性の問題のある前のセルが現在のセルとして選択されます。セルはまず、同じ行の先行する各列で検索され、続いて先行する各行で最後の列から順に検索されます。

- 問題のある次のセル
変換可能性の問題のある次のセルが現在のセルとして選択されます。セルはまず、同じ行の後続の各列で検索され、続いて後続の各行で最初の列から順に検索されます。

- キャラクタ・セット・ドロップダウン・リスト
想定列キャラクタ・セットとして選択できるキャラクタ・セットが含まれています。「想定キャラクタ・セットの設定」を参照してください。

データのクレンジング: 色の強調表示

変換可能性の問題のあるデータを含むセルは、他のセルの標準色とは別の色を使用して強調表示されます。デフォルトでは、長さの問題のあるセル、つまり変換後に列制限を超えるか、データ型制限を超えるセルは、黄色の背景で表示されます。無効なバイナリ表現の問題のあるセル、つまり宣言済(想定)キャラクタ・セットで無効な文字コードが含まれるセルは、ライト・コーラルの背景で表示されます。

値を含んでいる列の長さを調整したり、スケジュール済クレンジングの影響を表示ツールバー・ボタンをクリックするなどのスケジュール済クレンジング・アクションによってセル内の問題がクレンジングされた場合、デフォルトでセルの背景色が緑色に変わります。値の編集、想定列キャラクタ・セットの変更、列の変更ダイアログ・ボックスや属性の変更ダイアログ・ボックスを使用した列または属性の変更といった即時クレンジング・アクションを行うと、問題が完全に除去され、以前に影響を受けていたセルが変換可能になって強調表示がなくなります。

前述のデフォルト色は、図6-2「プリファレンス: クレンジング・エディタ」に示されている「プリファレンス」ダイアログ・ボックスのクレンジング・エディタ・ページでカスタマイズできます。「プリファレンス」ダイアログ・ボックスを開くには、ツール・メニューから「プリファレンス」を選択します。最初の2つの選択項目は長さ問題のあるセルに対応し、次の2つは変換不可能なデータ・ディクショナリ・セルのあるセルに対応し、その次の2つは無効なバイナリ表現のあるセルに対応し、最後の2つは解決された移行問題のあるセルに対応するものです。また、「デフォルトに戻す」をクリックすると、デフォルトの設定に戻すことができます。

図6-2 プリファレンス: クレンジング・エディタ

データのフィルタリング

クレンジング・エディタ・タブには、大きな表の操作を簡単にするための強力なフィルタリング機能が用意されています。エディタ・グリッドに含まれる行は、それに含まれる変換可能性の問題のタイプに基づいて、または任意のSQL条件に基づいてフィルタリングできます。

変換可能性ステータスに基づくフィルタリング

クレンジング・エディタ・ツールバーの「フィルタ」ドロップダウン・リストから、含める変換可能性の問題のタイプを選択できます。次の選択項目があります。

- すべて
このオプションを選択すると、変換可能性の問題に基づくフィルタリングがオフになり、内容にかかわらずすべての行が含められます。

- 変換の必要あり
このオプションを選択すると、不変でないすべての行が表示され、変換の必要な、またオプションで長さの拡張または無効な表現の問題のあるデータが1つ以上の列に含まれます。

- 列制限超過
このオプションを選択すると、変換後に1つ以上の列値が列制限を超えるすべての行が表示されます。

- データ型制限超過
このオプションを選択すると、変換後に1つ以上の列値がデータ型制限を超えるすべての行が表示されます。

- 無効なバイナリ表現
このオプションを選択すると、1つ以上の列に無効な文字コードが含まれるすべての行が表示されます。

DMUでは、次のいずれかの処理を実行することにより、特定のタイプの変換可能性の問題のある行を特定できます。

- 以前のスキャン・タスクによって移行リポジトリ内に収集された行識別子を参照します。

- データベースからフェッチされるときに列値を分析します。

編集対象表でフィルタを通過する変換可能性の問題のタイプが存在する行の割合がごくわずかである場合、DMUでは、エディタ・グリッドに含める十分な行を見つけるまでに多数の行をフェッチして分析する必要があることがあります。このため、フィルタリングがオンになっていると、大きな表を検索する際のスピードが大幅に低下する可能性があります。通常は、収集された行識別子によって行を見つけるほうがはるかに高速です。ただし、収集された行識別子は表の最後のスキャンの時点における表の状態と一致しています。この状態は、行がすでに追加、更新または削除されているためにすでに失効している可能性があります。それでも通常は、クレンジング・セッションが比較的長期にわたる場合、問題が疎らに分散されている大きな表を定期的に再スキャンするほうが、収集された行識別子を使用せずに行をフィルタリングするよりも便利です。

収集された行識別子を使用するようにDMUを設定するには、クレンジング・エディタのスキャン・ログを使用してデータをフィルタリングするボタンをクリックします。このボタンは、表の最後のスキャン中に行識別子収集がオンになっていた場合にのみ有効になります。行識別子収集レベルは、表プロパティ・タブのスキャン・サブタブ(「表プロパティ: スキャン」を参照)またはスキャン・ウィザードのスキャンの詳細ページで設定できます(「スキャン・ウィザードを使用したデータベースのスキャン」を参照)。表プロパティ・タブの設定は永続的です。スキャン・ウィザードの設定は現在のスキャンにのみ適用され、表プロパティ・タブの値を上書きします。このレベルは「すべて変換」または「問題あり」に設定できます。最初のオプションを選択すると、不変でないすべての行の行識別子が収集されます。2つ目のオプションを選択すると、列制限を超える、データ型制限を超える、または無効なバイナリ表現があるなど、問題のある行の行識別子のみが収集されます。最初のオプションは、フィルタを「変換の必要あり」に設定する場合に使用します。2つ目のオプションは、フィルタを「列制限超過」、「データ型制限超過」または「無効なバイナリ表現」に設定する場合にのみ使用します。

表内に変換が必要な行が多数存在する場合、たとえば表にCLOB列が含まれていて、データベース・キャラクタ・セットがシングルバイトであるために、すべての変換可能な行の行識別子を収集するのに非常にコストがかかることがあります。一般に、このオプションは、変換を妨げる可能性のある変換可能データを見つける目的でデータ・ディクショナリ表に対してのみ使用してください。行識別子はセルごとに収集されるため、収集基準を満たすデータを含む複数のセルが1つの行に含まれている場合、その行の行識別子は複数のコピーに格納され、そのたびに別の列のIDが使用されます。

SQL条件に基づくフィルタリング

行の変換可能性ステータスに基づくフィルタリングの他に、DMUが編集対象表からデータを取得するためにデータベースに送信する問合せに追加する任意のSQL条件を指定できます。この条件は、図6-3 カスタム・フィルタリング条件に示すカスタム・フィルタリング条件ダイアログ・ボックスで指定します。このダイアログ・ボックスを開くには、クレンジング・エディタ・タブのツールバーで「フィルタリング条件のカスタマイズ」をクリックします。このダイアログ・ボックスでカスタムSQL条件オプションを選択して、必要な条件を入力します。「適用」をクリックします。条件が表に適用されて、フェッチする行のサブセットが作成され、次に変換可能性の問題に基づくフィルタリングがこのサブセットに適用されます。フィルタリング条件を削除するには、カスタム・フィルタリング条件ダイアログ・ボックスを再び開き、カスタム・フィルタリングなしオプションを選択して「適用」をクリックします。

図6-3 カスタム・フィルタリング条件

想定キャラクタ・セットの設定

データに無効な表現の問題がある場合(「データの無効なバイナリ記憶域表現」を参照)、その一般的な原因は、アプリケーションがパススルー構成を使用して、変換を行うこともデータベース・キャラクタ・セットを判別することもなくクライアント・キャラクタ・セットに直接データを格納することです。DMUを使用すると、このようなクライアント・キャラクタ・セット(データの実際のキャラクタ・セット)を特定して、それがデータベース・キャラクタ・セットと異なっていれば変換のソース・キャラクタ・セットとして使用できます。これにより、間違って格納されたデータをターゲットのUnicodeエンコーディングに正しく変換できます。データベース・キャラクタ・セットから標準的な変換を行うと、データが破損し、判読不能になります。DMUで選択できる列内のデータの宣言済キャラクタ・セットは、想定列キャラクタ・セットと呼ばれます。

想定列キャラクタ・セットは、Unicodeへの変換のみでなく、クレンジング・エディタ、データの編集ダイアログ・ボックスまたはデータの表示ダイアログ・ボックスに表示される列データが解釈されるときにも使用されます。表示されたデータが人間に判読できる形式になるのは、実際のキャラクタ・セットまたは実際のキャラクタ・セットのバイナリ・スーパーセットに従ってその解釈が行われた場合のみです。そうでない場合、表示された値には予期しない文字や置換文字が含まれます。(置換文字は通常、大文字サイズの四角い形状で表されます。この表示はプラットフォームによって異なります。)この事実に基づいて、列内のすべてのデータが正しく表示されていれば、想定列キャラクタ・セットが正しく選択されていることを確認できます。

列スキャン結果に問題のない変換可能な内容のみが報告されている場合でも、列の想定キャラクタ・セットを設定できます。これは、データベース・キャラクタ・セットと異なる実際のキャラクタ・セットのデータに、(判読可能なテキストが生成されなくても)データベース・キャラクタ・セットで有効として解釈される可能性のあるバイト・シーケンスが含まれていることがあるためです。これは特に、キャラクタ・セット定義でほとんどのバイト値(0..255)に有効な文字が割り当てられているシングルバイト・データベース・キャラクタ・セットについて当てはまります。CL8MSWIN1251がわかりやすい例で、1バイト値のみがどの文字にも割り当てられていません。

列の実際のキャラクタ・セットを特定するには、次のいずれかを実行します。

- 関連するアプリケーション構成、データベース・クライアントおよびクライアント・キャラクタ・セット(優先される方法)に関する必要な情報を収集します。

- 列の想定キャラクタ・セットとして一連のキャラクタ・セットを選択し、表示されるテキストの正確性(読みやすさ)を確認します。

2つ目の方法は、データの言語はわかっているが、そのエンコードに使用される特定のキャラクタ・セットがわからない場合に非常に便利です。たとえば、ある列のテキストが日本語であることはわかっているが、それがEUC-JP (JA16EUC)かShift-JIS (JA16SJIS)のどちらでエンコードされるかがわからない場合などです。

列の想定キャラクタ・セットをクレンジング・エディタで設定するには、図6-4「想定列キャラクタ・セットの設定」に示すように、列の見出しをクリックして列を選択し、ツールバーのキャラクタ・セット・ドロップダウン・リストで目的のキャラクタ・セットを選択します。選択した列の内容が、新しい解釈に従って再表示されます。データが判読できない場合、別のキャラクタ・セットを選択してみます。また、色の強調表示(「データのクレンジング: 色の強調表示」を参照)によって、選択したキャラクタ・セットに従って列内の一部のバイトを解釈できないことがわかります。

図6-4 想定列キャラクタ・セットの設定

クレンジング・エディタで複数の列を選択した場合、その想定キャラクタ・セットすべてを一度に同じ値に設定できます。

選択した想定列キャラクタ・セットを追加の列処理で使用できるように移行リポジトリに永続的に保存するには、「保存」をクリックします。

データの表示

データ・ビューアは、「データのクレンジング: ツールバーの使用」で説明されているクレンジング・エディタ・タブの読取り専用バージョンです。

データを表示する手順は、次のとおりです。

1. ナビゲータ・ペインのデータ・ディクショナリ表ノードのコンテキスト・メニューから、またはデータベース・スキャン・レポートで「データ・ビューア」を選択します。
データ・ビューアは、標準のアプリケーション表には使用できません。これは図6-1「クレンジング・エディタ」のクレンジング・エディタ・タブと似ていますが、クレンジングのスケジュールの影響を表示」ボタンが無効になっている点が異なります。「保存」ボタンと「元に戻す」ボタンはありません。また、コンテキスト・メニュー項目の「データの編集」、「列の変更」、「列変更のスケジュール」、「属性の変更」および「属性変更のスケジュール」は使用できません。データの編集メニュー項目のかわりに、「データの表示」で説明されているデータの表示ダイアログ・ボックスを開くためのデータの表示メニュー項目が使用可能になります。クレンジング・エディタの表示およびフィルタリングの機能はいずれも、データ・ビューアで使用可能です。列の内容の実際のキャラクタ・セットを分析するために、データ・ビューアで列の想定キャラクタ・セットを設定できますが、この選択を保存することはできません。

データの編集

クレンジング・エディタで表セルをダブルクリックするか、現在のセルのコンテキスト・メニューから「データの編集」を選択するかして、図6-5「データの編集ダイアログ・ボックス」に示されているデータの編集ダイアログ・ボックスを開きます。セルの値は、ダイアログ・ボックスのメイン・テキスト領域に表示され、文字を追加、変更または削除することにより編集できます。値に行端文字(LF=0x0A)が含まれている場合、その値は複数の行で表示されます。行の折返しチェック・ボックスでは、テキスト領域の幅より長い行の表示方法を指定します。このチェック・ボックスを選択すると、ダイアログ・ボックスでは長い行がテキスト領域の複数の行で折り返されます。このチェック・ボックスを選択しない場合、行は折り返されず、ダイアログ・ボックスにはテキスト領域をスクロールするための水平スクロール・バーが表示されます。

データの編集ダイアログ・ボックスには、編集対象のテキスト値に関する次のデータが表示されます。

- データ型
これは、値が属する列のデータ型(VARCHAR2、CHAR、LONG、CLOBなど)です。

- データ長(バイト)
これは、編集対象の値がデータベースに格納された場合の長さ(バイト)です。

- データ長(文字数)
これは、編集対象の値がデータベースに格納された場合の長さ(文字数)です。

- 変換後の長さ(バイト)
これは、編集対象の値がターゲットUnicodeキャラクタ・セットへの変換後にデータベースに格納された場合の長さ(バイト)です。

- 現在の列制限(バイト)
これは、値をデータベース内のその列に収めるための現在の最大長(バイト)です。

- 現在の列制限(文字数)
これは、値をデータベース内のその列に収めるための現在の最大長(文字数)です。列でバイト長セマンティクスが使用されている場合は、何も表示されません。

- 変換後の制限(バイト)
これは、値をUnicodeへの変換後にデータベース内のその列に収めるために許容される最大長(バイト)です。

値を編集するときは、「データ長(バイト)」が「現在の列制限(バイト)」を超えていないこと、および「データ長(文字数)」が「現在の列制限(文字数)」(指定されている場合)を超えていないことを必ず確認してください。値の「列制限超過」の問題を解決するには、「変換後の長さ(バイト)」が「変換後の制限(バイト)」を超えていないことを確認する必要もあります。

現在の値が「変換後の制限(バイト)」を超える原因となっている文字は、黄色の背景で表示されます。これにより、「列制限超過」の問題を解決するために切り捨てる必要のある値の量をすばやく見積もることができます。

図6-5 データの編集ダイアログ・ボックス

右下に、編集対象テキストが、データベースに格納されるときのテキストを構成(エンコード)するバイトに対応する一連の16進数として表示されます。

編集対象テキストを構成するバイトの数値を確認すると、次のことが可能になります。

- 文字列に無効に格納されているバイナリ値(イメージや暗号化結果など)の特定
このような値には通常、0x00から0x08まで、および0x10から0x1fまでのバイトが含まれます。これらの範囲のバイトは現在ほとんど使用されない制御コードなので、このようなバイトを含む値が純粋なテキスト値になることはほとんどありません。

- 破損した文字の特定
テキスト内の編集対象テキストに置換文字がある場合、バイナリ表示を参照して、これらの文字に対応する特定のバイトを分析できます。データの言語を特定して、この言語に有効なキャラクタ・セットの定義を参照することにより、問題を、データの不適切なキャラクタ・セットとして、あるいは破損した文字コード(ソフトウェアの不具合やハードウェア障害によりマルチバイト・コードからバイトが欠落したり、バイトがランダムになる)として診断できます。

編集対象の値にバイトを挿入、変更または削除して、破損の問題を解決できます。バイトをクリックすると、それが現在のバイトになります。編集領域内の任意の場所を右クリックすると、コンテキスト・メニューが開きます。現在のバイトの前にバイトを追加するには、「挿入」を選択します。値から現在のバイトを削除するには、「削除」を選択します。現在のバイトの値を変更するには、「変更」を選択します。バイトをダブルクリックすることは、バイトを選択して現在のバイトにしてから「変更」を選択することと同じです。

データの編集ダイアログ・ボックスで目的の変更をすべて行ったら、「OK」をクリックして変更を受け入れ、ダイアログ・ボックスを閉じます。ダイアログ・ボックスを閉じて変更を廃棄する場合は、「取消」をクリックします。変更を受け入れた後も、変更をデータベースに保存するために、クレンジング・エディタ・タブで「保存」をクリックする必要があります。

データの表示

データの表示ダイアログ・ボックスは、データの編集ダイアログ・ボックスの読取り専用バージョンです。これはデータ・ディクショナリ表の値を表示するために使用するもので、値を直接変更することはできません。

データの編集ダイアログ・ボックスと同様に、データはテキスト形式またはバイナリ形式で表示されます。また、長い行を折り返したり、広げたりすることもできます。

列の変更

列の変更ダイアログ・ボックスを使用して実行できるクレンジング・アクションは、表の列定義(メタデータ)を即時に変更します。図6-6に、列の変更ダイアログ・ボックスを示します。これを開くには、クレンジング・エディタのコンテキスト・メニューから「列の変更」を選択します(「データのクレンジング: ツールバーの使用」を参照)。

図6-6 列の変更ダイアログ・ボックス

「列」リスト・ボックスに、列の変更ダイアログ・ボックスで変更される列が表示されます。依存性リスト・ボックスには、ビューやPL/SQLプロシージャなど、これらの列に依存するために、列の変更後に更新または再コンパイルが必要となる可能性のあるデータベース・オブジェクトが表示されます。

列の変更ダイアログ・ボックスでは、列に対して次のクレンジング・アクションを指定できます。

- キャラクタ・セマンティクスへの移行
列の長さセマンティクスをバイトから文字に変更できます。変更する列がVARCHAR2(n BYTE)として定義されている場合、列はVARCHAR2(n CHAR)になります。このような変更を行うと、n BYTE列に含まれる文字がnを超えることはなく、n CHAR列の基礎となるバイト長制限は、データベース・キャラクタ・セットの変更中に、長さn文字のすべての文字列を格納できるように自動的に拡大されます(ただし、これはデータ型制限を超えない場合にかぎります。つまり、データ型制限超過として報告された値は収まりません)。

- 調整後の長さ
列の長さを調整して新しい制限値(「オプション」ラベルの後の「編集」フィールドで指定)にすることを選択できます。同時に長さセマンティクスをバイトまたは文字に変更するには、次のドロップダウン・リストから目的のセマンティクスを選択します。「列制限超過」の問題を解決するには、すべての列に対して報告された変換後の最大長より大きい制限値を指定します。

- 移行後の型
一部のデータ型を新しいデータ型に移行できます。CHAR列は、VARCHAR2、CLOBまたはRAWに移行できます。VARCHAR2はCLOBまたはRAWに移行できます。LONG列はLONG RAWまたはCLOBに移行できます。CLOBへの移行を選択した場合、新しいCLOBセグメントの表領域および記憶域のプロパティを変更するためのプロパティ・ダイアログ・ボックスを使用できます。RAWまたはVARCHAR2への移行を選択した場合、新しい長さ制限(移行対象の列のいずれのバイト長制限も下回っていない値)を指定できます。VARCHAR2への移行を選択した場合、新しい長さに加えて長さセマンティクスを指定できます。VARCHAR2またはCLOBに移行すると、新しいデータ型は古いデータ型よりも大きくなるため、「データ型制限超過」の問題は解決されます。RAWまたはLONG RAWに移行すると、データベースでデータは実際にバイナリとして処理されるため、文字列にバイナリ・データが格納されることによる「無効なバイナリ表現」の問題は解決されます。

VARCHAR2、RAWおよびLONG RAWへの移行はメタデータのみの操作であるため、非常に高速です。CLOBに移行する場合、表のすべての行でデータを更新する必要があります。このため、表が大きい場合は非常に多くのリソースが消費されたり、データベース内に十分なUNDO領域がない場合には失敗することがあります。

クレンジング・アクションを定義した後、「適用」をクリックします。今すぐ列を変更してよいか確認を求められます。「はい」をクリックすると、適切なSQL DDL文がデータベースに送信されて即時に実行されます。

列変更のスケジュール

列変更のスケジュール・ダイアログ・ボックスは、前述の列の変更ダイアログ・ボックスとほとんど同じです。異なる点は次の2つです。

- このダイアログ・ボックスで指定したクレンジング・アクションは、スケジュール済アクションです。これらは、「適用」を選択したときに即時に実行されません。かわりに移行リポジトリに保存され、キャラクタ・セット移行プロセスの変換ステップで実行されます。これにより、表構造の変更に関連する必要なアプリケーション・アップグレードをデータベース変換と同期できます。

- 変更なしオプションが使用可能です。これを使用すると、データベース変換の開始前に、以前のスケジュール済クレンジング・アクションを再び呼び出すことができます。

列の変更をスケジュールする手順は、次のとおりです。

1. クレンジング・エディタのコンテキスト・メニューから「列変更のスケジュール」を選択して、列変更のスケジュール・ダイアログ・ボックスを開きます(「データのクレンジング: ツールバーの使用」を参照)。図6-31「列変更のスケジュール: 列サイズの長さ調整」に示すような列変更のスケジュール・ダイアログ・ボックスが表示されます。

属性の変更

「属性の変更」ダイアログ・ボックスを使用して実行できるクレンジング・アクションは、ユーザー定義オブジェクト・タイプの属性(ADT)を即時に変更します。オブジェクトの属性を変更すると、その属性を参照するすべての表に影響を与えます。属性の変更ダイアログ・ボックスを使用して、オブジェクト属性値を格納する表列を変更する必要があります。このような列に列の変更ダイアログ・ボックスを使用することはできません。

属性リスト・ボックスに、属性の変更ダイアログ・ボックスで変更される属性が表示されます。依存性リスト・ボックスには、ビューやPL/SQLプロシージャなど、これらの属性に依存するために、属性の変更後に更新または再コンパイルが必要となる可能性のあるデータベース・オブジェクトが表示されます。

現在、属性の変更ダイアログ・ボックスで定義できるのは、属性の長さを調整して新しい制限値にするためのクレンジング・アクション1つのみです。編集フィールドで制限値を指定します。同時に長さセマンティクスをバイトまたは文字に変更するには、次のドロップダウン・リストから目的のセマンティクスを選択します。「列制限超過」の問題を解決するには、データベース内のすべての表に属性の値を格納するすべての列に対して報告された変換後の最大長より大きい制限値を指定します。

属性を変更する手順は、次のとおりです。

1. クレンジング・エディタのコンテキスト・メニューから「属性の変更」を選択します(「データのクレンジング: ツールバーの使用」を参照)。図6-7に示すような属性の変更ダイアログ・ボックスが表示されます。

2. クレンジング・アクションを定義した後、「変更」をクリックします。

3. 今すぐ属性を変更してよいか確認を求められます。「はい」をクリックすると、適切なSQL DDL文がデータベースに送信されて即時に実行されます。

図6-7 属性の変更ダイアログ・ボックス

属性変更のスケジュール

属性変更のスケジュール・ダイアログ・ボックスは、前述の属性の変更ダイアログ・ボックスとほとんど同じです。異なる点は次の2つです。

- このダイアログ・ボックスで指定したクレンジング・アクションは、スケジュール済アクションです。これは、「適用」を選択したときに即時に実行されません。かわりに移行リポジトリに保存され、キャラクタ・セット移行プロセスの変換ステップで実行されます。これにより、表構造の変更に関連する必要なアプリケーション・アップグレードをデータベース変換と同期できます。

- 変更なしオプションが使用可能です。これを使用すると、データベース変換の開始前に、以前のスケジュール済クレンジング・アクションを再び呼び出すことができます。

属性変更のスケジュール・ダイアログ・ボックスを開くには、クレンジング・エディタのコンテキスト・メニューから「属性変更のスケジュール」を選択します(「データのクレンジング: ツールバーの使用」を参照)。

変換可能性の問題の無視

これは厳密にはクレンジング・アクションではありませんが、2つの列プロパティを使用して、報告された列内の変換可能性の問題を処理できます。これらのプロパティは、「列プロパティの表示および設定」で説明されている列プロパティ・タブの変換サブタブで設定できます。

1つ目のプロパティは、「問題のあるデータの変換を許可する」です。この列プロパティを「はい」に設定すると、その列に対して報告された変換可能性の問題は無視されます。つまり、これらがあっても変換ステップは開始されます。列はUnicodeに変換され、結果の値は列に収まるように自動的に切り捨てられます。無効な文字コードは置換文字に変換されます。このオプションは、変換後に完全に正しくなっている必要はないが、データベースからはまだ削除しない補助データまたは履歴データに変換可能性の問題がある場合に便利です。

2つ目のプロパティは、「変換から除外する」です。この列プロパティを「はい」に設定すると、その列は変換ステップでスキップされます。列の値は、キャラクタ・セット移行前の状態と同じになります。このオプションは、次のような列の変換を回避する場合に便利です。

- パススルー構成で様々なクライアントが異なるキャラクタ・セットを使用しているために、複数のキャラクタ・セットの値が混在している列。DMUによりデータベースの他の部分が変換され、データベース・キャラクタ・セットがUnicodeに更新された後で、このような値を手動で変換する必要があります。

- データ型がVARCHAR2であり、長さ制約が2000バイトより大きく、バイナリ・データを格納する列。このような列は、2000バイトの制約があるRAWに移行できないため、BLOBデータ型を介してこのデータをサポートするようにアプリケーションを更新する前に、Unicodeへの移行後にパススルー構成で列へのアクセスを維持するように決定できます。

変換から除外するようにマークされた列に対して変換可能性の問題が報告されていても、変換ステップは開始されます。このプロパティの設定の詳細は、「移行からの列および表の除外」を参照してください。

一括クレンジング

3つのアクションが一括で実行できます。

- CHARおよびVARCHAR2表列の長さセマンティクスをバイト・セマンティクスからキャラクタ・セマンティクスに変更
キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の記憶要件を定義する場合に役立ちます。たとえば、Unicodeデータベース(AL32UTF8)で、VARCHAR2列を英語の5文字とともに最大5文字の中国語文字を格納できるように定義する必要があるとします。バイト・セマンティクスを使用すると、この列には、長さ3バイトである中国語文字用に15バイトと、長さ1バイトである英語文字用に5バイト、合計20バイトが必要です。キャラクタ・セマンティクスを使用すると、この列に必要な文字数は10となります。キャラクタ・セマンティクスを使用すると、データベース・キャラクタ・セットとは関係なく文字数で列サイズを指定できます。Unicode移行で文字長セマンティクスを使用する利点の詳細は、「長さセマンティクスの変更」を参照してください。

即時クレンジング・モードまたはスケジュール・クレンジング・モードのいずれかで文字長セマンティクスに移行する一括クレンジング・アクションを定義できます。スケジュール・モードでは、文字長セマンティクスへの移行は、変換フェーズ中に本番環境を中断することなく適用されます。DMUを検証モードで使用している場合は、文字長セマンティクスへの即時の一括クレンジングのみが使用可能になります。

一括クレンジングでは、次のデータ型の列を文字長セマンティクスに移行することがサポートされています。

- CHAR組込みデータ型の列

- VARCHAR2組込みデータ型の列

- ADTのVARCHAR2属性の列

次の列は除外されます。

- ADTのCHAR属性の列

- クラスタ内の列

- パーティション・キーが定義されている列

一括クレンジングでは、通常のクレンジングの場合と同様に、Oracle提供のスキーマ(Oracle e-Business Suiteスキーマなど)の文字長セマンティクスの移行はサポートされていません。

- 「問題のあるデータの変換を許可する」列変換プロパティの設定
このプロパティを「はい」に設定すると、列のスキャン結果でいくつかの値に変換の問題がある、つまり変換後の値に置換文字が含まれるか、変換後の値が切り捨てられる問題があることが示された場合でも、DMUでデータの変換を実行できます。列またはデータ型の制限を超えたデータを自動的に切り捨てる場合や、破損した値があってもこのデータを使用するアプリケーションにとって大きな影響はないような場合には、これを使用すると便利です。

- 列値のすべてのバイト・パターンまたは文字パターンを置換または削除
場合によっては、個々のデータ例外の性質を分析した後、障害になっているバイトまたは文字を有効な同等のバイトまたは文字セットに置き換えるか、すべて削除することによってデータを変更できます。同じ問題の兆候が複数のデータベース・オブジェクトにある場合、そのような置換操作は一括での実行が望ましい可能性があります。パターンに基づいた置換クレンジング・オプションによって、選択したデータベース・オブジェクトのすべてのソース・パターンをターゲット・パターンへ置き換えることが可能になります。単一のバイトまたは文字を置き換えることもでき、バイトまたは文字を文字列で指定することもできます。

バイト・セマンティクスからキャラクタ・セマンティクスへデータを一括クレンジングする方法:

1. 移行メニューで「一括クレンジング」を選択します。図6-8「一括クレンジング・ウィザード - ようこそ」のようなダイアログが表示されます。

図6-8 一括クレンジング・ウィザード - ようこそ

2. 「次へ」をクリックすると、図6-9「一括クレンジング・ウィザード - アクション選択」が表示されます。

図6-9 一括クレンジング・ウィザード - アクション選択

文字長 セマンティクスへ「移行」を選択し、「次へ」をクリックします。

3. 図6-10 一括クレンジング・ウィザード - パラメータが表示されます。

図6-10 一括クレンジング・ウィザード - パラメータ

一括クレンジングの実行モードを選択します。スケジュール・クレンジング・モードの場合、以前にスケジュールされたクレンジング・アクションのある列の処理方法として、以前にスケジュールされたアクションを保持するか、そのアクションを上書きして列をキャラクタ長セマンティクスに移行するかを選択できます。

4. 「次へ」をクリックすると、図6-11「一括クレンジング・ウィザード - オブジェクト選択」が表示されます。

図6-11 一括クレンジング・ウィザード - オブジェクト選択

文字長セマンティクスに移行するオブジェクトを選択します。データ型列に列の現在のデータ型が表示され、スケジュール済クレンジング・アクション列に既存のスケジュール済クレンジング・アクションが表示されます。すでに文字長セマンティクスを使用しているオブジェクトや、文字長セマンティクスへの移行がサポートされていないオブジェクトは、ナビゲータ・ツリーで選択不可能になっています。

5. 「次へ」をクリックすると、図6-12「一括クレンジング・ウィザード - 詳細」が表示されます。

図6-12 一括クレンジング・ウィザード - 詳細

一括クレンジングの詳細ページに、文字長セマンティクスに移行される表列および型属性のリストが表示されます。

6. 一括クレンジング操作を確認して開始するには、「完了」をクリックします。図6-13「一括クレンジングの進行状況」が表示されます。

図6-13 一括クレンジングの進行状況

一括クレンジングのステータスは、一括クレンジングの進行状況パネルで監視できます。ある表列または型属性に対する操作がプロセス中に失敗した場合、そのエントリを強調表示すると、「ステータス」列およびパネルの一番下にエラー・メッセージが表示されます。エラーのあるエントリのみを表示するには、一番上のエラーのみを表示チェック・ボックスを選択します。

「停止」をクリックすることで、クレンジングを一時停止できます。

問題のあるデータの変換を許可することによるデータを一括クレンジングする方法:

1. 移行メニューで「一括クレンジング」を選択します。図6-14「一括クレンジング・ウィザード - ようこそ」のようなダイアログが表示されます。

図6-14 一括クレンジング・ウィザード - ようこそ

2. 「次へ」をクリックすると、図6-15「一括クレンジング・ウィザード - アクション選択」が表示されます。

図6-15 一括クレンジング・ウィザード - アクション選択

3. 「問題のあるデータの変換を許可」の設定を選択します。「次へ」をクリックすると、図6-16「一括クレンジング・ウィザード - パラメータ」が表示されます。

図6-16 一括クレンジング・ウィザード - パラメータ

4. 必要な値を選択し、「次へ」をクリックすると、図6-17「一括クレンジング・ウィザード - オブジェクト選択」が表示されます。

図6-17 一括クレンジング・ウィザード - オブジェクト選択

「問題のあるデータの変換を許可」プロパティを設定するオブジェクトを選択します。データ型列に列の現在のデータ型が表示され、スケジュール済クレンジング・アクション列に既存のスケジュール済クレンジング・アクションが表示されます。

5. 「次へ」をクリックすると、図6-18「一括クレンジング・ウィザード - 詳細」が表示されます。

図6-18 一括クレンジング・ウィザード - 詳細

6. 一括クレンジング詳細ページは、「問題のあるデータの変換を許可」プロパティを設定する表の列および型属性のリストを表示します。一括クレンジング操作を確認して開始するには、「完了」をクリックします。図6-13「一括クレンジングの進行状況」が表示されます。

図6-19 一括クレンジングの進行状況

一括クレンジングのステータスは、一括クレンジングの進行状況パネルで監視できます。ある表列または型属性に対する操作がプロセス中に失敗した場合、そのエントリを強調表示すると、「ステータス」列およびパネルの一番下にエラー・メッセージが表示されます。エラーのあるエントリのみを表示するには、一番上のエラーのみを表示チェック・ボックスを選択します。

「停止」をクリックすることで、クレンジングを一時停止できます。

パターンに基づく置換によってデータを一括クレンジングする方法:

1. 移行メニューで「一括クレンジング」を選択します。図6-20「一括クレンジング・ウィザード - ようこそ」のようなダイアログが表示されます。

図6-20 一括クレンジング・ウィザード - ようこそ

2. 「次へ」をクリックすると、図6-21「一括クレンジング・ウィザード - アクション選択」が表示されます。

図6-21 一括クレンジング・ウィザード - アクション選択

パターンに基づく置換クレンジングの実行を選択すると、図6-22「一括クレンジング・ウィザード - パラメータ」が表示されます。

3. 実行する置換操作のタイプおよびデータを入力する方法を選択します。単一のバイトまたは文字を置き換えることもでき、バイトまたは文字を文字列で使用することもできます。ソース値および置換値は、文字または16進バイト表現のいずれかで入力できます。置換バイトまたは文字の一部を空白のままにしておくと、対応するソース・バイトまたはソース文字が選択したターゲット列から削除されます。

図6-22 一括クレンジング・ウィザード - パラメータ

4. 「次へ」をクリックすると、図6-23「一括クレンジング・ウィザード - コミット頻度」が表示されます。コミット頻度ページでは、パターン置換の変更をコミットする方法を指定できます。終了時に操作全体を受け入れるか拒否するかを選択する場合には、最初のオプションを選択します。すべての変更をすぐにコミットする場合には、2番目のオプションを選択します。

図6-23 一括クレンジング・ウィザード - コミット頻度

5. コミットする方法を指定します。「次へ」をクリックすると、図6-24「一括クレンジング・ウィザード - オブジェクト選択」が表示されます。

図6-24 一括クレンジング・ウィザード - オブジェクト選択

6. パターンに基づく置換が実行されるオブジェクトを選択します。「次へ」をクリックすると、図6-25「一括クレンジング・ウィザード - 詳細」が表示されます。

図6-25 一括クレンジング・ウィザード - 詳細

7. 一括クレンジング詳細ページに、クレンジングされる表列および型属性のリストが表示されます。一括クレンジング操作を確認して開始するには、「完了」をクリックします。図6-26「一括クレンジングの進行状況」が表示されます。

図6-26 一括クレンジングの進行状況

一括クレンジングのステータスは、一括クレンジングの進行状況パネルで監視できます。ある表列または型属性に対する操作がプロセス中に失敗した場合、そのエントリを強調表示すると、「ステータス」列およびパネルの一番下にエラー・メッセージが表示されます。エラーのあるエントリのみを表示するには、一番上のエラーのみを表示チェック・ボックスを選択します。

「停止」をクリックすることで、クレンジングを一時停止できます。

例6-1 一括で無効なバイトを置換

この例では、データベースに次の図で示すように無効なバイト(WE8MSWIN1252データベース内に0x8Dおよび0x9D)が含まれています。

同じ無効データの兆候が複数ある場合、パターンに基づくクレンジングを実行することで一括で問題を解決できます。このケースでは、バイト値0x8dおよび0x9dは無視することができ、データの内容としては重要でないと考えると、次のようにパターンに基づく置換を定義してそれらをデータから削除できます。

これが完了すると、次のスクリーンショットで示すようなデータが表示されます。

行8の無効なデータが削除されたことに注意してください。

例6-2 一括で文字を置換

場合によっては、Unicodeに変換する際に列定義を変更することなく8ビット文字を7ビットの同等の文字に置き換えて、データ・サイズ拡張問題に対処できます。たとえば、次のスクリーンショットに示すように一括クレンジング・メソッドを使用してすべての文字äをaに置換できます。

クレンジング・シナリオ1: 問題のないデータベース

データベース内のデータに問題がない場合、スキャン・レポートは図6-27「データベース・スキャン・レポート: データの問題なし」のような画面になります。

図6-27「データベース・スキャン・レポート: データの問題なし」

レポート列「変更の必要なし(スケジュール済)」には、ターゲットのUnicodeキャラクタ・セットですでに有効になっているデータベース内の文字列値(セル)の数が表示されます。つまり、これらのセルはNULLか、またはASCII文字のみを含みます(ただし、UTF8からAL32UTF8に移行する場合は、文字がUnicodeの基本多言語面からの他の有効なUTF-8コードになることがあります)。レポート列「変換が必要(スケジュール済)」には、Unicodeにするために変換が必要であるが、変換してもエラーやデータ損失は起こらない文字セルの数が表示されます。

レポート列「無効なバイナリ表現(スケジュール済)」、「列制限超過(スケジュール済)」および「型制限超過(スケジュール済)」には、データベースの内容に変換可能性の問題がないことを表すゼロが表示されます。データベース・ノードの左側にある緑色の「OK」アイコンも、これと同じ意味です。移行ステータス・タブでデータベース内にそれ以外の問題がないことが示されている場合(「移行ステータスの追跡」を参照)、「データベースの変換」で説明されている移行プロセスの実際の変換フェーズに進むことができます。

クレンジング・シナリオ2: 拡張の問題のクレンジング

データベース内のデータに拡張の問題がない場合、スキャン・レポートは図6-28「データベース・スキャン・レポート: 拡張の問題」のような画面になります。「クレンジング・シナリオ1: 問題のないデータベース」で説明されている変更の必要なし(スケジュール済)列および変換が必要(スケジュール済)列に加えて、列制限超過(スケジュール済)列および型制限超過(スケジュール済)列にゼロでない値が含まれています。データベース・ノードの隣にある黄色い三角形のアイコンは、データに変換可能性の問題があることを示しています。

「列制限超過(スケジュール済)」として分類されたセルは、列の長さを調整しないかぎり、ターゲット・キャラクタ・セットへの変換後に列に収まらなくなります。「型制限超過(スケジュール済)」として分類されたセルは、長さがそのデータ型の制限を超えます。それらの列の長さを調整しても解決にはなりません。

「名前」列のオブジェクト・ツリーを開くと、問題のあるセルが含まれているスキーマ、スキーマ内の表、および表内の列を特定できます。黄色い三角形のアイコンは、開くことができるノードを示しています。列制限超過(スケジュール済)列と型制限超過(スケジュール済)列は、スキーマ、表および列に対応するデータベース・オブジェクト内の問題のあるセルの数を示しています。

図6-28 データベース・スキャン・レポート: 拡張の問題

また、スキャン・レポート・タブの情報量を減らして、問題のある列のスキャン結果のみをDMUで表示することもできます。このためには、図6-29「スキャン結果のフィルタリング」に示すフィルタ・ドロップダウン・リストをクリックしてこれを開きます。問題ありオプションを選択すると、データ問題があるすべてのデータベース列が表示され、長さの問題ありオプションを選択すると、この項で説明されているデータ拡張の問題がある列のみが表示されます。

図6-29 スキャン結果のフィルタリング

表レベルおよび列レベルでの列制限超過(スケジュール済)セルと型制限超過(スケジュール済)セルのゼロでないカウンタ値は、アクティブなリンクになっています。カウンタをクリックすると、DMUウィンドウのクライアント・ペイン内に図6-30「クレンジング・エディタ・タブ: 拡張問題」に示すようなクレンジング・エディタ・タブが開きます。このタブは、ナビゲータ・ペインまたはスキャン・レポート・ツリーで表ノードを右クリックして「クレンジング・エディタ」を選択しても開くことができます。

クレンジング・エディタ・タブに、対象となる表の内容が表示されます。デフォルトでは、長さ拡張の問題のあるデータ・セルは黄色の背景で表示されます。この色は、ツール・メニューから「プリファレンス」を選択すると開く「プリファレンス」ダイアログ・ボックスで変更できます。

問題のあるデータ・セルを特定するには、クレンジング・エディタの様々なフィルタリング機能および検索機能が役立ちます。これらの機能の詳細は、「データのフィルタリング」を参照してください。

クレンジング・エディタ・タブを開いた状態で、次の各項で説明されている報告された拡張問題のクレンジングを試行できます。

DMUで報告された問題のあるすべての表に対して、クレンジング・プロセスを繰り返します。スキャン・レポートまたは移行ステータス・タブに報告される問題がなくなったら、「データベースの変換」の説明に従って変換フェーズを開始できます。

図6-30 クレンジング・エディタ・タブ: 拡張の問題

「列制限超過」の問題

列内の「列制限超過」の問題をクレンジングするには、次のオプションがあります。

- 列の長さを調整します。

- 列の長さセマンティクスをバイトから文字に変更します。

- 格納されている値を手動で短縮します。

- 変換中のDMUで値が切り捨てられるように設定します。

- 値を編集して、変換で拡張される文字を置換します。

- より大きなデータ型に移行します。

どのクレンジング・アクションを選択するかは、クレンジング対象の表にアクセスするアプリケーションをユーザーが変更できるかどうかによって大きく左右されます。アプリケーションが自社で開発されていないなどの理由により自分でアプリケーションを変更できない場合、列の長さ調整、列の長さセマンティクスの変更、または別のデータ型への移行を行うと、バッファ・サイズやデータ・アクセス方法を変更後の列データ型に適応させるためにアプリケーション・コードを変更する必要があるため、このようなアクションは通常は実行できません。

列の長さの調整

列にアクセスするアプリケーションが拡張後の長さにあわせて自動的に適応される場合や、コード内の整然と定義された数箇所にわずかな手動変更を行うのみでよい場合は、列制限超過の問題に対処する方法として、列の長さの調整が最も効率的です。

列の長さを調整する手順は、次のとおりです。

1. 列の長さを調整するには、クレンジング・エディタで列の任意のセルを右クリックしてコンテキスト・メニューを開きます。メニューで、「列変更のスケジュール」または「列の変更」を選択します。前者を選択すると、図6-31「列変更のスケジュール: 列サイズの長さ調整」に示すような列変更のスケジュール・ダイアログ・ボックスが開きます。後者を選択すると、列の変更ダイアログ・ボックスが開きますが、画面は変換から除外するオプションと変更なしオプションがないことを除けば同じです。

図6-31 列変更のスケジュール: 列サイズの長さ調整

2. 列変更のスケジュール・ダイアログ・ボックスでは、列に対して、移行プロセスの実際の変換フェーズになってから実行されるスケジュール済クレンジング・アクションを定義できます。このアクションは移行リポジトリに保存され、表の変換直前または変換中に表に適用されます。表はその時点まで変更されず、このアクションを定義してもデータベース内の現在の処理に影響はありません。変換時になってから、変更に適応させる新しいアプリケーション・バージョンをインストールする必要があります。
クレンジング・アクションを即時に実行する場合は、列の変更ダイアログ・ボックスを使用します。このダイアログ・ボックスで「適用」をクリックすると、DMUによって適切なSQL DLL文がデータベースに即時に送信されます。適用した変更をロールバックすることはできません。

列変更のスケジュール・ダイアログ・ボックスまたは列の変更ダイアログ・ボックスで列の長さを調整するには、「調整後の長さ」を選択し、変換後の列内のすべての値の最大長以上の値を新しい長さとして入力します。変換後の最大長は、列プロパティ・タブのスキャン・サブタブで報告されています。「列プロパティ」の項の「データベースのスキャン」を参照してください。

列の長さを調整するときは、ドロップダウン・リストの設定を「バイト」のままにしてください。「適用」をクリックします。

長さセマンティクスの変更

VARCHAR2列またはCHAR列の長さセマンティクスをバイトから文字に変更することは、列の長さ調整の特殊な形態です。列の長さセマンティクスを変更すると、データベースに対して、列に格納する値の制限を、文字のエンコーディングを構成する特定のバイト数ではなく特定の文字数にするように指定します。長さ制約はキャラクタ・セットとは無関係になります。データベースによって、文字長セマンティクスの各列の暗黙的なバイト制限値が、宣言された最大文字数を持つ文字値の最大可能バイト長に設定されます。この暗黙的なバイト制限値は、最大文字数をデータベース・キャラクタ・セットの文字コードの最大バイト数で掛けた値と等しくなります。

キャラクタ・セットの変換によって文字数は変わりません(ただし、ZHT16HKSCS31からの補完的なUnicode文字をUTF8の代替ペアに変換する場合は例外です)。したがって、nバイトに収まる文字数はn文字以下であるため、列の長さ制約がnバイトからn文字に変更されると、データベース・キャラクタ・セット変換後にすべての列値がこの制約に準拠します。暗黙的なバイト制限値は、データベース・キャラクタ・セット変更によって自動的に調整されます。ただし、この場合も文字値の最大長はそのデータ型(VARCHAR2の場合は4000バイト、CHARの場合は2000バイト)によって制限されることに注意してください。変換後にこの制限を超える値は、「型制限超過」として分類されます。このような値の処理については、「「型制限超過」の問題の処理」を参照してください。

Unicodeを処理できるようにアプリケーションを適応させるときにバイトでなく文字数で文字値制限を管理させる場合は、列の長さ調整ではなく文字長セマンティクスへの移行を選択してください。

長さセマンティクスを変更する手順は、次のとおりです。

列の長さセマンティクスを変更するには、前述の「列の長さの調整」の手順に従って、列変更のスケジュール・ダイアログ・ボックスまたは列の変更ダイアログ・ボックスを開きます。

1. まず、「調整後の長さ」ではなく「キャラクタ・セマンティクスへの移行」を選択します。

2. 通常は必要ではありませんが、列を文字長セマンティクスに移行し、同時に宣言済の最大文字数を現在の宣言済の最大バイト数よりも大きくします。このためには、「調整後の長さ」を選択し、隣接するテキスト・フィールドに列の新しい文字制限値を入力して、ドロップダウン・リストから「文字」を選択します。

3. 「適用」をクリックします。

手動での文字値の短縮

列データ型を変更できない場合、格納されている文字値を、ターゲット・キャラクタ・セットへの変換後に拡張して列の長さ制限を超えることがないように変更する必要があります。これには次の3つの方法があります。

- 値を手動で短縮します。

- 変換中にDMUで値が自動的に短縮されるように設定します。

- 拡張する文字を拡張しない文字に置換します。

値を手動で短縮するには、「列制限超過」の問題があるセルの数が、操作を合理的な時間で完了できる程度の数であることが条件となります。値を手動で短縮する場合、クレンジングの結果を最もきめ細かく制御できますが、非常に時間がかかります。値の短縮は、家族の名前など、内容が正確に定義されているデータに対しては実行できないクレンジング・アクションです。

文字値を手動で短縮する手順は、次のとおりです。

1. クレンジング・エディタで黄色の背景でマークされている特定のセル内の文字値を短縮するには、そのセルをダブルクリックするか、右クリックしてコンテキスト・メニューから「データの編集」を選択します。図6-32「データの編集ダイアログ・ボックス」に示すように、編集対象の値を含むデータの編集ダイアログ・ボックスが表示されます。

図6-32 データの編集ダイアログ・ボックス

データの編集ダイアログ・ボックスでは、編集対象の文字値の末尾部分(変換後に値が列の最大長を超える分)が黄色の背景でマークされています。したがって、黄色の背景が表示されなくなるまで値から文字を削除してください。また、「変換後の長さ(バイト)」に表示されている数字と「変換後の制限(バイト)」に表示されている数字を比較し、1つ目の数字が2つ目の数字以下になるまで文字を削除することもできます。

2. 変更の準備ができたら、「OK」をクリックして新しい値を受け入れ、ダイアログ・ボックスを閉じます。新しい値はクレンジング・エディタに表示されますが、まだデータベースには格納されません。今度は、別のセルを編集できます。新しい値をデータベースに永続的に格納する場合は、クレンジング・エディタ・タブで「保存」をクリックします。「元に戻す」をクリックすると、最後の保存以降に行った変更を元に戻すことができます。

値の編集は常に、即時クレンジング・アクションです。手動での編集変更を、変換時になってから適用されるようにスケジュールすることはできません。

変換中の列値の切捨て

列のデータが履歴データであり、業務の目的に必要でなくなった場合や、重要な情報は常にセル値の先頭にのみ含まれている場合は、データが列の既存の長さ制約に準拠するように、変換中にDMUで値を自動的に切り捨てることを選択できます。この方法は、その結果がスキャン結果に反映されないため、クレンジング・アクションとはみなされません。ただし、DMUでは、データの変換可能性の問題によって変換を禁止するかどうかを決定する際に、ユーザーが自動切捨てを許可した列を無視します。

変換中に列値を切り捨てる手順は、次のとおりです。

列の既存の長さ制約に準拠するようにDMUで自動的に列値を切り捨てることを設定できます。手順は次のとおりです。

1. 列プロパティ・タブを開きます。

2. 準備状況サブタブを開きます。

3. 例外データの変換を許可プロパティの値に「はい」を選択します。

列プロパティの設定の詳細は、第3章「DMUでのオブジェクト・プロパティの表示および設定」を参照してください。

拡張する文字の置換

列のデータ型の変更も列値の短縮もできない場合、拡張を回避する最後の手段として、拡張する非ASCII文字をASCII文字で置換します。次に例を示します。

- 改行なしスペース(ほとんどのシングルバイトISOおよびMicrosoft Windowsコード・ページでは0xA0)を標準のスペース(すべてのASCIIベース・キャラクタ・セットで0x20)で置換します。

- スマート・クオーテーション・マーク文字('、'、"、"および„)をASCIIシングルクオーテーション・マーク(')およびダブルクオーテーション・マーク(")文字に置換します。

- 通貨記号を近似表現に置換します。つまり、¥ (円)はY、£ (ポンド)はLに、¢ (セント)はcになります。

- Latin文字からアクセントを削除します(この操作後も許容可能な値になる場合)。

セル内の文字を置換するには、「手動での文字値の短縮」の説明に従って、データの編集ダイアログ・ボックスで文字を編集します。これは、編集するセルの数が少ない場合には有効です。多数のセル内の文字を置換する場合は、Oracle SQL Developerなどのデータベース・ツールを使用し、UPDATE SQL文をTRANSLATE関数とともに発行して、表内の関連するすべての文字を一度に置換します。

より大きなデータ型への移行

列にデータ型制限を超える値が含まれていない場合、列データ型の移行は必要ありません。ただし、このような値が将来発生すると予測される場合は、列データ型をより大きなデータ型に移行することを選択できます。次の選択項目があります。

- CHAR列をVARCHAR2に移行します。

- CHAR列をCLOBに移行します。

- VARCHAR2列をCLOBに移行します。

- LONG列をCLOBに移行します。

DMUでは、非推奨のLONGデータ型への移行をサポートしていません。

列データ型を移行する場合は通常、CHARとVARCHAR2の比較およびパディング・セマンティクスの違い、またはCLOB値の様々なフェッチ方法に対してアプリケーションを適応させるためにコードを変更する必要があります。

列のデータ型を移行する手順は、次のとおりです。

1. 列のデータ型を移行するには、「列の長さ調整」の説明に従って、この列に対する列変更のスケジュール・ダイアログ・ボックスまたは列の変更ダイアログ・ボックスを開きます。次に、「調整後の長さ」を選択し、隣接するドロップダウン・リストからターゲット・データ型を選択します。ターゲット・データ型がVARCHAR2の場合、目的のターゲット長および長さセマンティクスを入力します。ターゲット・データ型がCLOBの場合、「プロパティ」をクリックしてCLOBのプロパティ・ダイアログ・ボックスを開きます。このダイアログ・ボックスで、CLOBセグメントの記憶域パラメータを入力できます。使用可能なオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。「適用」をクリックして、ダイアログ・ボックスを閉じてパラメータを保存します。

2. 列変更のスケジュール・ダイアログ・ボックスまたは列の変更ダイアログ・ボックスで「適用」をクリックして、定義済のクレンジング・アクションを受け入れます。列の変更ダイアログ・ボックスを使用して即時にデータ型を移行することを選択した場合、移行後のデータ型がCLOBであると、移行する列データの量によっては、次の処理に長い時間がかかることがあります。

CHARからVARCHAR2に移行しても、CHAR値の末尾の空白は削除されません。空白を削除する必要がある場合は、Oracle SQL Developerなどのデータベース・ツールを使用し、UPDATE SQL文をRTRIM関数とともに発行します。

「型制限超過」の問題の処理

次の手順は、「型制限超過」のセルに関する問題を解決することです。列内の「型制限超過」の問題をクレンジングするには、次のオプションがあります(これらは、「列制限超過」の問題のクレンジングに使用できるオプションのサブセットです)。

- より大きなデータ型に移行します。

- 格納されている値を手動で短縮します。

- 変換中のDMUで値が切り捨てられるように設定します。

- 値を編集して、変換で拡張される文字を置換します。

「「列制限超過」の問題」で説明されているように、どのクレンジング・アクションを選択するかは、クレンジング対象の表にアクセスするアプリケーションをユーザーが変更できるかどうかによって大きく左右されます。アプリケーションを自分で変更できない場合、より大きなデータ型に移行することはできません。

前述の使用可能なクレンジング・アクションを実行するために必要な手順は、「「列制限超過」の問題」を参照してください。

スキャン結果のリフレッシュ

列変更のスケジュール・ダイアログ・ボックスまたは列の変更ダイアログ・ボックスで列クレンジング・アクションを定義した場合、またはデータの編集ダイアログ・ボックスで値を編集した場合、DMUでは、実行したクレンジング・アクションに基づいて結果が調整されるか、あるいはそれが不可能な場合はその列のスキャン結果が無効化されます。結果が無効化された場合は、列を再スキャンする必要があります。

スキャン結果をリフレッシュする手順は、次のとおりです。

1. 列を再スキャンするには、スキャン・レポート・ツリーまたはナビゲータ・ツリーで列ノードを右クリックして、「スキャン」を選択します。この列のみがスキャン対象として選択された状態でスキャン・ウィザードが表示されます。

2. スキャン・パラメータを受け入れ、「完了」をクリックしてスキャンを開始します。
新しいスキャンでは、問題の分析中に、実行したばかりのクレンジング・アクションが考慮されます。列が適切にクレンジングされていれば、レポートの列制限超過(スケジュール済)列にその列の問題は報告されません。

スケジュール済クレンジング・アクションを定義した場合も、スキャン・レポート・タブのオプション・レポート列「列制限超過(スケジュール済)」(「データベースのスキャン」を参照)か、列プロパティ・タブのスキャン・サブタブに表示されたスキャン結果の現在のデータ列で、現在の表構造および内容の結果を確認できます。

スケジュール済クレンジング・アクションの取消し

列のスケジュール済クレンジング・アクションは、データベースの変換前であればいつでも取り消すことができます。

スケジュール済クレンジング・アクションを取り消す手順は、次のとおりです。

1. 影響を受ける列に対して列変更のスケジュール・ダイアログ・ボックスを開きます。

2. 「変更なし」を選択します。

3. 「適用」をクリックします。
列のスキャン結果が無効化されるため、列を再スキャンする必要があります。

クレンジング・シナリオ3: 無効な表現の問題のクレンジング

データベース内のデータに無効な表現の問題がある場合、スキャン・レポートは「データベース・スキャン・レポートの概要」に示したような内容になりますが、レポート列「列制限超過(スケジュール済)」と「型制限超過(スケジュール済)」に加えて、あるいはそのかわりに、レポート列「無効な表現(スケジュール済)」にゼロでない値が表示されます。データベース・ノードの隣にある黄色い三角形のアイコンは、データに変換可能性の問題があることを示しています。

スキャン・レポートで長さ拡張の問題のある列を見つける場合と同様にして、無効なバイナリ表現の問題のあるセルを含む列を特定できます。詳細は、「データベースのスキャン」を参照してください。

セルの値に無効なバイナリ表現の問題があるということは、値が想定(宣言済)キャラクタ・セット(デフォルトではデータベース・キャラクタ・セット)で無効になることを意味します。値の一部のバイトが、宣言済キャラクタ・セットで有効な文字コードを構成しません。

値に無効なバイナリ表現がある場合、次の3つの理由が考えられます。

- パススルー構成のアプリケーションで、バイナリ(純粋なテキストとして解釈されない値)が格納されています。最もよくある例は、イメージや固有のバイナリ形式のドキュメントがLONG列に格納される場合や、暗号化テキスト値(VARCHAR2結果を戻すDBMS_OBFUSCATION_TOOLKITプロシージャからの結果など)がVARCHAR2列に格納される場合です。

- パススルー構成のアプリケーションで文字値が格納され、値がデータベース・キャラクタ・セットと異なる1つ以上のキャラクタ・セットでエンコードされています。最もよくある例は、US7ASCIIを使用するデータベースに各種のMicrosoft Windowsクライアント・キャラクタ・セットのデータが格納される場合や、各種のISO 8859データベース・キャラクタ・セットのデータが格納される場合です。

- アプリケーションに、ソフトウェアの欠陥やハードウェアの障害で破損した文字コードを含む値が含まれています。

パススルー構成の詳細は、「データの無効なバイナリ記憶域表現」を参照してください。

特定の列に無効なバイナリ表現データがあり、その原因が3つのうちどれかを分析するには、この列の「無効な表現(スケジュール済)」のゼロでないカウンタ値をクリックして、この列のクレンジング・エディタ・タブを開きます。カウンタ値をクリックすると、DMUによって、DMUウィンドウのクライアント・ペインに、図6-33「クレンジング・エディタ・タブ: 無効なバイナリ表現の問題」に示すようなクレンジング・エディタ・タブが開きます。このタブは、ナビゲータ・ペインまたはスキャン・レポート・ツリーで表ノードを右クリックして「クレンジング・エディタ」を選択しても開くことができます。

問題のあるデータ・セルを特定するには、クレンジング・エディタの様々なフィルタリング機能および検索機能が役立ちます。これらの機能の詳細は、「データのクレンジング」を参照してください。

デフォルトでは、無効なバイナリ表現の問題があるデータ・セルはライト・コーラルの背景で表示されます。この色は、ツール・メニューから「プリファレンス」を選択すると開く「プリファレンス」ダイアログ・ボックスで変更できます。

図6-33 クレンジング・エディタ・タブ: 無効なバイナリ表現の問題

拡張の問題の場合と同様に、無効なバイナリ表現の問題のあるセルをダブルクリックすると、図6-32「データの編集ダイアログ・ボックス」に示すようなデータの編集ダイアログ・ボックスが開きます。

データの編集ダイアログ・ボックスの右下のペインに、バイナリ・データが表示されます。図6-34「データの編集ダイアログ・ボックス: バイナリ・データの表示」に示すように、編集対象の値を構成するバイトは2桁の16進文字で表示されます。

図6-34 データの編集ダイアログ・ボックス: バイナリ・データの表示

クレンジング・エディタ・タブとデータの編集ダイアログ・ボックスが開いた状態で、無効なバイナリ表現の問題の原因を特定し、次の各項で説明されている問題のクレンジングを試行できます。「スキャン結果のリフレッシュ」および「スケジュール済クレンジング・アクションの取消し」で説明されている考慮事項は、無効なバイナリ表現の問題のクレンジングにも同様に適用されます。

DMUで報告された問題のあるすべての表に対して、クレンジング・プロセスを繰り返します。スキャン・レポートまたは移行ステータス・タブに報告される問題がなくなったら、「データベースの変換」の説明に従って変換フェーズに進むことができます。

文字列内のバイナリ値のクレンジング

データの編集ダイアログ・ボックスの右下隅で、文字列に間違って格納されているバイナリ値を判別できます(このような値はダイアログ・ボックスの左下隅にガベージとして表示されているため)。ダイアログ・ボックスのバイナリ表示に0x00から0x08まで、および0x10から0x1fまでの範囲のバイトが多く表示されている場合、その値はバイナリです。これらのバイトは履歴目的のみでASCIIコントロール・コードに対応しているため、文字列に現れることはほとんどありません。

非常に長い一連のシングル・バイト(スペースを表すASCIIコードや、マイナス記号、プラス記号、アンダースコア、等記号、ピリオドなど、区切り線を引くために一般的に使用される文字を表すASCIIコードを除く)によって、バイナリ値であると判別できることもあります。

バイナリ値を格納する列に無効なバイナリ表現の問題がある場合、その問題をクレンジングするには、列のデータ型をRAWまたはLONG RAWに移行します。DMUでは、BLOBへの移行をサポートしていません。長さ2000バイトまでのCHAR列およびVARCHAR2列では、RAWへの移行がサポートされています。LONG列では、LONG RAWへの移行がサポートされています。

列をバイナリ型に移行する手順は、次のとおりです。

1. 列をバイナリ・データ型に移行するには、クレンジング・エディタでその列の任意のセルを右クリックします。コンテキスト・メニューが表示されます。

2. メニューで、「列変更のスケジュール」または「列の変更」を選択します。前者を選択すると列変更のスケジュール・ダイアログ・ボックスが開き、後者を選択すると列の変更ダイアログ・ボックスが開きます。これらのダイアログ・ボックスの違い、および関連するクレンジング・モード(スケジュール・モードと即時モード)の違いについては、「列の長さの調整」を参照してください。

3. 開かれるダイアログ・ボックス(図6-31「列変更のスケジュール: 列サイズの長さ調整」を参照)で「移行後の型」を選択し、隣接するドロップダウン・リストからターゲットのデータ型を選択します。ターゲットのデータ型がRAWの場合、目的の列の長さをバイト単位で入力します。この長さは、移行する列のすべての値の最大バイト長以上にする必要があります。

4. 「適用」をクリックします。

不適切なキャラクタ・セット宣言のクレンジング

データの編集ダイアログ・ボックスのバイナリ表示でそのバイナリ・データのバイト・パターン特性が明確になっていない場合、編集対象の値は、不適切に使用されているキャラクタ・セットの文字データである可能性があります。問題が疑われる場合は、アプリケーション開発者またはアプリケーション管理者に問い合せて、分析された列に格納されている情報のソースおよびタイプを特定してください。

不適切なキャラクタ・セット宣言を修正する手順は、次のとおりです。

1. 列内のデータの実際のキャラクタ・セットを特定するために、クレンジング・エディタでその列を選択し、キャラクタ・セット・ドロップダウン・リストで、その列内のすべての値が判読可能になるまで、選択する値を繰り返し変更します。図6-35「想定列キャラクタ・セット」を参照してください。時間を節約するために、「移行の準備の確認」で推奨されているように、移行の開始前に収集した情報に基づいて、キャラクタ・セットをデータベースのデータ・ソース(クライアント、入力ファイル)で使用できるキャラクタ・セットに制限します。
試行したキャラクタ・セットのいずれでも列内のすべての値が正しく表示されないが、それぞれの値はいずれかのキャラクタ・セットで正しく表示される場合、その列には異なるキャラクタ・セットのデータが混在しています。このような問題は、DMU外部で解決する必要があります。

2. 適切なキャラクタ・セットを特定した後は、クレンジング・エディタ・タブで「保存」をクリックして、それを永続的に列に割り当てます。その後、列を再スキャンします。その列には無効な表現の問題が報告されなくなるはずです。

図6-35 想定列キャラクタ・セット

破損した文字値のクレンジング

列の想定キャラクタ・セットで判読できない列値はごくわずかであり、ある値では文字が判読できないのに別の値では判読できる場合、無効なバイナリ表現の問題は、ソフトウェアやハードウェアの障害によって文字値がランダムに破損したことが原因です。ソフトウェアの場合、アプリケーションがシングルバイト・アルゴリズムを使用してマルチバイト・データを処理していることが、マルチバイト・データベースにこのような破損が起こる一般的な理由です。このようなアプリケーションでは、マルチバイト文字の途中で文字列が分割されたり切り捨てられて、部分的に無効なコードが生成されることがあります。

ランダムに破損した値をクレンジングするには、「手動での文字値の短縮」の説明に従って、データの編集ダイアログ・ボックスで値を編集して修正します。

用語集

AからBへの変換

キャラクタ・セット移行のタイプの1つ。AからBへの変換では、新しいUnicodeデータベースを作成し、エクスポート・ユーティリティ、インポート・ユーティリティまたはデータ・ポンプを使用してすべてのデータを既存のデータベースから新しいデータベースに移動します。

「インライン変換」を参照してください。

一括クレンジング・ウィザード

一括で3つの処理の実行を可能にするウィザード:

- CHARおよびVARCHAR2表列の長さセマンティクスをバイト・セマンティクスからキャラクタ・セマンティクスに一括で変更
即時クレンジング・モードまたはスケジュール・クレンジング・モードのいずれかで文字長セマンティクスに移行する一括クレンジングを実行できます。スケジュール・モードでは、文字長セマンティクスへの移行は、変換フェーズ中に本番環境を中断することなく適用されます。DMUを検証モードで使用している場合は、即時のクレンジング・オプションのみが使用可能になります。

- 「問題のあるデータの変換を許可する」列変換プロパティの設定
このプロパティを「はい」に設定すると、列のスキャン結果でいくつかの値に変換の問題がある、つまり変換後の値に置換文字が含まれるか、変換後の値が切り捨てられる問題があることが示された場合でも、DMUでデータの変換を実行できます。列またはデータ型の制限を超えたデータを自動的に切り捨てる場合や、破損した値があってもこのデータを使用するアプリケーションにとって大きな影響はないような場合には、これを使用すると便利です。

- 列値のすべてのバイト・パターンまたは文字パターンを置換または削除
場合によっては、個々のデータ例外の性質を分析した後、障害になっているバイトまたは文字を有効な同等のバイトまたは文字セットに置き換えるか、すべて削除することによってデータを変更できます。同じ問題の兆候が複数のデータベース・オブジェクトにある場合、そのような置換操作は一括での実行が望ましい可能性があります。パターンに基づいた置換クレンジング・オプションによって、選択したデータベース・オブジェクトのすべてのソース・パターンをターゲット・パターンへ置き換えることが可能になります。単一のバイトまたは文字を置き換えることもでき、バイトまたは文字を文字列で指定することもできます。

キャラクタ・セマンティクス

キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の記憶要件を定義する場合に役立ちます。たとえば、Unicodeデータベース(AL32UTF8)で、VARCHAR2列を英語の5文字とともに最大5文字の中国語文字を格納できるように定義する必要があるとします。バイト・セマンティクスを使用すると、この列には、長さ3バイトである中国語文字用に15バイトと、長さ1バイトである英語文字用に5バイト、合計20バイトが必要です。キャラクタ・セマンティクスを使用すると、この列に必要な文字数は10となります。キャラクタ・セマンティクスを使用すると、データベース・キャラクタ・セットとは関係なく文字数で列サイズを指定できます。

キャラクタ・セットの移行

あるデータベース・キャラクタ・セットから別のデータベース・キャラクタ・セットに移行するプロセス。このガイドでは、Unicodeへの移行について説明しています。

更新の確認ウィザード

DMUライブ・アップデート機能を使用すると、DMUの最新バージョンの有無を確認して、これをインストールできます。これは更新の確認ウィザードを使用して行い、これによってDMU更新センターから新しいバージョンのDMUが使用可能かどうかを確認できます。

クレンジング

スキャン・プロセスで見つかったデータ問題を特定して解決するプロセス。これらの問題を解決しないと、データベースを変換できません。

CSALTERスクリプト

CSALTERスクリプトは、Database Character Set Scannerユーティリティに付属しています。これは、キャラクタ・セットの移行方法としては最も簡単ですが、使用できるのは、すべてのスキーマ・データが、新しいキャラクタ・セットの完全なサブセットである場合のみです。

CSREPAIRスクリプト

パススルー構成を使用している場合、CSREPAIRスクリプトを使用して、データベース・キャラクタ・セット・メタデータを修復できます。パススルー構成においては、(通常はNLS_LANGクライアント設定を介して)クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されていますが、データベース内の文字データが宣言済データベース・キャラクタ・セットとは異なるキャラクタ・セットで格納される可能性があります。CSREPAIRスクリプトは、DMUリポジトリにアクセスすることにより、DMUクライアントと連携して動作します。これにより変更されるのはデータ・ディクショナリ・メタデータ内のデータベース・キャラクタ・セット宣言のみであり、データベース・データは変換されないことに注意してください。

CSSCANスクリプト

Database Character Set Scanner (CSSCAN)は、Oracleデータベースから新しいデータベース・キャラクタ・セットへの移行の実行可能性を査定するコマンドライン・ユーティリティです。Database Character Set Scannerにより、データベースのすべての文字データがチェックされ、キャラクタ・セット・エンコーディングの変更による影響と問題点がテストされます。スキャンの終了時には、データベースを新規キャラクタ・セットに変換するために必要な作業の範囲を示すサマリー・レポートが生成されます。

Database Migration Assistant for Unicode (DMU)

キャラクタ・セットを移行するための、直覚的でユーザーフレンドリなGUIツール。これを使用すると、ワークロードを軽減し、すべての移行問題を確実に解決し、データ変換を適切かつ効率的に実行できます。

データベース・スキャン・レポート

データベース・スキャン・レポートにはデータベースのスキャンからの出力が表示され、様々な方法で結果を確認できます。このレポートは、データのステータスに基づいてフィルタリングしたり、カスタマイズすることができます。たとえば、変換後にデータ型制限を超えるデータを含むすべてのオブジェクトのみが表示されるように、レポートをフィルタリングできます。

診断パッケージ作成ウィザード

DMUの使用中に問題が発生した場合、オラクル社がその問題を解決する際にその後の分析で使用する診断パッケージを作成できるウィザード。

拡張

レガシー・エンコーディングからUnicodeに移行する場合、Unicodeのエンコーディングのほうがバイト数が多いため、通常は変換で文字の値が拡張されます。その結果、データベースの領域要件が大きくなります。さらに、キャラクタ・セットをUnicodeに移行した後にCHAR列およびVARCHAR2列の幅が不足する可能性もあります。この場合、データが切り捨てられる危険があります。列の長さ制約を拡大したり、または、すでにデータ型の制限に達している場合は、列をCLOBデータ型に移行する必要があることもあります。

外部表

通常、外部表は変換の必要がありません。外部表(SQL*Loaderまたはデータ・ポンプ)のソース・ファイルのキャラクタ・セットが適切に宣言されていれば、データがファイルからフェッチされるたびにデータベースは自動的に文字データを新しいデータベース・キャラクタ・セットに変換します。パフォーマンス上の理由で、この変換が行われないようにファイルを完全に変換することも考慮してください。

インライン移行

最初に非ASCIIデータを特定してから、移行の変換フェーズでそのデータとメタデータのみが更新されるような、移行タイプの1つ。変更されるデータベース値の量は通常、データベースに格納されているすべての値のうちわずかな割合にすぎません。

「AからBへの変換」を参照してください。

初期化

必要なパッチおよびサポート・パッケージのインストール、リポジトリの表領域の作成、データベース接続、および移行リポジトリのインストールを行うプロセス。

無効なバイナリ表現

ユーザー・データでよくある問題は、列のデータが実際に宣言済データベース・キャラクタ・セットのデータでないことです。実際には別のキャラクタ・セットのデータであったり、バイナリ・データであったり(たとえば、イメージ、固有のワード・プロセッサ形式のドキュメント、またはカスタムの方法で暗号化されたテキストが含まれている)、1つの列に複数のキャラクタ・セットが存在している場合があります。この問題の原因として考えられるのは、(通常はNLS_LANGクライアント設定を介して)クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されているパススルー構成です。

移行

「キャラクタ・セット移行」を参照してください。

移行ワークフロー

データベース・キャラクタ・セットをUnicodeに移行するための一般的な手順およびその順序。

移行リポジトリ

処理対象のオブジェクト、エラーのフラグが付いたデータの詳細、スキャンや変換の進行状況、およびUnicodeへの移行に必要なその他の項目が含まれるリポジトリ。

パススルー構成

パススルー構成においては、(通常はNLS_LANGクライアント設定を介して)クライアント・キャラクタ・セットがデータベース・キャラクタ・セットと同じになるように定義されています。これらのキャラクタ・セットが同じであるため、Oracle通信プロトコルでは変換が必要でないと判断され、クライアント・キャラクタ・セットからサーバー・キャラクタ・セットへの変換が行われません。クライアント・アプリケーションからのデータが実際に宣言済キャラクタ・セットのデータであるかぎり、この構成でも問題はありません。しかし、データのキャラクタ・セット変換も文字検証も実行されないため、どのようなバイト・シーケンスも実際にデータベースに格納され、そのままの状態で取得される可能性があります。クライアント・アプリケーションのみでデータが解釈されるかぎり、格納されたバイト・シーケンスがデータベース・キャラクタ・セットとは異なる文字エンコーディングに一致する場合や、読取り可能なテキストにまったく一致しない場合があります。

準備

データ準備とは、実際の変換中または変換後に移行対象のデータベース・データに問題が発生することを回避するためのプロセスです。データ準備の要素は、スキャンとクレンジングです。

読取り専用オブジェクト

読取り専用の表および表領域は、読取り/書込みにしないかぎり変換できません。明示的に読取り専用とマークされた表、外部表、読取り専用表領域に格納された表などの表は、読取り専用です。このような表は、読取り/書込みにしないと変換できません。表が明示的に読取り専用とマークされている場合を除き(この場合は移行プロセスにより一時的に削除できます)、これ以外の前述の理由には、手動で対処する必要があります。

リポジトリ構成ウィザード

リポジトリを使用して移行の各ステップに必要な情報を管理できるウィザード。データベースに移行リポジトリがない場合、そのデータベースに接続するたびにリポジトリが自動的に作成されます。このウィザードはDMUユーザー・インタフェースから開始することもできます。

「移行リポジトリ」を参照してください。

スキャン

スキャンは、データのUnicodeへの移行の実行可能性を査定するプロセスです。このプロセスの一部として、DMUではデータベースから文字値を読み取ってターゲット・キャラクタ・セットに変換し、変換で変更される値、列に収まらない値、データ型に収まらない値、または無効な文字コードが含まれる値の数をカウントします。列内の値の変換後の最大長など、追加の統計も計算されます。

スキャン・ウィザード

スキャン・プロセスが順を追って示され、データの損失なくデータを完全に変換するためにクレンジングの必要なデータがあるかどうかが通知されるウィザード。

サブセット

スーパーセット・キャラクタ・セットに含まれるデータベース・キャラクタ・セット。たとえば、Unicodeに含まれるASCIIはこの一例です。

スーパーセット

サブセット・キャラクタ・セットを含むデータベース・キャラクタ・セット。たとえば、UnicodeにはASCIIのサブセットが含まれます。

切捨て

一部を切り取るか削除して、何かを短縮すること。データ移行のコンテキストにおける重要な考慮事項は、移行後のCHAR列およびVARCHAR2列の幅が十分でないとデータが切り捨てられる可能性があることです。

Unicode UTF-8

UTF8 (CESU-8)は可変幅キャラクタ・セットであり、文字は1-3バイト、補助文字は3バイトのペアで表現されます。

Unicode AL32UTF8

AL32UTF8は可変幅キャラクタ・セットであり、文字長は1、2、3または4バイトで、補助文字は4バイトで表現されます。

検証

DMUでは、既存のAL32UTF8またはUTF8データベースの内容を検証できます。このようなデータベースは過去にUnicodeに変換されていたり、最初はUnicodeキャラクタ・セットで作成されたものである可能性があります。どちらの場合も、データの現在の問題を確認できます。

索引
A B C D E F H I K M O P R S T U V W

A

アプリケーションへの影響

キャラクタ・セットの移行, 1.5.6

アプリケーション

Unicode移行に適応, 5.6

B

バイナリ・データ, 5.2.4.6

バイナリ・データ型, 1.5.1.7

一括クレンジング・ウィザード, 6.10

起動, 6.10

C

キャラクタ・セットの移行

アプリケーションへの影響, 1.5.6

ツール, 1.4

Character Set Scanner, 1.4.1 キャラクタ・セット

データベース, 1.1

スキャン, 1.1

更新の確認ウィザード, 5.8 クレンジング, 2.6.2, 4.5

データ長の問題, 5.3.2.1

一括, 6.10

無効なバイナリ表現の問題, 5.3.2.2

長さの問題, 5.2.4.2

クレンジング・エディタ・タブ, 6.1 コード変更

PL/SQL, 5.6.2

SQL, 5.6.2

色の強調表示, 6.1.2 変換

データベース, 4.6

変換の詳細タブ, 4.6.1 変換

データ・ディクショナリ表, 5.3.3

破損した文字コード, 5.2.4.5 CSALTERスクリプト, 1.4.2 CSREPAIRスクリプト, 5.7

D

データ

クレンジング, 4.5

データ変換

手順, 2.7.2

データ・ディクショナリ

内容, 5.3

表

変換, 5.3.3

データの拡張, 1.5.1.1 データ準備

クレンジング, 2.6.2

スキャン, 2.6.1

データ・ポンプ, 1.4.3 データ・ビューア・タブ, 6.2 データベース

キャラクタ・セット, 1.1

変換, 4.6

スキャン, 4.4

データベース・キャラクタ・セット, 1.1 データベース・プロパティ

設定, 4.4.1

データベース・スキャン・レポート, 4.4.4

表示, 4.4.4

依存オブジェクト, 1.5.2 診断パッケージ作成ウィザード, 4.8 DMU

列プロパティ, 3.4

変換, 3.4.4

概要, 3.4.1

準備状況, 3.4.3

スキャン, 3.4.2

データベース・プロパティ, 3.1

変換, 3.1.4

準備状況, 3.1.3

スキャン, 3.1.2

リポジトリ, 2.4.3

リフレッシュ, 4.2

アンインストール, 4.3

要件, 2.3 スキーマ・プロパティ, 3.2

準備状況, 3.2.3

スキャン, 3.2.2

表プロパティ, 3.3

変換, 3.3.4

概要, 3.3.1

準備状況, 3.3.3

スキャン, 3.3.2

DMUタスク, 3, 6

E

データの編集ダイアログ・ボックス, 6.3

暗号化データ, 1.5.1.6

列の除外, 5.1

表の除外, 5.1

エクスポート/インポート・ユーティリティ, 1.4.3

外部表, 5.2.4

クレンジング, 5.2.4.1

F

障害リカバリ, 1.5.5

H

ハイライト

色, 6.1.2

I

アクセス不能オブジェクト, 1.5.3

不適切なキャラクタ・セット宣言, 6.13.2

索引キー・サイズ

最大, 1.5.1.4

索引サイズ, 5.5.2 無効なバイナリ記憶域表現, 1.5.1.2

K

鍵

プライマリ, 1.5.1.5

一意, 1.5.1.5

M

データベースのUnicodeへの移行, 1

移行

Unicodeへの移行に対するアプリケーションの適用, 5.6

移行リポジトリ

リフレッシュ, 4.2

再インストール, 4.2

アンインストール, 4.3

「属性の変更」ダイアログ・ボックス, 6.7 「列の変更」ダイアログ・ボックス, 6.5 多言語列, 5.4

O

オブジェクト

依存, 1.5.2

アクセス不能, 1.5.3

読取り専用, 1.5.3

オフライン表領域, 5.2.3 Oracle Loader, 5.2.4.7 列制限超過の問題, 6.12.1 型制限超過の問題, 6.12.2

P

パーティション範囲の整合性, 5.5.3

パーティション化, 1.5.1.3

PL/SQL

コード変更, 5.6.2

ローカル識別子, 5.5.5

主キー, 1.5.1.5 プロパティ

列, 3.4

データベース, 3.1

スキーマ, 3.2

表, 3.3

R

読取り専用

オブジェクト, 1.5.3

読取り専用表, 5.2.1 読取り専用表領域, 5.2.2 リカバリ, 1.5.5 ごみ箱オブジェクト, 5.5.4 リポジトリ, 2.4.3 「リポジトリ構成」ウィザード, 2.4.3, 4.2 必要なパッチ, 4.1.1 要件

DMU, 2.3

S

「スキャン」ウィザード, 4.4.2

起動, 4.4.2

スキャン, 2.6.1

データベース, 4.4

データベースのスキャン, 4.4 属性変更のスケジュール・ダイアログ・ボックス, 6.8 列変更のスケジュール・ダイアログ・ボックス, 6.6 スキーマ・プロパティ, 3.2 「データの表示」ダイアログ・ボックス, 6.4 SQLコード変更, 5.6.2 サポート・パッケージ, 4.1.2

T

表

除外, 5.1

外部, 5.2.4

プロパティ, 3.3

読取り専用,5.2.1

表領域

オフライン, 5.2.3

読取り専用, 5.2.2

タスク

DMU, 3, 6

U

Unicode, 1.3

データベースの移行, 1

移行ロードマップ, 2.1

データの検証, 4.7

一意キー, 1.5.1.5 一意性の検証, 5.5.1 ユーティリティ

エクスポート/インポート, 1.4.3

V

データの検証, 4.7

検証

一意性, 5.5.1

「検証ステータス」タブ, 4.7.1

W

ウィザード

一括クレンジング, 6.10

更新の確認, 5.8

診断パッケージ作成, 4.8

リポジトリ構成, 2.4.3

「スキャン」ウィザード, 4.4.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。