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