更新系统表(props$)修改字符集

今天在Itpub上再次看到字符集变化导致的问题,作者给出的案例是这样的:

数据库为 9.2.0.7.0 ,OS : Solaris Operating System (SPARC 64-bit)

起因是这样的，我的一客户那里UPS出现故障导致系统宕机，
然后起来，大约过了10来分钟，突然操作系统找不到磁盘又一次宕机，
然后再起来，有用户报一个SQL用不上索引.

这个SQL是这样的：

select * from ww.test20060504 dg where dg.user_number='7290'

第一个想法是给那个索引做分析，但还是不行，我们就对这个表做了一次分析，但执行计划没有什么改变 。
我们尝试加提示（包括加 rule )，但也不行，用户反映是有一批这样类似的都用不到索引。
然后通过 10053 做 trace 居然发现优化器根本没有考虑索引。开始怀疑这个数据库的数据字典可能有问题。
我们只好用一个笨方法，将其中一个表导到测试库上去测试，在导出的过程中居然发现系统报错

EXP-00056: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized

居然系统报字符集的错！
.....

真是晕呀！我们马上仔细检查了一个 alter 文件发现了一条信息，系统在第一次宕机起来后就自已将 controlfile 中的字符集给更改了。最后我们将系统中的字符集改回来系统就恢复正常了。

警告日志中的信息是这样的:

SMON: enabling tx recovery
Mon Jun 5 09:52:52 2006
Updating character set in controlfile to ZHS16CGB231280
replication_dependency_tracking turned off (no async multimaster replication found)

其实这个信息是手工更新过数据库字符集后,重新启动,数据库比较数据库和控制文件信息,根据数据库字符集修改控制文件字符集导致的.

我在以前作过这样的测试,参考:

http://www.eygle.com/special/NLS_CHARACTER_SET_03.htm

通过更新props$的方式修改字符集是非常危险的,我在以上的文章中有过详细说明,在Oracle8i中,如果修改了错误的字符集,那么重新启动后数据库将无法启动.

如果需要提醒的话,我们需要再警世一次:

绝对不要用update系统表(props$)的方式来修改数据库字符集.

但是从Oracle9i开始,Oracle在启动时跳过了这个检查,即使修改了错误的字符集,也仍然可以启动,数据库启动时会将控制文件中的字符集更改为缺省的US7ASCII.

具体可以看看以下的测试:

此时警告日志中会记录如下信息:

不同版本中,Oracle行为已经不同.

原文地址：http://www.eygle.com/archives/2006/06/dba_update_prop.html