キャラクタ・セットの移行に関するベスト・プラクティス

キャラクタ・セットの移行に関する

ベスト・プラクティス

オラクル・ホワイト・ペーパー

キャラクタ・セットの移行に関する

ベスト・プラクティス

概要 ... 3

Oracle Database 10g での移行のための新機能 ... 3

移行の理由 ... 3

新規キャラクタ・セットの選択... 4

Unicode が最適な理由... 6

Unicode データ型の使用について ... 6

移行関連の検討事項 ... 7

変換前の作業 ... 8

データベース・キャラクタ・セット・スキャナ ... 8

データの切捨て... 9

データ消失... 9

ポストスキャン作業、変換前作業... 10

例外の処理... 10

切捨て ... 10

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

無効なデータ例外が発生する理由 ... 11

US7ASCII データベースの特殊な問題 ... 13

変換と変換後の作業 ... 14

移行方法... 14

Export/Import ユーティリティ ... 14

CSALTER スクリプトの使用... 15

Export および Import ユーティリティと

CSALTER スクリプトの組合せ... 15

Oracle Migration サービス... 16

バックアップの実行... 16

十分な領域割当ての確保... 16

リハーサルの実行... 16

変換および変換後の妥当性チェックの実行 ... 16

事例... 17

1)

追加言語をサポートする US7ASCII データベースの移行 .... 17

2)

ユーロ記号に対応する WE8ISO8859P1 から

WE8ISO8859P15 への移行 ... 18

3)

アジア系言語に対応する西欧キャラクタ・セットから

AL32UTF8 への移行 ... 18

4)

簡体字/繁体字中国語サポートが必要な顧客 ... 19

結論 ... 19

キャラクタ・セットの移行に関する

ベスト・プラクティス

概要

Oracle9i またはそれ以前のデータベース・リリースへの移行に関しては、このド キュメントの旧版である『Database Character Set Migration in Oracle9i』を参照して ください。データベース・キャラクタ・セット間の移行には、適切な手段とツー ルが必要です。このドキュメントは、多数の顧客の成功事例に基づくデータベー ス・キャラクタ・セットの移行に関するベスト・プラクティスの要点を提供しま す。これらの方法に従い、環境における最適な手段を判断することで、リスクお よび停止時間を最小限に抑えることができます。Oracle では、非常に大規模かつ 複雑な環境に対しても、停止時間を最小限に抑えると同時に基幹業務データの安 全な移行を支援するコンサルティング・サービスを提供しています。このドキュ メントは、Unicode への移行についても説明します。今日では、多くの顧客にとっ て、グローバル・ビジネスのサポートに Unicode が不可欠です。

Oracle Database 10g での移行のための新機能

CSALTER スクリプトは、特殊文字セットの移行のための DBA ツールであり、 Character Set Scanner Utilities の一部として提供されます。すでに廃止された ALTER DATABASE CHARACTER SET コマンド同様、CSALTER は、新規データ ベース・キャラクタ・セットの適切なサブセットである既存キャラクタ・セット からの移行に使用されます。このドキュメントでは、CSALTER スクリプトの使用 方法について詳しく説明します。

移行の理由

データベース・キャラクタ・セットの移行は、通常、新しい言語のサポートに必 要です。企業業務の国際化およびグローバルな顧客に対するサービスの拡張にと もない、既存のデータベース・キャラクタ・セット以外の言語でもデータ記憶域 のサポートが必要になります。これまで多くのレガシー・システムでは、当初は 1 つまたは 2∼3 の言語のみをサポートしていたため、最初に含まれているキャラ クタ・セットでサポート可能な言語は非常に限定されていました。たとえば、米 国で英語のデータをサポートするには、ASCII と呼ばれる 7 ビット・キャラクタ・ セットで十分でした。これに対し、欧州では、多様な 8 ビット欧州文字セットに より、英語および欧州言語の特定のサブセットに対応していました。アジアでは、 特定のアジア系言語と英語に対応できるマルチバイト・キャラクタ・セットが使 用されていました。このような選択は、当初の要件を満たす、経済性と性能にお いて最適な組合せでした。ただし、現在ではこのような選択はグローバル市場の

サポートにとっては障害であり、キャラクタ・セットの移行が必要になっていま す。 新しい言語のサポートのみがキャラクタ・セットの移行の唯一の動機ではありま せん。全世界におけるユーロ記号の必要性など、文化的変化も特殊文字や特殊文 字セットのサポートの必要性を促進しています。操作環境の変化も、キャラクタ・ セットの移行が必要な決定要因になることがあります。異なるキャラクタ・セッ トおよびデータベース・キャラクタ・セットとの非互換キャラクタ・セットを扱 う環境との相互運用性は、移行の必要性を余儀なくさせます。例としては、主に Unicode ベースの Java クライアントに公開されるデータベース、世界中のユーザー がデータベース・ストレージに文字データを提供する World Wide Web に公開され るデータベースなどがあります。ASCII データベースのレパートリ以外の多くの 文字（C “ ” ~）をサポートする、コード・ページ 1252 を使用している英語版 Windows のクライアントも、キャラクタ・セットの移行が必要となります。 もう 1 つの理由として、異なるキャラクタ・セット内のデータストアを整理統合 する手段として移行が必要な場合が考えられます。1 例として、2 つのデータスト ア、たとえば、フランス語データが入ったデータストアとロシア語データが入っ たデータストアを、両方の言語を表現できるキャラクタ・セットを持つデータス トアに統合する場合があります。

新規キャラクタ・セットの選択

