系统宕机导致数据库自动更改字符集

kwin

数据库为 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

居然系统报字符集的错！
后来通过查Metalink 上发的一篇文档 286964.1 ，里面提供了一个脚本来确认了系统中的字符集是有错的。

select distinct(nls_charset_name(charsetid)) CHARACTERSET, charsetid,
decode(type#, 1, decode(charsetform, 1, 'VARCHAR2', 2,
'NVARCHAR2','UNKOWN'),
9, decode(charsetform, 1, 'VARCHAR', 2, 'NCHAR VARYING',
'UNKOWN'),
96, decode(charsetform, 1, 'CHAR', 2, 'NCHAR', 'UNKOWN'),
112, decode(charsetform, 1, 'CLOB', 2, 'NCLOB', 'UNKOWN'))
TYPES_USED_IN
from sys.col$ where charsetform in (1,2) and type# in (1, 9, 96,
112);


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

zhxx_ora

系统在第一次宕机起来后就自已将 controlfile 中的字符集给更改了。

-------????
这个好像没有科学根据呀!
能不能把此个时间点前后的alert***.log贴上来看看??

kwin

我们当时也没想到会这样，后来Oracle的说法是，数据库在启动时检查到数据字典中的字符集与 controlfile 中的不一致，就到 controlfile 中的字符集给改了。
以下为 alter log 中给出的信息。
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)

cjf107

涨见识了。

zhxx_ora

Oracle的说法是，数据库在启动时检查到数据字典中的字符集与 controlfile 中的不一致，就到 controlfile 中的字符集给改了。

--难道不正常的关闭、启动会造成“数据字典中的字符集与 controlfile 中的不一致”？

kwin

最初由 zhxx_ora 发布
[B]Oracle的说法是，数据库在启动时检查到数据字典中的字符集与 controlfile 中的不一致，就到 controlfile 中的字符集给改了。

--难道不正常的关闭、启动会造成“数据字典中的字符集与 controlfile 中的不一致”？ [/B]

关于这个问题，正在等 Oracle 进一步确认，我想他们是要去查一查源码了。

oldboy

没有听说过,关注.

ZALBB

最初由 cjf107 发布
[B]涨见识了。 [/B]

晕，ORACLE真神通广大！这都行

kwin

最初由 ZALBB 发布
[B]

晕，ORACLE真神通广大！这都行 [/B]

  所以各位 DBA 可要注意，不要使 ORACLE 随便出现 异常宕机的情况，不然很难说会有什么事情发生的。

biti_rainy

肯定是有人手工update 过 props$ ，数据库正常情况下根本就不知道被直接update 过，所以一直运行正常。

重新启动的时候数据库去检查 props$ 结果发现和控制文件中不一样。