方案一：

UTF8包含了所有的GBK字符，不过只是编码不一样而已。字符集AL32UTF8和ZHS16GBK之间没有子集和超集的关系。

在已运行的数据库中，直接更改数据库字符集ZHS16GBK到AL32UTF8，中文字段无法匹配查询条件，例如name='张晓东’旧的数据无法查出，可以正常显示;但英文数字等可以正常匹配。

原来的gbk数据一个中文还是2个字节，新插入的变成3个字节；同时在数据库字符集为AL32UTF8，客户端为AL32UTF8可以保存及显示维文。

可见在保持字段类型varchar2不变的情况下，目前只能导出gbk库，再重新导入AL32UTF8库的方式，并将字段长度扩充为1.5倍;在导入的过程中，达到完成重新编码的目的。

方案二：

gbk库中将字段类型varchar2先修改为nvarchar2，在变更字符集AL32UTF8，可行。

两种字符集中nvarchar2，每个字符(英文，中文)，都占2个字节，查询显示也正常。

因为nvarchar2使用的是国家字符集(非数据库字符集)，默认为AF16UTF16。

经测试，nvarchar2在数据库字符集为AL32UTF8，客户端为AL32UTF8可以保存及显示维文；但客户端在ZHS16GBK环境下(非AL32UTF8)，nvarchar2依然不能正常保存显示维文。

因为涉及字符集的变更，需要整理所有中文字段，进行更改字段类型的操作。

 或者在相关表，只对已知的需要存储显示外文的字段，新增备用字段nvarchar2，以便保存外文等的unicode字符，并将原数据同步到对应字段，以后的查询显示以此为准。
 这种对原数据库的改动是最小的，扩展性差，需要程序配合。当然也可以直接将字段类型修改为nvarchar2。

关于ZHS16GBK与AL32UTF8库的互相访问：

客户端（注册表）ZHS16GBK/AL32UTF8

1、数据库AL32UTF8下，pl/sql直接查询gbk库，显示中文还是2字节；但在存储过程中的查询得到的中文，变成3字节。
可见，原库中的存储过程，涉及到中文参数的地方也应该扩大长度1.5倍。

2、数据库gbk下，pl/sql直接查询AL32UTF8库，显示中文3字节；但在存储过程中的查询得到的中文，变成2字节。

3、维文只有在客户端，数据库都是AL32UTF8下，才能正常显示和保存。

结论：

AL32UTF8关联gbk库，查询显示，入库正常;依然注意中文长度变3字节的问题。

显示时是数据库字符集与客户端字符集的转换;数据库入库处理中，变成客户端字符集与数据库字符集的转换