Lesson 5	National Character Sets
Objective	Choose a national character set for an Oracle 26ai database.

National Character Sets in Oracle 26ai

A Second, Separate Character Set

In the last lesson we covered the database character set — the encoding that governs CHAR, VARCHAR2, CLOB, and LONG columns, identifiers, and stored SQL/PL/SQL source, almost always AL32UTF8 in a 26ai database. What we didn't cover is that every Oracle database actually carries two character sets, not one. The second is the national character set, and it applies exclusively to a narrower set of column types: NCHAR, NVARCHAR2, and NCLOB.

It's a genuinely separate choice, made independently of the database character set at creation time, and this lesson walks through how to make it deliberately rather than by default.

Why NCHAR Columns Exist at All

The NCHAR, NVARCHAR2, and NCLOB data types were originally designed as an escape hatch: a way to guarantee Unicode-capable storage for a specific set of columns, even in databases whose primary character set wasn't Unicode. In practice today, with AL32UTF8 as the near-universal default database character set, that original motivation rarely applies — your regular VARCHAR2 columns are already Unicode-capable. Where the national character set types still earn their keep is in a handful of narrower cases: applications that need a fixed-width encoding for predictable in-memory processing, or legacy schemas and third-party products that were built around the NCHAR family and expect it to behave a particular way.

Before choosing a national character set, it's worth asking honestly whether your application needs NCHAR columns at all, or whether standard VARCHAR2 columns on an AL32UTF8 database character set already cover the requirement.

The National Character Set Options

Oracle has offered two national character set values for many releases:

AL16UTF16 — a fixed-width Unicode encoding using 2 bytes per character. Predictable storage size and simpler in-memory operations make it a good fit for applications with heavy multilingual NCHAR usage. This has been the default national character set since Oracle 12c, and remains the default well into the 26ai release line.
UTF8 — a variable-width Unicode encoding using 1 to 3 bytes per character (distinct from the database-character-set value AL32UTF8, despite the naming similarity). Its variable width can save storage for data that's mostly ASCII with occasional multi-byte characters, at the cost of more processing overhead per multi-byte character.

For the overwhelming majority of new databases, AL16UTF16 is the right call — it's the default for a reason, and most applications never have a strong enough storage-efficiency argument to justify the added complexity of the variable-width alternative.

Expert Oracle Indexing and Access Paths

Setting the National Character Set

Like the database character set, this is a creation-time decision:

Database Configuration Assistant (DBCA): the Character Set step of the database creation wizard prompts for both the database character set and the national character set. AL16UTF16 is preselected; switch to UTF8 only if you have a specific reason to.
Manual creation via CREATE DATABASE: specify it directly:
```
CREATE DATABASE your_database_name
...
NATIONAL CHARACTER SET AL16UTF16;
```
Substitute UTF8 for AL16UTF16 if you've deliberately chosen the variable-width option.

Checking What You Have

To see both character sets a database is actually running with, query NLS_DATABASE_PARAMETERS:


SELECT PARAMETER, VALUE
FROM NLS_DATABASE_PARAMETERS
WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

PARAMETER                 VALUE
------------------------  ----------------
NLS_CHARACTERSET          AL32UTF8
NLS_NCHAR_CHARACTERSET    AL16UTF16

That's a typical, healthy 26ai configuration: AL32UTF8 handling the bulk of your data, AL16UTF16 standing by for any NCHAR-family columns you actually use. Neither NLS_CHARACTERSET nor NLS_NCHAR_CHARACTERSET can be changed with ALTER SESSION — they aren't session-level settings at all. They're fixed properties of the database itself, set once at creation.

Getting It Right the First Time

Changing the national character set after a database already exists is not a routine operation. It typically means exporting and re-importing the affected data, or recreating the database outright — disruptive enough that "choose carefully at creation" isn't just cautious advice, it's the practical reality. A few things worth knowing going in:

Certain database-level elements — database name, instance name, filenames, rollback segment names, and reserved keywords — must always use single-byte characters, regardless of what national character set you've chosen.
For NCHAR and NVARCHAR2 columns, length is specified in characters, not bytes — the opposite convention from CHAR and VARCHAR2, and an easy thing to get wrong if you're used to byte-based sizing.
Whichever value you choose, test it against real data: run your application's actual character range through it, and validate any import/export or migration path before you depend on it in production.

In short: default to AL16UTF16 unless you have a concrete, storage-driven reason to reach for UTF8; set it once, deliberately, at creation; and verify it with NLS_DATABASE_PARAMETERS rather than assuming.

Next Steps

With both the database character set and the national character set defined, the pieces are in place to handle multilingual data correctly at the storage layer. The next lesson moves into what happens when that data needs to move between systems that don't share the same character set.