| Oracle® Database Migration Assistant for Unicodeガイド リリース2.0 E59465-03 |
|
 前 |
 次 |
この章では、データベース・キャラクタ・セットの移行プロセスについて説明します。まず、データベース・キャラクタ・セットの概要およびそれを移行する意味について説明します。また、移行プロセスに関連する基本的な問題と、これらのタスクに役立つツールについて説明します。
この章は次の項で構成されています。
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構成と呼ばれる不適切な構成になっている場合、アプリケーションによってデータベース内の文字データが、データベースに宣言されているキャラクタ・セットと異なるキャラクタ・セットで解釈される可能性があります。修復プロセスの目的は、データベース・キャラクタ・セット宣言をアプリケーションの予測と一致させることです。定義上、このような修復プロセスで文字コードの変換が行われることはありません。
キャラクタ・セット移行プロセスの重要な手順の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 (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スクリプトは、Database Character Set Scannerユーティリティに付属しています。このスクリプトにより、次の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グローバリゼーション・サポート・ガイド』を参照してください。 |
DMUには、インタフェースを介して移行プロセスを合理化する直覚的でユーザーフレンドリなGUIが備わっており、これによりワークロードを軽減し、すべての移行問題を確実に解決し、データ変換を適切かつ効率的に実行できます。
DMUの利点は次のとおりです。
ワークフローが順を追って説明されます。
DMUの大きな利点は、論理的なワークフローによってキャラクタ・セット移行プロセス全体が順を追って説明されることです。
特定の問題に対処するための推奨方法が示されます。
DMUは、データのスキャンやクレンジング中にエラーや障害などの特定の問題が発生したときに役立ちます。
データの選択的変換がサポートされています。
DMUを使用すると、表レベル、列レベルおよび行レベルで変換が必要なデータのみを変換できます。
進行状況モニターが提供されます。
DMUには、ステップの進行状況を表示するGUIが備わっています。
対話的な表示機能が提供されます。
DMUを使用すると、データを分析し、GUIで対話形式で結果を確認できます。また、GUIでデータそのものを確認して、特定された移行問題のあるデータを対話形式でクレンジングできます。
インライン変換専用にサポートされたツールが提供されます。
DMUを使用すると、Oracle Databaseでデータベースの内容のインライン変換がサポートされます。これは、パフォーマンスおよびセキュリティに関して、他の既存の変換方法よりも優れています。
変換ステップ中に、クレンジング・アクションを後で実行するようにスケジュールできます。
データ型移行などのクレンジング・アクションを延期すると、本番データベースおよびアプリケーションは、実際の停止期間に入るまでは影響を受けません。
このリリースのDatabase Migration Assistantには、変換できるデータベースに関するいくつかの制限事項があります。たとえば、ほとんどの場合、データ・ディクショナリに変換可能データの存在するデータベースは変換されません。エクスポート/インポート移行方法を使用する場合、これらの制限事項はありません。
次の各項では、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つの問題が発生する可能性があります。
特定のパーティション化キーが、そのキーが属するパーティションの下限と上限の範囲をソートしないことがあります。
パーティションの内部で境界値の順序と同じ順序の番号が付けられます。Unicodeへの変換時に境界値によってそのソート順序が変更された場合、内部の番号付けが無効になります。
一部のマルチバイト東アジア・キャラクタ・セットでは、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値の順序がレガシー・キャラクタ・セットの順序と異なることがよくあります。
新しいマルチバイト・データベース・キャラクタ・セットを最大限に活用するために、マルチバイト・テキストが正しく処理されるようにシングルバイト・アプリケーションを適応させる必要があることがあります。これは軽微な変更ではありません。
通常、前述のアプリケーション問題にすべて手動で対処する必要があります。アプリケーション開発者は、移行後の本番データベースのテスト・コピーを使用してアプリケーションを確認およびテストする必要があります。