多少のキャラクタ・セットで新規の言語要件を満たすことができますが、新規の データベース・キャラクタ・セットを選択する場合は、将来的な言語要件も同時 に考慮が必要です。追加の言語のサポートを予定している場合は、何度も移行を 行わずにすむよう、必要となるキャラクタ・セットを初めから用意してください。 データベース・キャラクタ・セットは独自のグローバリゼーション・アーキテク チャを所有しているため、オペレーティング・システムとは無関係です。たとえ ば英語版 Windows オペレーティング・システム上でも、日本語キャラクタ・セッ トでデータベースを作成して稼働できます。ただし、クライアント・オペレーティ ング・システムがデータベースにアクセスするには、クライアント・オペレーティ ング・システムが適切なフォントと入力メソッドでデータベース・キャラクタ・ セットのサポートが必要です。たとえば、英語版 Windows オペレーティング・シ ステム上では、日本語フォントと入力メソッドをまずインストールしないかぎり、 日本語データを直接挿入したり取得ができません。日本語データを挿入および取 得する別の方法として、リモートで日本語オペレーティング・システムを使用し たデータベース・サーバーにアクセスする方法があります。クライアント・オペ レーティング・システム上のキャラクタ・セットと異なるデータベース・キャラ クタ・セットを使用した場合、Oracle Database がオペレーティング・システムの キャラクタ・セットをデータベース・キャラクタ・セットに変換する必要があり ます。 最高の成果を得るには、キャラクタ・セット変換を避け、必要な言語に対し最も 効率のよいエンコーディングを使用するキャラクタ・セットを選択してください。 シングルバイト・キャラクタ・セットは、マルチバイト・キャラクタ・セットに 比べパフォーマンスが優れており、領域要件もより効率的です。ただし、シング

ルバイト・キャラクタ・セットがサポートできる言語数は限定されるため、この ようなパフォーマンスに関する考慮点は最優先事項となりません。ほとんどの環 境において、複数のクライアントが異なるコード・ページを使用して同一のデー タベースにアクセスするため、キャラクタ・セットの変換を避けることは不可能 かもしれません。 データベースにアクセスするすべてのクライアント・オペレーティング・システ ム環境およびアプリケーションを考慮したうえで、正しいキャラクタ・セットを 選択してください。データベース・キャラクタ・セットに等価の文字がない場合、 データ消失が発生する場合があります。たとえば、キャラクタ・セット A を持つ クライアントからキャラクタ・セット B を持つデータベースに変換する場合、宛 先のキャラクタ・セット B は A のサブセットである必要があります。A のレパー トリからの文字のサブセットでサブセット B のみが使用される場合は、キャラク タ・セット A は B の真のサブセットでなくてもすべてのデータが変換可能だと考 えられます。WE8MSWIN1252 と WE8ISO8859P1 のように、クライアントとデー タベースのキャラクタ・セットの関係が非常に密接な場合にこれが当てはまりま す。ユーロ記号のような文字が必要ない場合であれば、WE8MSWIN1252 から WE8ISO8859P1 への変換はデータ消失なしに可能になります。Oracle では、キャ ラクタ・セット B 内にない任意の文字を、疑問符号としてまたは言語学的に相関 する文字として使用される置換文字に変換します。たとえば ä（ウムラウト付きの a）は a に変換されます。分散環境の場合は、データ消失を避けるために類似のキャ ラクタ・レパートリを持つキャラクタ・セットの使用を検討してください。 すべてのクライアント・アプリケーションが同じキャラクタ・セットを使用する 場合、データベース・キャラクタ・セット用にはそのキャラクタ・セットまたは そのスーパーセットが通常最適な選択です。クライアント・アプリケーションが 異なるキャラクタ・セットを使用している場合、データベース・キャラクタ・セッ トはすべてのクライアント・キャラクタ・セットのスーパーセットである必要が あります。これにより、クライアント・キャラクタ・セットからデータベース・ キャラクタ・セットへの変換時にすべての文字が使用できることが保証されます。 すなわち、キャラクタ・セットの選択には、次の要因を組み合せた適切なキャラ クタ・セットの判断が必要です。 1) 現在および今後の言語要件を満たすキャラクタ・セットの選択。 2) データベース・キャラクタ・セットは、データベースにアクセスするすべ てのクライアント・オペレーティング・システムの集合的ネイティブ・キャ ラクタ・セットのスーパーセットまたは等価文字を含むセットの必要があ る。 3) データベース・キャラクタ・セットは、データベースにアクセスするすべ てのクライアント・アプリケーションの集合的ネイティブ・キャラクタ・ セットのスーパーセットまたは等価文字を含むセットの必要がある。

Unicode が最適な理由

多くの場合、多言語データのサポートとは、Unicode の使用を意味します。Unicode はユニバーサル・エンコードされたキャラクタ・セットであり、ユーザーが任意 の言語で情報を保存できるようにしたものです。Unicode はプラットフォーム、プ ログラム Unicode および言語に関係なく、すべての文字に対して固有なコード・ ポイントを提供します。Unicode により、世界中のほとんどの現代言語および文字 を簡単にエンコードできます。これにより、1 つのデータベース内で多言語を開 発、配置およびホスティングできます。 Unicode は急速に新しいテクノロジ向けの事実上の業界標準キャラクタ・セットに なりつつあり、ソフトウェアの新規リリースでは Unicode が積極的にサポートさ れています。今後の世界規模でのデータのやりとりに対する企業側の準備におい て、キャラクタ・セットの移行の大部分がレガシー・キャラクタ・セットから Unicode への移行であることは偶然ではありません。 Unicode は、Oracle がサポートしているほとんどのキャラクタ・セットの文字レ パートリ・レベルのスーパーセットであり、整理統合化やグローバル化の準備に おいて、あらゆるキャラクタ・セット移行の理想的なターゲットとなります。 パフォーマンスに関して、Oracle Database 10g に実装された Unicode データベース は、シングル・バイト・データベースよりも最大わずか 10%の追加オーバーヘッ ドで動作します。SQL 文字列処理機能が集中的に使用される環境では、パフォー マンスは大きい影響を受けます。 Unicode は特定の言語の組合せには必須の要件です。キャラクタ・セットは通常、 ラテン文字やキリル文字などの特定の筆記文字から発生した言語のサブセットに 対応します。異なる筆記文字（言語によって異なる文字表現）から言語構成（組 合せ）を採用する場合は、通常、Unicode が必要になります。 詳細は、 1) 次のホワイト・ペーパーを参照してください。『グローバリゼーション・ サポート Oracle Unicode データベース・サポート』 http://otn.oracle.co.jp/products/database/oracle10g/index.html

Unicode データ型の使用について

