Resource Manager资源管理器功能介绍

2011/10/14 by Leave a Comment

数据库资源管理器通过控制数据库内部的执行调度来控制资源在各个会话之间的分布。通过控制所要运行的会话以及会话运行的时间长度，数据库资源管理器可以确保资源分布与计划指令相匹配，因此也符合业务目标。

 

请注意，oracle resource manager对CPU的限制粒度为消费组(consumer group)， 无法细化控制消费组内个别进程消耗CPU的比例，只要不超出该消费组的CPU限制，消费组内的单个或多个进程的CPU使用不受限制。

 

 

10g中Resource Manager资源管理器可以控制的资源种类：

 

  1. Oracle进程的CPU使用率
  2. 并行度(Parallel)
  3. UNDO数量
  4. SQL语句操作执行时间(Execute Time)
  5. 会话空闲时间(Idle Time)
  6. 活跃会话(session)数

 

以下会话属性可以用来作为映射规则的条件，换而言之Resource Manager仅可以通过下列会话属性来区分session的消费组：

 

2．      介绍Resource Manager如何控制CPU

 

有两种方法可以通过CPU_MTH 参数指定CPU 使用率：

 

EMPHASIS，这是默认方法，用于多级计划，它以百分比形式指定CPU 如何在使用者组之间分布。

 

 

EMPHASIS CPU 分配方法确定在资源计划中对不同使用者组中的会话的重视程度。CPU

占用率的分配级别为从1 到8，级别1 的优先级最高。百分比指定如何将CPU 资源分配

给每一级中的各个使用者组。

 

以下规则适用于EMPHASIS 资源分配方法：

 

CPU 资源在给定级别按指定的百分比分配。为资源使用者组指定的CPU 百分比是该

使用者组在给定级别可以使用的最大值。

给定级别上没有使用的使用者资源可供下一级别的使用者组使用。例如，如果级别1

的使用者组只使用了60% 的可用资源，则其余的40% 可供级别2 的使用者组使用。

任何给定级别的百分比总和必须小于等于100。

对于没有明确指定计划指令的所有级别，其所有子计划或使用者组的默认资源是0%。

EMPHASIS 资源分配方法避免了资源缺乏问题，该问题导致优先级较低的使用者没

有运行的机会。

 

 

EM图形界面下使用EMPHASIS 资源分配方法

 

 

SQLPLUS命令行下使用EMPHASIS 资源分配方法

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_plan(plan    => ‘DB_CONSOLIDATE_PLAN’,

comment => ‘DB_CONSOLIDATE_PLAN comment’);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘BATCH_GROUP’,

‘Percentage of CPU for APP_1’,

mgmt_p1 => 40);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘OTHER_GROUPS’,

‘Percentage of CPU for APP_2’,

mgmt_p1 => 40);

dbms_resource_manager.submit_pending_area();

END;

 

 

以上使用EMPHASIS 资源分配方法指定了4个消费组在P1的CPU分配比例， 注意必须为OTHER_GROUPS指定分配比例， OTHER_GROUPS是默认消费组。

 

如以上配置，若CPU没有被任何一个或多个消费组使用，则Resource Manager将对此时需求CPU的消费组(consumer group)随需随取。 举一个例子来说，若APP_1是唯一在运行中的消费组，则此时Resource Manager理论上可以给予100%的CPU(如果APP_1确实需要的话)。由此，mgmt_p1指定了消费组所被保证可以获得的CPU使用比例。 消费组所能消费的最大CPU比例是100%。

 

 

在某些场景中，用户希望实现仅在高优先级消费组不使用部分CPU的情况下，将这些不被高级别消费组不使用的资源分配给其他用户组。 此时可以定义如上的计划资源分配来规划未被高级别使用的CPU。 如以上示例配置， 未被Level 1 使用 或 分配的CPU将被Level 2的消费组使用，按照LEVEL 2所指定的。 未被Level 2使用 或 分配的CPU将被Level 3的消费组使用，按照Level 3所指定的，以此类推。

 

举例来说，如上述配置BATCH消费组在mgmt_p1的比例为5%，在mgmt_p2的比例为100%。则其被保证可以获得的CPU比例为 %5+ 100% * (所有未被LEVEL 1分配或使用的CPU)。

 

 

 

RATIO 适用于单级计划，它使用比率来指定CPU 是如何分布的。

 

