eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle以48.6%占有率再居首位 | Blog首页 | 侏罗纪公园 »

DBA警世录:更新系统表(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.

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

SQL> select value$ from props$ where name='NLS_CHARACTERSET';

VALUE$
----------------------------------------------------------
ZHS16GBK

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

1 row updated.

SQL> commit;

Commit complete.

SQL> select value$ from props$ where name='NLS_CHARACTERSET';

VALUE$
-----------------------------------------
EYGLE

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

Total System Global Area 126948772 bytes
Fixed Size 452004 bytes
Variable Size 92274688 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
SQL> select value$ from props$ where name='NLS_CHARACTERSET';

VALUE$
----------------------------------------------
EYGLE

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

Thu Jun 8 16:28:05 2006
SMON: enabling cache recovery
SMON: enabling tx recovery
Thu Jun 8 16:28:05 2006
Updating character set in controlfile to US7ASCII
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN

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

 


历史上的今天...
    >> 2017-06-08文章:
    >> 2010-06-08文章:
    >> 2009-06-08文章:
    >> 2007-06-08文章:
           三十而立 是以为记
    >> 2005-06-08文章:

无觅

By eygle on 2006-06-08 15:31 | Comments (7) | Special | 787 |

7 Comments

但在EXP时会导不出数据.

再改回去就ok了。

请问一下你是怎么改回去就OK的啊?
如果 9i里面 通过修改 props$ 表的方式修改字符集,有办法‘改回去就OK了’吗?

数据库没关闭容易,数据库关闭起不来就麻烦了。

安装Oracle时字符集默认语言,现在想更改NLS_CHARACTERSET=ZHS16GBK,应该怎么做才能既更改字符集了,又不会出现像ORA-06552 & ORA-06553的错误呢?

安装Oracle时字符集默认语言,现在想更改NLS_CHARACTERSET=ZHS16GBK,应该怎么做才能既更改字符集了,又不会出现像ORA-06552 & ORA-06553的错误呢?


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com