すべてのデータを Unicode としてデータベースに保存するかわりに、SQL NCHAR データ型を使用する方法もあります。Unicode 文字はデータベース・キャラクタ・ セットの設定に関係なく、これらのデータ型の列に保存できます。NCHAR デー タ型は Oracle9i で再定義され、以降は排他的に Unicode データ型になりました。 つまり、Unicode エンコーディングのみでデータを保存するようになりました。 National Character Set は、次のエンコーディングの UTF-16 と1 _{UTF-8 をサポート} しています。

1) AL16UTF16（デフォルト）

2) UTF8

かぎられた数の列内の多言語データのみをサポートする場合は、SQL NCHAR データ型の列を既存の表または新規の表に追加して多言語をサポートできます。 ALTER TABLE MODIFY COLUMN コマンドを使用すれば、特定の列を SQL CHAR データ型から SQL NCHAR データ型に簡単に移行できます。

例:

ALTER TABLE emp MODIFY (ename NVARCHAR2(10));

SQL NCHAR データ型は、他にも次に示す多数のメリットを提供します。 1) 顧客に販売されるパッケージ・アプリケーションを構築する場合、NCHAR データ型が常に Unicode であることの確信。 2) データベース環境をネイティブ UCS-2 または UTF-16 アプリケーション環 境に適合できます。 3) 最高のパフォーマンスを得ることができます。既存のデータベース・キャ ラクタ・セットがシングル・バイトの場合は、それを SQL NCHAR データ 型での拡張より、データベース全体を Unicode に移行するよりも高いパ フォーマンスが得られます。 SQL NCHAR とその他のデータ型およびキャラクタ・セマンティクスとの相互運 用性が強化されたため、NCHAR をサポートするアプリケーションの移行も簡素 化されます。NCHAR とその他のデータ型とのインターオペレーションが必要な 場合、ユーザーは明示的または暗黙的な変換を適用できます。暗黙的および明示 的変換により、ユーザーは NCHAR データを CHAR データと同じ方法で保存、検 索および処理できます。Oracle は、NCHAR データ型とその他のデータ型（DATE、 NUMBER、ROWID、RAW、CLOB など）の間だけでなく、NCHAR データ型と CHAR データ型の間でも暗黙的変換をサポートしています。暗黙的変換は、異な るデータ型の間でインターオペレーションが起きた場合、または引数の型が関数 の公式定義と異なる場合に必要です。明示的な変換は比較的制御可能です。ユー ザーは変換の方向を決定できます。Oracle は次のような広範な変換関数を提供し ています。

TO_NCHAR(), TO_CHAR(), TO_CLOB(), TO_NCLOB(), TO_NUMBER(), TO_DATE() UNISTR(), ASCIISTR(), ROWIDTONCHAR(), CHARTOROWID() 詳細は、 1) 次のホワイト・ペーパーを参照してください。『多言語データベース/ア プリケーションを目的とした Unicode データ型への移行』 http://otn.oracle.co.jp/products/database/oracle10g/index.html

移行関連の検討事項

データベースの移行を決定した後、IT 部門には他にもいくつかの主要な検討事項 が残ります。 1) 移行処理中の停止時間をできるかぎり短くする必要があります。つまりこ れは移行を最小時間内で実施し、問題が発生した場合には緊急時対策計画 の実行を意味します。許容できる停止時間は、ミッション・クリティカル

なアプリケーションについては数時間、一般的なデータ・ストアについて は数日間です。 2) データの内容により、移行実施時のデータ消失は重大な問題にもなります。 移行後のデータは通常、移行前のデータとセマンティックにおいて等価の 必要があります。これは、なんらかの方法で文字データを参照する数値 データにも当てはまります。データ消失の詳細は、「無効なデータ例外が 発生する理由」の項を参照してください。移行が成功するようにリソース を割り当てるため、移行後のイメージのサイズを見積もる必要があります。 マルチバイト・キャラクタ・セットへの移行は、ほとんどの場合にサイズ が増加するため、データ・サイズの拡大を考慮します。 3) 新規キャラクタ・セットでデータベースを稼働する場合のパフォーマンス も考慮事項です。通常、類似のプロパティのキャラクタ・セットは同等の パフォーマンスを提供します。そのため、シングルバイト・キャラクタ・ セット間の切替え、またはダブルバイト・キャラクタ・セット間の切替え は、パフォーマンスに影響しません。シングル・バイトからマルチバイト へのキャラクタ・セットの切替えは、ある程度パフォーマンスに影響しま す。

変換前の作業

移行を始める前に、変換作業の範囲を理解しておくことが重要です。変換に伴う 潜在的な問題をチェックするためと実際にどれだけのデータの変換が必要になる かを評価するため、データ分析を行います。

データベース・キャラクタ・セット・スキャナ

使用する移行方法に関係なく、移行の確実な成功には最初にソース・データをプ リスキャンすることが重要です。Database Character Set Scanner は、すべての文字 データ・フィールドまたは選択済データをスキャンしてデータベースの新規デー タベース・キャラクタ・セットへの移行に伴う問題を事前に識別する強力かつ洗 練されたユーティリティです。スキャン自体は既存データから新規キャラクタ・ セットへの変換をシミュレーションし、最後にデータベース・スキャンのサマ リー・レポートを出力します。このレポートに、データベースを新規キャラクタ・ セットに変換するために必要な作業の範囲が示されます。また最適なデータベー ス・キャラクタ・セット移行方法の判断に役立ちます。スキャン結果から各デー タ・セルを 4 つのカテゴリに分類ができます。 不変データとは、ソース・キャラクタ・セットからターゲットへの変換にバイナ リ表現が変わらないデータです。たとえば、ソース・キャラクタ・セットでは文 字 A は 16 進の 41 であり、ターゲット・キャラクタ・セットでも文字 A は 16 進 の 41 としてエンコーディングされます。したがって A はソースとターゲット間 で不変です。通常使用が許可される Oracle Database 10g 内で CSALTER スクリプ トを安全に使用するには、すべてのデータが不変の必要があります。

変換可能データとは、ソース・キャラクタ・セットからターゲットへの変換パス が存在するデータです。たとえば、ソース・キャラクタ・セットでは文字 A は 16 進の 41 ですが、ターゲット・キャラクタ・セットでは文字 A は 16 進の 90 とし

