17,382
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
fxbsmile 2003-02-27
- 打赏
- 举报
850到852
修改数据库
connect sys/change_on_install
update props$ set value$ = 'ZHS16CGB231280' where value$ = 'ZHS16GBK'
修改注册表
regedit
ORACLE HOME1 NLS_LANG: SIMPLIFIED CHINESE_CHINA.ZHS16CGB231280
852到850
connect sys/change_on_install
update props$ set value$ = ZHS16GBK where value$ = ZHS16CGB231280
regedit
修改注册表
ORACLE HOME1 NLS_LANG: SIMPLIFIED CHINESE_CHINA.ZHS16GBK
你可以结贴了，
修改数据库
connect sys/change_on_install
update props$ set value$ = 'ZHS16CGB231280' where value$ = 'ZHS16GBK'
修改注册表
regedit
ORACLE HOME1 NLS_LANG: SIMPLIFIED CHINESE_CHINA.ZHS16CGB231280
852到850
connect sys/change_on_install
update props$ set value$ = ZHS16GBK where value$ = ZHS16CGB231280
regedit
修改注册表
ORACLE HOME1 NLS_LANG: SIMPLIFIED CHINESE_CHINA.ZHS16GBK
你可以结贴了，
lnzyb 2003-02-27
- 打赏
- 举报
up
lnzyb 2003-02-27
- 打赏
- 举报
不了解呀，有没有什么具体解决的办法？？
我把老的数据库的database文件夹考到新的oravle中，找不到用户。为什么，不是说oracle支持文件移植吗？
我把老的数据库的database文件夹考到新的oravle中，找不到用户。为什么，不是说oracle支持文件移植吗？
CHENGTOM 2003-02-27
- 打赏
- 举报
字符集转换的原因
Export、Import过程如下图所示，从这个示意图中可以看到有四处关系到字符集，而这四处字符集的不一致恰恰是导致Oracle进行字符集转换的原因。
源数据库字符集；
Export过程中用户会话字符集；
Import过程中用户会话字符集；
目标数据库字符集。
在Export和Import过程中，如果存在影响字符集转换的四因素不一致，则可能发生Oracle字符集转换，即：
在Export过程中，如果源数据库字符集与Export用户会话字符集不一致，会发生字符集转换，并在导出的二进制格式Dmp文件的头部几个字节中存储Export用户会话字符集的ID号。在这个转换过程中可能发生数据的丢失。
例1: 如果源数据库使用ZHS16GBK，而Export用户会话字符集使用US7ASCII，由于ZHS16GBK是8位字符集,而US7ASCII是7位字符集，这个转换过程中，中文字符在US7ASCII中不能够找到对等的字符，所以所有中文字符都会丢失而变成“?? ”形式，即这种转换后生成的Dmp文件已经发生了数据丢失。
例2: 如果源数据库使用ZHS16GBK,而Export用户会话字符集使用ZHS16CGB231280，但由于ZHS16GBK字符集是ZHS16CGB231280字符集的超集，这个过程中绝大部分字符都能够正确转换，只有一些超出ZHS16CGB231280字符集的字符变为“?? ”形式。如果源数据库使用ZHS16CGB231280字符集，而Export用户会话使用ZHS16GBK字符集，则转换过程能够完全转换成功。
在Import向目标数据库转换过程中，其字符集发生转换的情况正好与Export过程相反，这里不再详述。
在Export导出的Dmp文件中，含有Export用户会话字符集。在Import过程中，首先发生的是Dmp文件字符集（即Export用户会话字符集）向Import用户会话字符集的转换。如果这个转换过程不能正确完成，Import向目标数据库的导入过程也就不能完成。
进行字符集的正确转换
通常情况下，我们在使用Oracle的Export和Import过程中，并不希望发生字符的转换，但有时这种转换却是必要的。如我们在安装Oracle数据库时，选择ZHS16CGB231280字符集，由于这种字符集是一种中文小字符集，对于一些汉字不能够正确表示，这需要通过使用ZHS16GBK字符集得到解决，此时就要进行字符集的转换。
为了确保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’; COMMIT;
重启数据库；
恢复数据。
下面字符集之间的转换是可行的：
字符集子集向字符集父集转换是可行的，如ZHS16CGB231280向ZHS16GBK转换；而字符集父类向字符集子集进行转换时，会损失部分数据。
只包含英文字符数据的双字节字符集也可向单字节字符集转换，如ZHS16GBK(English Only)可以向US7ASCII正确转换。
编码范围相同的单字节字符集之间通常可以进行相互转换。
请注意，这里所说的没有数据损失，是指一种字符集A转换成另一种字符集B之后，可以再从字符集B正确转换成字符集A或字符集B能够正确表示字符集A中转换过来的数据。
字符集对程序的影响
根据一个字符需要多少位字节来表示，可以把字符集分为单字节字符集和多字节字符集。其中，单字节字符集又分为7位字符集和8位字符集。单字节7位编码字符集有US7ASCⅡ，单字节8位编码字符集有符合ISO 8859-1标准规定的WE8ISO8859P1等。多字节编码又分为固定长度（长度大于或等于2）编码模式和不固定长度编码模式。多字节编码字符集中的ZHS16GBK、ZHS16CGB231280、JA16SJIS等是采用两个字节表示一个字符的字符集，又叫双字节字符集。
一个英文字母是一个字符，一个中文汉字是几个字符呢？我们知道，一个中文汉字是双字节字符，但它有几个字符与其数据库字符集有关。如果数据库字符集使用单字节US7ASCII，则一个中文汉字是二个字符；如果数据库字符集使用双字节字符集ZHS16GBK，则一个中文汉字是一个字符。有关这一点可以使用Oracle的函数Substr得到证明。
使用US7ASCⅡ字符集时:
Select substr(‘东北大学’,1,2) from dual;
语句执行结果返回‘东’。
使用ZHS16GBK字符集时:
Select substr(‘东北大学’,1,2) from dual;
语句执行结果返回‘东北’。
选择合适的数据库字符集
选择数据库字符集时应考虑以下事项：
1．数据库需要支持什么语言
在为数据库选择字符集时，常会发现几种字符集都适合你当前语言需求，如简体中文就有ZHS16GBK和ZHSCGB231280等字符集可供选择，应选择哪种？在选择字符集时，应考虑到数据库将来的系统需求。如果知道将来数据库要扩展支持不同的语言，选择一个范围较广的字符集会是一个更好的主意。
2．系统资源与应用之间的互作用性
选择的数据库字符集应保证操作系统与应用之间的无缝连接。如果选择的字符集不是操作系统有效的字符集，则系统就需要在这两者之间做字符转换。在这种字符转换过程中，就有可能发生一些字符丢失现象。从一种字符集A向另一种字符集B转换过程中，A中的字符必须在B中可以找到等价的字符，否则就会以“？”来代替。从这个意义上说，如果两种字符集编码范围是相同的，则可以相互转换。
字符集转换过程中会影响系统性能，因此，应保证客户端和服务器端有相同的字符集以避免字符集转换，也可以提高一定的系统性能。
3．系统的性能要求
不同的数据库字符集对于数据库的性能是有一定影响的。为了得到最好的数据库性能，选择的数据库字符集应避免字符转换，并且要选择对于期望的语言有最高效的编码效率。通常，单字节字符集比多字节字符集有更优的性能表现，在空间需求方面也更小些。
4．其他一些限制
在为数据库选择一个合适的字符集时，应参考Oracle对应版本的相关文档，检查Oracle对于一些字符集的限制。如Oracle 8.1.5版本中，以下字符集是不能使用的: JA16EUCFIXED、ZHS16GBKFIXED、JA16DBCSFIXED、KO16DBCSFIXED、ZHS16DBCSFIXED、JA16SJISFIXED、ZHT32TRISFIXED。
综上所述，正确理解Oracle字符集的转换过程，可以使我们避免不必要的麻烦和数据损失。合理利用Oracle字符集的转换过程，也可以帮助我们正确地从一种字符集转换到另一种字符集，以满足我们各种不同的应用需求。
Export、Import过程如下图所示，从这个示意图中可以看到有四处关系到字符集，而这四处字符集的不一致恰恰是导致Oracle进行字符集转换的原因。
源数据库字符集；
Export过程中用户会话字符集；
Import过程中用户会话字符集；
目标数据库字符集。
在Export和Import过程中，如果存在影响字符集转换的四因素不一致，则可能发生Oracle字符集转换，即：
在Export过程中，如果源数据库字符集与Export用户会话字符集不一致，会发生字符集转换，并在导出的二进制格式Dmp文件的头部几个字节中存储Export用户会话字符集的ID号。在这个转换过程中可能发生数据的丢失。
例1: 如果源数据库使用ZHS16GBK，而Export用户会话字符集使用US7ASCII，由于ZHS16GBK是8位字符集,而US7ASCII是7位字符集，这个转换过程中，中文字符在US7ASCII中不能够找到对等的字符，所以所有中文字符都会丢失而变成“?? ”形式，即这种转换后生成的Dmp文件已经发生了数据丢失。
例2: 如果源数据库使用ZHS16GBK,而Export用户会话字符集使用ZHS16CGB231280，但由于ZHS16GBK字符集是ZHS16CGB231280字符集的超集，这个过程中绝大部分字符都能够正确转换，只有一些超出ZHS16CGB231280字符集的字符变为“?? ”形式。如果源数据库使用ZHS16CGB231280字符集，而Export用户会话使用ZHS16GBK字符集，则转换过程能够完全转换成功。
在Import向目标数据库转换过程中，其字符集发生转换的情况正好与Export过程相反，这里不再详述。
在Export导出的Dmp文件中，含有Export用户会话字符集。在Import过程中，首先发生的是Dmp文件字符集（即Export用户会话字符集）向Import用户会话字符集的转换。如果这个转换过程不能正确完成，Import向目标数据库的导入过程也就不能完成。
进行字符集的正确转换
通常情况下，我们在使用Oracle的Export和Import过程中，并不希望发生字符的转换，但有时这种转换却是必要的。如我们在安装Oracle数据库时，选择ZHS16CGB231280字符集，由于这种字符集是一种中文小字符集，对于一些汉字不能够正确表示，这需要通过使用ZHS16GBK字符集得到解决，此时就要进行字符集的转换。
为了确保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’; COMMIT;
重启数据库；
恢复数据。
下面字符集之间的转换是可行的：
字符集子集向字符集父集转换是可行的，如ZHS16CGB231280向ZHS16GBK转换；而字符集父类向字符集子集进行转换时，会损失部分数据。
只包含英文字符数据的双字节字符集也可向单字节字符集转换，如ZHS16GBK(English Only)可以向US7ASCII正确转换。
编码范围相同的单字节字符集之间通常可以进行相互转换。
请注意，这里所说的没有数据损失，是指一种字符集A转换成另一种字符集B之后，可以再从字符集B正确转换成字符集A或字符集B能够正确表示字符集A中转换过来的数据。
字符集对程序的影响
根据一个字符需要多少位字节来表示，可以把字符集分为单字节字符集和多字节字符集。其中，单字节字符集又分为7位字符集和8位字符集。单字节7位编码字符集有US7ASCⅡ，单字节8位编码字符集有符合ISO 8859-1标准规定的WE8ISO8859P1等。多字节编码又分为固定长度（长度大于或等于2）编码模式和不固定长度编码模式。多字节编码字符集中的ZHS16GBK、ZHS16CGB231280、JA16SJIS等是采用两个字节表示一个字符的字符集，又叫双字节字符集。
一个英文字母是一个字符，一个中文汉字是几个字符呢？我们知道，一个中文汉字是双字节字符，但它有几个字符与其数据库字符集有关。如果数据库字符集使用单字节US7ASCII，则一个中文汉字是二个字符；如果数据库字符集使用双字节字符集ZHS16GBK，则一个中文汉字是一个字符。有关这一点可以使用Oracle的函数Substr得到证明。
使用US7ASCⅡ字符集时:
Select substr(‘东北大学’,1,2) from dual;
语句执行结果返回‘东’。
使用ZHS16GBK字符集时:
Select substr(‘东北大学’,1,2) from dual;
语句执行结果返回‘东北’。
选择合适的数据库字符集
选择数据库字符集时应考虑以下事项：
1．数据库需要支持什么语言
在为数据库选择字符集时，常会发现几种字符集都适合你当前语言需求，如简体中文就有ZHS16GBK和ZHSCGB231280等字符集可供选择，应选择哪种？在选择字符集时，应考虑到数据库将来的系统需求。如果知道将来数据库要扩展支持不同的语言，选择一个范围较广的字符集会是一个更好的主意。
2．系统资源与应用之间的互作用性
选择的数据库字符集应保证操作系统与应用之间的无缝连接。如果选择的字符集不是操作系统有效的字符集，则系统就需要在这两者之间做字符转换。在这种字符转换过程中，就有可能发生一些字符丢失现象。从一种字符集A向另一种字符集B转换过程中，A中的字符必须在B中可以找到等价的字符，否则就会以“？”来代替。从这个意义上说，如果两种字符集编码范围是相同的，则可以相互转换。
字符集转换过程中会影响系统性能，因此，应保证客户端和服务器端有相同的字符集以避免字符集转换，也可以提高一定的系统性能。
3．系统的性能要求
不同的数据库字符集对于数据库的性能是有一定影响的。为了得到最好的数据库性能，选择的数据库字符集应避免字符转换，并且要选择对于期望的语言有最高效的编码效率。通常，单字节字符集比多字节字符集有更优的性能表现，在空间需求方面也更小些。
4．其他一些限制
在为数据库选择一个合适的字符集时，应参考Oracle对应版本的相关文档，检查Oracle对于一些字符集的限制。如Oracle 8.1.5版本中，以下字符集是不能使用的: JA16EUCFIXED、ZHS16GBKFIXED、JA16DBCSFIXED、KO16DBCSFIXED、ZHS16DBCSFIXED、JA16SJISFIXED、ZHT32TRISFIXED。
综上所述，正确理解Oracle字符集的转换过程，可以使我们避免不必要的麻烦和数据损失。合理利用Oracle字符集的转换过程，也可以帮助我们正确地从一种字符集转换到另一种字符集，以满足我们各种不同的应用需求。
lnzyb 2003-02-27
- 打赏
- 举报
把原nt系统的数据倒入到2000server系统中.nt系统的注册表中的字符集是台湾的BIG5,sqlplus中的字符集是231080的字符集。2000中的字符集是ZHS16GBK。在倒入时字符集不对。我把2000系统中的字符集修改成nt的字符集时不好用。请问是否有其他办法
lnzyb 2003-02-27
- 打赏
- 举报
修改后是否用重心启动计算机？式过。不成
bearpp 2003-02-27
- 打赏
- 举报
set NLS_LANG AMERICAN_AMERICA.ZHS16CGB231280
lnzyb 2003-02-27
- 打赏
- 举报
我式过修改注册表，但不成功
lnzyb 2003-02-27
- 打赏
- 举报
直接拷贝database 文件夹是否好使？？？？？？？？？？？？
CHENGTOM 2003-02-27
- 打赏
- 举报
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=FOR&p_id=294416.999
看看这个吧。
看看这个吧。
CHENGTOM 2003-02-27
- 打赏
- 举报
你将为此付出很大的代价。我们将从两个方面来说明问题。
首先字符集转换并非单纯的更新PROPS$表，它只是第一步。比如第二步必须是更新cols$.charset_id字段。你可以用oradebug 输出trace查看
其直接后果将使某些data dictionary信息无法访问，如表的statistics，OPTIMIZER也将无法正常工作
第二方面，直接更新此表并不转换存储内容的字符集，比如原先是zhs16gbk的，直接:
update sys.props$ set name = 'UTF8' where name = 'NLS_CHARACTERSET';
将会使汉字乱码。
在9i里面，直接Update数据库字符集，还会造成优化器的极度变态工作。
最后还是重新Create的Database。
这个同时还会导致Exp等出错
从US7ASCII到别的，可以直接ALTER DATABASE实现。
别的几乎都不可以。
只有从严格的子集到父集，才能这样实现。
首先字符集转换并非单纯的更新PROPS$表，它只是第一步。比如第二步必须是更新cols$.charset_id字段。你可以用oradebug 输出trace查看
其直接后果将使某些data dictionary信息无法访问，如表的statistics，OPTIMIZER也将无法正常工作
第二方面，直接更新此表并不转换存储内容的字符集，比如原先是zhs16gbk的，直接:
update sys.props$ set name = 'UTF8' where name = 'NLS_CHARACTERSET';
将会使汉字乱码。
在9i里面，直接Update数据库字符集，还会造成优化器的极度变态工作。
最后还是重新Create的Database。
这个同时还会导致Exp等出错
从US7ASCII到别的，可以直接ALTER DATABASE实现。
别的几乎都不可以。
只有从严格的子集到父集，才能这样实现。
CHENGTOM 2003-02-27
- 打赏
- 举报
哎，又一个update props$的，这样会害死人的
