Ja, hvis din Oracle-database er oprettet ved hjælp af et Unicode-tegnsæt, en NVARCHAR i SQL Server skal migreres til en VARCHAR2 i Oracle. I Oracle er NVARCHAR datatypen findes for at tillade applikationer at gemme data ved hjælp af et Unicode-tegnsæt, når databasens tegnsæt ikke understøtter Unicode.
En ting, man skal være opmærksom på ved migrering, er karakterlængde semantik. I SQL Server, en NVARCHAR(20) tildeler plads til 20 tegn, hvilket kræver op til 40 bytes i UCS-2. I Oracle er som standard en VARCHAR2(20) tildeler 20 bytes lagerplads. I AL32UTF8 tegnsæt, der potentielt kun er nok plads til 6 tegn, selvom det højst sandsynligt vil håndtere meget mere (et enkelt tegn i AL32UTF8 kræver mellem 1 og 3 bytes. Du vil sandsynligvis erklære dine Oracle-typer som VARCHAR2(20 CHAR) hvilket angiver, at du vil allokere plads til 20 tegn uanset hvor mange bytes det kræver. Det plejer at være meget lettere at kommunikere end at forsøge at forklare, hvorfor nogle 20 tegnstrenge er tilladt, mens andre 10 tegnstrenge afvises.
Du kan ændre standardlængdesemantikken på sessionsniveau, så alle tabeller, du opretter uden at angive nogen længdesemantik, vil bruge karakter frem for bytesemantik
ALTER SESSION SET nls_length_semantics=CHAR;
Det lader dig undgå at skrive CHAR hver gang du definerer en ny kolonne. Det er også muligt at indstille det på systemniveau, men at gøre det frarådes af NLS-teamet - tilsyneladende er ikke alle de scripts, Oracle leverer, blevet grundigt testet mod databaser, hvor NLS_LENGTH_SEMANTICS er blevet ændret. Og sandsynligvis har meget få tredjeparts-scripts været det.