newchar

转贴：字符集问题的初步探讨(七)

2006-05-12T08:57:00Z

前面我们提到，通过修改props$的方式更改字符集在Oracle7之后是一种极其危险的方式，应该尽量避免。

我们又知道，通过ALTER DATABASE CHARACTER SET更改字符集虽然安全可靠，但是有严格的子集和超集的约束，实际上我们很少能够
用到这种方法。

实际上Oracle还存在另外一种更改字符集的方式.

如果你注意过的话，在Oracle的alert<sid>.log文件中，你可能看到过这样的日志信息:

alter database character set INTERNAL_CONVERT ZHS16GBK
Updating character set in controlfile to ZHS16GBK
 SYS.SNAP$ (REL_QUERY) - CLOB representation altered
 SYS.METASTYLESHEET (STYLESHEET) - CLOB representation altered
 SYS.EXTERNAL_TAB$ (PARAM_CLOB) - CLOB representation altered
 XDB.XDB$RESOURCE (SYS_NC00027$) - CLOB representation altered
 ODM.ODM_PMML_DTD (DTD) - CLOB representation altered
 OE.WAREHOUSES (SYS_NC00003$) - CLOB representation altered
 PM.ONLINE_MEDIA (SYS_NC00042$) - CLOB representation altered
 PM.ONLINE_MEDIA (SYS_NC00062$) - CLOB representation altered
 PM.ONLINE_MEDIA (PRODUCT_TEXT) - CLOB representation altered
 PM.ONLINE_MEDIA (SYS_NC00080$) - CLOB representation altered
 PM.PRINT_MEDIA (AD_SOURCETEXT) - CLOB representation altered
 PM.PRINT_MEDIA (AD_FINALTEXT) - CLOB representation altered
Completed: alter database character set INTERNAL_CONVERT ZHS1

在这里面，我们看到这样一条重要的，Oracle非公开的命令:


alter database character set INTERNAL_CONVERT/ INTERNAL_USE ZHS16GBK

这个命令是当你选择了使用典型方式创建了种子数据库以后，Oracle会根据你选择的字符集设置，把当前种子数据库的字符集更改为期望字符
集，这就是这条命令的作用.

在使用这个命令时，Oracle会跳过所有子集及超集的检查，在任意字符集之间进行强制转换，所以，使用这个命令时你必须十分小心，你必须
清楚这一操作会带来的风险.
我们之前讲过的内容仍然有效，你可以使用csscan扫描整个数据库，如果在转换的字符集之间确认没有严重的数据损坏，或者你可以使用有效
的方式更改，你就可以使用这种方式进行转换.
我们来看一下具体的操作过程及Oracle的内部操作:

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  135337420 bytes
Fixed Size                   452044 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
Database mounted.

SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;

System altered.

SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;

System altered.

SQL> ALTER SYSTEM SET AQ_TM_PROCESSES=0;

System altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> alter session set events '10046 trace name context forever,level 12';

Session altered.

SQL> alter database character set INTERNAL_USE ZHS16CGB231280

Database altered.

SQL>

这是alert.log文件中的记录信息:

Tue Oct 19 16:26:30 2004
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Tue Oct 19 16:27:07 2004
alter database character set INTERNAL_USE ZHS16CGB231280
Updating character set in controlfile to ZHS16CGB231280
Tue Oct 19 16:27:15 2004
Thread 1 advanced to log sequence 118
  Current log# 2 seq# 118 mem# 0: /opt/oracle/oradata/primary/redo02.log
Tue Oct 19 16:27:15 2004
ARC0: Evaluating archive   log 3 thread 1 sequence 117
ARC0: Beginning to archive log 3 thread 1 sequence 117
Creating archive destination LOG_ARCHIVE_DEST_1: '/opt/oracle/oradata/primary/archive/1_117.dbf'
ARC0: Completed archiving  log 3 thread 1 sequence 117
Tue Oct 19 16:27:20 2004
Completed: alter database character set INTERNAL_USE ZHS16CGB231280
Shutting down instance: further logons disabled
Shutting down instance (immediate)
License high water mark = 1
Tue Oct 19 16:29:06 2004
ALTER DATABASE CLOSE NORMAL
...

格式化10046跟踪文件,得到以下信息(摘要):

alter session set events '10046 trace name context forever,level 12'


alter database character set INTERNAL_USE ZHS16CGB231280


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      4.88       6.04        910      16825      18099           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      4.88       6.04        910      16825      18099           0

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  control file sequential read                    4        0.00          0.00
  control file parallel write                     2        0.05          0.08
  log file sync                                   2        0.08          0.08
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1       18.06         18.06
********************************************************************************

....

update col$ set charsetid = :1 
where
 charsetform = :2

....

update argument$ set charsetid = :1 
where
 charsetform = :2

....

update collection$ set charsetid = :1 
where
 charsetform = :2

....

update attribute$ set charsetid = :1 
where
 charsetform = :2
....

update parameter$ set charsetid = :1 
where
 charsetform = :2
....

update result$ set charsetid = :1 
where
 charsetform = :2

....

update partcol$ set spare1 = :1 
where
 charsetform = :2

....

update subpartcol$ set spare1 = :1 
where
 charsetform = :2

....

update props$ set value$ = :1 
where
 name = :2

....

update "SYS"."KOTAD$" set SYS_NC_ROWINFO$ = :1 
where
 SYS_NC_OID$ = :2
....

update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,
  cache=:7,highwater=:8,audit$=:9,flags=:10 
where
 obj#=:1

....

update kopm$ set metadata = :1,  length 
  = :2 
where
 name='DB_FDO'

....

ALTER DATABASE CLOSE NORMAL

此处生成的日志你可以在这里下载(供参考):

http://www.eygle.com/special/primary_ora_13730.zip
http://www.eygle.com/special/primary_ora_13730.tkf.log

我们看到这个过程和之前ALTER DATABASE CHARACTER SET操作的内部过程是完全相同的，也就是说INTERNAL_USE提供的帮助就是使
Oracle数据库绕过了子集与超集的校验.
这一方法在某些方面是有用处的，比如测试；应用于产品环境大家应该格外小心，除了你以外，没有人会为此带来的后果负责:

结语(我们不妨再说一次):

对于DBA来说，有一个很重要的原则就是:不要把你的数据库置于危险的境地！

这就要求我们，在进行任何可能对数据库结构发生改变的操作之前，先做有效的备份，很多DBA没有备份的操作中得到了惨痛的教训。

转贴：字符集问题的初步探讨(六)

2006-05-12T08:56:00Z

最后我们来讨论一下乱码的产生。

通常在我们的现实环境中，存在3个字符集设置。

第一: 客户端应用字符集(Client Application Character Set)

第二: 客户端NLS_LANG参数设置

