Oracle 是大海,这里是它的一滴水! http://songhefei.itpub.net

ora-600 12333 错误

上一篇 / 下一篇 2008-06-21 11:39:37 / 个人分类：Oracle数据库

这几天, 日志中经常出现ORA-00600: internal error code, arguments: [12333], [4], [1], [2], [], [], [], [].

Typically the ORA-600 [12333] itself is not the problem,
It may be a chance of the underlying network problems
This is usually a client side related issue and is not normally related to server. It is a communications issue and not related to the version of the RDBMS. Thats why you do have this errors intermittently only.

Most occurances of ORA-600 [12333] just means that something has
gone wrong in the communication between the client and the server processes. Often, this could be the result of an abnormal condition (a process is inadvertently killed, or a database shuts down)

The error indicates a protocol communications mismatch

<Note:112660.1>

PURPOSE
-------

This paper describes one known reason of frequent occurence of ORA-600 [12333]
errors.
NOTE: There may exist many other issues however.

SCOPE & APPLICATION
-------------------

Support Analysts and DBAs.

ORA-600 [12333] in case of termination of user sessions
-------------------------------------------------------

ORA-600 [12333] may occur in case of abnormal termination of user
sessions, eg. shutdown immediate, forced disconnections etc.

Frequent ORA-600 [12333] in case of using resource limit
--------------------------------------------------------

Using user profiles and resource_limit=true may cause frequent ORA-600 [12333]occurence. We may also see many SNIPPED session in V$SESSION. For those ones resources are not freed until any server related action is taken at the client side. It seems that ORA-600 [12333] appears while sending ORA-1012 or ORA-2396 messages to the client process.

If we really have to use user profiles to enforce resource limit policies(especially idle time) we'
d better proactively remove sUCh sessions.
For now, the only found way preventing from ORA-600 [12333] occurence
caused by resource_limit issue is killing processes related to SNIPPED sessions at OS level. This implies it is applicable only to the DEDICATED server processes. Killing shadow processes for SNIPPED sessions is eXPlained in <Note:96170.1>.

NOTE: Killing shadow processes only decreases the likehood of ORA-600 [12333] occurence. It is a workaround.

Couple of suggestion
=======================

1)Check the network errors, their should be any errors or protocol mismatch

2)Check the NLS settings on client as well as server side settings
ORA_NLS (ORA_NLS32, ORA_NLS33) Environment Variables.

Article-ID: <Note:77442.1>
Title: ORA_NLS (ORA_NLS32, ORA_NLS33) Environment Variables

3)NO users should disconnect abnormally

有人推荐,利用登陆信息查看

create table
SYSTEM.login_info
( logindatetime date,
LogoffDateTime Date,
LoggedUser Varchar2(30),
SESSIONID Number,
TERMINAL varchar2(20),
ip varchar2(16),
PROGRAM varchar2(20)
);
--------------------------------------------------------------------
CREATE OR REPLACE TRIGGER logoff_audit Before LOGOFF ON DATABASE
BEGIN
insert into system.login_info
select
'',sysdate,user,sys_context('USERENV','SESSIONID'),sys_context('USERENV'
,'TERMINAL'),utl_inaddr.get_host_address, program from v$session where logon_time = (select
logindatetime from SYSTEM.login_info where SESSIONID=
sys_context('USERENV','SESSIONID'));
END;
---------------------------------------------------------------------
CREATE OR REPLACE TRIGGER logon_audit AFTER LOGON ON DATABASE
BEGIN
insert into system.login_info
select sysdate,null,user,sys_context('USERENV','SESSIONID'),sys_context(
'USERENV','TERMINAL'),utl_inaddr.get_host_address,program from v$session;
END;
==============================================================.

导入论坛引用链接收藏分享给好友推荐到圈子管理举报

TAG:

查看全部评论