还是字符集的问题，解决了只给100分（外加一顿饭）

[blandkiller]

遇到了这个问题，我不知道我是不是该向oracle的字符集屈服了：

DBServer：RedHat Linux + Oracle 8.1.7，系统没有export任何NLS_LANG，
SQL> select name,value$ from props$;

NAME VALUE$
------------------------------ ----------------------------------------
DICT.BASE 2
DBTIMEZONE 0:00
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

NAME VALUE$
------------------------------ ----------------------------------------
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_NCHAR_CHARACTERSET US7ASCII
NLS_RDBMS_VERSION 8.1.7.0.1
GLOBAL_DB_NAME ORAL
EXPORT_VIEWS_VERSION 8

某日，出差在外，公司里某鸟人导入一NLS_LANG为ZHS16GBK的DMP，然后打电话告诉我他的JAVA程序取出数据为乱码，在毫不知情的情况下我叫他select一下props$看NLS_NCHAR_CHARACTERSET和NLS_CHARACTERSET是不是跟他的导入数据一致，该鸟人居然擅自把这两个参数改为CHS16GBK，GOD！！！至此数据库就再也没有启起来，每次都报ORA-12701: CREATE DATABASE character set is not known，在网上找到N多资料论坛里的N多贴子oracle官方网站的解决办法，诸如
SQL> STARTUP MOUNT;
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE CHARACTER SET <new_character_set_name>;
SQL> SHUTDOWN IMMEDIATE; -- or NORMAL
SQL> STARTUP;
还是报ORA-12701: CREATE DATABASE character set is not known，不open database，直接ALTER DATABASE CHARACTER SET US7ASCII;说新字符集必须是原字符集的超集，改ALTER DATABASE CHARACTER SET ZHS16GBK，却又要我open database。。。。。。。。。。。

在N天的努力之后我放弃了所有恢复原来数据库的企图，找到以前的逻辑备份（公司的鸟人从来不听话，从不做操作系统备份脱机备份联机备份，只会exp），最近的一次是6月1日做的，鸟人是在2000下直接exp出数据，2000客户端的NLS_LANG为ZHS16GBK，导出时被convert了，导入后全是乱码，再想这种情况的解决办法。再次在网上找N多资料论坛里的N多贴子oracle官方网站的解决办法，按照现今流行的
------------------------------------------------------------
SQL > create database character set US7ASCII
* create database character set US7ASCII
ERROR at line 1:
ORA-01031: insufficient privileges
---- 你会发现语句执行过程中，出现上述错误提示信息，此时不用理会，实际上ORACLE数据库的字符集已被强行修改为US7ASCII，接着用imp命令装载数据。等数据装载完成以后，shutdown 数据库，再startup 数据库，用合法用户登录ORACLE数据库，在sql>命令提示符下，运行select * from V$NLS_PARAMETERS，可以看到ORACLE数据库字符集已复原，这时再查看有汉字字符数据的表时，汉字已能被正确显示。
-------------------------------------------------------------------
...................................(等等，太多太多了）


兢兢业业地按步就班地执行完了所有网站上的资料所有论坛里的贴子...........10来天过去了,字符依然顽强地以乱码出现在我面前，无奈，只能用我在去年12月从本机导出的DMP文件EXP了。从此，我每天在老总怀疑的目光下以泪洗面，我不知道现在我该继续在网站上搜索贴子以完成我不可能完成的任务还是忿然弃oracle就我痛恨的SQLSERVER还是在老总怀疑的目光下继续以泪洗面。

遇到过同样问题或者真正彻底地解决了这个问题的oracle战友们，请指条明路给我，能给的分不多，一顿饭却是没得问题，只要你是成都的朋友，13880254354，随时开机

[penitent]

改成了CHS16GBK（没有的字符集），那数据库还能启动？？？
你导出的时候环境是ZHS16GBK，已经是乱码了，再怎么导入还是乱码的。
没有文件备份？？？sigh

[blandkiller]

就是因为改成了CHS16GBK数据库才不能启动，要不我也不会郁闷至今了。
导入已经是乱码了所以才会考虑让他正常，要不我也不会在这里发贴子了。
要有文件备份，恢复这点小工作还是能做的，要不我也不会搭上一顿饭了。

[penitent]

我不在成都，吃不到也不会吃你的饭
呵呵，好象不好解决，看大家还有好办法没有

[biti_rainy]

找oracle支持
上metalink看一下吧
sigh

[ATCG]

你刚才说有DMP备份，那问题就可以解决的，
I think you can surely solve the problem if you have a correct
DMP file which is exported successfully without warnings.

[tlbbqf]

你试过改注册表的方法吗?

[shshsh_0510]

改为GBK的超集，如UTF8

[xinpingf]

兄弟节哀

[snowy_howe]

一个建议是：
不要给予不懂Oracle的人太大的权限。