RATIO 策略是一个单级别CPU 分配方法。将指定要为使用者组分配的CPU 比率相对应的数字，而不是百分比。例如，假定有三个使用者组OLTP_USERS、DSS_USERS 和BATCH_USERS，可以指定下列比率：

 

OLTP_USERS：4
DSS_USERS：3
BATCH_USERS：2
OTHER：1

 

这就类似于让OLTP 用户获得40% 的资源、DSS 用户获得30% 的资源、批用户获得20%的资源、所有其它使用者组获得10% 的可用资源。如果OTHER 或DSS_USERS 使用者组中当前都没有使用者在使用CPU 资源，则OLTP_USERS 使用者组将获得三分之二的可用资源，而BATCH_USERS 使用者组将获得三分之一。

 

3．      介绍Resource Manager如何控制其他资源

 

最大估计执行时间

 

1.     数据库资源管理器可以预先估计操作的执行时间。

2.     可以在资源使用者组级别为操作指定最大估计执行时间。

3.     如果估计时间超过MAX_EST_EXEC_TIME，则操作不会启动。(ORA-07455)

4.     此功能的好处是消除了使用过多系统资源的异常大的作业。

5.     默认值为UNLIMITED。

 

通过设置资源计划指令的MAX_EST_EXEC_TIME 参数，可以定义任何给定时间发生的

任何操作的最大估计执行时间。设置了此参数后，数据库资源管理器将估计特定作业消

耗的时间。如果操作的估计时间超过MAX_EST_EXEC_TIME，则不启动操作并发出

ORA-07455 错误。这样可以消除占用过多系统资源的任何异常大的作业。

如果有多个计划指令引用了某个资源使用者组，则该组可能有多个MAX_EST_EXEC_TIME。

数据库资源管理器将选择所有传入值中限制性最强的那个值。

使用基于成本的优化程序的统计信息，可以计算出给定语句的估计执行时间。

 

 

 

并行度

 

PARALLEL_DEGREE_LIMIT_MTH 限制任何操作的最大并行度。只能为资源使用者组，

而不能为子计划指定此方法。ABSOLUTE 方法是可能值，该方法指定可以为一个操作分配

的进程数量。如果有多个计划指令引用了相同的子计划或使用者组，则使用所有可能值中

的最小值作为该子计划或使用者组的并行度限制。

 

 

 

 

 

 

 

 

 

 

 

活动会话池

 

 

ACTIVE_SESS_POOL_MTH 限制活动会话的数量。所有其它会话均为非活动的，在队列

中等待激活。ACTIVE_SESS_POOL_ABSOLUTE 是默认且唯一的可用方法。

 

使用活动会话池功能，可以控制每个资源使用者组的最大并发活动会话数。使用此功能，

由于资源的消耗与活动会话的数量成比例，所以DBA 能间接控制任何资源使用者组使用

的资源量。使用活动会话池有助于减少从系统中获取资源的服务器数量，因而可以避免

由于试图同时运行过多作业而导致的低效的分页、交换和其它资源损耗（如内存）。

使用活动会话填充活动会话池后，资源管理器对尝试成为活动会话的所有后续会话进行

排队，直到其它活动会话完成或成为不活动会话。活动会话是事务处理、查询或并行操作

中当前涉及的会话。单独的并行从属进程不被视为会话；而将整个并行操作视为一个活动

会话。

 

每个资源使用者组只有一个队列，排队方法是先进先出(FIFO)，并带有超时。队列采用

内存结构，不能直接查询。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4．      配置Resource Manager的步骤

 

如何为多种类型的负载配置Oracle Resource Manager，可以分为9个步骤，部分为可选步骤：

 

1.     授予必要的Resource Manager权限

2.     创建一个pending区域

3.     创建consumer group消费组

4.     映射Oracle session会话到消费组

5.     为消费组增加权限(可选)

6.     创建一个资源计划resource plan

7.     增加资源计划指令(directives)

8.     提交一个pending区域

9.     启用以上资源计划resource plan

 

 

步骤1：授予管理者Resource Manager管理员权限

 

管理Resource Manager要求使用”ADMINISTER_RESOURCE_MANAGER”权限， 该权限自动已授予SYS用。 如下PL/SQL命令将此权限授予MACLEAN用户：

 

 

 

exec dbms_resource_manager_privs.grant_system_privilege(grantee_name=>’MACLEAN’,admin_option=>true);

 

