數據庫為 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其實這個信息是手工更新過數據庫字符集后,重新啟動,數據庫比較數據庫和控制文件信息,根據數據庫字符集修改控制文件字符集導致的.我在以前作過這樣的測試,參考:http://www.eygle.com/special/NLS_CHARACTER_SET_03.htm通過更新PRops$的方式修改字符集是非常危險的,我在以上的文章中有過具體說明,在Oracle8i中,假如修改了錯誤的字符集,那么重新啟動后數據庫將無法啟動.假如需要提醒的話,我們需要再警世一次:
Mon Jun 5 09:52:52 2006
Updating character set in controlfile to ZHS16CGB231280
replication_dependency_tracking turned off (no async multimaster replication found)
絕對不要用update系統表(props$)的方式來修改數據庫字符集.但是從Oracle9i開始,Oracle在啟動時跳過了這個檢查,即使修改了錯誤的字符集,也仍然可以啟動,數據庫啟動時會將控制文件中的字符集更改為缺省的US7ASCII.具體可以看看以下的測試:SQL> select value$ from props$ where name='NLS_CHARACTERSET';VALUE$
新聞熱點
疑難解答
