Oracle在数据转储时的字符集问题

如题所述

第1个回答  2022-10-30
  作为一个Oracle数据库的用户 对于Export和Import两个命令绝对不会感到陌生 因为这二者正是我们经常用于数据备份和恢复的工具 但在使用这两个命令过程中所发生的Oracle字符集问题 常给一些Oracle使用者带来不必要的麻烦和不必要的数据损失 本文将就Export和Import过程中Oracle字符集的转换规律及使用这两个命令的注意事项做一总结   字符集转换的原因     Export Import过程如上图所示 从这个示意图中可以看到有四处关系到字符集 而这四处字符集的不一致恰恰是导致Oracle进行字符集转换的原因   * 源数据库字符集   * Export过程中用户会话字符集   * Import过程中用户会话字符集   * 目标数据库字符集   在Export和Import过程中 如果存在影响字符集转换的四因素不一致 则可能发生Oracle字符集转换 即   在Export过程中 如果源数据库字符集与Export用户会话字符集不一致 会发生字符集转换 并在导出的二进制格式Dmp文件的头部几个字节中存储Export用户会话字符集的ID号 在这个转换过程中可能发生数据的丢失   例 : 如果源数据库使用ZHS GBK 而Export用户会话字符集使用US ASCII 由于ZHS GBK是 位字符集 而US ASCII是 位字符集 这个转换过程中 中文字符在US ASCII中不能够找到对等的字符 所以所有中文字符都会丢失而变成 ?? 形式 即这种转换后生成的Dmp文件已经发生了数据丢失   例 : 如果源数据库使用ZHS GBK 而Export用户会话字符集使用ZHS CGB 但由于ZHS GBK字符集是ZHS CGB 字符集的超集 这个过程中绝大部分字符都能够正确转换 只有一些超出ZHS CGB 字符集的字符变为 ?? 形式 如果源数据库使用ZHS CGB 字符集 而Export用户会话使用ZHS GBK字符集 则转换过程能够完全转换成功   在Import向目标数据库转换过程中 其字符集发生转换的情况正好与Export过程相反 这里不再详述   在Export导出的Dmp文件中 含有Export用户会话字符集 在Import过程中 首先发生的是Dmp文件字符集(即Export用户会话字符集)向Import用户会话字符集的转换 如果这个转换过程不能正确完成 Import向目标数据库的导入过程也就不能完成   进行字符集的正确转换  通常情况下 我们在使用Oracle的Export和Import过程中 并不希望发生字符的转换 但有时这种转换却是必要的 如我们在安装Oracle数据库时 选择ZHS CGB 字符集 由于这种字符集是一种中文小字符集 对于一些汉字不能够正确表示 这需要通过使用ZHS GBK字符集得到解决 此时就要进行字符集的转换   为了确保Export Import过程中 Oracle字符集不发生转换或正确转换 建议最好在进行这个过程前 检查一下源数据库字符集与Export用户会话字符集是否一致 源数据库字符集与目标数据库字符集是否一致 目标数据库字符与Import用户会话字符集是否一致 如果能够保证这四个字符集是一致的 则在Export Import过程中 Oracle字符集就不用发生转换   可用以下办法检查数据库字符集:   通过InitXXXX ora文件进行查看   借助SQL语句查看 SELECT NAME VALUE$ FROM SYS PROPS$ WHERE NAME= NLS_CHARACTERSET   对于Export Import用户会话字符集 在Windows系统中也可以通过注册表中的NLS_LANG进行查看或修改 对于Unix系统则可通过设置用户的环境变量NLS_LANG来查看或修改   特别要注意的是 Oracle数据库字符集通常是在创建时确定 一旦存储用户数据后就不要再修改了 因为其数据都是使用该字符集进行存储的 改换其他字符集之后 原有数据就不能够正确表示了 但如果确实想进行字符集改变 则可通过以下几步来实现   备份数据库后删除原数据(可物理备份 如使用Export 请注意确保字符集不发生转换或数据无损失)   使用Internal用户更新sys props$表中的字符集:  Update sys props$ set name= Dest CharSet Where name= NLS_CHARACTERSET ; MIT;   重启数据库   恢复数据   下面字符集之间的转换是可行的   字符集子集向字符集父集转换是可行的 如ZHS CGB 向ZHS GBK转换 而字符集父类向字符集子集进行转换时 会损失部分数据   只包含英文字符数据的双字节字符集也可向单字节字符集转换 如ZHS GBK(English Only)可以向US ASCII正确转换   编码范围相同的单字节字符集之间通常可以进行相互转换   请注意 这里所说的没有数据损失 是指一种字符集A转换成另一种字符集B之后 可以再从字符集B正确转换成字符集A或字符集B能够正确表示字符集A中转换过来的数据   字符集对程序的影响  根据一个字符需要多少位字节来表示 可以把字符集分为单字节字符集和多字节字符集 其中 单字节字符集又分为 位字符集和 位字符集 单字节 位编码字符集有US ASCⅡ 单字节 位编码字符集有符合ISO 标准规定的WE ISO P 等 多字节编码又分为固定长度(长度大于或等于 )编码模式和不固定长度编码模式 多字节编码字符集中的ZHS GBK ZHS CGB JA SJIS等是采用两个字节表示一个字符的字符集 又叫双字节字符集   一个英文字母是一个字符 一个中文汉字是几个字符呢?我们知道 一个中文汉字是双字节字符 但它有几个字符与其数据库字符集有关 如果数据库字符集使用单字节US ASCII 则一个中文汉字是二个字符 如果数据库字符集使用双字节字符集ZHS GBK 则一个中文汉字是一个字符 有关这一点可以使用Oracle的函数Substr得到证明   使用US ASCⅡ字符集时:   Select substr( 东北大学 ) from dual;   语句执行结果返回 东   使用ZHS GBK字符集时:   Select substr( 东北大学 ) from dual;   语句执行结果返回 东北   选择合适的数据库字符集  选择数据库字符集时应考虑以下事项    .数据库需要支持什么语言   在为数据库选择字符集时 常会发现几种字符集都适合你当前语言需求 如简体中文就有ZHS GBK和ZHSCGB 等字符集可供选择 应选择哪种?在选择字符集时 应考虑到数据库将来的系统需求 如果知道将来数据库要扩展支持不同的语言 选择一个范围较广的字符集会是一个更好的主意    .系统资源与应用之间的互作用性  选择的数据库字符集应保证操作系统与应用之间的无缝连接 如果选择的字符集不是操作系统有效的字符集 则系统就需要在这两者之间做字符转换 在这种字符转换过程中 就有可能发生一些字符丢失现象 从一种字符集A向另一种字符集B转换过程中 A中的字符必须在B中可以找到等价的字符 否则就会以 ? 来代替 从这个意义上说 如果两种字符集编码范围是相同的 则可以相互转换   字符集转换过程中会影响系统性能 因此 应保证客户端和服务器端有相同的字符集以避免字符集转换 也可以提高一定的系统性能    .系统的性能要求  不同的数据库字符集对于数据库的性能是有一定影响的 为了得到最好的数据库性能 选择的数据库字符集应避免字符转换 并且要选择对于期望的语言有最高效的编码效率 通常 单字节字符集比多字节字符集有更优的性能表现 在空间需求方面也更小些    .其他一些限制  在为数据库选择一个合适的字符集时 应参考Oracle对应版本的相关文档 检查Oracle对于一些字符集的限制 如Oracle 版本中 以下字符集是不能使用的: JA EUCFIXED ZHS GBKFIXED JA DBCSFIXED KO DBCSFIXED ZHS DBCSFIXED JA SJISFIXED ZHT TRISFIXED   综上所述 正确理解Oracle字符集的转换过程 可以使我们避免不必要的麻烦和数据损失 合理利用Oracle字符集的转换过程 也可以帮助我们正确地从一种字符集转换到另一种字符集 以满足我们各种不同的应用需求 lishixinzhi/Article/program/Oracle/201311/17956