步骤2：创建一个pending区域

 

定义或修改消费组和资源计划的第一步骤是创建一个pending区域，pending area是针对resource management配置的一个临时工作区域。 任何pending区域中的变化在实际pending区域被提交前都不实际生效。

 

创建一个pending area:

 

 

exec dbms_resource_manager.create_pending_area();

 

在任何时候都可以放弃pending area中的所有变更，执行以下命令清理pending area:

 

exec dbms_resource_manager.clear_pending_area();

 

步骤3：创建消费组(Consumer Group)

 

Oracle数据库默认会预配置以下多个消费组。 在自定义创建消费组之前，应当考虑下面是否有满足要求的预定义消费组：

 

 

 

 

 

若以上预定义的消费组均不满足要求，则需要自行创建定义消费组。 执行以下PL/SQL命令将会创建名为MACLEAN_APP的消费组：

 

 

begin

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_consumer_group(‘MACLEAN_APP’,

‘Sessions for the MACLEAN Application’);

dbms_resource_manager.submit_pending_area();

end;

/

 

 

 

步骤4：映射会话到消费组

 

自动将Oracle session会话对应到一个消费组的方式叫做映射规则(Mapping RULE)。 举例来说下面的示例映射规则将SERVICE_NAME=BATCH的所有会话对应为’BATCH_GROUP’消费组：

 

begin

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.set_consumer_group_mapping(attribute      => dbms_resource_manager.service_name,

value          => ‘BATCH’,

consumer_group => ‘BATCH_GROUP’);

dbms_resource_manager.submit_pending_area();

end;

/

 

 

 

以下会话属性可以用来作为映射规则的条件：

 

ORACLE会话可以自行显示地映射到一个消费组，使用如下命令：

 

dbms_session.switch_consumer_group()

 

 

 

步骤5：为消费组增加权限(可选)

 

该步骤仅针对需要启用切换消费组的功能实现，如果不需要消费组切换功能可以跳过。

 

为了实现消费组切换，用户或角色必须有相应的权限，如下PL/SQL命令将允许”scott”用户切换到INTERACTIVE_GROUP消费组。

 

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

 

dbms_resource_manager_privs.grant_switch_consumer_group(grantee_name   => ‘scott’,

consumer_group => ‘INTERACTIVE_GROUP’,

grant_option   => FALSE);

 

dbms_resource_manager.submit_pending_area();

END;

/

 

 

 

如下PL/SQL命令允许任何用户切换到”BATCH_GROUP”消费组：

 

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

 

dbms_resource_manager_privs.grant_switch_consumer_group(grantee_name   => ‘public’,

consumer_group => ‘BATCH_GROUP’,

grant_option   => FALSE);

 

dbms_resource_manager.submit_pending_area();

END;

/

 

 

 

步骤6：创建资源计划

 

 

以下是Oracle数据库预定义的多个资源计划， 在自行创建资源计划前应当考虑以下现有resource plan 是否满足需求。

 

可以通过如下SQL语句查询某个资源计划相关的消费组：

 

select group_or_subplan

from dba_rsrc_plan_directives

where plan = ‘DSS_PLAN’;

 

 

通过如下语句创建一个资源计划”DB_CONSOLIDATE_PLAN”:

 

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

 

dbms_resource_manager.create_plan(‘DB_CONSOLIDATE_PLAN’,

‘Plan for database consolidation’);

 

dbms_resource_manager.submit_pending_area();

END;

/

 

 

 

 

步骤7：增加资源计划指令(resource plan directives)

 

资源计划指令(resource plan directives)指定了消费组如何分配CPU、UNDO、并行度等等资源。 可以使用dbms_resource_manager.create_plan_directive()函数创建新的资源指令。也可以通过update_plan_directive或delete_plan_directive() 更新或删除现有的资源指令。

 

参数mgmt_p1指定了消费组分配的CPU使用比例。

 

下列PL/SQL命令，创建了上表描述的资源指令：

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

 

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘APP_1’,

‘Percentage of CPU for APP_1’,

mgmt_p1 => 40);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘APP_2’,

‘Percentage of CPU for APP_2’,

mgmt_p1 => 25);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘APP_3’,

‘Percentage of CPU for APP_3’,

mgmt_p1 => 25);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘APP_4’,

‘Percentage of CPU for APP_1’,

