一部のデータを SQL Server から Oracle に移行しています。NVARCHARSQLサーバーで定義された列についてNVARCHAR、類似していると考えてOracleで列を作成し始めました..しかし、そうではないようです。
stackoverflow に関するいくつかの投稿を読み、調査結果を確認したいと思います。
データベースの文字セットが AL32UTF8 の場合、Oracle VARCHAR2 はすでに Unicode をサポートしています (これは私たちの場合に当てはまります)。
SQLServerはユニコードをサポートVARCHAR していません。SQLServer では、NCHAR/NVARCHARデータを Unicode (具体的には 2 バイトの UCS-2 形式) で格納するために、列が型であることが明示的に要求されます。
したがって、SQL Server NVARCHAR 列を Oracle VARCHAR2 列として移行できる/移行する必要があると言うのは正しいでしょうか?
はい。Oracle データベースが Unicode 文字セットを使用して作成されている場合、NVARCHARSQL Server の を Oracle の に移行する必要がありVARCHAR2ます。Oracle にはNVARCHAR、データベースの文字セットが Unicode をサポートしていない場合に、アプリケーションが Unicode 文字セットを使用してデータを格納できるようにするためのデータ型が存在します。
ただし、移行時に注意すべきことの 1 つは、文字の長さのセマンティクスです。SQL Server では、NVARCHAR(20)UCS-2 で最大 40 バイトを必要とする 20 文字のスペースが割り当てられます。Oracle では、デフォルトで、aVARCHAR2(20)は 20 バイトのストレージを割り当てます。文字セットでは、これAL32UTF8は潜在的に 6 文字分の十分なスペースにすぎませんが、おそらくもっと多くの文字を処理できます (1 文字で1 AL32UTF8～ 3 バイトが必要です)。VARCHAR2(20 CHAR)必要なバイト数に関係なく、20 文字のスペース. 20 文字の文字列が許可され、他の 10 文字の文字列が拒否される理由を説明しようとするよりも、はるかに簡単に伝えることができます.
セッション レベルでデフォルトの長さセマンティクスを変更して、長さセマンティクスを指定せずに作成するテーブルがバイト セマンティクスではなく文字セマンティクスを使用するようにすることができます。
ALTER SESSION SET nls_length_semantics=CHAR;
これによりCHAR、新しい列を定義するたびに入力する必要がなくなります。システム レベルで設定することも可能ですが、NLS チームはそうすることをお勧めしません。明らかに、Oracle が提供するすべてのスクリプトが、NLS_LENGTH_SEMANTICS変更されたデータベースに対して完全にテストされているわけではありません。おそらく、サードパーティのスクリプトはほとんどありません。