第三: 服务器端，数据库字符集(Character Set)设置

我们说，一个字符在客户端应用(比如SQLPLUS,CMD,NOTEPAD等)中以怎样的字符显示取决于客户端操作系统，客户端能够显示怎样的字符，
我们就可以在应用中录入这些字符，至于这些字符能否在数据库中正常存储，就和另外的两个字符集设置紧密相关了。

在传输过程中，客户端NLS_LANG主要用于进行转换判断

如果NLS_LANG等于数据库字符集，则不进行任何转换直接把字符插入数据库

如果不同则进行转换，转换主要有两个任务

如果存在对应关系，则把相应二进制编码经过映射后(这一步映射以后，所代表的字符可能发生转换)传递给数据库
如果不存在对应关系，则传递一个替换字符(很多平台就是?)

数据库字符集，在和客户端NLS_LANG不同时，会把经过NLS_LANG转换的字符进行进一步处理

对于?（即不存在对应关系的字符）直接以？形式存放入数据库
对于其他字符，在NLS_LANG和数据库字符集之间进行转换后存入。

以下我们来看一下最为常见的字符集及乱码的产生:

1.当NLS_LANG字符集与数据库字符集不同，同时NLS_LANG不同于Server端字符集设置

在这种情况下，存在两种可能:

客户端输入的字符在NLS_LANG中没有对应的字符，这时无法转换，NLS_LANG使用替换字符替代这些无法映射的字符(这一步转换在TTS中
完成)，在很多字符集中这个替代字符就是”?”
当客户端的字符在NLS_LANG中对应了不同的字符时，传递给数据库以后发生转换，存储的是字符，但是已经丢失了元数据，数据库中
的字符不再代表客户端的输入。而且这个过程不可逆，这也就是为什么很多时候在客户端输入的是正常的编码，查询之后会得到未知字符的原因。

我们通过上图来简单说明一下这个过程，当客户端在WE8ISO8859P15字符集时，输入欧元符号: €,这时客户端NLS_LANG和数据库端字符集不同，
进行第一次转换，客户端€符号编码是A4,在NLS_LANG转换时，A4对应了NLS_LANG中的‘¤’，这一步的转换产生了错误映射。由于数据库字符集不
同于NLS_LANG设置，这时进一步的转换发生了，存入数据库的编码变成了C2A4,虽然同NLS_LANG进行了正确的转换，但是客户端录入的数据已经
损坏或者丢失了。

我们可以用我们熟悉的字符集做一个简单的测试:

测试环境:

客户端应用为中文18030字符集

NLS_LANG设置为US7ASCII字符集

数据库CHARACTER SET为ZHS16GBK

c:\>set NLS_LANG=AMERICAN_AMERICA.US7ASCII

c:\>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 4 01:19:57 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> insert into test values('测试');

1 row created.

SQL> select name,dump(name) from test;

NAME	DUMP(NAME)
--------------------------------------------------
2bJT	Typ=1 Len=4: 50,98,74,84

这时候我们发现，查询出来的是混乱的字符，我们把这些字符转换为2进制就是
110010   1100010   1001010   1010100
补全8位就是       00110010  01100010  01001010  01010100
我们把首位换成1   10110010  11100010  11001010  11010100

我们来看正确的存储:
c:\>set nls_lang=AMERICAN_AMERICA.ZHS16GBK
c:\>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 4 01:40:18 2003

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> insert into test values('测试');

1 row created.

SQL> col dump(name) for a30
SQL> select name,dump(name) from test;

NAME DUMP(NAME)
---------- ------------------------------
测试 Typ=1 Len=4: 178,226,202,212

1 row selected.
我们把这个结果转换为2进制表示
          10110010  11100010  11001010  11010100
这个结果正是我们前面乱码首位补全1后的结果。

这个测试说明在US7ASCII转换中文的时候除去了首位的 1,这样就丢失了元数据，导致乱码出现，NLS_LANG的转换作用由此可加一斑！
 

                                            

3． NLS_LANG和数据库字符集相同时
在这种情况下，数据库端对客户端传递过来的编码不进行任何转换(这样可以提高性能)，直接存储进入数据库，那么这时候就存在和上面同样的问题，
如果客户端传递过来的字符集在数据库中有正确的对应就可以正确存储，如果没有，就会被替换字符置换成？，乱码就这样产生了。

如上图所示，当NLS_LANG和数据库字符集设置相同都为UTF8时，客户端的欧元符号的编码A4就不会经过任何转换就插入到数据库中，而在UTF8的数
据库中，A4代表的是一个非法字符。

我们来看一个简单的测试

测试环境:

客户端字符集应用为中文GB18030

客户端NLS_LANG为US7ASCII

数据库字符集为US7ASCII

我们知道这个时候，存入的数据，数据库不进行任何转换，在以下的测试中，我们看到中文在US7ASCII字符集下得以正确显示。

c:\>set nls_lang=AMERICAN_AMERICA.US7ASCII

c:\>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 4 01:02:04 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> insert into test values('测试');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from test;

NAME
----------
测试

1 row selected.

SQL> col dump(name) for a30
SQL> select name,dump(name) from test;

NAME       DUMP(NAME)
---------- ------------------------------
测试       Typ=1 Len=4: 178,226,202,212

1 row selected.

SQL> select * from nls_database_parameters;

PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               US7ASCII
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM

PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              9.2.0.4.0

20 rows selected.

SQL>

结语:

对于DBA来说，有一个很重要的原则就是:不要把你的数据库置于危险的境地！

这就要求我们，在进行任何可能对数据库结构发生改变的操作之前，先做有效的备份，很多DBA没有备份的操作中得到了惨痛的教训。

转贴：字符集问题的初步探讨(五)

2006-05-12T08:55:00Z

我们知道在导出文件中，记录着导出使用的字符集id,通过查看导出文件头的第2、3个字节，我们可以找到16进制表示的字符集ID,在Windows上，
我们可以使用UltraEdit等工具打开dmp文件，查看其导出字符集::

在Unix上我们可以通过以下命令来查看:


cat expdat.dmp | od -x | head

Oracle提供标准函数，对字符集名称及ID进行转换:

 
SQL> select nls_charset_id('ZHS16GBK') from dual;

NLS_CHARSET_ID('ZHS16GBK')
--------------------------
                       852

1 row selected.

SQL> select nls_charset_name(852) from dual;

NLS_CHAR
--------
ZHS16GBK

1 row selected.

十进制转换十六进制:

SQL> select to_char('852','xxxx') from dual;

TO_CH
-----
  354

1 row selected.

对应上面的图中第2、3字节，我们知道该导出文件字符集为ZHS16GBk.