mgmt_p1 => 5);

dbms_resource_manager.create_plan_directive(‘DB_CONSOLIDATE_PLAN’,

‘APP_1’,

‘Percentage of CPU for APP_1’,

mgmt_p1 => 5);

 

dbms_resource_manager.submit_pending_area();

END;

 

 

 

以上使用EMPHASIS 资源分配方法指定了4个消费组在P1的CPU分配比例， 注意必须为OTHER_GROUPS指定分配比例， OTHER_GROUPS是默认消费组。

 

如以上配置，若CPU没有被任何一个或多个消费组使用，则Resource Manager将对此时需求CPU的消费组(consumer group)随需随取。 举一个例子来说，若APP_1是唯一在运行中的消费组，则此时Resource Manager理论上可以给予100%的CPU(如果APP_1确实需要的话)。由此，mgmt_p1指定了消费组所被保证可以获得的CPU使用比例。 消费组所能消费的最大CPU比例是100%。

 

步骤8：提交pending area

 

一旦你完成了配置资源计划，应当执行以下PL/SQL 代码以便使变更真正生效。若你所修改的资源计划目前正被激活，则这些变更将立即被启用。

 

exec dbms_resource_manager.submit_pending_area();

 

 

步骤9：启用资源计划

 

在资源计划已经定义好的情况下，则可以修改resource_manager_plan参数来启用该resource plan了：

 

alter system set resource_manager_plan = ‘DB_CONSOLIDATION_PLAN’ sid=’*’;

 

除了手动启用资源计划外，也可以将资源计划绑定到Oracle自动作业的窗口时间，这样每次该scheduler windows启动时都会激活该资源计划。 例如我们将上述的DB_CONSOLIDATION_PLAN和MONDAY_WINDOW这个窗口绑定，则每次MONDAY_WINDOW打开均会激活DB_CONSOLIDATION_PLAN，当MONDAY_WINDOW结束DB_CONSOLIDATION_PLAN也会随之被关闭。

 

 

exec dbms_scheduler.set_attribute(‘MONDAY_WINDOW’, ‘RESOURCE_PLAN’, ‘DB_CONSOLIDATION_PLAN’);

 

 

 

5．      示例Resource Manager配置

 

以下我们示例配置一个Resource Plan及其3个消费组，其中我们使用MODULE_NAME模块名作为消费组的映射规则，并采用EMPHASIS方式指定其中APP1_GROUP、APP2_GROUP消费组分别mgmt_p1 40%和30%的CPU，并限定APP1_GROUP、APP2_GROUP消费组的空闲时间为7200秒及3600秒。

 

1、创建APP_1和APP_2消费组

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_consumer_group(consumer_group => ‘APP1_GROUP’,

comment        => ‘FOR TEST PURPOSE’);

 

dbms_resource_manager.create_consumer_group(consumer_group => ‘APP2_GROUP’,

comment        => ‘FOR TEST PURPOSE’);

dbms_resource_manager.submit_pending_area();

END;

 

 

2、使用MODULE_NAME模块名作为消费组的映射规则条件，创建Consumer Groups Mapping

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.module_name,

‘APP1’,

‘APP1_GROUP’);

 

dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.module_name,

‘APP2’,

‘APP2_GROUP’);

dbms_resource_manager.submit_pending_area();

END;

/

 

 

 

 

 

3、创建Resource Manager Plan及resource directives

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_plan(plan    => ‘APP_PLAN’,

comment => ‘PLAN FOR APPS’);

dbms_resource_manager.create_plan_directive(plan             => ‘APP_PLAN’,

group_or_subplan => ‘APP1_GROUP’,

comment          => ‘FOR APP1’,

mgmt_p1          => 40,

max_idle_time    => 7200);

 

dbms_resource_manager.create_plan_directive(plan             => ‘APP_PLAN’,

group_or_subplan => ‘APP2_GROUP’,

comment          => ‘FOR APP2’,

mgmt_p1          => 30,

max_idle_time    => 3600);

 

dbms_resource_manager.create_plan_directive(plan             => ‘APP_PLAN’,

group_or_subplan => ‘OTHER_GROUPS’,

comment          => ‘FOR OTHER’,

mgmt_p1          => 30);

 

dbms_resource_manager.submit_pending_area();

END;

/

 

 

4、激活此resource manager plan

 

