不放过任何错误处理的机会

不放过任何错误处理的机会-巧遇ORA-06553

在运行一个sql语句的时候，出现了这个问题。不放过任何一个出错的机会，一定先用自己的知识解决掉，是我学习oracle的口诀

检查了一下这个error-code

ORA-06552: PL/SQL: Compilation unit analysis terminated

ORA-06553: PLS-553: character set name is not recognized 

不知道是什么原因，先查查相关的metalink没有查到什么东西。

itpub里看到一个贴，现象是一样的，不过没有结果，biti大人的回答，感觉上是不靠谱的。和字符集确实有关，信息这样提示的，

不过怎样的无法法了，为什么别的表就是OK的，而只有这个表不行哟。应该不是一个单纯的字符集问题了，更何况我的字符集

是正确的

分析一下这个问题。先看alert.log,里面记录了这个错误，如下

ksedmp: internal or fatal error

Current SQL statement for this session:

select * from all_tables

----- Call Stack Trace -----

calling              call     entry                argument values in hex      

location             type     point                (? means dubious value)     

-------------------- -------- -------------------- ----------------------------

_ksedst+38           CALLrel  _ksedst1+0           0 1

_ksedmp+898          CALLrel  _ksedst+0            0

__VInfreq__psdghi+6  CALLrel  _ksedmp+0            1

528                                                

_psdgbt+530          CALLrel  _psdgbtds_debug_sup  7D9B858 1 354 0

                              port+0               

_ph2gbi+319          CALL???  00000000             7D9B858 7D9B984 2 0 60C50D80

                                                   7D9B220 7D9B858 60E18200

                                                   80000008 6E

_ph2dr2+148          CALLrel  _ph2gbi+0            7D9B2F0 80000008

_ph2drv+204          CALLrel  _ph2dr2+0            7D9B2F0 31051404 0

_phpsem+31           CALLrel  _ph2drv+0            7D9B858 31051404 0

_phpcmp+1105         CALLrel  _phpsem+0            7D9B858 31051404 0

_pcicms2+302         CALLrel  _phpcmp+0            7D9B858 31051404 4BE8374 51 7

                                                   31444968 309A6A00 0

_pcicms+31           CALLrel  _pcicms2+0           7D9B858 31051404 4BE8374 51

                                                   7D9B940 31444968 309A6A00 0 0

_kkxcms+538          CALLrel  _pcicms+0            

_kkxswcm+130         CALLrel  _kkxcms+0            7D9BA00

_kkxmpbms+1084       CALLrel  _kkxswcm+0           4BE1E04 31051404 4BE8374 51

                                                   309A69E8 31444968 309A6A00 0

                                                   0

_kkxmesu+88          CALLrel  _kkxmpbms+0          7EDF4C4 309A69E8

_xtypls+347          CALLrel  _kkxmesu+0           7EDF4C4 4BE81A0

_qctopls+484         CALLreg  00000000             31DCBDB8 0 313C6128 4BE4F0A E

                                                   7 7ED2C64 7D9BB84 7D9BB98

                                                   7EDF4C4

底下是一堆的stack的信息。没有头绪。

在错误的上方发现一条信息

*** 2009-09-05 08:48:46.625

*** SERVICE NAME:(SYS$USERS) 2009-09-05 08:48:46.609

*** SESSION ID:(168.1) 2009-09-05 08:48:46.609

psdgbt: bind csid (852) does not match session csid (1)

psdgbt: session charset is US7ASCII

奇怪这里的session怎么就变了US7ASCII了哟。

我这个session有过什么变化了。

如果是这个问题的话，那么应该不是常发性的问题，应该是我的session的字符集被修改了导致这个问题，如果我断掉在来，可能就不会有这个问题了。大胆的一番推测以后，我conn / as ssydba以后。

再次运行同样的sql，问题已经消失了。奇怪的问题就这样消失了，

一连测试了好几遍，都没有出现问题，想想，刚才我的操作，是不是刚才的一些操作导致呀，我刚才也只做了RMAN而已呀。

不会是RMAN对我的这个有影响吧。现在的关键问题就是在session的字符集怎么就变了上了。

......