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

• 作者: 三十而立
• 时间：2009年9月05日 21:12:10
• 本文出自 “inthirties（三十而立）”博客，转载请务必注明作者和保留出处http://blog.csdn.net/inthirties/archive/2009/09/05/4521886.aspx

 

不放过任何错误处理的机会-巧遇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的字符集怎么就变了上了。

 

......

 

 

• 如果没有那句“三十而立”，三十岁的男人正可以轻轻松松
• 专业论坛 http://www.inthirties.com
• 技术博客 http://blog.csdn.net/inthirties
• 个人站点 http://blog.inthirties.com
• Oracle Mysql技术论坛| 打造实用的Oracle Mysql技术交流园地