てエンコーディングされています。エクスポートまたはインポート・ユーティリ ティの使用前に、潜在的な切捨てなしにすべてのデータが変換可能カテゴリまた は不変カテゴリに分類の必要があります。 切捨てとは、変換が行われ、結果として生じるデータが列定義に適合しない場合 を意味します。たとえば、シングル・バイトの西欧キャラクタ・セットから Unicode への移行時、アクセント記号付き文字は 1 バイトから 2 バイトへ拡張されるため、 列の拡張が必要な場合があります。 データ消失とは、ターゲット・キャラクタ・セットへの変換パスが存在しない場 合、またはラウンドトリップ変換がオリジナルと異なる場合です。たとえば、C は WE8MSWIN1252 では 16 進の 80 で表現されますが、WE8ISO8859P1（Latin 1） のレパートリの一部ではありません。切捨てとデータ消失の場合は集合的に例外 と呼ばれます。

データの切捨て

Database Character Set Scanner は、変換後のデータが現在の列サイズに収まるかを 調べます。Scanner は、サイズ変更が必要な列を正確に示し、列内の最初の 30 バ イトを表示します。データの修正または列サイズの更新に失敗すると、Export お よび Import ユーティリティの処理中にデータ行全体のデータ消失を引き起こす可 能性があります。データの切捨ては、移行ターゲットがマルチバイト・キャラク タ・セットであれば、どのようなケースにおいても考慮が必要です。列定義は通 常、バイト・セマンティクスで列挙されます。VARCHAR (1)として定義される列 は、シングル・バイト・エンコーディング形式で 1 つの文字を収容しますが、1 つのマルチバイト・キャラクタの収容には不十分な可能性があります。たとえば、 Unicode UTF-8 の 1 つのシングル・バイト文字は 1∼4 バイトの記憶域を必要とし ます。 UTF-8 への移行時の切捨ての可能性は、保存される言語に依存することがありま す。英語データのみが保存されるデータベースの場合、かぎられた記号文字のみ がシングル・バイト・エンコーディングから UTF-8 に拡張されるため、セル切捨 ての可能性はほとんどありません。西欧言語には、通常 UTF-8 で 2 バイトへ拡張 する特殊記号が多く含まれます。アジア系言語はレガシー（2 バイト）キャラク タ・セットから UTF-8（通常は 3 バイト）への移行時に拡張される文字が頻出す るため、切捨ての可能性が最も高くなります。 西から東へ増大する切り捨て –English [£ ™ ©] (1%) –European [ä ß ñ] (10%)

データ消失

Export/Import ユーティリティは、元のデータベース・キャラクタ・セットから新 規のデータベース・キャラクタ・セットにデータを変換できます。ただし、キャ ラクタ・セット変換は、データ消失またはデータ破損を引き起こすことがありま す。ソース・データがクリーンであり、各文字がターゲットのキャラクタ・セッ

トにおいて同等の表現を所有していることの確認が必要です。たとえば、キャラ クタ・セット A からキャラクタ・セット B へ移行する場合、宛先のキャラクタ・ セット B はキャラクタ・セット A のスーパーセットの必要があります。宛先のキャ ラクタ・セット B は、キャラクタ・セット A 内のすべての文字の定義を含んでい る場合はスーパーセットです。キャラクタ・セット B にない文字は、置換文字（通 常?または¿として指定される）または存在しない文字と相関する文字に変換され ます。たとえば ä（ウムラウト付きの a）は a に変換されます。置換文字はターゲッ ト・キャラクタ・セットによって定義されます。データ消失は、次の 3 つのカテ ゴリに分類できます。 1) ソースでのデータ消失は、ソース・キャラクタ・セット内で値が文字表現 を持たないため、ターゲット・キャラクタ・セットへのマッピングが存在 しない場合です。これは不適切な文字列処理によるデータ破損の結果とし て起こる場合があります。また、より一般的には、なんらかの形式の PASS-THRU シナリオが発生し、データが変換されていない状態でその他 のキャラクタ・セットから入ってきた結果として起こります。PASS-THRU は、予測できない時もありますが、故意に誤用される場合もあります。そ のようなデータの場合、キャラクタ・セットおよび言語分析を適用し、デー タのコンテキストにおいて予測される文字の判別を試みる必要がありま す。 2) ターゲットでのデータ消失は、文字が存在しないため、有効なソース文字 からターゲット・エンコーディングへの変換パスが存在しない場合です。 3) ラウンドトリップでのデータ消失は、ソース・キャラクタ・セットからター ゲット・キャラクタ・セットへのマッピングは存在しますが、ソース・キャ ラクタ・セットを指す同じコードを変換するとオリジナルとは別の文字を 生成する場合です。 データ消失の詳細は、次の「無効なデータ例外が発生する理由」の項を参照して ください。

ポストスキャン作業、変換前作業

Database Character Set Scanner の実行後、予想外の問題に対処し、適切な移行処理 を選択します。

例外の処理

まず、例外カテゴリの 1 つに分類されるこれらのデータ・セルを検討し、対処方 法を決定します。

切捨て

切捨ての場合、ソースにおいてターゲットでの拡張を必要とする予期しない不正 のデータがないかぎり、ユーザーは列を拡張するのが普通です。この場合、不正 データを編集する方法もあります。列のサイズを変更する場合は、結果として発 生する最大のセルを保存できる拡張、またはターゲット・キャラクタ・セットの 内容に応じた拡張かを決定します。たとえば、8859-1 の CHAR(1)の列を UTF-8 に

移行するには、後で補充文字が使用されることを想定して常に 1 文字を確実に保 存できるよう、CHAR(4)に自動的な拡張もできます。データ型の物理的制限を超 える場合は、保存可能なデータに対して制限を課す必要があります。

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

