彻底弄清楚字符集问题(取消置顶，已经加入精华区)

biti_rainy

按照guo的说法
nls_database_parameters是跟随props而变化的么？
他们都应该是实际的表，我觉得不应该立即有相应变化
v$这种表应该是适时变化的，也是对应于props？
props是数据解释的用途，也是数据库最基础的字符集？
但我似乎觉得既然是解释用途，那么存储格式就应该不是它才对，那存储到底是什么呢

据说props修改后重新启动数据库后props会恢复到原状，是这样么？
如果这个说法成立
那我猜测可能是props是作为数据解释用途
nls_database_parameters则是存储数据库安装时选择的字符集，（是不可改变的？）
当数据库重新启动的时候则变为跟nls_database_parameters保持一致
而props的可修改就是为了有包含关系下的字符集的导入

那安装时候选择的字符集，在哪里可以查看出来呢（当前假设已经修改props）
如果数据库安装后存储格式不可更改，就一定有一个参数或者表应该是不可更改的

biti_rainy

只要做测试就可以做到
可惜我连不同字符集的数据库都没有，现有数据库也不允许我这样折腾，我自己机器没有数据库  ：（

就怕有一点，还有别的表或者参数什么起了决定作用，到头来我也只能推翻了自己的猜测而无法找出正确的解释
所以还望各位GGJJDDMM共享这方面的经验
这样让大家以后不但知其然还要知其所以然

westapple

我也对此一塌糊涂，有人能给个较全面的深刻介绍吗。
辛苦辛苦斑竹了。

westapple

斑竹，能不能置顶两天，多听听大家的心得经验！！

xzforacle

SYS.PROPS$的修改主要是对应客户端的显示，应该与存储无关。按照ORACLE的说法数据库的字符集是在建立数据库时就确定的不可更改。在建好的数据库上你可以通过更改SYS.PROPS和客户端的参数来获得所需的显示，存储对你来说是透明的。
所以一般情况下不需要修改数据库的字符集
在确实要修改的情况下，可以使用 EXP/IMP 来实现转换。但是只能从子集转到超集。

这是结合文档和使用的经验所得。如用不当之处请大家指出。。。。。。。谢谢！

xzforacle

最初由 chao_ping 发布
[B]

直接编辑dmp文件？
建议还是spool出来，然后用工具转换，最后在用sqlldr到回去比较合适？ [/B]

能说详细点吗？

xzforacle

了解ORACLE的NLS
ORACLE SERVER NLS ARCHITECTURE
ORACLE 的支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。
参数设置决定了个体常规的行为。
LOCALE-INDEPENDENT OPERATION
ORACLE使用运行时间库来实现支持国家语言的体系结构。这NLS提供了
一套综合的与语言无关的函数，它允许适当的文本和字符处理以及语言的常规
操作。这些函数在运行时标识和载入一套本地专用的数据来管理专门的语言和地区。这些本地专用的数据存储在环境变量ORA_NLS*所指定的目录中。对每一个新版本，ORA_NLS数据目录都用一个不同的对应。在ORACLE8I中为ORA_NLS33。在UNIT平台中ORA_NLS33变量被设置为$ORACLE_HOME/ocommon/nls/admin/data。在WIN32平台中当一个ORACLE_HOME刚好对应一个ORACLE版本时这默认设置将工作的很好。如果你的数据库运行一多版本的ORACLE环境中，你必须确保设置适当的NLS_ORA*对应有效版本的NLS数据文件。
使用一个引导文件来决定有效的NLS对象的载入。ORACLE支持系统和用户的引导文件。这用户引导文件使你能灵活的定制数据库的有效的NLS本地对象。因此帮助你控制内存消耗。也能添加新的本地化数据并且定制一些本地化数据的组成。
CLIENT/SERVER ARCHITACTURE
   ORACLE8I由客户/服务体系结构组成。与语言相关的操作在客户和服务端都由一个参数和环境变量来控制。在服务器上每一个开始的会话，在客户方都可能有相同或不同的本地环境，并且有着相同或不同的规定的语言需求。数据库建立时也有一套会话无关的规定的NLS参数。包括数据库和国家字符集。他们规定在数据库中使用字符集存储文本数据。其他参数，如语言和地区，在检查约束的估计是使用。
   当客户和服务规定了不同的字符集时，ORACLE将自动控制字符串的常规字符集。
   就ORACLE的体系结构而言，所有应用，甚至那些运行在相同机器上的ORACLE实例，客户机要被考虑。例如，SQL*PLUS开始，被一个拥有ORACLE软件的UNIX用户使用RDBMS软件通过指定ORACLE_SID的适配器，它仍然作为客户端并且其行为由客户端的NLS参数确定。
   当一个应用被开始时，它从环境设置中初始化客户的NLS环境，使用这些设置所有NLS执行局部性的被完成。