alter system set resource_manager_plan=APP_PLAN scope=memory;

 

 

 

示例2，限制module_name为sqlplus.exe和toad.exe的程序的IDLE_TIME为200s。

 

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_consumer_group(consumer_group => ‘SQLPLUS_TOAD_GROUP’,

comment        => ‘FOR TEST PURPOSE’);

 

dbms_resource_manager.submit_pending_area();

END;

 

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.module_name,

‘sqlplus.exe’,

‘SQLPLUS_TOAD_GROUP’);

 

dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.module_name,

‘toad.exe’,

‘SQLPLUS_TOAD_GROUP’);

dbms_resource_manager.submit_pending_area();

END;

/

 

BEGIN

dbms_resource_manager.clear_pending_area();

dbms_resource_manager.create_pending_area();

dbms_resource_manager.create_plan(plan    => ‘SQLPLUS_TOAD_PLAN’,

comment => ‘PLAN FOR APPS’);

dbms_resource_manager.create_plan_directive(plan             => ‘SQLPLUS_TOAD_PLAN’,

group_or_subplan => ‘SQLPLUS_TOAD_GROUP’,

comment          => ‘FOR SQLPLUS_TOAD_GROUP’,

max_idle_time    => 200);

dbms_resource_manager.create_plan_directive(plan             => ‘SQLPLUS_TOAD_PLAN’,

group_or_subplan => ‘OTHER_GROUPS’,

comment          => ‘FOR OTHER’,

mgmt_p1          => 50);

 

dbms_resource_manager.submit_pending_area();

END;

/

 

 

alter system set resource_manager_plan=SQLPLUS_TOAD_PLAN;

 

 

SQL> select RESOURCE_CONSUMER_GROUP from v$session where sid=(select distinct sid from v$mystat);

 

RESOURCE_CONSUMER_GROUP

—————————————————————-

SQLPLUS_TOAD_GROUP

 

wait 200 seconds

 

SQL> select * from dual;

select * from dual

*

ERROR at line 1:

ORA-02396: exceeded maximum idle time, please connect again

以上使用sqlplus.exe登陆实例后session映射SQLPLUS_TOAD_GROUP消费组，到空闲200s以上，session自动退出。

 

 

Filed Under: Oracle Tagged With:

Script:Diagnostic Resource Manager

2011/08/30 by Leave a Comment

以下脚本可以用于诊断Oracle 10g以后的Resource Manager信息:

set echo on;
    set linesize 300;
    set pages 1000;
    set numwidth 10;
    set trimspool on;
    col VALUE for a30;
    col ATTRIBUTE for a15;
    col GRANTEE for a25;
    col CPU_METHOD for a15;
    col COMMENTS for a30;
    col MGMT_METHOD for a15;
    col STATUS for a10;
    alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss';
    spool info.lst;
    SELECT SYSDATE FROM DUAL;
    SELECT * FROM DBA_RSRC_MANAGER_SYSTEM_PRIVS;
    SELECT * FROM DBA_RSRC_CONSUMER_GROUP_PRIVS;
    SELECT * FROM DBA_RSRC_CONSUMER_GROUPS;
    SELECT * FROM DBA_RSRC_PLANS;
    SELECT * FROM DBA_RSRC_PLAN_DIRECTIVES;
    SELECT * FROM V$RSRC_CONSUMER_GROUP;
    SELECT * FROM V$RSRC_CONSUMER_GROUP_CPU_MTH;
    SELECT * FROM V$RSRC_PLAN;
    SELECT * FROM V$RSRC_PLAN_CPU_MTH;
    SELECT * FROM DBA_RSRC_MAPPING_PRIORITY;
    SELECT * FROM DBA_RSRC_GROUP_MAPPINGS;
    -- For 10gR2 -------
    SELECT * FROM V$RSRC_CONS_GROUP_HISTORY;
    SELECT * FROM V$RSRC_PLAN_HISTORY;
    SELECT * FROM V$RSRC_SESSION_INFO;
    -- FOR 11gR1 -------
    SELECT * FROM V$RSRCMGRMETRIC
    order by BEGIN_TIME,END_TIME,CONSUMER_GROUP_ID;
    SELECT * FROM V$RSRCMGRMETRIC_HISTORY
    order by BEGIN_TIME,END_TIME,CONSUMER_GROUP_ID;
    spool off;

 create_sample_plan.sql
    ----------------------------------------------------------------------------
    set echo on
    begin
       dbms_resource_manager.create_pending_area();
    end;
    /
    begin
       dbms_resource_manager.create_plan(
          plan => 'ONLINE_PLAN',
          comment => 'Resource plan/method for Day Time On-Line sessions');
       dbms_resource_manager.create_plan(
          plan => 'BATCH_PLAN',
          comment => 'Resource plan/method for Night Time Batch sessions');
    end;
    /