Oracle9i に採用された長さセマンティクスは、マルチバイト変換用に特に UTF-8 への拡張が必要な列のサイズを再定義する代替方法を提供します。長さセマン ティクスは、可変幅のマルチバイト文字列に関する文字列の処理と記憶要件の定 義の両方に便利です。シングルバイト・キャラクタ・セットでは、文字列内のバ イト数と文字数は通常同じです。マルチバイト・キャラクタ・セットでは、文字 またはコード単位は 1 つまたは複数のバイトで構成されます。列長のバイト数計 算はバイト・セマンティクスと呼ばれ、列長の文字数計算はキャラクタ・セマン ティクスと呼ばれます。 たとえば、8 ビットの西欧キャラクタ・セットから Unicode データベース （AL32UTF8）に移行する場合、発音区別記号付きの文字が入った既存の VARCHAR2 列があるとします。スキャンにより、バイト・セマンティクス・マル チバイト・データベースへの移行時に拡張を保存するため、これらの列のサイズ 変更が必要なことがわかります。さらに、アジア言語のデータをシステムに追加 の予定には、移行後の新しいデータベースでのキャラクタ・セマンティクスの使 用が最適なソリューションとなります。特に、キャラクタ・セマンティクスを使 用しないと列の大部分の拡張が必要となり、またこれらの列に保存される情報タ イプの要件が不変の場合は効果的です。 NLS_LENGTH_SEMANTICS 初期化パラメータは、列の作成時に、列の文字デー タ型がバイト・セマンティクスまたはキャラクタ・セマンティクスのどちらかを 決定します。バイト・セマンティクスは、データベース・キャラクタ・セットの 場合のデフォルトです。文字長セマンティクスは、NCHAR データ型の場合のデ フォルトであり、唯一使用可能な長さセマンティクスです。NCHAR 定義に対し て、ユーザーは CHAR または BYTE 修飾子を指定できません。

無効なデータ例外が発生する理由

データ消失が発生した場合、原因の分析が必要です。例外の解決は、データ・ク レンジングと呼ばれます。無効なデータは通常、クライアント上で NLS_LANG パ ラメータが正しく設定されず適切に変換されないため、データベース内で発生し ます。NLS_LANG 値は、クライアント・オペレーティング・システムのコード・ ページを示す必要があります。たとえば英語版 Windows 環境では、オペレーティ ング・システムのコード・ページは 1252 です。これは Oracle キャラクタ・セット WE8MSWIN1252 に対応します。NLS_LANG パラメータが正しく設定されている と、データベースはクライアント・オペレーティング・システムからの入力デー タを自動的に変換します。NLS_LANG パラメータが正しく設定されていない場合 は、データベースへのデータは正しく変換されません。このような不正の変換に は 2 つの形式があります。

1) 第 1 のケースは、NLS_LANG 設定がクライアントの OPERATING SYSTEM コード・ページ、およびデータベース・キャラクタ・セットとも異なる場 合です。

− 変換処理中、クライアント・コード・ページの NLS_LANG キャラク タ・セット内に、相当する値を持たない文字の存在があります。この ような文字にはデータベース・キャラクタ・セットへのマッピングが ないため、置換文字が使用されます。 − 変換処理中、クライアント・コード・ページで等価のエンコーディン グを持つ文字が、環境変数 NLS_LANG キャラクタ・セット内では別 の値を持つ場合があります。たとえば、クライアント・コード・ペー ジでは、文字 A は 16 進の 61 とエンコーディングされていますが、 NLS_LANG キャラクタ・セットでは 061 は%記号です。この場合、元 の文字は A を意味していましたが、不正に変換され、データはデータ ベース・キャラクタ・セット内の%記号のエンコーディングにマッピ ングされます。図 1 を参照してください。 図 1 2) 第 2 のケースは、環境変数 NLS_LANG がクライアント OPERATING SYSTEM コード・ページとは異なりますが、データベース・キャラクタ・ セットとは一致する場合です。これは、顧客がクライアントの NLS_LANG をクライアント OPERATING SYSTEM のコード・ページではなく、デー タベース・キャラクタ・セットと等価に設定した場合に起こります。環境 変数 NLS_LANG がデータベース・キャラクタ・セットに一致した場合、 Oracle は、パフォーマンスの最適化に変換しません。これは、PASS-THRU と呼ばれます。変換されていないデータは、別の文字にマッピングされる 等価のエンコーディングをデータベース・キャラクタ・セット内に持つ結 果となり、事実上ガベージ・データの記憶域を作成することになります。 このケースには、データが表示されるときデータベースからクライアント に戻されても変換は行われないため、また環境変数 NLS_LANG の間違っ

た設定のため、クライアント・オペレーティング・システムの観点からデー タには何の問題もないように見えるという重大な側面があります。 PASS-THRU シナリオでは、データベースに保存されている不正な変換済 データをマスクします。 図 2

US7ASCII データベースの特殊な問題

今日、ほとんどの顧客は、レガシーUS7ASCII データベースから英語以外の様々な 言語をサポートでき、8 ビットまたはマルチバイト・データに通常対応している クライアント・オペレーティング・システムやアプリケーションからのデータを サポートできる、より豊富な文字レパートリを持つキャラクタ・セットへの移行 を必要と感じています。真のサブセット/スーパーセット・リレーションシップに より、Oracle9i での ALTER DATABASE CHARACTER SET コマンド、および Oracle Database 10g での CSALTER スクリプトの使用が可能になり、データがクリーンと みなされるため、US7ASCII から多数の ASCII ベース・キャラクタ・セットへの 移行手順をより簡素化できます。ただし、多くの場合、US7ASCII データベースに は不正なデータや無効なデータが含まれます。この不適切なデータの原因となる 一般的なケースもまた 2 つあります。 1) 前述の第 1 番目の問題は、PASS-THRU シナリオと呼ばれます。データベー スにアクセスするクライアント・オペレーティング・システムの環境変数 NLS_LANG が、誤って US7ASCII に設定されています。これは、8 ビット およびマルチバイト・データをデータベースに保存するため意図的なこと がありますが、特別な専門知識や処置なしには簡単に解決できません。そ の場合は、Oracle Migration サービスを検討してください。通常は、無意識 に誤って NLS_LANG が設定され、いくつかの 8 ビット・データは、本来