查询数据库中有效的字符集可以使用以下脚本:

 
col nls_charset_id for 9999
col nls_charset_name for a30
col hex_id for a20
select 
nls_charset_id(value) nls_charset_id,  
value nls_charset_name,
to_char(nls_charset_id(value),'xxxx') hex_id
from  v$nls_valid_values
where parameter = 'CHARACTERSET'
order by nls_charset_id(value)
/

输出样例如下:

 
NLS_CHARSET_ID NLS_CHARSET_NAME               HEX_ID
-------------- ------------------------------ -------------
             1 US7ASCII                           1
             2 WE8DEC                             2
             3 WE8HP                              3
             4 US8PC437                           4
             5 WE8EBCDIC37                        5
             6 WE8EBCDIC500                       6
             7 WE8EBCDIC1140                      7
             8 WE8EBCDIC285                       8
 ...................
           850 ZHS16CGB231280                   352
           851 ZHS16MACCGB231280                353
           852 ZHS16GBK                         354
           853 ZHS16DBCS                        355
           860 ZHT32EUC                         35c
           861 ZHT32SOPS                        35d
           862 ZHT16DBT                         35e
           863 ZHT32TRIS                        35f
           864 ZHT16DBCS                        360
           865 ZHT16BIG5                        361
           866 ZHT16CCDC                        362
           867 ZHT16MSWIN950                    363
           868 ZHT16HKSCS                       364
           870 AL24UTFFSS                       366
           871 UTF8                             367
           872 UTFE                             368

..................................

在很多时候，当我们进行导入操作的时候，已经离开了源数据库，这时如果目标数据库的字符集和导出文件不一致，很多时候就需要进行特殊处理，
以下介绍几种方法，主要以US7ASCII和ZHS16GBK为例

1．源数据库字符集为US7ASCII，导出文件字符集为US7ASCII或ZHS16GBK，目标数据库字符集为ZHS16GBK
在Oracle92中，我们发现对于这种情况，不论怎样处理，这个导出文件都无法正确导入到Oracle9i数据库中，这可能是因为Oracle9i的编码方案发生了较大改变。

以下是我们所做的简单测试，其中导出文件命名规则为:

S-Server ，后跟Server字符集
C-client , 后跟导出操作时客户端字符集

导入时客户端字符集设置在命令行完成，限于篇幅，我们省略了部分测试过程。
对于Oracle9iR2,我们的测试结果是US7ASCII字符集，不管怎样转换，都无法正确导入ZHS16GBK字符集的数据库中。

在进行导入操作时，如果字符不能正常转换，Oracle数据库会自动用一个”?”代替，也就是编码63。

 
E:\nls2>set NLS_LANG=AMERICAN_AMERICA.US7ASCII

E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii.dmp fromuser=eygle touser=eygle tables=test

Import: Release 9.2.0.4.0 - Production on Mon Nov 3 17:14:39 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Nov 3 17:14:50 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name,dump(name) from test;

NAME	DUMP(NAME)
-----------------------------
????	Typ=1 Len=4: 63,63,63,63
test	Typ=1 Len=4: 116,101,115,116

2 rows selected.

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii.dmp fromuser=eygle touser=eygle tables=test ignore=y

