| Oracle® Database Migration Assistant for Unicodeリリース・ノート リリース2.0 E56368-02 |
|
 前 |
 次 |
このドキュメントには、今回のリリースのOracle Database Migration Assistant for Unicode製品固有のドキュメントに記載されていない重要な情報が含まれています。
製品名Oracle Database Migration Assistant for Unicodeは、多くの場合、このドキュメント、他のOracleドキュメントおよびOracle WebサイトでDMUと略されます。
このドキュメントは、リリース後に更新される場合があります。このドキュメントに対する更新を確認するには、また他のDMUドキュメントを表示するには、Oracle Technology Network(OTN) DMU Webサイトのドキュメントに関する項を参照してください。
このドキュメントは次のトピックで構成されています。
DMUリポジトリ・スキーマは、リリース2.0で更新されています。1.2リリースに古いリポジトリがインストールされている場合、アンインストールし、DMU 2.0を使用してリポジトリを再インストールする必要があります。
リリース2.0の変更点は次のとおりです。
DMUは、Database 12cでのOracleプラガブル・データベース(PDB)の移行をサポートします。新しいPDB機能を使用して、様々なデータベース・キャラクタ・セットを含むデータベースを統合する場合、PDBがプラグインされるコンテナ・データベース(CDB)のキャラクタ・セットと互換性のあるデータベース・キャラクタ・セットがすべてのPDBに必要です。互換性があるとは、キャラクタ・セットが同じである、またはPDBのキャラクタ・セットがCDBのキャラクタ・セットのバイナリ・サブセットであり、両方がシングルバイトかマルチバイトであることを意味します。このような統合のベスト・プラクティスの手法として、新規のCDBとそのPDBにはUnicodeキャラクタ・セット(AL32UTF8)を使用することをお薦めします。AL32UTF8は、あらゆる言語のキャラクタ・セットをサポートできる統一されたスーパーセット・キャラクタ・セットを提供するため、レガシー・キャラクタ・セットが異なる統合対象データベース間で最大の互換性が保たれます。
様々なキャラクタ・セットを含むデータベースを統合するには、次のようにします。
データベース・キャラクタ・セットAL32UTF8および各国語キャラクタ・セットAL16UTF16でCDBを作成します。統合するほとんどのデータベースで各国語キャラクタ・セットUTF8が使用されている場合、AL16UTF16ではなくUTF8を使用してください。
統合する非CDBそれぞれについて、次の手順を実行します。
Oracle Database 12cより前のOracle Databaseリリースが使用されている場合、Oracle Database 12cにアップグレードします。
DMUを使用して、データベース・キャラクタ・セットをAL32UTF8に移行します。
各国語キャラクタ・セットをCDBの各国語キャラクタ・セット(AL16UTF16またはUTF8)に移行します。この手順は、Oracleサポートに連絡してください。
アップグレードおよび移行された非CDBを使用して、新規のPDBを作成します。非CDBを使用してPDBを作成する詳細は、『Oracle Database管理者ガイド』を参照してください。
Unicode以外のキャラクタ・セットを使用して、データベースをすでに統合済であり、既存のPDBをUnicodeに移行する必要がある場合、DMU 2.0を使用して実行します。
移行済のPDBがプラグインされるAL32UTF8 CDBを作成または識別します。
移行する各PDBについて、次の手順を実行します。
PDBが元のUnicode以外のCDBにまだプラグインされている場合、DMUを使用してPDBをスキャンし、報告された変換の問題を解決します。
移行するPDBを切断し、ターゲットAL32UTF8 CDBにプラグインします(これにより、キャラクタ・セットの非互換性のため、PDBは制限モードになります)。
DMUを使用して、PDBをUnicodeに変換します。
非制限モードの変換済PDBを再起動します。
この方法では、必要な停止期間を削減する、効率的で予測可能な統合プロセスが可能になります。
PDBでスキャンおよびクレンジング操作を実行するには、ローカルPDB内のSYSDBA権限を持つ任意のユーザーとしてDMUを使用して接続できます。PDBで変換操作を実行するには、SYSユーザーまたはローカルPDBとCDBの両方でSYSDBA権限を持つ共通ユーザーのいずれかとして、DMUを使用して接続する必要があります。
CSREPAIRスクリプトも拡張されており、データ変換が不要な場合に格納済データベース・コンテンツと一致するようPDBのキャラクタ・セットを修正する機能がサポートされています。PDBでCSREPAIRを実行するには、SYSユーザーまたはローカルPDBとCDBの両方でSYSDBA権限を持つ共通ユーザーのいずれかを使用して接続する必要があります。
DMU 2.0は、類似する原因または兆候のあるデータ変換の問題のクレンジングを促進する拡張一括クレンジング機能を提供します。文字長セマンティクスへの一括移行を実行する機能に加えて、DMUは、列値でのバイトまたは文字シーケンスの発生を一括置換または一括削除を可能にするパターンベースのクレンジングをサポートするようになりました。これは、複数のデータベース・オブジェクトに出現する、問題のあるバイトまたは文字に対処する場合に特に便利です。変換の問題があるデータを含むがアプリケーションに対しては重要ではない列では、「問題のあるデータ変換を許可」プロパティを一括で設定し、報告された問題にかかわらず列を変換するようにDMUに指示できるようになりました。
このリリースのDMUでは、PeopleSoftデータベースのUnicodeへの移行のサポートも導入されています。接続されたデータベースがPeopleSoftインスタンスであると検出された場合、DMUは、PeopleSoft固有の移行ロジックを移行ワークフローの一部として透過的に実行します。前提条件として、データベースはPeopleSoftアプリケーション・バージョン9.0以降、PeopleToolsバージョン8.48以降用である必要があります。
変換エラー処理のメカニズムが拡張され、マテリアライズド・ビューのリフレッシュおよび索引の再構築に関連するエラーを自動的にスキップし、後で解決するために失敗したSQL文を外部スクリプトにエクスポートするオプションが追加されました。変換フェーズ内のすべての手順は再開可能となり、これには、インメモリー・キャラクタ・セット情報をデータ・ディクショナリと再同期するためにデータベースの再起動を要求するALTER DATABASE CHARACTER SETなどが含まれます。
"CREATE TABLE AS SELECTを使用したデータのコピー"変換方法を、ユーザーが名前を指定したLOBセグメントを含む表に適用できるようになりました。
大量の文字長セマンティクス列数を含むデータベースで、スケーラビリティおよび変換の時間を改善するために、パフォーマンスの最適化機能が実装されました。
検証モード変換実行可能性チェックが再設計され、無効な列をUnicodeに変換するための準備状況がより明確に伝達されるようになりました。ユーザーが様々なキャラクタ・セットのデータを含む列をUnicodeに変換する前に、すべての関連するエラーおよび警告が検証ステータス・パネルに表示されます。
Oracle Database Migration Assistant for Unicodeの最新のサポート情報は、次のOTN DMU Webサイトで入手できます。
ドキュメントのタイトルは、「サポートされる構成」です。
Oracle Database Migration Assistant for Unicodeのインストール手順は、次のOTN DMU Webサイトで入手できます。
ドキュメントのタイトルは、「はじめに」です。
この項では、次の要件のタイプについて説明します。
DMUでサポートされるデータベースは、特定の要件を満たしている必要があります。要件は次のとおりです。
データベース・キャラクタ・セットはASCIIベースである必要があるため、EBCDICベースのプラットフォームIBM z/OSおよびFujitsu BS2000で実行されているデータベースはサポートされません。
パッケージSYS.DBMS_DUMA_INTERNALをデータベースにインストールする必要があります。
パッケージを作成するスクリプト?/rdbms/admin/prvtdumi.plbが、データベースのインストールの一部として使用可能です。データベースのOracleホームからスクリプトを実行して、パッケージを手動で作成する必要があります。詳細はインストール手順を参照してください。
Oracle Database Vaultが有効になっている状態でのDMUの動作は保証されていないため、移行プロセスの開始前にOracle Database Vaultを無効化する必要があります。
データベースは読取り/書込みモードで開く必要があります。
この他に、DMUで変換するデータベースに関連する要件もあります。これらの要件を満たしていなくても、DMUを使用してデータベースのスキャンとクレンジングを行うことはできます。要件は次のとおりです。
DBMS_RULE、DBMS_DATA_MINING、DBMS_WMなどの標準のPL/SQLパッケージにより作成された補助オブジェクトを含むすべてのデータベース・オブジェクトは、ASCIIキャラクタ・セットの文字のみを使用した名前を付ける必要があります。つまり、いくつかの選択された表を除いて、データベースのデータ・ディクショナリに非ASCII文字を含めることはできません。
詳細は、『Oracle Database Migration Assistant for Unicodeガイド』の第5章のデータ・ディクショナリ・コンテンツの移行に関する項を参照してください。
事前定義済システム・ワークスペースおよび特定の事前定義済Oracle Applicationsワークスペースを除くOLAPアナリティック・ワークスペースをデータベースに含めることはできません。
フラッシュバック・データ・アーカイブをデータベースに含めることはできません。
変換するデータを読取り専用またはオフラインの表領域に格納することはできません。
クラスタ・キー列とパーティション化キー列はいずれも、文字長セマンティクスを使用して定義できません。
ごみ箱の中の表に変換可能データを含めることはできません。
参照パーティション化キー列に変換可能データを含めることはできません。
変換できないデータがANYDATA/ANYDATASET列に存在する場合があります。
移行プロセスには、データベース内に空き領域が必要です。空き領域は、次の領域で必要です。
移行リポジトリ
リポジトリ表には、DMUの内部状態情報、スキャン結果、スケジュールされたクレンジング・アクション、変換計画詳細、およびスキャンされた表内の変換可能な行または問題のある行(あるいはその両方)に対して収集された行識別子が格納されます。移行リポジトリには、個別の表領域を作成することをお薦めします。このような表領域の作成の詳細は、『Oracle Database Migration Assistant for Unicodeガイド』を参照してください。
データ変換
レガシー・キャラクタ・セットからAL32UTF8またはUTF8に変換され、ASCII文字のみで構成されないデータは、通常、サイズで拡張されますが、これはほとんどの場合、文字のUTF-8エンコーディングが同じ文字のレガシー・キャラクタ・セット・エンコーディングよりも多くのバイトを含むためです。さらに、変換方法「CREATE TABLE AS SELECTを使用してデータをコピー」は、表内のデータを変換し、SQL文CREATE TABLE AS SELECTにより表のコピーを作成します。コピーの作成後にソース表は削除されますが、しばらくの間、両方の表が同時に存在します。したがって、この変換方法を使用して変換される表のコピーを格納するために追加の領域が必要になります。
CREATE TABLE AS SELECT用のデータ拡張および一時領域を格納する表領域ごとに必要な空き領域の見積り量を表示するには、DMUの「ナビゲータ」ペイン内のデータベース・ノードを右クリックし、「プロパティ」を選択します。開かれたデータベース・プロパティ・タブで、スキャン・サブタブを選択します。ページの下部にある「表領域拡張の見積り」ボタンをクリックして、各表領域の最小および最大領域要件を計算します。最小表領域拡張は、変換後のデータ・サイズ拡張と、「CREATE TABLE AS SELECTを使用してデータをコピー」方法を使用して変換された最大表の一時領域要件を考慮して計算されます。最大表領域拡張は、変換後のデータ・サイズ拡張と、「CREATE TABLE AS SELECTを使用してデータをコピー」方法を使用して変換された最初のn個の最大表の一時領域要件を考慮して計算されます(nは変換ワーカー・スレッド数)。
報告された拡張情報を使用して、必要な空き領域の規模を見積りますが、必要に応じて表領域を拡張できるようにデータベース・データ・ファイルの自動拡張機能を使用します。
この項では、既知の問題および制限について説明します。
DMU 2.0を使用してOracle Database 12.1.0.2 PDBを移行する場合、データ・ディクショナリ列sys.bootstrap$.sql_textにレポートされる無効なバイナリ表現データのため、変換の実行可能性テストが失敗します。パッチ19533216をMy Oracle Support (MOS) Webサイトhttps://support.oracle.comからダウンロードし、パッチのREADMEファイルの指示に従い、修正を適用して、この問題を解決します。
既知のデータベース・バグが原因でCDBキャラクタ・セットと互換性のないキャラクタ・セットがPDBにある場合、診断パッケージの作成機能は、Oracle Database 12.1.0.1.0でのPDBでは機能しません(参照: Bug#17384878)。
移行対象のPDBで、PL/SQLオブジェクト、トリガーおよびビュー定義に非ASCII文字が含まれている場合、DMU変換SQL生成操作は、データベース12.1.0.1.0リリースでORA-6502により失敗します(参照: Bug#16488610)。回避策として、変換SQL文を生成する前に、定義から非ASCII文字を削除し、データ・ディクショナリを再スキャンします。
クレンジング・エディタで、VARRAYまたはネストされた表を含むANYDATASET列を適切に表示できません(参照: Bug#11692435)。
このような列内のデータをクレンジングするには、報告された問題に応じて、問題のある値を更新するか、より大きい組込みコンテンツ・タイプを使用する必要があります。ANYDATASETおよびANYDATA OCIまたはPL/SQL API(あるいはその両方)を使用して、ANYDATASET値を分解、編集、再構築できます。
|
関連項目:
|
RDBMS Bug#5577093、#5983283および#6677390が原因で、変換方法「CREATE TABLE AS SELECTを使用してデータをコピー」によって変換されたLOBセグメントが記憶域属性RETENTIONを失い、記憶域属性PCTVERSIONを取得する場合があります。想定した属性をリストアするには、SQL文ALTER TABLE table_name MODIFY LOB (lob_name) (RETENTION)を使用します。
CHAR列からVARCHAR2データ型に移行するスケジュー済クレンジング・アクションが定義されている場合、変換後の長さがVARCHAR2データ型制限内に収まっていても、スキャン結果で型制限の問題が誤って報告される場合があります。変換後のデータ・サイズが、VARCHAR2データ型制限内に収まっていることをクレンジング・エディタで確認できる場合、回避策として、「問題のあるデータ変換を許可」列変換プロパティを「はい」に設定し、この列の変換実行可能性テストを省略します。この問題は、データベース11.2.0.3リリースで修正されています(参照: Bug#12868420)。
DMUサーバー側データ・スキャン機能の制限のため、データベースのキャラクタ・セットがマルチバイトで、データベース・バージョンが11.2.0.3以前の場合、DMUでは文字長セマンティクス列のキャラクタ・セットのタグ付が許可されません。タグ付が必要な場合、移行中、列をバイト長セマンティクスに一時的に切り替えることを検討してください(参照: Bug#13242969)。
クレンジング・エディタは、シフトセンシティブなキャラクタ・セットでタグ付けされた列内のデータの編集を現在サポートしていません。データ・ビューアを使用して、これらの列内のセルのデータ詳細を表示することは可能です(参照: Bug#14241789)。
データベース10.2リリースで、ソースのキャラクタ・セットがマルチバイトで、ターゲットのキャラクタ・セットがUTF8の場合、スキャン結果で'?'文字が無効と誤って報告されます。11gの11.2.0.3リリースまででは、スキャン中のデータに非ASCII文字に続いて'?'文字が含まれていると、ソースのキャラクタ・セットがマルチバイトで、ターゲット・キャラクタ・セットがUTF8の場合、誤って無効と報告されます。他に無効なデータが列にないことが確実な場合、この列の「問題のあるデータ変換を許可」変換プロパティを「はい」に設定し、この列の変換実行可能性テストを省略できます(参照: Bug#14530511)。
自分および適切な認可ユーザーのみがアクセスできるホスト・マシンにDMUをインストールしている場合を除き、DMUインストールおよびDMU構成ファイルを保護するために予防策を取る必要があります。これを行わない場合、ファイルへの未認可のアクセスにより、DMUを使用して接続するデータベースのセキュリティが損なわれる可能性があります。
DMUインストールでアーカイブ・ファイルを解凍した後、すべての解凍済ファイルおよびディレクトリが自分自身と他の認可されたオペレーティング・システム・ユーザーによってのみ書込み可能であることを確認します。DMUには、ファイル権限を自動的に設定できるインストーラは同梱されていません。未認可ユーザーからの書込み権限の削除は、DMUホストへのアクセス権を持つユーザーがDMUファイルを変更して、後からSYSDBA資格証明でDMUが起動されたときに任意のSQL文が実行される可能性があるため、非常に重要です。このようなSQL文はデータベース・セキュリティを損う可能性があります。
データベース接続の作成時、「パスワードの保存」チェック・ボックスを選択すると、指定したパスワードが、ユーザー・ディレクトリ内のcwallet.ssoという名前のパスワード・ファイルに不明瞭化されて保存されます。不明瞭化は元に戻せる操作なので、この機能は、本番データを含まないテスト・データベースへのパスワードに対してのみ、またはDMUが非常に保護の度合が高いホストにインストールされている場合にのみ使用してください。自分のみがパスワード・ファイルを読取り可能であるこを確認してください。
UNIXベースのプラットフォームでは、ファイルはディレクトリ$HOME/.dmu/にあります。Microsoft Windowsでは、ファイルはディレクトリ%APPDATA%\DMU\にあります。
このリリースのDMUでは、SYSDBA権限のあるデータベース・ユーザーを指定してデータベースに接続する必要があります。このユーザーには、DMUのリポジトリ・オブジェクトへの完全なアクセス権があります。DMUドキュメントに明示的に記載されている場合を除き、DMU表またはPL/SQLパッケージに対するいかなる権限もデータベース・ユーザーに付与しないでください。