7 ビットのデータベースに紛れ込みます。このケースについては事例 1 を 参照してください。 2) 2 番目のケースは、クライアント環境変数 NLS_LANG が正しくセットさ れている場合です。着信文字が異なるコーディングの可能性があることを NLS_LANG が示した場合、Oracle は通常、必要に応じてクライアント・ キャラクタ・セットからデータベース・キャラクタ・セットへ自動的に変 換します。US7ASCII データベースは 7 ビット文字のみをサポートしてい るため、7 ビット文字のみを想定しています。したがって、進入する 8 ビッ ト・データはすべて置換文字に変換されます。可能なかぎり言語的に相関 する 7 ビット文字に変換されますが、それ以外の場合は疑問符が使用され ます。たとえば、7 ビット文字の a は言語的に 8 ビット文字の ä（ウムラ ウト付き）と相関しています。

変換と変換後の作業

移行方法

Oracle は、業務に不可欠なデータ移行の安全性を最大限確保すると同時に、停止 時間を最小限に抑えるためコマンド、ユーティリティおよびサービスを提供して います。使用される移行方法に関係なく、前述したとおり、Character Set Migration Utility を使用して最初にデータをプリスキャンすることが重要です。

Export/Import ユーティリティ

Export/Import ユーティリティを使用すると、ハードウェアおよびソフトウェアの 構成が異なるプラットフォーム上にデータ・オブジェクトが存在する場合でも、 Oracle Database 間で、すべてのデータ・オブジェクトまたは選択した一部のデー タ・オブジェクトを簡単に転送できます。Oracle Database に対して Export ユーティ リティを実行すると、オブジェクト（たとえば表など）の抽出後に関連オブジェ クト（索引、コメント、および権限付与など）があればデータと一緒に抽出され ます。抽出されたデータは、Export ダンプ・ファイルに書き込まれます。Export ダンプ・ファイルを読めるのは、Oracle Import ユーティリティのみです。Import ユーティリティは、Export ダンプ・ファイルからオブジェクト定義と表データを 読み取ります。データ・オブジェクトを Oracle Database に挿入します。

Oracle9i 以降、Export ユーティリティは必ず Unicode データを含むユーザー・デー

タをサーバーのキャラクタ・セットにエクスポートします。キャラクタ・セット はデータベース作成時に指定されます。Oracle8i では、Export ユーティリティは Export サーバーの NLS_LANG に基づいて、ユーザー・データをエクスポートしま す。Import ユーティリティは、データを Import サーバーのキャラクタ・セットに 自動的に変換します。エクスポート・ファイルのキャラクタ・セットが、Import サーバーのキャラクタ・セットのサブセットになるよう注意してください。マル チバイト・キャラクタ・セットから作成されるエクスポート・ファイルには制限 があります。Export および Import ユーティリティの詳細は、『Oracle Database

ユーティリティ』を参照してください。Oracle Streams の機能を使用すれば、Export

および Import ユーティリティは、わずかな停止時間で、または停止時間なしに実 施できます。詳細は、『Oracle Streams 概要および管理』を参照してください。

CSALTER スクリプトの使用

CSALTER スクリプトは、特殊文字セットの移行のための DBA ツールであり、 Character Set Scanner Utilities の一部として提供されます。CSALTER スクリプトは、 キャラクタ・セットを移行する最も簡単な方法ですが、特別な状況でのみ使用で きます。データベース・キャラクタ・セット自体とそのスキーマ・データ全部が 新規キャラクタ・セットの厳密なサブセットの必要があります。次の条件が満た される場合、新規キャラクタ・セットは現在のキャラクタ・セットの厳密なスー パーセットです。 1) 現在のキャラクタ・セットのすべての文字が、新しいキャラクタ・セット で使用可能な場合。 2) 現在のキャラクタ・セットのすべての文字が新しいキャラクタ・セットで 同じコード・ポイント値を持つ場合。たとえば、多くのキャラクタ・セッ トは US7ASCII の厳密なスーパーセットです。 厳密なスーパーセット基準に従い、CSALTER によりメタデータのみが新規キャラ クタ・セットに変換されます。ただし、次の例外があります。CSALTER スクリプ トは、データ・ディクショナリの CLOB 列のデータおよび Oracle が作成した Sample Schema でのみ変換します。ユーザーが作成した CLOB 列は、別の対処が必要な場 合もあります。Oracle9i 以降、データ・ディクショナリと Sample Schema 内のフィー ルドの一部は、CLOB 列に保存されるようになりました。顧客による CLOB フィー ルドへのデータ保存も可能です。データベース・キャラクタ・セットがマルチバ イトの場合、CLOB データは UCS-2 データと互換性のある形式で保存されます。 データベース・キャラクタ・セットがシングル・バイトの場合、CLOB データは データベース・キャラクタ・セットを使用して保存されます。CSALTER スクリプ トは、Oracle が作成した Sample Schema およびデータ・ディクショナリの CLOB 列のデータのみ変換するため、CSALTER スクリプトの実行前に、作成済みのその 他の CLOB 列をまずエクスポートし、その後でスキーマからの削除が必要となり ます。

Export および Import ユーティリティと CSALTER スクリプトの組合せ

CSALTER スクリプトは、Oracle が作成した Sample Schema およびデータ・ディク ショナリ内の CLOB 列以外のデータ変換を行わないため、最も高速な移行方法の 1 つです。移行対象のソース・キャラクタ・セットのデータの大部分は、ターゲッ ト・キャラクタ・セットの厳密なサブセットです。しかし、非不変データ（変換 可能データ）が多少でも存在する場合は、CSALTER スクリプトの使用は妨げられ ます。大規模データベースの場合、全体 Export および Import ユーティリティの実 行には時間がかかり大量のリソースを消費するため、ハイブリッド・ソリューショ ンを使用できます。基本的には、まず小量の変換可能データがダンプ・ファイル にエクスポートされ、ソース・データベースから取り除かれるため、CSALTER スクリプトの実行が可能になります。次に、Import ユーティリティにより、残り のデータが入ったダンプ・ファイルがターゲット・データベースの新規キャラク タ・セットに変換されます。この実施に適したケースと方法を示した事例は、後 半の「事例 3」を参照してください。CSALTER スクリプトの使用の詳細は、『Oracle Database グローバリゼーション・サポート・ガイド』を参照してください。

