Ja, als uw Oracle-database is gemaakt met een Unicode-tekenset, een NVARCHAR in SQL Server moet worden gemigreerd naar een VARCHAR2 bij Orakel. In Oracle is de NVARCHAR gegevenstype bestaat om toepassingen in staat te stellen gegevens op te slaan met behulp van een Unicode-tekenset wanneer de databasetekenset Unicode niet ondersteunt.
Een ding om op te letten bij het migreren is echter de semantiek van de tekenlengte. In SQL Server, een NVARCHAR(20) wijst ruimte toe voor 20 tekens, wat tot 40 bytes vereist in UCS-2. In Oracle is standaard een VARCHAR2(20) wijst 20 bytes aan opslagruimte toe. In de AL32UTF8 tekenset, dat is potentieel slechts genoeg ruimte voor 6 tekens, hoewel het waarschijnlijk veel meer zal verwerken (een enkel teken in AL32UTF8 vereist tussen de 1 en 3 bytes. U wilt waarschijnlijk uw Oracle-typen declareren als VARCHAR2(20 CHAR) wat aangeeft dat u ruimte voor 20 tekens wilt toewijzen, ongeacht het aantal bytes dat daarvoor nodig is. Dat is meestal veel gemakkelijker om te communiceren dan te proberen uit te leggen waarom sommige 20 tekenreeksen zijn toegestaan, terwijl andere 10 tekenreeksen worden afgewezen.
U kunt de standaardlengtesemantiek op sessieniveau wijzigen, zodat alle tabellen die u maakt zonder enige lengtesemantiek op te geven, tekens gebruiken in plaats van byte-semantiek
ALTER SESSION SET nls_length_semantics=CHAR;
Zo kunt u voorkomen dat u CHAR . typt elke keer dat u een nieuwe kolom definieert. Het is ook mogelijk om dat op systeemniveau in te stellen, maar dit wordt ontmoedigd door het NLS-team - blijkbaar zijn niet alle scripts die Oracle biedt grondig getest op databases waar de NLS_LENGTH_SEMANTICS is veranderd. En waarschijnlijk zijn er maar heel weinig scripts van derden geweest.