如何更改Oracle字符集
这里我们使用Oracle推荐的工具DMU（Database Migration Assistant for Unicode），该工具提供数据库从传统编码迁移到Unicode的端到端解决方案。通过在整个迁移流程中为DBA提供指导并实现许多迁移任务的自动化，DMU直观的用户界面极大简化了迁移流程并降低了对字符集迁移专业知识的要求。它采用可扩展的就地迁移架构，与传统的导出和导入迁移方法相比，可显著减少数据转换所需的工作河停机时间。对于迁移后的数据库和已经使用Unicode字符集的现有数据库，DMU还提供了一种验证模式，可识别未正确用Unicode编码的数据，从而对数据库应用中的Unicode实现的潜在问题进行健康检查。
1、创建恢复点
创建恢复点就是为了字符集转换失败回退使用的。
设置db_recovery_file_dest和db_recovery_file_dest_size两个参数 create restore point before_cs_change guarantee flashback database; select FLASHBACK_ON from v$database; 如果执行转换失败，执行如下命令恢复shutdown immediate;startup mount;flashback database to restore point before_cs_change;alter database open resetlogs;select FLASHBACK_ON from v$database;drop restore point before_cs_change;select FLASHBACK_ON from v$database; |
2、创建存放DMU repository的表空间
create tablespace tbs_dmu datafile ‘+xxx’ size 200m autoextend on; |
3、字符集转换
3.1 启动DMU工具
3.2 新建数据库连接
3.3 连接数据库
3.4 建立repository
3.5 扫描数据库
3.6 清洗数据
expand all之后，可以看到cs_test和cs_test3有问题。因为这2个表的a字段都是varchar2(4)，里面包含两个汉字的行，zhs16gbk是可以满足的，但是转换成AL32UTF8之后，2个汉字会占用6个字符，varchar2(4)就无法容纳了。在这里，我们对于两个表采用不同的修改方式：第一个表用手工清洗，第二个我们用bulk cleansing放在批量的方式中处理。
我们开始对第一个表进行手工清洗。点击cleansing editor
可以看到转换前后的差别
然后我们进行修改，点击schedule的modify，这样就能在最后convert阶段修改，而不是当前就修改了。
可以看到现在都已经变成了绿色。
选择Migrate to character length semantics，就原来是varchar2(4)，会修改成varchar2(4 char)。即按照实际使用的字符计算。
同样也选择schedule，即在convert阶段进行折现操作。
点击所有红圈和感叹号的对象。
可以看到需要转换的表。
两个表都被列在了计划中
3.7 转换字符集
点击convert database开始转换
注意看conversion step。列出来了convert的各个步骤，我们看到第一个步骤是修改一些参数和禁用一些trigger。可以防止在转换过程中触发内部操作。
第一步
第二步，是对字段进行了内部更新
第三步，这一步没有看到具体的sql。
第四步，是进行了internal_use的转换
第五步，是将刚刚bulk cleansing的字段进行修改，并且将在第一步中修改的参数复原
注意，在右上角，我们可以修改一些convert时的参数。如点击一个conversion parameters
我们可以选择并行度（就是第二步的update的语句的并发度），另外还有convert的进程数等。
3.8 验证结果
3.9 转换失败回退
