Ano, pokud je vaše databáze Oracle vytvořena pomocí znakové sady Unicode, NVARCHAR v SQL Server by měl být migrován na VARCHAR2 v Oracle. V Oracle, NVARCHAR existuje datový typ, který umožňuje aplikacím ukládat data pomocí znakové sady Unicode, když znaková sada databáze nepodporuje Unicode.
Jedna věc, kterou je třeba si při migraci uvědomit, je sémantika délky znaků. V SQL Server, NVARCHAR(20) přiděluje prostor pro 20 znaků, což vyžaduje až 40 bajtů v UCS-2. V Oracle je ve výchozím nastavení VARCHAR2(20) přiděluje 20 bajtů úložiště. V AL32UTF8 znaková sada, což je potenciálně dostatek místa pouze pro 6 znaků, i když s největší pravděpodobností zvládne mnohem více (jeden znak v AL32UTF8 vyžaduje 1 až 3 bajty. Pravděpodobně budete chtít deklarovat své typy Oracle jako VARCHAR2(20 CHAR) což znamená, že chcete přidělit prostor pro 20 znaků bez ohledu na to, kolik bajtů to vyžaduje. To bývá mnohem snazší komunikovat, než se snažit vysvětlit, proč jsou některé 20znakové řetězce povoleny, zatímco jiných 10znakových je odmítnuto.
Výchozí sémantiku délky můžete změnit na úrovni relace, takže všechny tabulky, které vytvoříte bez zadání jakékoli délky sémantiky, budou používat spíše znakovou než bajtovou sémantiku
ALTER SESSION SET nls_length_semantics=CHAR;
To vám umožní vyhnout se psaní CHAR pokaždé, když definujete nový sloupec. Je také možné nastavit to na systémové úrovni, ale tým NLS to odrazuje – zjevně ne všechny skripty, které Oracle poskytuje, byly důkladně testovány s databázemi, kde NLS_LENGTH_SEMANTICS bylo změněno. A pravděpodobně existuje jen velmi málo skriptů třetích stran.