更新系统表(props$)修改字符集
|
今天在Itpub上再次看到字符集变化导致的问题,作者给出的案例是这样的: 数据库为 9.2.0.7.0 ,OS : Solaris Operating System (SPARC 64-bit) 起因是这样的,我的一客户那里UPS出现故障导致系统宕机, 这个SQL是这样的: select * from ww.test20060504 dg where dg.user_number="7290" 第一个想法是给那个索引做分析,但还是不行,我们就对这个表做了一次分析,但执行计划没有什么改变 。 EXP-00056: ORACLE error 6552 encountered 居然系统报字符集的错! 真是晕呀!我们马上仔细检查了一个 alter 文件发现了一条信息,系统在第一次宕机起来后就自已将 controlfile 中的字符集给更改了。最后我们将系统中的字符集改回来系统就恢复正常了。 警告日志中的信息是这样的: SMON: enabling tx recovery 其实这个信息是手工更新过数据库字符集后,重新启动,数据库比较数据库和控制文件信息,根据数据库字符集修改控制文件字符集导致的. 我在以前作过这样的测试,参考: http://www.eygle.com/special/NLS_CHARACTER_SET_03.htm 通过更新props$的方式修改字符集是非常危险的,我在以上的文章中有过详细说明,在Oracle8i中,如果修改了错误的字符集,那么重新启动后数据库将无法启动. 如果需要提醒的话,我们需要再警世一次: 绝对不要用update系统表(props$)的方式来修改数据库字符集. 但是从Oracle9i开始,Oracle在启动时跳过了这个检查,即使修改了错误的字符集,也仍然可以启动,数据库启动时会将控制文件中的字符集更改为缺省的US7ASCII. 具体可以看看以下的测试: SQL> select value$ from props$ where name="NLS_CHARACTERSET"; VALUE$ SQL> update props$ set value$="EYGLE" 1 row updated. SQL> commit; Commit complete. SQL> select value$ from props$ where name="NLS_CHARACTERSET"; VALUE$ SQL> shutdown immediate; Total System Global Area 126948772 bytes VALUE$ 此时警告日志中会记录如下信息: Thu Jun 8 16:28:05 2006 不同版本中,Oracle行为已经不同. 源代码网供稿. |