Oracle Migration サービス

キャラクタ・セットの移行には、通常、1 つのキャラクタ・セットのデータベー スから他のキャラクタ・セットのデータベースにデータをアンロードする必要が あり、その間にキャラクタ・セットの変換が行われます。その処理には時間がか かり、完全な移行の場合は実質的に最初からデータベースの構築が必要です。そ の間、データベースへのアクセスは許可されません。また、アンロードされたデー タを、新しいインスタンスのロード前に、第 2 のデータストアに保存が必要な場 合もあります。1 テラバイトのデータベースの場合、移行の実施には 3 テラバイ ト以上が推奨されます。Oracle Migration サービスは、適切な移行に必要な時間と リソースを最小限にするツールと専門知識を提供します。コンサルタントは潜在 するデータ例外を見極め、データを浄化し、インライン移行のための特別なユー ティリティを実行できます。

バックアップの実行

この段階において、ソース・データのスキャンと準備が完了し、変換の移行方針 が選択されます。変換の直前に、本番データベースのバックアップは不可欠です。 最後のスキャン以降にデータが更新されている場合は、Database Character Set Scanner の再実行が必要です。

十分な領域割当ての確保

シングル・バイトからマルチバイト・システムへ移行する場合、新規データベー スでこれまで以上の記憶域が必要な可能性があります。データ拡張の規模は、ソー ス・キャラクタ・セットとターゲット・キャラクタ・セット間のバイト比率に基 づいて算出できます。たとえば、シングルバイト・キャラクタ・セットから固定 マルチバイト・キャラクタ・セットへの移行には、たとえば 1 バイト:2 バイト比 に基づいた簡単な計算になります。可変幅マルチバイト・キャラクタ・セットの 場合、計算はより複雑になります。たとえば UTF-8 の場合、ASCII 文字はそれぞ れ 1 バイトを占めます。アクセント付きラテン文字、ギリシャ文字、キリル文字、 アラビア文字、ヘブライ文字はそれぞれ 2 バイトを占めます。中国語、日本語、 韓国語、インド語などの文字はそれぞれ 3 バイトを占めます。さらに補充文字は それぞれ 4 バイトを占めます。

リハーサルの実行

テスト環境でのリハーサルも推奨されています。リハーサルによるすべての手順 に慣れることで、本番の停止時間を軽減できます。またリハーサルによって、本 番の変換に要する時間、および停止時間の適切な処理に必要なリソースを予測で きます。これは、レガシー・アプリケーションと新規アプリケーションの両方で 新規データベース・キャラクタ・セットの正しい動作をテストする機会でもあり ます。

変換および変換後の妥当性チェックの実行

変換が完了してデータベースの回復後は、妥当性チェックを実行してください。 妥当性チェックには、データ変換が正しいかの確認も含みます。Import ユーティ リティを使用した場合は、ログで警告や例外を確認してください。サンプル・デー

タは視覚的に調べることができます。また例外のチェックには、Database Character Set Scanner を使用できます。すべての本番アプリケーションをテストし、正しく 動作することを確認してください。最後に、問題の発生やパフォーマンスの状態 をチェックするため、システムを一定時間監視します。

事例

次の事例では、安全で効率的なキャラクタ・セットの移行の管理に必要な、主要 方針、方法および決定事項を示します。

1) 追加言語をサポートする US7ASCII データベースの移行

ある顧客が、西欧およびアジア諸国向けに新規言語をサポートするため、 US7ASCII データベースの移行を検討しています。このデータベースに入るデータ は、環境変数 NLS_LANG が AMERICAN_AMERICA.US7ASCII に設定されており、 PASS-THRU シナリオを作成するクライアントの英語版 Windows システムからの データです。それにもかかわらず、顧客は、ほとんどのデータまたはすべてのデー タが純粋に ASCII であると見込んでいます。顧客はソース・セットを US7ASCII、 ターゲット・セットを AL32UTF8 に設定して、Database Character Set Scanner を実 行します。スキャンは例外データを検出し、顧客はその例外データをさらに詳し く調べた結果、データベースに保存されている発音記号や特殊記号付きの文字は 無効であると判断しました。ここで、顧客は最適な処置が必要となります。その 8 ビット・データが重要でなければ、削除や編集などの組合せで浄化できます。 たとえば、ä を a に置き換えます。データの浄化を行い、CSALTER スクリプトを 再度スキャンして完全に不変であることが検証されると使用可能になります。 また、8 ビット・データの保持が必要ならば、別の方法をとることができます。 データを視覚的に調べて、内容の判断が必要です。このケースでは、データが英 語版 Windows からの 8 ビット・データであると想定し、スキャナを使用して、デー タが含んでいると思われるソース・キャラクタ・セットを選びます。なお、Latin 1 キャラクタ・セットの WE8ISO8859P1 と WE8MSWIN1252 は非常に似ているが同 じではないことに注意してください。Microsoft キャラクタ・セット WE8MSWIN1252 は、8 ビット文字の全範囲を網羅する追加文字を持ちます。した がって、スキャナを WE8MSWIN1252 に設定しても、8 ビット例外の検出には役 立ちません。この場合は、データベース・ソースを WE8ISO8859P1 に設定し、最 終的な新規キャラクタ・セット（たとえば AL32UTF8）を選択してスキャンする ことをお薦めします。アクセント付き欧州文字は UTF-8 では 2 バイトを占めるた め、ここでは切捨ての問題の可能性が発生し、列のサイズ変更にも対処が必要な こともあります。スキャニングによってすべてのデータが新規キャラクタ・セッ トに変換可能なことが示され、切り捨てられる列がなければ、Export および Import ユーティリティを使用してデータを安全に移行できます。データベース・キャラ クタ・セットが US7ASCII であれば、2 つの手順により正常な移行が可能です。デー タベース・キャラクタ・セットを WE8MSWIN1252 または WE8ISO8859P1 に変更 します。次に、全体エクスポートおよびインポートを実行してすべてのデータを 正しく UTF-8 に変換します。

2) ユーロ記号に対応する WE8ISO8859P1 から WE8ISO8859P15 への移