opatch lsinventory -detail

 top -b -d 1 -n 3600 >> toplog
 sar -P ALL 1 3600 >> sarlog

ALTER SYSTEM SET resource_manager_plan='';
Filed Under: Oracle, Oracle脚本script Tagged With: ,

Oracle内部错误:ORA-00600[kgskdecrstat1]一例

2011/04/28 by 3 Comments

一套Itanium HP-UX上的9.2.0.5系统最近出现了ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [],内部错误，其错误日志如下:

Mon Apr 18 12:32:20 2011
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []
ARC0: Completed archiving  log 6 thread 1 sequence 831803
Mon Apr 18 12:32:22 2011
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []
Mon Apr 18 12:32:23 2011
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []

Trace file
----------
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
ORACLE_HOME = /opt/oracle/product/9.2.0.5
System name:	HP-UX
Release:	B.11.23
Version:	U
Machine:	ia64
Redo thread mounted by this instance: 1
Oracle process number: 28
Unix process pid: 14827, image: oracle@(TNS V1-V3)

*** 2011-04-18 02:39:15.043
*** SESSION ID:(276.16183) 2011-04-18 02:39:15.042
DEADLOCK DETECTED
Current SQL statement for this session:
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                      ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00030022-0070d56f        28     276     X            344     259           X
TX-000a0012-0058e4fc       344     259     X             28     276           X
session 276: DID 0001-001C-0000002C	session 259: DID 0001-0158-000020E6
session 259: DID 0001-0158-000020E6	session 276: DID 0001-001C-0000002C
Rows waited on:
Session 259: obj - rowid = 00001F0D - AABNCDAAEAAAAXYAAL
 (dictionary objn - 7949, file - 4, block - 1496, slot - 11)
Session 276: obj - rowid = 00001F0B - AABNCAAAEAAAAXCAAY
 (dictionary objn - 7947, file - 4, block - 1474, slot - 24)
Information on the OTHER waiting sessions:
Session 259:
 pid=344 serial=17280 audsid=106170227 user: 41
           program: JDBC Thin Client
 application name: JDBC Thin Client, hash value=0
 Current SQL Statement:
End of information on OTHER waiting sessions.
*** 2011-04-18 12:32:20.392
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kgskdecrstat1], [], [], [], [], [], [], []
----- Call Stack Trace -----
... kgskdecrstat  kskdecrstat  ktudecrustat  ktcdso  ktcrcm  ktdcmt  k2lcom ...
----- End of Call Stack Trace -----

PROCESS STATE
-------------
   program: JDBC Thin Client
   application name: JDBC Thin Client, hash value=0
   last wait for 'SQL*Net message from client' blocking sess=0x0 seq=39332 wait_time=21242
               driver id=74637000, #bytes=1, =0

可以看到以上引发ORA-00600[kgskdecrstat1]内部错误的进程同时发现了死锁(DEADLOCK)，在MOS上搜索可以发现”Bug 2894072: ORA-00600: INTERNAL ERROR CODE, ARGUMENTS: [KGSKDECRSTAT1]”，但是该Bug最早发生在9.2.0.3上，已经确定影响9.2.0.x所有版本，并且在9.2.0.5上没有backport的bug fix。

提交sr后，Oracle Gcs给出了解决的solution:
1.升级数据库到10.2.0.5，11.1.0.7，11.2.0.2等目前支持的版本
2.解决引发该bug的ORA-00060 dead lock问题
3.如果在解决ORA-00060后仍出现以上ORA-00600[kgskdecrstat1]内部错误，且启用了9i早期版本中的resource manager的话，可以尝试禁用该特性:
ALTER SYSTEM SET resource_manager_plan=” SCOPE=BOTH;
以便绕过bug 2494790。

Filed Under: Oracle, Oracle Bug Tagged With: , , ,

沪ICP备14014813号-2

沪公网安备 31010802001379号