Import: Release 9.2.0.4.0 - Production on Mon Nov 3 17:15:28 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
export client uses US7ASCII character set (possible charset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Nov 3 17:15:34 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name,dump(name) from test;

NAME		DUMP(NAME)
--------------------------------------------------------------------------------
????		Typ=1 Len=4: 63,63,63,63
test		Typ=1 Len=4: 116,101,115,116
????		Typ=1 Len=4: 63,63,63,63
test		Typ=1 Len=4: 116,101,115,116


4 rows selected.

SQL> drop table test;

Table dropped.

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

E:\nls2>imp eygle/eygle file=Sus7ascii-Czhs16gbk.dmp fromuser=eygle touser=eygle tables=test ignore=y

Import: Release 9.2.0.4.0 - Production on Mon Nov 3 17:17:21 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Nov 3 17:17:30 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name,dump(name) from test;

NAME	DUMP(NAME)
----------------------------------------------
????	Typ=1 Len=4: 63,63,63,63
test	Typ=1 Len=4: 116,101,115,116

2 rows selected.

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.US7ASCII

E:\nls2>imp eygle/eygle file=Sus7ascii-Czhs16gbk.dmp fromuser=eygle touser=eygle tables=test ignore=y

Import: Release 9.2.0.4.0 - Production on Mon Nov 3 17:18:00 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
export client uses ZHS16GBK character set (possible charset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Nov 3 17:18:08 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name,dump(name) from test;

NAME	DUMP(NAME)
----------------------------------------
????	Typ=1 Len=4: 63,63,63,63
test	Typ=1 Len=4: 116,101,115,116
????	Typ=1 Len=4: 63,63,63,63
test	Typ=1 Len=4: 116,101,115,116

4 rows selected.

SQL>

对于这种情况，我们可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后修改第二、三字符，修改 0001 为
0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中。

修改导出文件:

导入修改后的导出文件:

 
E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle tables=test

Import: Release 9.2.0.4.0 - Production on Mon Nov 3 17:37:17 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V08.01.07 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
export server uses UTF8 NCHAR character set (possible ncharset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Nov 3 17:37:23 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select name,dump(name) from test;

NAME     DUMP(NAME)
--------------------------------------------------------------------------------
测试       Typ=1 Len=4: 178,226,202,212
Test        Typ=1 Len=4: 116,101,115,116

2 rows selected.

SQL>

2．使用create database的方法
如果导出文件使用的字符集是US7ASCII，目标数据库的字符集是ZHS16GBK,我们可以使用create database的方法来修改，具体如下:

 
SQL> col parameter for a30
SQL> col value for a30
SQL> select * from v$nls_parameters;

PARAMETER                      VALUE
------------------------------ ------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_CHARACTERSET               ZHS16GBK
NLS_SORT                       BINARY
……………….

19 rows selected.

SQL> create database character set us7ascii;
create database character set us7ascii
*
ERROR at line 1:
ORA-01031: insufficient privileges


SQL> select * from v$nls_parameters;

PARAMETER                      VALUE
------------------------------ ------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_CHARACTERSET               US7ASCII
NLS_SORT                       BINARY
…………..

19 rows selected.

SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

E:\nls2>set nls_lang=AMERICAN_AMERICA.US7ASCII

E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii.dmp fromuser=eygle touser=eygle

Import: Release 9.2.0.4.0 - Production on Sun Nov 2 14:53:26 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Export file created by EXPORT:V09.02.00 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Sun Nov 2 14:53:35 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select * from test;

NAME
----------
测试
test

2 rows selected.

我们看到，当发出create database character set us7ascii；命令时，数据库v$nls_parameters中的字符集设置随之更改，该参数影响导入进程，
更改后可以正确导入数据，重起数据库后，该设置恢复。

提示:v$nls_paraemters来源于x$nls_parameters,该动态性能视图影响导入操作；而nls_database_parameters来源于props$数据表，影响数据存储。

3． Oracle提供的字符扫描工具csscan

我们说以上的方法只是应该在不得已的情况下使用，其本质是欺骗数据库，强制导入数据，可能损失元数据。
如果要确保数据的完整性，应该使用csscan扫描数据库，找出所有不兼容的字符，然后通过编写相应的脚本及代码，在转换之后进行更新，确保数据的正确性。
我们简单看一下csscan的使用。

要使用csscan之前，需要以sys用户身份创建相应数据字典对象:

 
E:\nls2>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sun Nov 2 19:42:07 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select instance_name from v$intance;
select instance_name from v$intance
                          *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
penny

1 row selected.

SQL> @?/rdbms/admin/csminst.sql

User created.


Grant succeeded.

………..

这个脚本创建相应用户(csmig)及数据字典对象，扫描信息会记录在相应的数据字典表里。

我们可以在命令行调用这个工具对数据库进行扫描:

 
E:\nls2>csscan FULL=Y FROMCHAR=ZHS16GBK TOCHAR=US7ASCII LOG=US7check.log CAPTURE=Y ARRAY=1000000 PROCESS=2


Character Set Scanner v1.1 : Release 9.2.0.1.0 - Production on Sun Nov 2 20:24:45 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Username: eygle/eygle

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Enumerating tables to scan...

. process 1 scanning SYS.SOURCE$[AAAABHAABAAAAIRAAA]
. process 2 scanning SYS.ATTRIBUTE$[AAAAEoAABAAAAhZAAA]
. process 2 scanning SYS.PARAMETER$[AAAAEoAABAAAAhZAAA]
. process 2 scanning SYS.METHOD$[AAAAEoAABAAAAhZAAA]
……..
. process 2 scanning SYSTEM.DEF$_AQERROR[AAAA8fAABAAACWJAAA]
. process 1 scanning WMSYS.WM$ENV_VARS[AAABeWAABAAAFMZAAA]
………………….
. process 2 scanning SYS.UGROUP$[AAAAA5AABAAAAGpAAA]
. process 2 scanning SYS.CON$[AAAAAcAABAAAACpAAA]
. process 1 scanning SYS.FILE$[AAAAARAABAAAABxAAA]

Creating Database Scan Summary Report...

Creating Individual Exception Report...

Scanner terminated successfully.

然后我们可以检查输出的日志来查看数据库扫描情况:

 
Database Scan Individual Exception Report


[Database Scan Parameters]

Parameter                      Value                                           
------------------------------ ------------------------------------------------
Scan type                      Full database                                   
Scan CHAR data?                YES                                             
Current database character set ZHS16GBK                                        
New database character set     US7ASCII                                        
Scan NCHAR data?               NO                                              
Array fetch buffer size        1000000                                         
Number of processes            2                                               
Capture convertible data?      YES                                             
------------------------------ ------------------------------------------------

[Data Dictionary individual exceptions]


[Application data individual exceptions]

User  : EYGLE
Table : TEST
Column: NAME
Type  : VARCHAR2(10)
Number of Exceptions         : 1         
Max Post Conversion Data Size: 4         

ROWID              Exception Type      Size Cell Data(first 30 bytes)     
------------------ ------------------ ----- ------------------------------
AAABpIAADAAAAAMAAA lossy conversion         测试                          
------------------ ------------------ ----- ------------------------------

不能转换的数据将会被记录下来，我们可以根据这些信息在转换之后，对数据进行相应的更新，确保转换无误。

转贴：字符集问题的初步探讨(四)

2006-05-12T08:54:00Z

4．导入导出及转换

导入导出是我们常用的一个数据迁移及转化工具，因其导出文件具有平台无关性，所以在跨平台迁移中，最为常用。
在导出操作时，非常重要的是客户端的字符集设置，也就是客户端的NLS_LANG设置。
NLS_LANG参数由以下部分组成:

NLS_LANG=<Language>_<Territory>.<Clients Characterset>

NLS_LANG各部分含义如下:
LANGUAGE指定:
-Oracle消息使用的语言
-日期中月份和日显示
TERRITORY指定
-货币和数字格式
-地区和计算星期及日期的习惯
CHARACTERSET:
-控制客户端应用程序使用的字符集
通常设置或者等于客户端(如Windows)代码页	
或者对于unicode应用设置为UTF8
在Windows上查看当前系统的代码页可以使用chcp命令:

E:\>chcp

 活动的代码页: 936

代码页936也就是中文字符集 GBK,在Microsoft的官方站点上，我们可以遭到关于936代码页的具体编码规则,请参考以下链接:

http://www.microsoft.com/globaldev/reference/dbcs/936.htm

我们看一个简单的测试，来了解一下这几个参数的作用:

E:\>set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK

E:\>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on 星期六 11月 1 22:51:59 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


连接到:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select sysdate from dual;

SYSDATE
----------
01-11月-03

已选择 1 行。

SQL> exit
从Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production中断开

E:\>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

E:\>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Nov 1 22:52:24 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> select sysdate from dual;

SYSDATE
---------
01-NOV-03

1 row selected.

SQL>

查看客户端NLS_LANG设置可以使用以下方法:


Windows使用:


echo %NLS_LANG%
如:
E:\>echo %NLS_LANG%
AMERICAN_AMERICA.ZHS16GBK




Unix使用:

env|grep NLS_LANG
如:
/opt/oracle>env|grep NLS_LANG
NLS_LANG=AMERICAN_CHINA.ZHS16GBK

	Windows客户端设置,可以在注册表中更改NLS_LANG,具体键值位于:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMExx\
xx指存在多个ORACLE_HOME时系统编号。

导入和导出是客户端产品，同SQL*PLUS和Oralce Forms一样，因此，使用EXP/IMP工具将按照NLS_LANG定义的方式转换字符集。

导出使用的字符集将会记录在导出文件中，当文件导入时，将会检查导出时使用的字符集设置，如果这个字符集不同于导入客户端的NLS_LANG
设置，字符集将根据导入客户端NLS_LANG设置进行转换，如果必要，在数据插入数据库之前会进行进一步转换。

通常在导出时最好把客户端字符集设置得和数据库端相同，这样可以避免在导出时发生不必要的数据转换，导出文件将和数据库具有相同的字符集。
即使将来会把导出文件导入到不同字符集的数据库中，这样做也可以把转换延缓至导入时刻。

当进行数据导入时，主要存在以下两种情况:
1.源数据库和目标数据库具有相同字符集设置
这时，只需要设置NLS_LANG等于数据库字符集即可导入(前提是，导出使用的是和源数据库相同字符集，即三者相同)

2.源数据库和目标数据库字符集不同
如果我们导出时候使用的NLS_LANG是和源数据库相同的字符集，那么导入时就可以设置客户端NLS_LANG等于导出时使用的字符集，这
样转换只发生在数据库端，而且只发生一次。

例如:
如果进行从WE8MSWIN1252到UTF8的转换
1)使用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252导出数据库。
这时创建的导出文件包含WE8MSWIN1252的数据
2)导入时使用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
这时转换仅发生在insert数据到UTF8的数据库中。

以上假设的转换只在目标数据库字符集是源数据库字符集的超集时才能转换。如果不同，一般就需要进行一些特殊的处理。

我们简单看一下导入的转换过程(以Oracle8i为例)：

1.确定导出数据库字符集环境
通过读取导出文件头，可以获得导出文件的字符集设置
2.确定导入session的字符集，即导入Session使用的NLS_LANG环境变量
3.IMP读取导出文件
读取导出文件字符集ID，和导入进程的NLS_LANG进行比较
4.如果导出文件字符集和导入Session字符集相同，那么在这一步骤内就不需要转换
如果不同，就需要把数据转换为导入Session使用的字符集。
然而这种转换只能在单byte字符集之间进行。
我们看一个测试：

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.US7ASCII

设置导入session NLS_LANG为US7ASCII

E:\nls2>e:\oracle\ora8i\bin\imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle tables=test

这个导出文件是从US7ASCII数据库导出，导出客户端NLS_LANG也是US7ASCII

Import: Release 8.1.7.1.1 - Production on Fri Nov 7 00:59:22 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.

Connected to: Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production

这时导入，在DMP文件和NLS_LANG之间不需要进行字符集转换。

Export file created by EXPORT:V08.01.07 via conventional path
import done in US7ASCII character set and ZHS16GBK NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
export server uses UTF8 NCHAR character set (possible ncharset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

5.对于多Byte字符集的导入(如:UTF8)
需要设置导入Session字符集和导出字符集相同
否则就会遇到:IMP-16 "Required character set conversion (type %lu to %lu) not supported" 错误。
:

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

导入Session字符集设置为ZHS16GBK
导入US7ASCII的导出文件

E:\nls2>e:\oracle\ora8i\bin\imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle

Import: Release 8.1.7.1.1 - Production on Fri Nov 7 00:38:55 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production

IMP-00016: required character set conversion (type 1 to 852) not supported
IMP-00000: Import terminated unsuccessfully

在从导出文件US7ASCII到导入 NLS_LANG设置为ZHS16GBK的过程中，不支持单Byte字符集向多Byte转换，报出以上错误。

6.导入Session字符集应该是导出字符集的超级，否则，专有的字符将难以正确转换。
7.当数据转换为导入Session字符集设置以后，如果导入Session字符集不同于导入数据库字符集，这时还需要最后一步转换，这要求导入数据库字符
集是导入session字符集的超级，否则某些专有字符将不能正常转换。
我们继续看上面的两个过程，这里有这样两个原则:
1．如果NLS_LANG的设置和数据库相同，那么数据（在传输过程中当然是2进制码）不经过转换就直接插入数据库中。
2．如果NLS_LANG的设置和数据库不同，那么数据需要转换后才能插入数据库中。
我们再回头来看上面的第一个例子:
:

Export file created by EXPORT:V08.01.07 via conventional path
import done in US7ASCII character set and ZHS16GBK NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
export server uses UTF8 NCHAR character set (possible ncharset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.

这时候经过第一步转换后的数据，US7ASCII到ZHS16GBK丢失首位，原样插入数据库，我们看到这时数据库中存放的就是错误的字符(在后面
部分我们做了详细的转换):

E:\nls2>sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Nov 7 00:35:39 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production

SQL> select * from test;

NAME
--------------------
2bJT
test

在Oracle9i中，以上情况略有不同。

转贴：字符集问题的初步探讨(三)

2006-05-12T08:53:00Z

2．字符集的更改

数据库创建以后，如果需要修改字符集，通常需要重建数据库，通过导入导出的方式来转换。
我们也可以通过以下方式更改

ALTER DATABASE CHARACTER SET

注意:修改数据库字符集时必须谨慎，修改之前一定要为数据库备份。由于不能回退这项操作,因此可能会造成数据丢失或者损坏。

这是最简单的转换字符集的方式，但并不总是有效。
这个命令在Oracle8时被引入Oracle,这个操作在本质上并不转换任何数据库字符，只是简单的更新数据库中所有跟字符集相关的信息。

这意味着，你只能在新字符集是旧字符集严格超集的情况下使用这种方式转换。
所谓超集是指:
当前字符集中的每一个字符在新字符集中都可以表示，并使用同样的代码点
比如很多字符集都是US7ASCII的严格超集。

如果不是超集，将获得以下错误:


SQL> ALTER DATABASE CHARACTER SET  ZHS16CGB231280;
ALTER DATABASE CHARACTER SET  ZHS16CGB231280
*
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set

下面我们来看一个测试(以下测试在Oracle9.2.0下进行，Oracle9i较Oracle8i在编码方面有较大改变，在Oracle8i中，测试结果可能略有不同):

SQL> select name,value$ from props$ where name like '%NLS%';

NAME                           VALUE$
------------------------------ ------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               US7ASCII
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
……………….
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              9.2.0.4.0

20 rows selected.
SQL> select name,dump(name) from eygle.test;

NAME   DUMP(NAME)
------------------------------------------------------
测试     Typ=1 Len=4: 178,226,202,212
Test      Typ=1 Len=4: 116,101,115,116


2 rows selected.

转换字符集，数据库应该在RESTRICTED模式下进行.

c:\>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Sat Nov 1 10:52:30 2003

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP MOUNT;
ORACLE instance started.

Total System Global Area   76619308 bytes
Fixed Size                   454188 bytes
Variable Size              58720256 bytes
Database Buffers           16777216 bytes
Redo Buffers                 667648 bytes
Database mounted.
SQL> ALTER SESSION SET SQL_TRACE=TRUE;

Session altered.

SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;

System altered.

SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;

System altered.

SQL> ALTER SYSTEM SET AQ_TM_PROCESSES=0;

System altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> set linesize 120
SQL> ALTER DATABASE CHARACTER SET ZHS16GBK;
ALTER DATABASE CHARACTER SET ZHS16GBK
*
ERROR at line 1:
ORA-12721: operation cannot execute when other sessions are active


SQL> ALTER DATABASE CHARACTER SET ZHS16GBK;
ALTER DATABASE CHARACTER SET ZHS16GBK
*
ERROR at line 1:
ORA-12716: Cannot ALTER DATABASE CHARACTER SET when CLOB data exists

在Oracle9i中，如果数据库存在CLOB类型字段，那么就不允许对字符集进行转换

SQL>

这时候，我们可以去查看alert<sid>.log日志文件，看CLOB字段存在于哪些表上:


ALTER DATABASE CHARACTER SET ZHS16GBK
 SYS.METASTYLESHEET (STYLESHEET) - CLOB populated
ORA-12716 signalled during: ALTER DATABASE CHARACTER SET ZHS16GBK...

对于不同情况，Oracle提供不同的解决方案，如果是用户数据表，一般我们可以把包含CLOB字段的表导出，然后drop掉相关对象，
转换后再导入数据库；对于系统表，可以按照以下方式处理:


SQL> truncate table Metastylesheet;

Table truncated.

然后可以继续进行转换！



SQL> ALTER SESSION SET SQL_TRACE=TRUE;

Session altered.

SQL> ALTER DATABASE CHARACTER SET ZHS16GBK;

Database altered.

SQL> ALTER SESSION SET SQL_TRACE=FALSE;

Session altered.

在9.2.0中，转换完成以后，可以通过运行catmet.sql脚本来重建Metastylesheet表:

SQL> @?/rdbms/admin/catmet.sql

转换后的数据：



SQL> select name,value$ from props$ where name like '%NLS%';

NAME                           VALUE$
------------------------------ ------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               ZHS16GBK
…..
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              9.2.0.4.0

20 rows selected.

SQL> select * from eygle.test;

NAME
------------------------------
测试
test

2 rows selected.

提示:
通过设置sql_trace，我们可以跟踪很多数据库的后台操作，这个工具是DBA常用的“利器”之一。
我们简单看一下数据库更改字符集时的后台处理，我提取了主要的更新部分。
通过以下跟踪过程，我们看到数据库在更改字符集的时候，主要更新了12张数据字典表，修改了数据库的原数据，这也证实了我们以前的说法:
这个更改字符集的操作在本质上并不转换任何数据库字符，只是简单的更新数据库中所有跟字符集相关的信息。

update col$ set charsetid = :1 
where
 charsetform = :2


update argument$ set charsetid = :1 
where
 charsetform = :2


update collection$ set charsetid = :1 
where
 charsetform = :2


update attribute$ set charsetid = :1 
where
 charsetform = :2


update parameter$ set charsetid = :1 
where
 charsetform = :2


update result$ set charsetid = :1 
where
 charsetform = :2


update partcol$ set spare1 = :1 
where
 charsetform = :2


update subpartcol$ set spare1 = :1 
where
 charsetform = :2


update props$ set value$ = :1 
where
 name = :2


update "SYS"."KOTAD$" set SYS_NC_ROWINFO$ = :1 
where
 SYS_NC_OID$ = :2

update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,
  cache=:7,highwater=:8,audit$=:9,flags=:10 
where
 obj#=:1

update kopm$ set metadata = :1, length  = :2 
where
 name='DB_FDO'

在这里我们顺便纠正一个由来以及的错误方法.
经常可以在网上看到这样的更改字符集的方法：

1）用SYS用户名登陆ORACLE。
2）查看字符集内容

SQL>SELECT * FROM PROPS$;

3）修改字符集

SQL> update props$ set value$='新字符集' where name='NLS_CHARACTERSET'

4) COMMIT;

我们看到很多人在这个问题上遇到了惨痛的教训，使用这种方式更改字符集，如果你的value$值输入了不正确的字符集，在8i中那么你
的数据库可能会无法启动，这种情况是非常严重的,有时候你必须从备份中进行恢复；如果是在9i中，可以重新启动数据库后再修改回正
确的字符集。但是我们仍然不建议使用这种方式进行任何数据库修改，这是一种极其危险的操作。
实际上当我们更新了字符集，数据库启动时会根据数据库的字符集自动的来修改控制文件的字符集，如果字符集可以识别，更新控制文
件字符集等于数据库字符集；如果字符集不可识别，那么控制文件字符集更新为US7ASCII.

通过更新props$表的方式修改字符集,在Oracle7之后就不应该被使用.

以下是我的测试结果，但是严禁一切不备份的修改研究，即使是对测试库的。

SQL> update props$ set value$='EYGLE' where name='NLS_CHARACTERSET';

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value$ from props$ where name like '%NLS%';

NAME                           VALUE$
------------------------------ -----------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               EYGLE
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
….
NLS_NCHAR_CHARACTERSET         ZHS16GBK
NLS_RDBMS_VERSION              8.1.7.1.1

18 rows selected.

重新启动数据库，发现alert.log文件中记录如下操作:

Mon Nov 03 16:11:35 2003
Updating character set in controlfile to US7ASCII
Completed: ALTER DATABASE OPEN

启动数据库后恢复字符集设置:

SQL> update props$ set value$='ZHS16GBK' where name='NLS_CHARACTERSET';

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value$ from props$ where name like '%NLS%';

NAME                           VALUE$
------------------------------ -----------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               ZHS16GBK
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
………
NLS_COMP                       BINARY
NLS_NCHAR_CHARACTERSET         ZHS16GBK
NLS_RDBMS_VERSION              8.1.7.1.1

18 rows selected.

重新启动数据库后，发现控制文件的字符集被更新:

Mon Nov 03 16:21:41 2003
Updating character set in controlfile to ZHS16GBK
Completed: ALTER DATABASE OPEN

理解了字符集调整的内部操作以后，我们可以轻易的指出，以上的方法是不正确的，通过前面 ” ALTER DATABASE CHARACTER SET” 方式更改字
符集时，Oracle至少需要更改12张数据字典表，而这种直接更新props$表的方式只完成了其中十二分之一的工作，潜在的完整性隐患是可想而知的。

所以，更改字符集尽量要使用正常的途径。

转贴：字符集问题的初步探讨(二)

2006-05-12T08:52:00Z

2．数据库的字符集

字符集在创建数据库时指定，在创建后通常不能更改，所以在创建数据库时能否选择一个正确的字符集就显得尤为重要。

在创建数据库时，我们可以指定字符集(CHARACTER SET)和国家字符集(NATIONAL CHARACTER SET)。
字符集用来存储:
     CHAR, VARCHAR2, CLOB, LONG等类型数据
     用来标示诸如表名、列名以及PL/SQL变量等
     SQL和PL/SQL程序单元等
国家字符集用以存储:
     NCHAR, NVARCHAR2, NCLOB等类型数据

这些设置在数据库创建时指定，我们可以看一下数据库的创建脚本:

connect SYS/change_on_install as SYSDBA
set echo on
spool E:\oracle\ora92\assistants\dbca\logs\CreateDB.log
startup nomount pfile="E:\oracle\admin\eygle\scripts\init.ora";
CREATE DATABASE eygle
MAXINSTANCES 1
MAXLOGHISTORY 1
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE 'E:\oracle\oradata\eygle\system01.dbf' SIZE 250M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE 'E:\oracle\oradata\eygle\temp01.dbf' SIZE 40M REUSE AUTOEXTEND
ON NEXT 640K MAXSIZE UNLIMITED
UNDO TABLESPACE "UNDOTBS1" DATAFILE 'E:\oracle\oradata\eygle\undotbs01.dbf' SIZE 50M REUSE AUTOEXTEND
ON NEXT 5120K MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('E:\oracle\oradata\eygle\redo01.log') SIZE 10M,
GROUP 2 ('E:\oracle\oradata\eygle\redo02.log') SIZE 10M,
GROUP 3 ('E:\oracle\oradata\eygle\redo03.log') SIZE 10M;
spool off
exit;

以上用粗体显示的就是对我们至关重要的字符集设置。

在创建数据库的过程中，在以下界面选择你的字符集，对于简体中文平台，缺省的字符集是:ZHS16GBK

一旦你的字符集选定了，数据库中能够存储的字符就受到了限制，所以你选择的字符集的应该可以容纳所有你将用到字符。

常见的中文字符集有:

ZHS16CGB231280 	CGB2312-80 	16-bit Simplified Chinese MB, ASCII
ZHS16GBK 	    GBK 		16-bit Simplified Chinese MB, ASCII, UDC

其中GB2312码是中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集--基本集》，由国家标准总局发布，
1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。
GBK编码是1995年12月颁布的指导性规范。
GBK与国家标准 GB 2312-80 信息处理交换码所对应的、事实上的内码标准兼容；同时，在字汇一级支持 ISO/IEC 10646-1 和
GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。包含了更多的编码。

但是我们说，ZHS16GBK 并非是ZHS16CGB231280的严格超集（虽然后者的汉字在前者中都存在，但是同样的编码在不同两个
字符集中可能表达不同的汉字），所以在做数据库字符转换时仍然需要特别注意。

Oracle的字符集命名遵循以下命名规则:

     <Language><bit size><encoding>
即:  <语言>    <比特位数><编码>
比如: ZHS    · 16	    ·GBK

需要说明的是，有些字符集命名违背了这个规范，Oracle8/Oralce8i中的UTF-8是第一个打破这个命名规范的字符集。
我们可以看到一类字符集以 AL开头，如:
AL16UTF16
其中 AL代表 ALL,指适用于所有语言(All Languages)，按照这个标准当年UTF-8本应被命名为AL24UTF8。

转贴：字符集问题的初步探讨(一)

2006-05-12T08:51:00Z

Oracle全球支持(即Globalization Support)允许我们使用本地语言和格式来存储和检索数据。通过全球支持，Oracle可以支持多种语言及字符集，得以展示数据库的强大魅力。

由于不同语言及字符集的共同存储存在设置上具有一定的复杂性，字符集一度成为普遍困扰大家的一个主要问题。
本文试图就一些常见问题进行探讨，希望可以把一些实际经验共享给大家！

1．字符集的基本知识

如果从头说起，字符集最早的编码方案来自于与ASCII.
这也是我们最常见的编码方式。该方案起源于1960年代初期，最初是美国国会图书馆制定用来作为美国图书馆界书目交换的共同标准，最后完善成为美国的国家标准ASCII（American Standard Codefor Information Interchange），之后进一步演变成世界性的计算机字符编码标准ISO646（其全名为7-bit coded character set for information interchange）。成为计算机编码方案的基础。

Oracle数据库最早支持的编码方案也就是US7ASCII.
但是我们知道，英文字符一般是以一个字节来存储的，7位的编码方案最多只能代表128个字符；经过扩展的8位的编码方案也只能代表256个字符，这远远不能满足计算机发展的需要，对于亚洲国家复杂的字符存储需要更多的码位，于是各种编码方案随之而生。

为了容纳全世界各种语言的所有字符和符号，解决不同编码之间的兼容和转换问题，1991年元月，10多家公司共同出资，组建Unicode协会,随后Unicode编码产生了。
Unicode协会的口号是: 给每个字符提供了一个唯一的数字，不论是什么平台，不论是什么程序，不论什么语言。
最初Unicode编码使用2-Byte(16bit)来进行编码，但是最多只能容纳65536个字符，仍然不够使用，后来进行了扩充，也就是Unicode3.1标准，增加了额外的补充字符定义，现在Unicode4.0标准已经发布，具体可以参考Unicode官方站点:

www.unicode.org

Unicode编码方案主要有三个实施标准:
UTF-8
USC-2
UTF-16
Oracle从7.2开始支持UTF-8编码，提供Unicode编码支持。

按照各种标准的含义，Oracle推荐，如果你的数据库需要存放不同语言的不同符号和字符，建议使用Unicode编码方案。诚然，Unicode方案可以表示更多的字符，但是由于多位的存储，需要额外的存储空间和网络传输，所以选择最适合的数据库字符集仍然需要慎重考虑。

番禺生活蒲点

2006-04-12T10:02:00Z

康乐活动

【电影】
番禺文化宫电影订票:84823380  84823381  84818172
====================================
【羽毛球】
德兴场：84634871       20元/小时
青少宫：84834525       18元/小时
星海场：34811771   88451357     25元/小时
活力场：34511377 （中发、番师、话雨庭）       25元/小时
德宝场：84696703        22元/小时
康裕北：84801233   84895462        28元/小时
番师场：84642316         18元/小时
英东场：84893210         28元/小时
实验小学:33100533        25元/小时
黄沙会所：34612622      30元/小时
南郊华景附近:34716181  18元/小时
南郊..禺山中学:13060623724   20元/小时
====================================
【英皇桌球会】
电话：34510898
地址：市桥西城路西兴苑18号楼二层
====================================
【国飚桌球城】
电话：34512828
地址：番禺市桥西城路57号市桥西兴园18栋西2楼
====================================
【风度桌球城】
电话：13802832488/84829222/84884822
地址：番禺区市桥镇西堤路142号
====================================
【萍果桌球城】
电话：13660854977/84667308
地址：番禺市桥康乐路154号二楼

酒店住宿

（桥福酒楼）：84693666 84693168
====================================
（喜悦酒店）：84892888
====================================
（世昌大酒店）
详细地址：番禺区市桥镇繁华路3号
联系电话： 84888333
====================================
（长隆酒店）
电话： 84786838
地址：番禺区迎宾路
====================================
（丽江明珠酒店）
电话：84582288
地址：广州番禺区大石镇迎宾北
====================================
（番禺宾馆）
电话：84822127
地址：番禺区市桥大北路130号
====================================
（祈福酒店度假俱乐部）
电话：34710088
地址：广州市番禺区市广路祈福新邨

娱乐文化

（墨西哥啤酒牛扒城）
市桥中银大厦　电话:84642728
市桥桥东路　　电话:84817828
市桥西丽路      电话:84661113
市桥光明路      电话:84884696
====================================
（荷里活）:34807086
====================================
（飞士）:84882368
====================================
（阳光西餐厅）：84660357
====================================
（森美西餐厅）：84611115　84617037
====================================
（梦娜西餐厅）：84824050　84881070
====================================
（音乐路）:34811399
====================================
（金石廊）84880648

休闲餐饮

（樱屋日本料理）:84833890
====================================
（今日靓i汤）:84887782 84887786
====================================
（沁芳园）
沙湾总店  电话：84732479
德兴分店  电话：84699049
西丽分店  电话：84604644
禺山分店  电话：84700700
南郊分店  电话：84697757
====================================
（四季堂）
1.市桥富华西路96号:34809266 34801177
2.祈福食街:34711176
3.东沙路96号:84698466 84643886
4.桥兴大道:84899556 84669066
5.南郊桥南路:34616966 34616922
====================================
（富华美食）:富华西路124~126号:34817123
====================================
（味了园）:光明北路工商行对面:84871005
====================================
（東沙松記）:84873261
====================================
（壹加壹）：84899254（兴发食街）
====================================
（天府火锅）:84894617
====================================
（绿岛）
详细地址：總店：番禺市橋光明北路65-67號 84803583
分店：市橋禺山大道97號 84833382
南沙加盟店 84686028
市橋廣場西路49-50號  订座电话：84637623
====================================
（水上西桥）
地址: 番禺大石沙溪大道珠江花园斜对面
订座电话: 34502233 34502888
====================================
（梅峰茶楼）
详细地址：番禺市桥富华东路82号
订座电话：020-84800399
====================================
（天野屋日本料理）
光明南路： 020-34736607
====================================
（珍菌王大酒楼）
020--34879399 34731654
番禺区市桥南岸金叶商务酒店二楼
====================================
（真功夫）
广州番禺区市桥镇繁华路62号友谊大厦二楼
020-34807726
====================================
（缘乐居茶廊）
详细地址：广州近郊番禺迎宾路长隆酒店内
联系电话： 020-84786838
====================================
（小肥羊）
详细地址：广州近郊番禺区市桥镇西丽南路169-183号
联系电话： 020-34802068 84601029
====================================
（蓝与白）
详细地址：广州番禺市桥镇桥东路34号
联系电话： 020-84830200
====================================
（德克士脆皮炸鸡）
详细地址：广州番禺区东涌路147号一楼
联系电话： 020-84812560
====================================
（川江鱼头火锅城）
详细地址：广州近郊市桥兴发食街9-12号
联系电话： 020-84662448
====================================
（大四川火锅）
详细地址：广州近郊市桥坑口路1号
联系电话： 020-84628344
====================================
（灯塔吧）
详细地址：广州近郊番禺区洛溪大桥附近
联系电话： 020-34501648
====================================
（海怡阁）
详细地址：广州近郊番禺大桥南端
联系电话： 020-34502109
====================================
（嘉仙鸡雷州土菜馆）
详细地址：番禺区市桥南郊沙湾镇汇景大道1号汇庭雅苑2楼
联系电话： 020-34616210 34616211
====================================
（好里韩国料理）
详细地址：广州番禺丽江花园学校后门对面德汇22铺
联系电话： 020-84594594
====================================
（食通天）
详细地址：广州近郊番禺迎宾路长隆酒店内
联系电话： 020-84786838转
====================================
（番禺粤菜馆）
详细地址：广州近郊市桥兴发食街
联系电话： 020-34775534
====================================
（港葡风味）
详细地址：广州近郊祈福新邨食街18－19号铺
联系电话： 020-34711185
====================================
（万绿海湾酒家）
详细地址：广州近郊番禺区南村镇兴业路宏信食街
交通线路： 华南碧桂园旁边
联系电话： 020-34765239 34765249
====================================
（别致咖啡）
详细地址：广州近郊市桥繁华路140-142号
联系电话： 020-34803003
====================================
（国泰卡拉OK娱乐城）
电话： 84898882/84898883
地址：番禺区市桥禺山大道西路210-220号

旅游速递

[南航国旅]
电话：84812070
====================================
[南沙国旅]
电话：84896844
====================================
[招商国旅 ]
电话：37658503    8778 3515
====================================
[西部假期 ]
电话：83327777
====================================
[ 广东铁青 ]
电话：61281888    61324333
市桥分店：34805361
====================================
[ 南航旅游 ]
总部电话：28326666
番禺分店：34815643
光明北路218号
====================================
[ 广之旅 ]
番禺分店：84665222
====================================
[ 广东中旅 ]
总部电话：83336888
番禺分店：84837192
====================================
[ 康泰 ]
电话：87608833
====================================
[ 广东职旅 ]
83837823
====================================
[ 康辉游踪 ]
电话：83330000
地址：广州沿江中路313号康富来大厦5楼
网址：www.cctpage.com
====================================
[ 金粤国旅 ]
电话：83359717
====================================
[ 国旅假期 ]
总部电话：86666889
番禺分店：84667127    84667137
====================================
[ 广东青旅 ]
电话：38869400    38860401    84543782
====================================
[ 广东羊城之旅 ]
总部地话：81309333
番禺分店：84896189
====================================
[ 三茂国旅 ]
电话：83881399     83862192
地址：环市东路374号三茂大酒店首层
====================================
[ 和平国旅 ]
电话：61223822     61223833
====================================
[ 天马国旅 ]
电话：37632566
====================================
[ 华龄美老年旅游之家 ]
电话：87552506    87748989
====================================
[ 假日通 ]
电话：83393789
====================================
[ 风行旅游 ]
电话：31619366

摄影冲印

（芝柏婚纱摄影艺术中心）
电话：84889792
地址：番禺市桥东涌路122号(麦当劳左边)

美容美发

（东城自然美沙龙SPA）
电话：(020)84620073
地址：番禺区市桥兴泰路40号
====================================
（天使美容美体中心）
电话：84612002
地址：番禺市桥兴泰路42号
====================================
（章飞一绝祛斑美容院）
电话：020-34563426
地址：番禺区石基镇傍西村城市花园金龙阁十号铺
====================================
（名豪美发美容店）
电话：34806593
地址：番禺区市桥镇大北路253-255号
====================================
（发国）
电话：84666966
地址：番禺区市桥捷进中路来福园68号
====================================
（诗莉奥发型设计中心）
电话：34509980
地址：洛溪新城吉祥道71号A
====================================
（卡莲娜美容美发）
电话：84602200
地址：番禺区市桥西丽路252号
====================================
（出色SALON）
电话：84666197
地址：番禺市桥禺山大道237号