这时候经过第一步转换后的数据，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中，以上情况略有不同。
Posted by eygle at 12:04 PM | Comments (0)
字符集问题的初步探讨(三)-字符集的更改
作者:eygle
出处:http://blog.eygle.com
原文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.
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$表的方式只完成了其中十二分之一的工作，潜在的完整性隐患是可想而知的。
所以，更改字符集尽量要使用正常的途径。
Posted by eygle at 12:04 PM | Comments (1)
字符集问题的初步探讨(五)-导出文件字符集
作者:eygle
出处:http://blog.eygle.com
原文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.
我们知道在导出文件中，记录着导出使用的字符集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 测试
------------------ ------------------ ----- ------------------------------
不能转换的数据将会被记录下来，我们可以根据这些信息在转换之后，对数据进行相应的更新，确保转换无误。
Posted by eygle at 12:04 PM | Comments (1)
字符集问题的初步探讨(一)-字符集的基本知识
作者:eygle
出处:http://blog.eygle.com
原文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.
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 方案可以表示更多的字符，但是由于多位的存储，需要额外的存储空间和网络传输，所以选择最适合的数据库字符集仍然需要慎重考虑。
Posted by eygle at 12:04 PM | Comments (0)
字符集问题的初步探讨(二)-数据库的字符集
作者:eygle
出处:http://blog.eygle.com
原文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.
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。
http://www.eygle.com/archives/2004/09/11/
扫一扫
04-02
1491
1491
07-08
18万+
18万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