当应用连接到数据库时，一个会话在服务器上被建立。这新的会话初始化它的NLS环境使用在初始化参数文件中规定的NLS初始化参数。那些设置之后能被ALTER SESSION语句改变。这些语句仅仅改变NLS环境，它不能改变本地客户的NLS环境。这些会话改变在服务器上可以使用SQL或PL/SQL语句来执行。
紧跟着连接，如果这些NLS环境设置在客户端被定义，那么一个隐含的ALTER SESSION语句同步客户和会话的环境。

  NSL_LANG包括三个部分（语言，地区，字符集）。
语言：规定ORACLE消息，校验，日期命名
地区：规定默认日期，货币和数字格式
字符集：规定客户应用

以上是我照oracle的文档译的，可能有些地方不够准确。请大家多评论！。。。。谢谢

xzforacle

请教你是用什么工具把exp导出的文件中的繁体字转成简体

yushiyin

我的一点理解（不知是否正确）：
我认为字符级可能要分几级：
1。数据库级
这一层应该是数据的直接存储，在创建数据库时确定，基表是sys.props$，可以通过视图nls_database_parameters查询。可以从子集向超集修改。
2。instance级
这一层可以通过initSID.ora中设置nls_language来确定，可以通过V$nls_parameters来查询
3。session级
这一层可以通过
alter session set nls_language=。。。来修改，v$parameters
4。statement级
TO_CHAR(hiredate, 'DD/MON/YYYY', 'nls_date_language = FRENCH')
。。。。
仅个人观点，时间有限，以后在研究。。。。

xfeng

不好意思，我说两句。我是个初学者，但前一段时间我也被数据库间不同的字符集搞的头昏脑涨。我说一下我们的情况：

开始：NT+ORACLE8I
后来：LINUIX+ORACLE9I

我把8I里的数据导入9I时，就出现问题了。

8I的字符集为：NLS_CHARACTERSET: ZHS16GBK ; NLS_NCHAR_CHARACTERSET : ZHS16GBK

我先检查了一下9I的数据库：随便打开一个表，直接往里写中文，然后应用，发现表中中文马上就变成了问号。我个人认为，这就是因为数据库本身的字符集不支持中文。然后我就查看了props$表，发现里面的NLS_CHARACTERSET 和 NLS_NCHAR_CHARACTERSET 的值分别是：US7ASCII 和 AL16UTF16 ，照我看上面几位的发言，US7ASCII是ZHS16GBK的子集，那8I里导出的数据，在9I里应该是不支持的。

于是，我就修改了表props$ (update props$ set value$='ZHS16GBK' where name='NLS_CHARACTERSET'  和 update props$ set value$='ZHS16GBK' where name='NLS_NCHAR_CHARACTERSET'); 修改完该表后，要重新启动一下实例，才能生效（启动实例后，V$NLS_PARAMETERS 中的内容就改来和props$一样了。在没重新启动前，V$NLS_PARAMETERS 中内容不变，所以，我觉得视图V$NLS_PARAMETERS 是跟着props$变的。）然后，再将8I中的数据重新导入一次，就OK拉。

**修改表props$要用sys用户作为sysdba登录。

我试过几次，都很成功。我觉得真正去操作过，心里会比较明白一点。我前天把我们的9I数据库搞坏了，我焦头烂额了两天，后来终于想到一个比较不那么麻烦的办法搞好了，我觉得我从这次破坏中又学到了很多东西，所以大家不要怕破坏（当然数据库中的数据一定要备份好）。

另：补充一句，我觉得9I的数据库被改了表，那是针对实例改的。今天我们删掉了被我弄坏的9I中的实例，又重新建了一个，我去导数据时，又出现中文问题（以前已经改过的），我又去改了一遍，再导一遍才好的。我个人认为，要从根本上决定数据库的字符集，可能跟操作系统有关，和装的时候设置有关，这我就不懂了。希望懂的人来解释一下。