行

これは、ユーロ記号に対応するために WE8ISO8859P1（Latin 1）データベースを WE8ISO8859P15（Latin 9）データベースに移行するというケースです。 WE8ISO8859P1 は WE8ISO8859P15 ではサポートされていない文字{¼ , ½, ¾, ¤, そ の他}からなる小さいサブセットを含みます。WE8ISO8859P1 内のその他すべての 文字は、WE8ISO8859P15 の同じエンコーディングに直接マッピングされます。ス キャニングによりすべてのデータが不変である場合は、CSALTER スクリプトを使 用できます。サポートについては、オラクル・サポートにお問い合せください。 なお通常の操作では、CSALTER スクリプトは厳密なサブセット/スーパーセット 関連のキャラクタ・セットにのみ使用可能です。そのためデータが不変にもかか わらず、このケースで CSALTER スクリプトの実行には、オラクル・サポートに よる支援が必要になります。スキャニングにより、すべてのデータが不変ではな い場合は、変換不可能なデータの扱いを決定する必要があります。

WE8ISO8859P15 キャラクタ・セットをカスタマイズするために Oracle Locale Builder を使用すると、サポートされていない WE8ISO8859P1 文字が追加されるた め、これらの特殊文字をサポートする Export および Import ユーティリティによる 移行が可能になります。

3) アジア系言語に対応する西欧キャラクタ・セットから AL32UTF8 へ

の移行

西欧キャラクタ・セットを使用しているほとんどのデータベースでは、ASCII デー タが占める割合が多いのが普通です。西欧データを持つデータ列のみを選択して 移行し、データベースから取り除くと、ASCII データのみが残るため、CSALTER スクリプトを使用できます。このアプローチの利点は、たとえば Export および Import ユーティリティの使用による全面移行に際しての停止時間を大幅に削減で きることです。スキャニングによって、ASCII データが不変であることが明らか になります。その上、有効な西欧データは変換可能です。 − 西欧文字（UTF-8 では 2 バイトに変換される Euro などの特殊文字やアク セント付き文字）の使用頻度が非常に高い場合は、全体エクスポートまた はインポートが最適なオプションです。 − 西欧文字の使用頻度が低く、たとえば 2∼3 の表のみに偏っている場合が あります。これらの表のみを選択してエクスポートおよびインポートする 場合は、Export および Import ユーティリティの使用で簡単に実行できます。 スキャニングによって残りのデータが不変であることが確認された場合 は、残りのデータベースは CSALTER スクリプト経由で変更対象のままに しておきます。 − 西欧文字の使用がそれほど偏っていない場合、たとえば多数の表で部分的 に使用されている場合、Oracles Migration Services が最適なオプションです。 前述のインライン移行ユーティリティはスキャンからの出力を使用して 西欧データのみを変換できるため、CSALTER スクリプト経由で残りの ASCII データに再度 AL32UTF8 としてタグを付けたまま残します。

前述の選択項目に留意しながら、無効データがこれらのケースにどのような影響 を及ぼすかを考えてみます。すでにサポートされている既存の西欧言語の他に、 アジアの諸言語に対応するため、顧客は WE8ISO8859P1（Latin 1）データベース の AL32UTF8（UTF-8）への移行を検討しています。顧客はソース・セットを WE8ISO8859P1、ターゲット・セットを AL32UTF8 と設定して、Database Character Set Scanner を実行します。スキャニングにより、無効な日本語文字がデータベー スに保存されていることが判明しました。ここで、顧客は最適な処置が必要とな ります。顧客は、このデータがおそらく PASS-THRU シナリオによってデータベー スに追加されると判断します。今後、アジア言語のデータをサポートする傾向に あり、このデータの保存が望ましいため、保存方法を検討します。Export および Import ユーティリティはオプションですが、技術的な問題があります。データベー スには WE8ISO8859P1 というラベルが付いているため、Export ユーティリティは このキャラクタ・セットでダンプ・ファイルを作成しますが、AL32UTF8 の変換 に Import ユーティリティは失敗します。オラクル移行サービスは、このようなケー スに対処する理想的なソリューションです。

4) 簡体字/繁体字中国語サポートが必要な顧客

顧客は現在、データベース・キャラクタ・セット ZHS16GBK を使用して簡体字中 国語に対応しています。顧客は最近、繁体字中国語のサポートも必要になりまし た。複数のアジア系言語を同時にサポートする場合は、通常 Unicode が必要にな ります。顧客は Oracle Database 10g データベースを使用しており、多数のアジア 系表意文字を含む 94,140 の追加文字をサポートするために AL32UTF8 を選択しま す。スキャニングと必要なクリーンアップの後、顧客は Export および Import ユー ティリティを使用してデータを変換します。このケースでは、1 文字当たり 2 バ イト（ZHS16GBK）から 3 バイト（AL32UTF8）への拡張に対処するため、顧客 はいくつかの列のサイズを増やす必要があると判断します。

結論

キャラクタ・セットの移行は、重要な作業になります。問題点を理解せず適切な 手順を踏まずに急いで移行すると、不適切な結果となる可能性があります。この ドキュメントで説明した正しい予防策を講じ、実績ある方法およびツールを使用 すれば、安全で効率的な移行が保証されます。移行に関する疑問点は、オラクル・ サポートおよび移行サービスにお問い合せください。Oracle は、これまで、デー タベースから新規キャラクタ・セットへの移行の成功例を多数支援してきました。 効果的な移行により、データベースの整理統合、新しい言語および文化的記号の サポートが可能になり、さらに効率的な業務運営、顧客数およびサービスの拡大 を実現します。

キャラクタ・セットの移行に関するベスト・プラクティス 2003 年 9 月 著書: 寄稿者: Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。 Oracle はオラクル社の登録商標です。 このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。 その他のすべての製品名およびサービス名は、各社の商標です。 この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 万一、誤植などにお気づきの場合は、オラクル社までお知らせください。オラクル社は本書の内容に関していかなる保証もしません。また、本書の内容に 関連したいかなる損害についても責任を負いかねます。

Copyright © 2004 Oracle Corporation All rights reserved.