Oracle 12.2 新特性--PDB和CDB的字符集可以不一样
在 12.1 中， PDB 的字符集与 root 容器必须保持一致，这样无形中造成了 PDB 迁移或者克隆的限制性。从 12.2 开始，同一个 cdb 中的各个 PDB 字符集可以不相同。
对于最新版本 12.2.0.1 ，在新创建 PDB 时并没有办法指定 PDB 的字符集，因此只能和 root 容器字符集相同，而不同 PDB 可以使用 hot clone, 或 Relocate PDB online 方式直接 plug-in ，还可使用 internal_use 进行转换。
alter session set container=pdbsample;
select userenv('language') from dual;
alter pluggable database pdbsample close immediate;
alter pluggable database pdbsample open restricted;
alter database character set INTERNAL_CONVERT AL32UTF8;
alter pluggable database pdbsample close immediate;
alter pluggable database pdbsample open;
或：
alter system enable restricted session;
alter database character set INTERNAL_CONVERT ZHS16GBK;
alter system DISABLE restricted session;
实验过程：
[oracle@rhel6lhr dbs]$ ORACLE_SID=CDBLHR18c
[oracle@rhel6lhr dbs]$ sas
SQL*Plus: Release 18.0.0.0.0 - Production on Sun Dec 2 08:33:45 2018
Version 18.3.0.0.0
Copyright (c) 1982, 2018, Oracle. All rights reserved.
Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
SYS@CDBLHR18c> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBLHR2 MOUNTED
4 PDBSAMPLE READ WRITE NO
5 PDB18CLHR1 MOUNTED
6 PDB18CLHR3 MOUNTED
SYS@CDBLHR18c> select userenv('language') from dual;
USERENV('LANGUAGE')
--------------------------------------------------------------------------------
AMERICAN_CHINA.AL32UTF8
SYS@CDBLHR18c> alter session set container=PDBSAMPLE;
Session altered.
SYS@CDBLHR18c> select userenv('language') from dual;
USERENV('LANGUAGE')
--------------------------------------------------------------------------------
AMERICAN_CHINA.US7ASCII
SYS@CDBLHR18c> alter pluggable database pdbsample close immediate;
Pluggable database altered.
SYS@CDBLHR18c> alter pluggable database pdbsample open restricted;
Pluggable database altered.
SYS@CDBLHR18c>
SYS@CDBLHR18c> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
4 PDBSAMPLE READ WRITE YES
SYS@CDBLHR18c>
SYS@CDBLHR18c> alter database character set INTERNAL_CONVERT AL32UTF8;
Database altered.
SYS@CDBLHR18c> select userenv('language') from dual;
USERENV('LANGUAGE')
--------------------------------------------------------------------------------
AMERICAN_CHINA.AL32UTF8
SYS@CDBLHR18c> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
4 PDBSAMPLE READ WRITE YES
SYS@CDBLHR18c> alter pluggable database pdbsample close immediate;
Pluggable database altered.
SYS@CDBLHR18c> alter pluggable database pdbsample open;
Pluggable database altered.
SYS@CDBLHR18c>
SYS@CDBLHR18c> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
4 PDBSAMPLE READ WRITE NO
SYS@CDBLHR18c> select count(1) from scott.emp;
COUNT(1)
----------
14
SYS@CDBLHR18c> select count(1) from CDB_tables where owner='HR';
COUNT(1)
----------
7
Oracle 12c R2 新特性: Per-PDB Character Sets （同一CDB中PDB可以使用不同的字符集）
在oracle12.1版本中，同一CDB中的所有PDB使用的都是相同的字符集，并且Plug-in时PDB也要和目标CDB相同字符集或者是子集，否则plug-in时会失败在 PDB_PLUG_IN_VIOLATIONS 视图提示，这样影响了PDB的迁移灵活性，在MOS Note 1968706.1摘录
In Oracle Database 12c, all pluggable databases (PDBs) in a container database (CDB) must have
* the same Database character set (NLS_CHARACTERSET) or the NLS_CHARACTERSET need to be a (Plug-in compatible) binary subset of the CDB NLS_CHARACTERSET
* the same National character set (NLS_NCHAR_CHARACTERSET) as the CDB’s root container
in order to be able to plug in.If PDB NLS_CHARACTERSET is a (Plug-in compatible) binary subset of the CDB’s NLS_CHARACTERSET the NLS_CHARACTERSET of the PDB is automatically changed to the NLS_CHARACTERSET of the CDB at the first open .
The character sets of the root container are considered the character sets of the whole CDB.
从12.2起引入新特性同一CDB中每个PDB可以使用不同的字符集，前提CDB是AL32UTF8。 如CDB是AL32UTF8，其中的PDB1为WE8ISO8859P1 , PDB2为ZHS16GBK， 从其它CDB plug-in一个JA16EUC字符集的PDB也是允许的，在plug-in PDB的过程中PDB会原封不动的进入目标CDB，过程中并不会转换字符集，并且以后新insert的数据是直接使用的原PDB的字符集。
Per-PDB Character Set的有几个前提条件：
1） CDB must be AL32UTF8
2） Application Container requires single character set
3） National character set also supported per PDB
4） Truncation of data can occur in cross-container queries if data conversion to UNICODE causes expansion
在CDB必须是AL32UTF8时（DBCA 时12.2的默认项），虽然同一个CDB中每个PDB可以使用不同的PDB，但是发现当前版本12.2.0.1对于新创建PDB时并没有办法指定PDB 的字符集，对于已存在的PDB 可以使用hot clone,或Relocate PDB online 方式直接plug-in, 像我之前的笔记[Oracle 12c R2 新特性: Online PDB Relocate (PDB hot move) http://www.anbob.com/archives/2833.html ]中,也是直接把ZHS16GBK 字符集的PDB Plug-in 到了AL32UTF8的CDB中。
如为了以后同一个CDB中的PDB可以使用不同字符集的PDB， 前期规划时建议CDB直接选择AL32UTF8字符集， 但是如果目前想创建一个ZHS16GBK的空PDB时怎么办呢？ 目前没有提供创建PDB指定字符集的选项。这种情况下，我目前能想到两种方式。
1， 第一种迁移；创建一个ZHS16GBK 的CDB， 同时自带ZHS16GBK的PDB， 然后通过HOT CLONE PDB或Relocate PDB的方式迁移到另一个AL32UTF8字符集的CDB中。
该操作可以在同一台数据库服务器上创建，因为同一server是可以创建不同的CDB的。具体的方法就不再重复，可以参考ANBOB.com上我之前的clone,relocate的笔记。
2， 第二种转换；可以创建一个AL32UTF8的PDB 然后转换为ZHS16GBK，下面使用了internal_use，这个方法在ORACLE是不太建议的。
下面CDB 是AL32UTF8 并且PDBANBOB 也是AL32UTF8后来转换为ZHS16GBK。 字符集的可用值可以查询V$NLS_VALID_VALUES 视图， 当前的值可以查询V$NLS_PARAMETERS 视图。
Single Instance
--lang.sql: col PROPERTY_NAME for a30 col PROPERTY_VALUE for a30 col DESCRIPTION for a30 select * from database_properties where PROPERTY_NAME='NLS_CHARACTERSET'; SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 PDBANBOB MOUNTED 5 PDBTEST2_PROXY MOUNTED 6 PDBWEEJAR MOUNTED SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET AL32UTF8 Character set SQL> alter pluggable database PDBANBOB open; Pluggable database altered. SQL> alter session set container=pdbanbob; Session altered. SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET AL32UTF8 Character set SQL> alter database character set ZHS16GBK; alter database character set ZHS16GBK * ERROR at line 1: ORA-12712: new character set must be a superset of old character set SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK * ERROR at line 1: ORA-12719: operation requires database is in RESTRICTED mode SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION; System altered. SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; Database altered. SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET ZHS16GBK Character set
RAC Instance
rac实例修改时和单实例有点不多，需要先停提所有其它instance，修改后再打开。
alter pluggable databse pdbanbob close instances=all; alter pluggable database pdbanbob open read write restricted; -- in container pdbanbob alter database character set internal_use zhs16gbk; alter pluggable databse pdbanbob close; alter pluggable database pdbanbob open instances=all;
已经把pdbanbob 字符集修改成了ZHS16GBK， 同样在12C的版本中推出了Oracle Database Migration Assistant for Unicode（DMU）工具， 如果有兴趣可以去 官方免费下载 测试
You can use Oracle Database Migration Assistant for Unicode (DMU) to migrate a non-CDB NLS_CHARACTERSET to AL32UTF8. Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool
There is a few restrictions with DMU :
1- It does not support the migration of Oracle Database 12c Pluggable Databases (PDBs) to NLS_CHARACTERSET other than Unicode.
Oracle strongly recommends migrating the database character set to Unicode (AL32UTF8) NLS_CHARACTERSET before consolidating your databases.
2- You will receive the following error upon Initiating step 4 “convert database” using the DMU while being connected to PDB:
conversion feasibility test failed . the migration target character set is different from the CDB root character set.
To go from a non-Unicode CDB with (also non-Unicode) PDB’s the steps are:
* Create a new Unicode (AL32UTF8) CDB
* Use the DMU to scan the non-Unicode PDB’s and resolve any reported convertibility issues while it is still plugged into the original non-Unicode CDB.
* Unplug the PDB to be migrated and plug it into the target Unicode AL32UTF8 CDB (this will put the PDB into restricted mode due to the character set incompatibility).
* Use the DMU tool to convert the non-Unicode PDB to Unicode once plugged in the target Unicode AL32UTF8 CDB (= finish the conversion).3- DMU does not support the migration of Oracle Database 12c container database (CDB) to any NLS_CHARACTERSET ( as this is not needed).
You will receive the following error upon connecting to CDB using the DMU :
Encountered an error while checking database’s compatibility: Migration of container databases (CDB) is not supported.
The export/import migration methods could be used to overcome these limitations.
References:
12c Multitenant Container Databases (CDB) and Pluggable Databases (PDB) Character set restrictions / ORA-65116/65119: incompatible database/national character set ( Character set mismatch: PDB character set CDB character set ) (文档 ID 1968706.1)
Oracle 12c R2 新特性: Per-PDB Character Sets （同一CDB中PDB可以使用不同的字符集）
在oracle12.1版本中，同一CDB中的所有PDB使用的都是相同的字符集从CDB继承而来，这样影响了PDB的迁移灵活性，从12.2起同一CDB中每个PDB可以使用不同的字符集， 如CDB是AL32UTF8，其中的PDB1为WE8ISO8859P1 , PDB2为ZHS16GBK， 从其它CDB plug-in一个JA16EUC字符集的PDB也是允许的，在plug-in PDB的过程中PDB会原封不动的进入目标CDB，过程中并不会转换字符集，并且以后新insert的数据是直接使用的原PDB的字符集。
Per-PDB Character Set的有几个前提条件：
1） CDB must be AL32UTF8
2） Application Container requires single character set
3） National character set also supported per PDB
4） Truncation of data can occur in cross-container queries if data conversion to UNICODE causes expansion
在CDB必须是AL32UTF8时（DBCA 时12.2的默认项），虽然同一个CDB中每个PDB可以使用不同的PDB，但是发现当前版本12.2.0.1对于新创建PDB时并没有办法指定PDB 的字符集，对于已存在的PDB 可以使用hot clone,或Relocate PDB online 方式直接plug-in, 像我之前的笔记[Oracle 12c R2 新特性: Online PDB Relocate (PDB hot move) http://www.anbob.com/archives/2833.html
]中,也是直接把ZHS16GBK 字符集的PDB Plug-in 到了AL32UTF8的CDB中。
如为了以后同一个CDB中的PDB可以使用不同字符集的PDB， 前期规划时建议CDB直接选择AL32UTF8字符集， 但是如果目前想创建一个ZHS16GBK的空PDB时怎么办呢？ 目前没有提供创建PDB指定字符集的选项。这种情况下，我目前能想到两种方式。
1， 第一种迁移；创建一个ZHS16GBK 的CDB， 同时自带ZHS16GBK的PDB， 然后通过HOT CLONE PDB或Relocate PDB的方式迁移到另一个AL32UTF8字符集的CDB中。
该操作可以在同一台数据库服务器上创建，因为同一server是可以创建不同的CDB的。具体的方法就不再重复，可以参考ANBOB.com上我之前的clone,relocate的笔记。
2， 第二种转换；可以创建一个AL32UTF8的PDB 然后转换为ZHS16GBK，下面是演示一下。
下面CDB 是AL32UTF8 并且PDBANBOB 也是PDBANBOB。 字符集的可用值可以查询V$NLS_VALID_VALUES 视图， 当前的值可以查询V$NLS_PARAMETERS 视图。
--lang.sql: col PROPERTY_NAME for a30 col PROPERTY_VALUE for a30 col DESCRIPTION for a30 select * from database_properties where PROPERTY_NAME='NLS_CHARACTERSET'; SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED READ ONLY NO 3 PDBANBOB MOUNTED 5 PDBTEST2_PROXY MOUNTED 6 PDBWEEJAR MOUNTED SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET AL32UTF8 Character set SQL> alter pluggable database PDBANBOB open; Pluggable database altered. SQL> alter session set container=pdbanbob; Session altered. SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET AL32UTF8 Character set SQL> alter database character set ZHS16GBK; alter database character set ZHS16GBK * ERROR at line 1: ORA-12712: new character set must be a superset of old character set SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK * ERROR at line 1: ORA-12719: operation requires database is in RESTRICTED mode SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION; System altered. SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; Database altered. SQL> @lang PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------ ------------------------------ NLS_CHARACTERSET ZHS16GBK Character set
已经把pdbanbob 字符集修改成了ZHS16GBK， 同样在12C的版本中推出了Oracle Database Migration Assistant for Unicode（DMU）工具， 如果有兴趣可以去 官方免费下载测
试
| 如何选择或更改数据库字符集 (NLS_CHARACTERSET) (文档 ID 1525394.1) |
文档内容
| 用途 |
| 适用范围 |
| 详细信息 |
| A) 数据库字符集 (NLS_CHARACTERSET) |
| B) 选择新数据库字符集 |
| C) 在8i, 9i, 10g 和 11g 中更改数据库字符集。 |
| C1) 运行 Oracle Application (EBS) 或 PeopleSoft 系统的 数据库字符集转换 |
| C2) 在8i, 9i, 10g 和 11g 中使用“export/import”操作（在 10g 及更高版本中使用Datapump操作）。 |
| C3) 组合使用 ALTER DATABASE CHARACTER SET（8i、9i）/ CSALTER（10g 和 11g）与 “export/import” 操作 |
| C4) 在 8i、9i、10g 和 11g 中将字符集转换为 Unicode (UTF8/AL32UTF8) 的分步指南（包括导出/导入操作） |
| C5) Physical / Logical Standby 数据库如何操作? |
| C6) 如何将数据库从 AL32UTF8/UTF8 改回另外的字符集? |
| D) 在 Oracle 12c 中将数据库字符集修改为 Unicode(UTF8/AL32UTF8) |
| E) 12c Multitenant Container Databases (CDB) 和 Pluggable Databases (PDB) 中字符集的限制: |
| F) 其他阅读材料 |
| 参考 |
适用于:
Oracle Database - Enterprise Edition - 版本 8.1.7.4 和更高版本
Oracle Database - Standard Edition - 版本 8.1.7.4 和更高版本
本文档所含信息适用于所有平台
用途
本文章概述了更改数据库字符集或在具有不同 NLS_CHARACTERSET 的数据库之间导出/导入前进行检查的方法。
当前的 NLS_CHARACTERSET 在 NLS_DATABASE_PARAMETERS 中可以看到。
conn / as sysdba
select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';
NLS_CHARACTERSET（“字符集”）定义了“普通”的 CHAR, VARCHAR2, LONG 以及 CLOB 字段的编码。
NLS_NCHAR_CHARACTERSET（“国家字符集”）定义了 NCHAR, NVARCHAR2 以及 NCLOB 字段的编码。从 9i 以后都是 Unicode 编码。如果没有使用 NCHAR, NVARCHAR2 以及 NCLOB 字段，那么 NLS_NCHAR_CHARACTERSET 的设置不会被使用或者说不相关。详见 Note 276914.1 The National Character Set in Oracle 9i , 10g and 11g
要更改 Oracle Application 数据库的 NLS_CHARACTERSET ： 请参阅 Note 124721.1 Migrating an Applications Installation to a New Character Set.
这是 Oracle Application 唯一支持的方法。如果您有任何疑问，请开一个 Oracle Applications SR 以寻求帮助。
适用范围
尝试更改 NLS_CHARACTERSET 的所有用户。
现在仍然有数据库管理员尝试通过修改 props$ 来更改 NLS_CHARACTERSET 或 NLS_NCHAR_CHARACTERSET 。我们不支持使用这种方法 ， 因为这将会损坏您的数据库。这是破坏整个数据集的最直接方式之一。如果您已经做了这个操作,那么第一件事就是从备份中完全恢复数据库.如果没有做任何备份,那么 Oracle Support 可以尝试帮助您进行恢复 ， 但 Oracle 不能保证可以恢复数据 ， 也不能保证恢复后的数据完全正确。我们会要求您执行完全导出操作，并重新建立整个数据库。 切勿更新 props$ 。
详细信息
A) 数据库字符集 (NLS_CHARACTERSET)
Oracle 数据库的 NLS_CHARACTERSET 定义了数据库中哪些字符可以存储在 CHAR 、 VARCHAR2 、 LONG 和 CLOB 数据类型中。字符集不定义语言 ， 而是定义字符的特定范围。任何语言 ， 只要它使用包含在该字符集中的字符 ， 即可存储在数据库中。
需要注意的是 NLS_LANGUAGE 和 NLS_TERRITORY 同数据库是否有能力存储某种字符没有任何关系。
一个使用 NLS_CHARACTERSET 为 WE8MSWIN1252 并且 NLS_LANGUAGE/NLS_TERRITORYJAPANESE 为 JAPAN 的数据库是不能存储日文的，因为 WE8MSWIN1252 中不包含日文字符的定义。
一个使用 NLS_CHARACTERSET 为 AL32UTF8 并且 NLS_LANGUAGE/NLS_TERRITORY 为 AMERICAN AMERICA 的数据库能存储日文 (或者从某种意义上说任何世界上其它的语言).
如果您准备修改数据库的字符集，并且当前使用的某些字符在新的字符集中没有定义，或者当前字符集的设置是不正确的，那么在字符集修改之后就可能发生数据丢失。
在更改字符集前 ， 应始终使用 Character Set Scanner (Csscan) 检查是否存在这种情况。
使用导出 / 导入操作或 Expdp/Impdp 时也一样。
Note 458122.1 Installing and Configuring Csscan in 8i and 9i (Database Character Set Scanner)
Note 745809.1 Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
Note 444701.1 Csscan output explained
切勿在字符数据类型（ CHAR 、 VARCHAR2 、 LONG 、 CLOB ）中存储 “ 二进制 ” （加密）数据。
如果将二进制数据作为 CHAR 、 VARCHAR2 、 LONG 或 CLOB 数据类型存储 / 处理，则可能会丢失数据，特别是在使用 AL32UTF8 数据库时（即使没有使用导出 / 导入操作）。或者，可能会出现 ORA-29275 或 ORA-600 [kole_t2u], [34] 等错误。
请参阅 Note 1297507.1 Problems with (Importing) Encrypted Data After Character Set Change Using Other NLS_CHARACTERSET Database or Upgrading the (client) Oracle Version
B) 选择新数据库字符集
对于大多数客户，Unicode 字符集 (AL32UTF8) 是最好的选择。
使用AL32UTF8字符集的数据库,你可以存储/查询世界上所有的语言
请参阅 Note 333489.1 Choosing a database character set means choosing Unicode 以及 Note 1051824.6 What languages are supported in an Unicode (UTF8/AL32UTF8) database?
需要注意的是，在选择 Unicode(AL32UTF8) 数据库前，您需要确认应用程序是否支持。这个不是 Oracle 技术支持能检查或确认的。
请检查对应的应用程序文档，或咨询应用程序提供商及支持团队，以确认应用程序同 AL32UTF8 或 UTF8 的认证关系。我们强烈建议这么做。
不需要特意安装Unicode或其它字符集,因为所有Oracle的字符集包括Unicode,都已经默认安装了.
您不能将 AL16UTF16 作为 NLS_CHARACTERSET，AL16UTF16 只能作为 NLS_NCHAR_CHARACTERSET，请参阅 Note:276914.1 The National Character Set in Oracle 9i 10g and 11g
人们经常会有一个错误的认识,认为简单的使用NCHAR, NVARCHAR2 和 NCLOB就可以让应用程序变得Unicode化,并且比改变NLS_CHARACTERSET花费的工作更少.
但是一般的N-类型在编程语言以及应用的角度上的支持是很差的.为了使用N-类型,应用程序需要显式的支持.
所以Oracle一般建议使用NLS_CHARACTERSET, CHAR, VARCHAR2 , LONG 和 CLOB 这样的数据类型,而不是N-类型的数据类型.
对于非 Unicode 字符集，最佳选择是 xx8MSWIN125x 字符集，即使数据库自身在 Unix 平台上运行。原因很简单：大多数客户端都是基于 Windows 系统的，因此最适合数据库的非 Unicode 字符集是可以存储这些客户端能够识别的所有字符的字符集，即 xx8MSWIN125x 字符集：
EE8MSWIN1250 , CL8MSWIN1251, WE8MSWIN1252, EL8MSWIN1253 ,TR8MSWIN1254, IW8MSWIN1255, AR8MSWIN1256, BLT8MSWIN1257。
对于亚洲语言推荐的字符集是 VN8MSWIN1258, TH8TISASCII, JA16SJIS , KO16MSWIN949, ZHS16GBK, ZHT16MSWIN950 , ZHT16HKSCS31。
详细讨论，请参阅 Note 264294.1 Choosing from WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as db character set.
如果想知道哪些语言可以存储在大多数常用字符集中，请参阅 Note 62421.1 Which Character Set Supports Which Language
如果想知道特定字符集中包含哪些字符，请参阅 Note 282336.1 Charts of most current mono-byte Character sets
或者使用 Locale Builder 打开 Oracle 字符集定义，请参阅 Note 223706.1 Using Locale Builder to view the definition of character sets
这里有一个非常优秀的外部资源： http://www.eki.ee/letter/ . 在该网站中选择某个语言后，它将显示包含此语言所需的全部字母的所有字符集概览。
请注意，Oracle 不保证该网站中的信息完全正确。
* 对数据库(RDBMS)的升级是 不会 改变 NLS_CHARACTERSET 的，所以将数据库从 9i 或 10g 升级到 11g 或 12c 后 NLS_CHARACTERSET 还会是原来的值。
* 如果您计划将数据库从一个不推荐的8位字符集（比如US7ASCII 或 WE8ISO8859P1），改为一个推荐的8位字符集（比如WE8MSWIN1252），请参见 C3 中提供的步骤。在没有对源数据库运行 csscan 前， 不要 尝试做 export 和 import！
从版本 11g 开始，DBCA 默认提供“推荐”字符集列表用作 NLS_CHARACTERSET，出于上述相同的原因，列表中不包含类似于 WE8ISO8859P1 的字符集。请注意，Oracle仍然对这些字符集提供支持，并且根据需要，也可以使用“非推荐”字符集。有关更多信息，请参阅 Note 306411.1 Character Set Consolidation for Oracle Database 11g以及如下文档的"Locale Data" , "Character Sets"部分
11.2. : http://docs.oracle.com/cd/E11882_01/server.112/e10729/applocaledata.htm#NLSPG585
12.1: http://docs.oracle.com/database/121/NLSPG/applocaledata.htm#NLSPG584
如果在 11g 中必需使用 DBCA 中的一个“非推荐”字符集（如 US7ASCII 或 WE8ISO8859P1）创建数据库，则在 11g DBCA 的步骤 9（共 11 个）"Character Sets"选项卡中，钩掉"show recommended character sets only"，然后选择"Choose from the list of character sets"。
在 12c 的 DBCA 中，选择" create a database"，在第2步中选择"advanced mode"，第10步在"Character Sets"选项卡中，钩掉"show recommended character sets only"，然后选择"Choose from the list of character sets"，之后就可以选择不推荐的字符集（比如 US7ASCII 或 WE8ISO8859P1）作为数据库的字符集（NLS_CHARACTERSET）。
关于 ORA-xxxx 错误的语言问题,请参照文档 Note 985974.1 Changing the Language of RDBMS (Error) Messages
C) 在8i, 9i, 10g 和 11g 中更改数据库字符集。
请注意，如果一开始就更改数据库字符集，很有可能*无法*解决显示问题。
因此，请先检查是否可以使用 SQLdeveloper 存储/检索数据，这款工具是无需进行 NLS 配置的“好客户端”。
note 1628060.1 How to diagnose losing characters , getting "funny" output when inserting or selecting other than A-Z,a-z data ( = non English data like Chinese, Russian, Hebrew , insert any language here to the list that is not English) CHAR, VARCHAR2, LONG or CLOB
需要注意的是重建 control 文件不会改变 NLS_CHARACTERSET。CREATE CONTROLFILE DATABASE ... RESETLOGS ....CHARACTER SET <NLS_CHARACTERSET> 中的字符集（从 ALTER DATABASE BACKUP CONTROLFILE TO TRACE..得到的） 需要同数据库的 NLS_CHARACTERSET 一致 。
要确保数据库中没有使用字符集相关的数据类型(CHAR, VARCHAR2, LONG, CLOB)来存储二进制的文件(pdf , doc, docx, jpeg, png等文件)或者加密的数据(passwords).
如果二进制文件(如PDF , doc, docx, jpeg, png等)或者加密的数据(passwords)存成了CHAR, VARCHAR2, LONG 或 CLOB ,那么就很可能会发生数据的丢失,尤其当使用AL32UTF8的数据库的时候(就算没有使用exp/imp)
或者像ORA-29275 或 ORA-600 [kole_t2u], [34]这样的错误就会发生.
唯一支持存储二进制数据或加密的数据的数据类型是LONG RAW 或者 BLOB.
如果你想把二进制数据或加密的数据存储在CHAR, VARCHAR2, LONG or CLOB数据类型里,那么它们在application端必须被转换成"characterset safe"的形式,比如base64.
Note 1297507.1 Problems with (Importing) Encrypted Data After Character Set Change Using Other NLS_CHARACTERSET Database or Upgrading the (client) Oracle Version
C1) 运行 Oracle Application (EBS) 或 PeopleSoft 系统的 数据库字符集转换
请参见文档: Note 124721.1 Migrating an Applications Installation to a New Character Set.
这是唯一的 Oracle applications 提供支持的方法。如果您有任何疑问请创建一个 Oracle Applications 的 SR 以寻求协助。
对于一个Oracle PeopleSoft的数据库，请参照文档 note 703689.1 Converting PeopleSoft Systems to Unicode Databases
如果您有任何疑问请创建一个 Oracle PeopleSoft 的 SR 以寻求协助。
C2) 在8i, 9i, 10g 和 11g 中使用“export/import”操作（在 10g 及更高版本中使用Datapump操作）。
您只需导出当前的数据库，然后使用新字符集新建一个数据库，并将数据导入到该数据库中。Export/import (原来的 exp/imp tools 或者 expdp/impdp) 适用于原字符集中的字符在新字符集中都有定义（但它们可能有不同的编码）。
需要注意的是您要存储的字符仍需在原字符集中有正确的定义。
很多时候这个条件都是无法满足的，所以需要通过对源数据库使用 csscan检测这些错误，因此在使用 exp/imp 时，我们建议始终 先 用 Csscan 检测是否存在问题。
数据丢失（字符在 export/import 之后变成 ? 或者 ¿ ）在 export/import 的过程中是不会报错的。
请务必参阅 C3) 或尽早使用 csscan 来避免问题的发生。
如果 csscan 报告有可能发生数据丢失，那么不要使用 export/import
如果要在现有数据库之间导出/导入特定的用户或表，且其中一个数据库是 UTF8 或 AL32UTF8 数据库，则请参阅： Note 1297961.1 ORA-01401 / ORA-12899 While Importing Data In An AL32UTF8 / UTF8 (Unicode) Or Other Multibyte NLS_CHARACTERSET Database.
在所有 10g 版本（包括 10.1.0.5 和 10.2.0.3）和 11.1.0.6 中，使用数据抽取时，将 8 位字符集更改为 UTF8 / AL32UTF8 或其他多字节字符集可能会损坏数据。除非已应用 Patch 5874989 ，否则 Impdp 可能会损坏数据。
“旧”的导出/导入功能可以正常工作。10.2.0.4 和 11.1.0.7 补丁集中已修正此问题。
以下链接中包括了此故障的所有现有补丁集： https://updates.oracle.com/download/5874989.html
对于 Windows，修正程序包括在
10.1.0.5.0 Patch 20 (10.1.0.5.20P) 或更高版本中 ( Note 276548.1 )
10.2.0.3.0 Patch 11 (10.2.0.3.11P) 或更高版本中 ( Note 342443.1 )
从技术角度看，只需要在 impdp 端应用补丁集，但是如果您在不同的字符集之间使用 expdp/impdp，我们建议您对所有系统应用补丁集。
注意对于 Transportable tablespaces 的局限: note 297396.1 The Character Set Check Performed When Plugging In a Transportable Tablespace 或者文档 http://docs.oracle.com/cd/E11882_01/server.112/e25494/tspaces.htm#i1007233
C3) 组合使用 ALTER DATABASE CHARACTER SET（8i、9i）/ CSALTER（10g 和 11g）与 “export/import” 操作
在大多数情况下 Csscan 会指出有些数据需要转换为新的字符集（“Convertible”数据），而方法 c2 又会占用太多时间。
在这些情况下，通常可以混合使用 export/import 和 ALTER DATABASE CHARACTER SET（8i、9i）/ CSALTER（10g 和 11g）：
a) 导出 Csscan 列出的表中的“Convertible”数据（即代码在当前字符集和新字符集之间会发生转换的字符）
b) truncate 或 drop 掉这些表。
c) 再次运行 csscan，以确保所有数据现已准备好直接移到新字符集中，如果确实已准备就绪，则使用 ALTER DATABASE CHARACTERSET（8i、9i）/CSALTER（10g 和 11g）命令更改数据库的字符集。
d)由于字符集现已更改，我们只需导入在步骤 (a) 导出的数据。导入操作将转换该数据，并使用该新字符集的正确字符代码进行存储。
在 8i、9i、10g 和 11g 中的 8 位字符集之间执行字符集转换的分步指南 。
下面这些文章会指导您完成一些常用的转换操作，其中介绍了如何将上述“组合方法”（如果需要）付诸实践以及如何进行额外的校验：
从 US7ASCII 更改为 WE8MSWIN1252 或从其他 xxIOS8859Pxx 更改为 xx8MSWIN12xx 字符集
Note 555823.1 Changing from US7ASCII or WE8ISO8859P1 to WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 1213683.1 Changing from US7ASCII or WE8ISO8859P1 or IW8ISO8859P8 to IW8MSWIN1255 in 8i, 9i, 10g and 11g
Note 260022.1 Changing From US7ASCII or WE8ISO8859P1 or AR8ISO8859P6 to AR8MSWIN1256 in 8i, 9i, 10g and 11g
Note 261871.1 Changing EL8ISO8859P7 to EL8MSWIN1253 in 8i, 9i, 10g and 11g
Note 263119.1 Changing EE8ISO8859P2 to EE8MSWIN1250 in 8i, 9i, 10g and 11g
Note 266309.1 Changing WE8ISO8859P9 to WE8ISO8859P1/WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 246008.1 Changing WE8ISO8859P15 to WE8MSWIN1252 in 8i, 9i, 10g and 11g
其他组合：
Note 1104893.1 Changing US7ASCII TO WE8ISO8859P1 in 8i, 9i, 10g and 11g
Note 1963942.1 Changing WE8DEC to WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 in 8i, 9i, 10g and 11g
Note 257722.1 Changing WE8ISO8859P1 to WE8ISO8859P15 in 8i, 9i, 10g and 11g
Note 261639.1 Changing WE8MSWIN1252 to WE8ISO8859P15 in 8i, 9i, 10g and 11g
Note 273281.1 Changing WE8ISO8859P15 TO WE8ISO8859P1 in 8i, 9i, 10g and 11g
如果要转换成 ZHS16GBK, ZHT16MSWIN950, ZHT16HKSCS, ZHT16HKSCS31,KO16MSWIN949, JA16SJIS 这样的字符集，步骤同文档 Note:260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) 是一样的。
我们强烈推荐使用 AL32UTF8 做数据库的 NLS_CHARACTERSET。使用上边的字符集没有什么额外的价值。
基本上 AL32UTF8 是大势所趋，AL32UTF8 支持所有其它字符集定义的字符。
C4) 在 8i、9i、10g 和 11g 中将字符集转换为 Unicode (UTF8/AL32UTF8) 的分步指南（包括导出/导入操作）
人们经常会有一个错误的认识,认为简单的使用NCHAR, NVARCHAR2 和 NCLOB就可以让应用程序变得Unicode化,并且比改变NLS_CHARACTERSET花费的工作更少.
However N-types are rather poorly supported in (other vendor) programming languages and on application level in general.
但是一般的N-类型在编程语言以及应用的角度上的支持是很差的.为了使用N-类型,应用程序需要显式的支持.
所以Oracle一般建议使用NLS_CHARACTERSET, CHAR, VARCHAR2 , LONG 和 CLOB 这样的数据类型,而不是N-类型的数据类型.
转换到 Unicode ( AL32UTF8 or UTF8 NLS_CHARACTERSET) 可以：
根据文档 Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode), 里边也包括了如何使用 csscan 的步骤。
或者使用部分 export/import 加 csscan / csalter 将现有的数据库转换掉。
或者使用全库 export/import 迁移到一个新的 AL32UTF8 数据库。
或者使用 DMU 工具将现有数据库转换成 AL32UTF8 ，参见 Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool
DMU 支持11.2.0.3 及之后版本的数据库以及某些选定的旧版本/平台的组合。
建议在使用 DMU 转换前阅读文档 Note 1272374.1 以及 note 1522722.1 Known Issues With The Database Migration Assistant for Unicode (DMU) Tool version 1.2 (current version)
究竟使用 csscan 加 csalter及部分 export/import，还是使用 DMU 工具，或者使用全库 export/import 我们没有特别的推荐。
一般来说 DMU 工具
对用户更友好
在转换一个已存在的数据库时，转换过程不需要 export/import
如果有很多数据需要修正那么它更简单(通常发生在 US7ASCII 或 WE8ISO8895P1 的数据库上)
如果需要操作的数据量比较少那么它比csscan/csalter/部分 export/import 快。
一般来说 csscan 加 csalter 以及部分 export/import ( = 按Note 260192.1的所有步骤操作)
喜欢用脚本的人更倾向于使用
过去就知道或者使用过
如果操作的数据量比较打那么它比 DMU 工具快。
一般来说如果迁移到新的机器那么通常先使用csscan转换，之后使用全库 export/import。 (检查文档 Note 260192.1 的前六步和第12步)
导入一个新的AL32UTF8数据库 （如果是迁移到新的机器上）
导入到同一台机器的另一个新建的AL32UTF8数据库中 (这样的步骤最少，如果可以容忍停机时间的话)
这三种方式最终的成果是一样的，都是转换成 AL32UTF8。
我们也无法知道究竟哪种方法更快，只能通过测试才能知道。
最好先阅读 Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications，特别是 "c) the Client side", 关于 NLS_LANG 通常有很多误解。
将 NLS_CHARACTERSET 从 UTF8 改为 AL32UTF8 (或者从 AL32UTF8 到 UTF8) 可以通过 Note 260192.1 Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) in 8i, 9i, 10g and 11g. 来实现。
C5) Physical / Logical Standby 数据库如何操作?
如果配置中涉及到 Logical Standby 数据库，那么在修改了主库字符集后 Logcial Standby 数据库必须重建。其它修改 logical standby 数据库的字符集的方式我们都不支持。
Logical standby 数据库需要同主库有相同的 NLS_CHARACTERSET，而且如果说先修改 Logical Standby 的字符集，之后的 SQL apply 也不会成功。
对于版本低于11.1.0.7的 Physical Standy 数据库，备库也需要重建。
对于11.1.0.7 之后的 Physical Standbys 不需要重建, 详见 Note 1124165.1 Changing Primary Database Character Set without Recreating Data Guard Physical Standbys
C6) 如何将数据库从 AL32UTF8/UTF8 改回另外的字符集?
如果您已经有了一个 AL32UTF8 或者 UTF8 但是后来发现应用程序不支持 AL32UTF8 或者 UTF8，那么您可以通过 note 1283764.1 Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET in 8i, 9i, 10g and 11g 将 NLS_CHARACTERSET 改为另外一个。
注意在很多情况下这会造成数据丢失。
D) 在 Oracle 12c 中将数据库字符集修改为 Unicode(UTF8/AL32UTF8)
对于将已经存在的数据库字符集迁移至AL32UTF8 (以及已经废弃的 UTF8)，在 12c 中我们提供了工具 Database Migration Assistant for Unicode (DMU)。
DMU 工具是唯一的下一代的用来将字符集迁移至 Unicode 的工具。
DMU 提供的交互界面能极大的简化迁移的步骤并且不需要 DBA 有太多的字符集移植经验，同时它还自动完成了很多移植过程需要的操作。
详见文档 Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool.
从 Oracle database 12c开始，迁移 NLS_CHARACTERSET 只能使用工具DMU： Note 1418321.1 CSSCAN and CSALTER To Be Desupported after DB 11.2.
E) 12c Multitenant Container Databases (CDB) 和 Pluggable Databases (PDB) 中字符集的限制:
如何把一个字符集不同的pdb插入到CDB中,请参照请参照
note 1968706.1 ORA-65116/65119: incompatible database/national character set ( Character set mismatch: PDB character set CDB character set )
或者
参见如下文档 Oracle® Database Globalization Support Guide 12c Release 1 (12.1) , 2 Choosing a Character Set , Choosing a Database Character Set for a Multitenant Container Database
http://docs.oracle.com/cd/E16655_01/server.121/e17750/ch2charset.htm#NLSPG1035
DMU工具是唯一一个可以用来把pdb从非Unicode转换成Unicode的工具,参照文档 note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool / 13) How to convert non-Unicode PDB's to Unicode PDB's?
F) 其他阅读材料
更改 Oracle Application 数据库的字符集时，还有一些其他注意事项，有关这些事项的完整概述，请参阅以下文章： Note 124721.1 Migrating an Applications Installation to a New Character Set
客户端配置：
Note 788156.1 AL32UTF8 / UTF8 (Unicode) Database Character Set Implications / point "c) the Client side",
Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?)
Note 179133.1 The correct NLS_LANG in a Windows Environment
Note 264157.1 The correct NLS_LANG on Unix Environments
Note 229786.1 NLS_LANG and webservers explained.
有关调试指南的详细信息，请参阅 Note 788931.1 Troubleshooting RDBMS (client and server) NLS Problems (Charactersets, sorts, dates, ..)
Note that NLS_LANGUAGE and NLS_TERRITORY have nothing to do with the ability to *store* characters in a database.
A database using WE8MSWIN1252 NLS_CHARACTERSET and JAPANESE JAPAN as NLS_LANGUAGE and NLS_TERRITORY will *not* allow you to store Japanese as WE8MSWIN1252 doesn't define Japanese characters.
A database using AL32UTF8 NLS_CHARACTERSET and AMERICAN AMERICA as NLS_LANGUAGE and NLS_TERRITORY *will* allow you to store Japanese (or any other language in the world for that matter).
参考
NOTE:264157.1 - The Correct NLS_LANG Setting in Unix Environments
NOTE:246008.1 - Changing WE8ISO8859P15 to WE8MSWIN1252 in 8i, 9i, 10g and 11g.
NOTE:444701.1 - Csscan Output Explained
NOTE:1051824.6 - What languages are supported in an Unicode (UTF8/AL32UTF8) database?
NOTE:555823.1 - Changing US7ASCII or WE8ISO8859P1 to WE8MSWIN1252 in 8i, 9i, 10g and 11g
NOTE:66320.1 - 8i/9i only: Changing the Database Character Set or the Database National Character Set in 8i/9i
NOTE:342443.1 - 10.2.0.x Oracle Database and Networking Patches for Microsoft Platforms
NOTE:745809.1 - Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
NOTE:273281.1 - Changing WE8ISO8859P15 TO WE8ISO8859P1 in 8i, 9i, 10g and 11g
NOTE:263119.1 - Changing EE8ISO8859P2 to EE8MSWIN1250
NOTE:266309.1 - Changing WE8ISO8859P9 to WE8ISO8859P1/WE8MSWIN1252
NOTE:788931.1 - Troubleshooting RDBMS (client and server) NLS Problems (Charactersets, sorts, dates, ..)
NOTE:458122.1 - Installing and Configuring Csscan in 8i and 9i (Database Character Set Scanner)
NOTE:257722.1 - Changing WE8ISO8859P1 to WE8ISO8859P15 in 8i, 9i, 10g and 11g.
NOTE:261871.1 - Changing EL8ISO8859P7 to EL8MSWIN1253
NOTE:264294.1 - Choosing between WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as NLS_CHARACTERSET
NOTE:179133.1 - The Correct NLS_LANG in a Microsoft Windows Environment
NOTE:282336.1 - Charts of most current mono-byte / 8 bit Character sets
NOTE:260022.1 - Changing From US7ASCII or WE8ISO8859P1 or AR8ISO8859P6 to AR8MSWIN1256 in 8i, 9i, 10g and 11g.
NOTE:261639.1 - Changing WE8MSWIN1252 TO WE8ISO8859P15 in 8i, 9i, 10g and 11g
NOTE:260192.1 - Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) in 8i, 9i , 10g and 11g
NOTE:1104893.1 - Changing WE8DEC to WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 in 8i, 9i, 10g and 11g.
NOTE:229786.1 - NLS_LANG and webservers explained.
NOTE:1283764.1 - Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET in 8i, 9i , 10g and 11g
NOTE:158577.1 - NLS_LANG Explained (How does Client-Server Character Conversion Work?)
NOTE:1297507.1 - Problems with (Importing) Encrypted Data After Character Set Change Using Other NLS_CHARACTERSET Database or Upgrading the (client) Oracle Version
NOTE:276914.1 - The National Character Set ( NLS_NCHAR_CHARACTERSET ) in Oracle 9i, 10g , 11g and 12c
NOTE:1213683.1 - Changing from US7ASCII or WE8ISO8859P1 or IW8ISO8859P8 to IW8MSWIN1255 in 8i, 9i, 10g and 11g.
NOTE:119164.1 - Alter Database Character Set - Valid Superset Definitions
NOTE:1297961.1 - ORA-01401 / ORA-12899 / ORA-01461 While Importing Or Loading Data In An AL32UTF8 / UTF8 (Unicode) Or Other Multibyte NLS_CHARACTERSET Database.
NOTE:306411.1 - Character Set Consolidation for the Oracle Database ( 11gR1 and up) - what character sets are available in the DBCA (Database Creation Assistant)
NOTE:333489.1 - Choosing a database character set means choosing Unicode
NOTE:1272374.1 - The Database Migration Assistant for Unicode (DMU) Tool
NOTE:788156.1 - AL32UTF8 / UTF8 (Unicode) Database Character Set Implications
NOTE:124721.1 - Migrating an E-Business Suite Installation to a New Character Set
NOTE:223706.1 - Using Locale Builder to view the definition of character sets
NOTE:62421.1 - Which Character Set Supports Which Language
12c Multitenant Container Databases (CDB) and Pluggable Databases (PDB) Character set restrictions / ORA-65116/65119: incompatible database/national character set ( Character set mismatch: PDB character set CDB character set ) (文档 ID 1968706.1)
In this Document
| Symptoms |
| Cause |
| Solution |
| References |
APPLIES TO:
Database Migration Assistant for Unicode - Version 2.0 to 2.1
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.2 [Release 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Information in this document applies to any platform.
SYMPTOMS
After plugged a pluggable database (PDB) into a container database (CDB) , The following Warning is in the alert log file :
***************************************************************
WARNING: Pluggable Database PDB1 with pdb id - 4 is
altered with errors or warnings. Please look into
PDB_PLUG_IN_VIOLATIONS view for more details.
***************************************************************
SQL> select NAME,CAUSE,TYPE,ERROR_NUMBER,MESSAGE,STATUS,ACTION from PDB_PLUG_IN_VIOLATIONS;
NAME CAUSE TYPE ERROR_NUMBER
------------------------------ ---------------------------------------------------------------- --------- ------------
MESSAGE
-----------------------------------------------------------------------------------------------------------------------
STATUS
---------
ACTION
-----------------------------------------------------------------------------------------------------------------------
PDB1 Database CHARACTER SET ERROR 65116
Character set mismatch: PDB character set WE8MSWIN1252. CDB character set AL32UTF8.
PENDING
Convert the character set of the PDB to match the CDB or plug the PDB in a CDB with compatible character set
If the NLS_NCHAR_CHARACTERSET differs between PDB and CDB you will see
National character set mismatch: PDB national character set UTF8. CDB national character set AL16UTF16.
or
National character set mismatch: PDB national character set AL16UTF16. CDB national character set UTF8.
CAUSE
The pluggable database (PDB) and the container database (CDB) character sets/national character sets are not binary subsets ,
You can check the multitenant container database (CDB) character sets (NLS_CHARACTERSET) and national character set (NLS_NCHAR_CHARACTERSET) set by :
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> select value,parameter from NLS_DATABASE_PARAMETERS where PARAMETER like '%CHARACTERSET';
VALUE PARAMETER
--------------- ----------------------
AL16UTF16 NLS_NCHAR_CHARACTERSET
AL32UTF8 NLS_CHARACTERSET
You can check the pluggable database (PDB) character sets (NLS_CHARACTERSET) and national character set (NLS_NCHAR_CHARACTERSET) set by :
SQL> alter session set container=pdb1;
Session altered.
SQL> select value,parameter from NLS_DATABASE_PARAMETERS where PARAMETER like '%CHARACTERSET';
VALUE PARAMETER
--------------- ----------------------
AL16UTF16 NLS_NCHAR_CHARACTERSET
WE8MSWIN1252 NLS_CHARACTERSET
SOLUTION
In Oracle Database 12c, all pluggable databases (PDBs) in a container database (CDB) must have
* the same Database character set (NLS_CHARACTERSET) or the NLS_CHARACTERSET need to be a (Plug-in compatible) binary subset of the CDB NLS_CHARACTERSET
* the same National character set ( NLS_NCHAR_CHARACTERSET) as the CDB's root container
in order to be able to plug in.
If PDB NLS_CHARACTERSET is a (Plug-in compatible) binary subset of the CDB's NLS_CHARACTERSET the NLS_CHARACTERSET of the PDB is automatically changed to the NLS_CHARACTERSET of the CDB at the first open.
The character sets of the root container are considered the character sets of the whole CDB.
You can consolidate multiple databases by plugging them into a single CDB. These databases can be traditional, non-CDBs or PDBs unplugged from other CDBs.
A) The Database character set (NLS_CHARACTERSET)
Three situations may happen depending on the Database character set (NLS_CHARACTERSET) of a database being plugged in, that is, a new PDB:
1- The PDB NLS_CHARACTERSET is the same as the NLS_CHARACTERSET of the CDB. In this case, the plugging operation succeeds (as far as the database character set is concerned).
2- The PDB NLS_CHARACTERSET is (Plug-in compatible) binary subset of the CDB's NLS_CHARACTERSET and both are single-byte or both are multibyte.
In this case, the NLS_CHARACTERSET of the new PDB is automatically changed to the NLS_CHARACTERSET of the CDB at the first open and the plugging operation succeeds.
examples:
CDB is WE8MSWIN1252 NLS_CHARACTERSET, PDB is US7ASCII or WE8ISO8859P1 NLS_CHARACTERSET
CDB is TR8MSWIN1254 NLS_CHARACTERSET, PDB is US7ASCII or WE8ISO8859P9 NLS_CHARACTERSET
CDB is any xx8xxxxx characterset NLS_CHARACTERSET , PDB is US7ASCII NLS_CHARACTERSET
CDB is AL32UTF8 NLS_CHARACTERSET, PDB is UTF8 NLS_CHARACTERSET
3- The PDB NLS_CHARACTERSET is not plug-in compatible with the NLS_CHARACTERSET of the CDB. In this case, the new PDB can only be opened in restricted mode for administrative tasks and cannot be used for production and ORA-65116 is Raised. Unless you have a tool that can migrate the NLS_CHARACTERSET of the new PDB to NLS_CHARACTERSET of the CDB, the new PDB is unusable.
examples of common NOT plug-in compatible situations:
CDB is AL32UTF8 or UTF8 NLS_CHARACTERSET, PDB is US7ASCII or any xx8xxxxx NLS_CHARACTERSET.
CDB is WE8MSWIN1252 NLS_CHARACTERSET, PDB is WE8ISO8859P15 NLS_CHARACTERSET
CDB is AR8MSWIN1256 NLS_CHARACTERSET , PDB is AR8ISO8859P6 NLS_CHARACTERSET
See Also:
http://docs.oracle.com/database/121/NLSPG/applocaledata.htm#NLSPG591
Table Binary Subset-Superset Pairs
If the CDB NLS_CHARACTERSET is AL32UTF8 then use the DMU tool Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool
Note that the DMU tool cannot convert a non-Unicode CDB to AL32UTF8 as this is not needed.
You will receive the following error upon connecting to CDB using the DMU : Encountered an error while checking database's compatibility: Migration of container databases (CDB) is not supported.
To go from a non-Unicode CDB with (also non-Unicode) PDB's the steps are:
* Create a new Unicode (AL32UTF8) CDB if needed
* Use the DMU to scan the non-Unicode PDB's and resolve any reported convertibility issues while it is still plugged into the original non-Unicode CDB.
* Unplug the PDB to be migrated and plug it into the target Unicode AL32UTF8 CDB (this will put the PDB into restricted mode due to the character set incompatibility).
* Use the DMU tool to convert the non-Unicode PDB to Unicode once plugged in the target Unicode AL32UTF8 CDB (= finish the conversion).
To consolidate non-Unicode non-pluggable/non-container databases in one Unicode (AL32UTF8) container CDB Oracle suggest to migrate each one to AL32UTF8 before doing the consolidation (= before trying to make them pluggable) .
B) The National character set (NLS_NCHAR_CHARACTERSET)
Two situations may happen depending on the National character set of the new PDB:
1- The PDB NLS_NCHAR_CHARACTERSET set is the same as the NLS_NCHAR_CHARACTERSET of the CDB. In this case, the plugging operation succeeds (as far as the national character set is concerned).
2- The PDB NLS_NCHAR_CHARACTERSET is not the same as the NLS_NCHAR_CHARACTERSET of the CDB. In this case, the new PDB can only be opened in restricted mode for administrative tasks and cannot be used for production and ORA-65119 is raised . Unless you have a tool that can migrate the NLS_NCHAR_CHARACTERSET of the new PDB to the NLS_NCHAR_CHARACTERSET of the CDB, the new PDB is unusable.
Note that difference between NLS_CHARACTERSET and NLS_NCHAR_CHARACTERSET Note 276914.1 The National Character Set ( NLS_NCHAR_CHARACTERSET ) in Oracle 9i, 10g , 11g and 12c
The NLS_NCHAR_CHARACTERSET can have only 2 values: UTF8 and AL16UTF16 , AL16UTF16 is the recommended value.
There is currently no tool , besides full export/import into a new PDB, to change the NLS_NCHAR_CHARACTERSET once a database is 12c.
C) What CDB NLS_CHARACTERSET and NLS_NCHAR_CHARACTERSET to use.
Because of these restrictions, you should consider the character sets of databases that you want to plug into a given CDB when selecting character sets for this CDB.
In general Oracle recommends the following:
For all new deployments and if all PDBs are created empty, Oracle strongly recommends AL32UTF8 for the CDB database character set (NLS_CHARACTERSET) and AL16UTF6 for the CDB national character set ( NLS_NCHAR_CHARACTERSET ).
If you can migrate your existing databases to AL32UTF8 NLS_CHARACTERSET before consolidation, Oracle recommends that you do so and consolidate into one or more AL32UTF8 NLS_CHARACTERSET CDBs, depending on your needs. If the NLS_NCHAR_CHARACTERSET is UTF8 then Oracle suggest to change the NLS_NCHAR_CHARACTERSET to AL16UTF16 before consolidation.
You can use Oracle Database Migration Assistant for Unicode (DMU) to migrate a non-CDB NLS_CHARACTERSET to AL32UTF8. Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool
There is a few restrictions with DMU :
1- It does not support the migration of Oracle Database 12c Pluggable Databases (PDBs) to NLS_CHARACTERSET other than Unicode.
Oracle strongly recommends migrating the database character set to Unicode (AL32UTF8) NLS_CHARACTERSET before consolidating your databases.
2- You will receive the following error upon Initiating step 4 "convert database" using the DMU while being connected to PDB:
conversion feasibility test failed . the migration target character set is different from the CDB root character set.
To go from a non-Unicode CDB with (also non-Unicode) PDB's the steps are:
* Create a new Unicode (AL32UTF8) CDB
* Use the DMU to scan the non-Unicode PDB's and resolve any reported convertibility issues while it is still plugged into the original non-Unicode CDB.
* Unplug the PDB to be migrated and plug it into the target Unicode AL32UTF8 CDB (this will put the PDB into restricted mode due to the character set incompatibility).
* Use the DMU tool to convert the non-Unicode PDB to Unicode once plugged in the target Unicode AL32UTF8 CDB (= finish the conversion).
3- DMU does not support the migration of Oracle Database 12c container database (CDB) to any NLS_CHARACTERSET ( as this is not needed).
You will receive the following error upon connecting to CDB using the DMU :
Encountered an error while checking database's compatibility: Migration of container databases (CDB) is not supported.
The export/import migration methods could be used to overcome these limitations.
You can use Data Pump to migrate all, or portions of, a database from a non-CDB into a PDB, between PDBs within the same or different CDBs, and from a PDB into a non-CDB.
In general, using Data Pump with PDBs is identical to using Data Pump with a non-CDB.
Note: In Oracle Database 12c Release 1 (12.1), Data Pump does not support any CDB-wide operations. Data Pump issues the following warning if you are connected to the root or seed database of a CDB:
ORA-39357: WARNING: Oracle Data Pump operations are not typically needed when connected to the root or seed of a container database.
See Also: http://docs.oracle.com/database/121/SUTIL/GUID-45B17B65-20F2-4128-9A39-B1B0F5E323BB.htm#SUTIL4334
Using Data Pump With CDBs
If you cannot migrate your existing databases prior to consolidation, then you have to partition them into sets with plug-in compatible database NLS_CHARACTERSET and plug each set into a separate CDB with the appropriate superset NLS_CHARACTERSET.
For example, if you have US7ASCII, WE8ISO8859P1, WE8MSWIN1252, WE8ISO8859P15, JA16SJISTILDE, JA16EUC, KO16KSC5601, KO16MSWIN949, UTF8 and AL32UTF8 NLS_CHARACTERSET databases that you want to consolidate, you need to consolidate as follows:
- US7ASCII, WE8ISO8859P1, and WE8MSWIN1252 into a WE8MSWIN1252 CDB
- WE8ISO8859P15 into a WE8ISO8859P15 CDB
- JA16SJISTILDE into a JA16SJISTILDE CDB
- JA16EUC into a JA16EUC CDB
- KO16KSC5601, KO16MSWIN949 into a KO16MSWIN949 CDB
- UTF8 and AL32UTF8 into an AL32UTF8 CDB
Or use the DMU tool ( see Note 1272374.1 The Database Migration Assistant for Unicode (DMU) Tool ) to migrate the PDB to AL32UTF8 NLS_CHARACTERSET and use an AL32UTF8 NLS_CHARACTERSET CDB
Note that the DMU tool cannot convert a non-Unicode CDB to AL32UTF8 as this is not needed.
You will receive the following error upon connecting to CDB using the DMU : Encountered an error while checking database's compatibility: Migration of container databases (CDB) is not supported.
To go from a non-Unicode CDB with (also non-Unicode) PDB's the steps are:
* Create a new Unicode (AL32UTF8) CDB
* Use the DMU to scan the non-Unicode PDB's and resolve any reported convertibility issues while it is still plugged into the original non-Unicode CDB.
* Unplug the PDB to be migrated and plug it into the target Unicode AL32UTF8 CDB (this will put the PDB into restricted mode due to the character set incompatibility).
* Use the DMU tool to convert the non-Unicode PDB to Unicode once plugged in the target Unicode AL32UTF8 CDB (= finish the conversion).
Please make sure that if the NLS_NCHAR_CHARACTERSET is UTF8 but the CDB is using AL16UTF16 NLS_NCHAR_CHARACTERSET to change the NLS_NCHAR_CHARACTERSET to AL16UTF16 before consolidation (or inverse).
REFERENCES
NOTE:225912.1 - Changing Or Choosing the Database Character Set ( NLS_CHARACTERSET )
NOTE:1272374.1 - The Database Migration Assistant for Unicode (DMU) Tool