ORA-600(kgh_heap_sizes:ds)和ORA-600(kghGetHpSz1)错误

在客户10203数据库中发现多个ORA-600和ORA-7445错误。
详细错误信息如下:

Tue DEC 27 11:13:55 2011 
Errors IN file /oracle/admin/htzback/udump/htzback_ora_22492.trc:
ORA-00600: 内部错误代码, 参数: [kgh_heap_sizes:ds], [0x2B902679E3F8], [], [], [], [], [], [] 
ORA-00600: 内部错误代码, 参数: [kghGetHpSz1], [0x2B902679F868], [], [], [], [], [], [] 
ORA-00600: 内部错误代码, 参数: [kghstack_free2], [], [], [], [], [], [], [] 
ORA-00602: 内部编程异常错误
ORA-07445: 出现异常错误: 核心转储 [pfrtcs()+96] [SIGSEGV] [Address NOT mapped TO object] [0x00000027D] [] []
ORA-07445: 出现异常错误: 核心转储 [_intel_fast_memcpy.A()+10] [SIGSEGV] [Invalid permissions FOR mapped object] [0x2B90269B9000] [] []

根据MOS上的信息,这是10.2上的bug。这个错误的表现包括,出现ORA-600 [kgh_heap_sizes:ds]错误、ORA-600 [kghGetHpSz1]错误以及ORA-7445 [_intel_fast_memcpy.A]错误。
解决这个问题可以将数据库补丁升级到10.2.0.4以上。或者打上任何包含Bug:6085625和Bug:6452485的补丁集。

Posted in BUG | Tagged , , , , , , , | Leave a comment

告警日志出现分布式事务缺少DTP服务信息

客户的RAC环境中出现这个告警信息。
详细信息如下:

Thu DEC 23 09:23:15 2011
Running Distributed Transactions IN RAC WITHOUT DTP service.

查询MOS发现,对于10.2版本的数据库,如果连接RAC环境,且执行分布式事务,那么应该启用DTP服务。
从告警日志的其他部分,可以发现数据库确实使用了分布式事务,因为已经出现了分布式事务的错误:

Tue DEC 23 09:25:14 2011
DISTRIB TRAN 44444444.99A137F01FBF14AACDCA8A9D3C8FED5800000000
IS LOCAL tran 7.25.1798234 (hex=07.1a.1b705a)
INSERT pending prepared tran, scn=6812962413 (hex=1.96158e6d)

解决办法是为数据库已启用的服务设置DTP:

EXECUTE DBMS_SERVICE.MODIFY_SERVICE(service_name => '', DTP=>TRUE);

除了使用DBMS_SERVICE包外,还可以在命令行通过srvctl工具对单独的实例设置DTP选项,方法类似如下:

srvctl MODIFY service -d db -s db.oracle.com -x TRUE
Posted in ORACLE | Tagged , , , , | Leave a comment

由于DBTIME时间太短导致AWR出现告警信息

一个客户的RAC环境的AWR,由于DB TIME时间太短,导致出现告警信息。

这是一个10.2.0.5 RAC for Linux X86环境,由于全部应用都连接到一个节点上,因此另一个节点出现这个告警。

在AWR报告中的正文开始之前的部分,有下面的告警信息:

WARNING: Since the DB Time is less than one second, there was minimal foreground activity in the snapshot period. Some of the percentage values will be invalid.

虽然以前也碰到过节点很闲的情况,但是真没有碰到过负载这么轻的系统:

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

3609

06-1月 -12 10:00:22

38

1.2

End Snap:

3610

06-1月 -12 11:00:23

39

1.1

Elapsed:

60.02 (mins)

DB Time:

0.01 (mins)

从这个DB TIME上看,系统时间还不到1秒,查看每秒的统计值:

Load Profile

Per Second

Per Transaction

Redo size:

196.38

9,556.59

Logical reads:

4.62

224.99

Block changes:

0.45

21.70

Physical reads:

0.00

0.16

Physical writes:

0.06

3.08

User calls:

0.16

7.84

Parses:

0.19

9.31

Hard parses:

0.00

0.04

Sorts:

0.40

19.47

Logons:

0.03

1.23

Executes:

0.74

36.23

Transactions:

0.02

可以看到,除了逻辑读和REDO外,其余的值每秒都小于1,在看看TOP 5等待:

Top 5 Timed Events

Event

Waits

Time(s)

Avg Wait(ms)

% Total Call   Time

Wait Class

control file   sequential read

9,928

4

0

600.8

System I/O

control file   parallel write

1,200

2

2

354.8

System I/O

CPU time

1

81.0

os thread   startup

10

0

35

52.2

Concurrency

CGS wait for IPC   msg

26,151

0

0

40.2

Other

可以看到控制文件的读写分别是4秒和2秒,占用了600%和350%的系统时间,这也是前面告警信息提示的百分比不准确的原因。

AWR报告本身没有太多有意义信息,只是这种情况比较少见,特此为记。

 

Posted in ORACLE | Tagged , , | Leave a comment

数据泵导出出现ORA-31617错误

客户的Oracle10204 RAC FOR Hp数据库执行EXPDP并行导出时出现了这个错误信息。
导出报错如下:

Export: Release 10.2.0.4.0 - 64bit Production ON Thursday, 12 January, 2012 6:10:00
Copyright (c) 2003, 2007, Oracle.  ALL rights reserved.
Connected TO: Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
WITH the Partitioning, REAL Application Clusters, Oracle Label Security, DATA Mining
AND REAL Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01":  parfile=/home/oracle/backup/moddb_par_mesadmin 
Estimate IN progress USING BLOCKS method...
Processing object TYPE SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation USING BLOCKS method: 72.74 GB
Processing object TYPE SCHEMA_EXPORT/USER
Processing object TYPE SCHEMA_EXPORT/SYSTEM_GRANT
Processing object TYPE SCHEMA_EXPORT/ROLE_GRANT
Processing object TYPE SCHEMA_EXPORT/DEFAULT_ROLE
Processing object TYPE SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object TYPE SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
.
.
.
Processing object TYPE SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object TYPE SCHEMA_EXPORT/TABLE/TRIGGER
ORA-31693: TABLE DATA object "MESADMIN"."S_IFCPRODUCT" failed TO LOAD/unload AND IS being skipped due TO error:
ORA-29913: error IN executing ODCIEXTTABLEPOPULATE callout
ORA-31617: unable TO OPEN dump file "/archive/temp_exp/moddb_exp_mesadmin_3.dmp" FOR wr
Processing object TYPE SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
ORA-31693: TABLE DATA object "MESADMIN"."PRODUCTHISTORY" failed TO LOAD/unload AND IS being skipped due TO error:
ORA-29913: error IN executing ODCIEXTTABLEPOPULATE callout
ORA-31617: unable TO OPEN dump file "/archive/temp_exp/moddb_exp_mesadmin_2.dmp" FOR wr
Processing object TYPE SCHEMA_EXPORT/JOB
Processing object TYPE SCHEMA_EXPORT/POST_SCHEMA/PROCACT_SCHEMA
ORA-31693: TABLE DATA object "MESADMIN"."S_R_WIP" failed TO LOAD/unload AND IS being skipped due TO error:
ORA-29913: error IN executing ODCIEXTTABLEPOPULATE callout
ORA-31617: unable TO OPEN dump file "/archive/temp_exp/moddb_exp_mesadmin_2.dmp" FOR wr
ORA-31693: TABLE DATA object "MESADMIN"."C_FGMSIF_PANELINFO" failed TO LOAD/unload AND IS being skipped due TO error:
ORA-29913: error IN executing ODCIEXTTABLEPOPULATE callout
ORA-31617: unable TO OPEN dump file "/archive/temp_exp/moddb_exp_mesadmin_5.dmp" FOR wr
ORA-31693: TABLE DATA object "MESADMIN"."C_AC_PANEL_GRADE" failed TO LOAD/unload AND IS being skipped due TO error:
ORA-29913: error IN executing ODCIEXTTABLEPOPULATE callout
ORA-31617: unable TO OPEN dump file "/archive/temp_exp/moddb_exp_mesadmin_2.dmp" FOR wr
. . exported "MESADMIN"."S_R_MOVEMENT"                   191.2 MB 2070491 ROWS
.
.
.
. . exported "MESADMIN"."USERPROFILEATTRIBUTEHISTORY"        0 KB       0 ROWS
. . exported "MESADMIN"."RTDRULETRACEHISTORY"            1.627 GB 3812462 ROWS
. . exported "MESADMIN"."PRODUCT"                        1.057 GB 2593517 ROWS
Master TABLE "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file SET FOR SYSTEM.SYS_EXPORT_SCHEMA_01 IS:
  /archive/temp_exp/moddb_exp_mesadmin_1.dmp
  /archive/temp_exp/moddb_exp_mesadmin_2.dmp
  /archive/temp_exp/moddb_exp_mesadmin_3.dmp
  /archive/temp_exp/moddb_exp_mesadmin_4.dmp
  /archive/temp_exp/moddb_exp_mesadmin_5.dmp
  /archive/temp_exp/moddb_exp_mesadmin_6.dmp
  /archive/temp_exp/moddb_exp_mesadmin_7.dmp
  /archive/temp_exp/moddb_exp_mesadmin_8.dmp
  /archive/temp_exp/moddb_exp_mesadmin_9.dmp
  /archive/temp_exp/moddb_exp_mesadmin_10.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" completed WITH 5 error(s) at 06:22:57

数据泵的并行度设置为10,同时向10个DUMPFILE中写入数据。在写入时出现ORA-31693、ORA-29913和ORA-31617错误。
发现对于RAC环境而言,Oracle会尝试将并行导出放到两个节点上,而由于DIRECTORY是本地磁盘,且在另外一个节点上没有建立同样的目录,因此打开文件报错的信息。
那么如果想要使用RAC上的并行导出,确保相同的目录在两个节点上同时存在。如果只想在一个节点上执行数据泵的导出那么就不要使用并行方式。

Posted in ORACLE | Tagged , , , , | 1 Comment

ORA-600(13013)错误

客户环境中出现ORA-600(13013)错误。
错误信息如下:

Mon DEC 26 23:13:00 2011 
Errors IN file /oracle/admin/htzback/udump/htzback_ora_32522.trc:
ORA-00600: 内部错误代码, 参数: [13013], [5001], [52828], [625368235], [67], [629556358], [17], []

查询MOS发现,对于13013错误而言,随后的6个参数含义如下:

Arg [a] Passcount 
Arg [b] DATA Object NUMBER 
Arg [c] Tablespace Relative DBA OF block containing the ROW TO be updated 
Arg [d] ROW Slot NUMBER 
Arg [e] Relative DBA OF block being updated (should be same AS [c]) 
Arg [f] Code

可以根据DATA OBJECT ID在DBA_OBJECTS视图中找到对应的对象,如果是表,可以使用ANALYZE TABLE TABLENAME VALIDATE STRUCTURE CASCADE的方式来验证表结构,如果是索引,可以用ANALYZE INDEX INDEXNAME VALIDATE STRUCTURE的方式验证索引结构。
根据参数C可以计算出问题出现的相对文件号和BLOCK号:

SQL> SELECT dbms_utility.data_block_address_file(625368235) rfile, 
  2 dbms_utility.data_block_address_block(625368235) blocks
  3 FROM dual;
RFILE     BLOCKS
---------- ----------
       149     416939

根据找到的文件号,可以使用dbv对指定的文件进行检查。
如果确实发现逻辑损害,且错误发生在索引上,那么最简单的办法莫过于利用DBMS_METADATA获取索引的源数据,然后将索引删除后重建。
如果错误发生在表上,且存在备份,可以直接利用BLOCKRECOVER命令进行恢复。
如果备份不存在,可以利用DBMS_REPAIR包,或者使用EVENTS 10231的LEVEL 10,跳过坏块。当然也完全可以通过ROWID方式来手工跳过这个错误。

Posted in BUG | Tagged , , | Leave a comment

DATE类型截取到天的效率

在ITPUB上看了一个帖子,根据日期类型对每天的记录进行GROUP BY,帖子的地址如下:http://www.itpub.net/thread-1564295-1-1.html
这种包含全表扫描执行GROUP BY的语句是否还有优化的余地吗,事实上确实还有,因为对于处理日期类型,TO_CHAR并没有TRUNC高效。
下面看一个简单的例子:

SQL> CREATE TABLE T_DATE AS
  2  SELECT ROWNUM ID, CREATED 
  3  FROM DBA_OBJECTS A, (SELECT 1 FROM DUAL CONNECT BY ROWNUM < 100)  
  4  WHERE ROWNUM <= 1000000;
TABLE created.
SQL> SELECT COUNT(*) FROM T_DATE;
  COUNT(*)
----------
   1000000
SQL> SET TIMING ON
SQL> SELECT TO_CHAR(CREATED, 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TO_CHAR(CREATED, 'YYYY-MM-DD');
TO_CHAR(CR   COUNT(*)
---------- ----------
2012-01-07       3600
2012-01-08       3750
2012-01-09       4650
2012-01-06     987925
2012-01-10         75
Elapsed: 00:00:00.46
SQL> SELECT TO_CHAR(CREATED, 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TO_CHAR(CREATED, 'YYYY-MM-DD');
TO_CHAR(CR   COUNT(*)
---------- ----------
2012-01-07       3600
2012-01-08       3750
2012-01-09       4650
2012-01-06     987925
2012-01-10         75
Elapsed: 00:00:00.40
SQL> SELECT TO_CHAR(CREATED, 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TO_CHAR(CREATED, 'YYYY-MM-DD');
TO_CHAR(CR   COUNT(*)
---------- ----------
2012-01-07       3600
2012-01-08       3750
2012-01-09       4650
2012-01-06     987925
2012-01-10         75
Elapsed: 00:00:00.39
SQL> SELECT TO_CHAR(CREATED, 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TO_CHAR(CREATED, 'YYYY-MM-DD');
TO_CHAR(CR   COUNT(*)
---------- ----------
2012-01-07       3600
2012-01-08       3750
2012-01-09       4650
2012-01-06     987925
2012-01-10         75
Elapsed: 00:00:00.44
SQL> SELECT TO_CHAR(TRUNC(CREATED), 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TRUNC(CREATED);
TO_CHAR(TR   COUNT(*)
---------- ----------
2012-01-06     987925
2012-01-10         75
2012-01-08       3750
2012-01-07       3600
2012-01-09       4650
Elapsed: 00:00:00.36
SQL> SELECT TO_CHAR(TRUNC(CREATED), 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TRUNC(CREATED);
TO_CHAR(TR   COUNT(*)
---------- ----------
2012-01-10         75
2012-01-07       3600
2012-01-09       4650
2012-01-06     987925
2012-01-08       3750
Elapsed: 00:00:00.35
SQL> SELECT TO_CHAR(TRUNC(CREATED), 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TRUNC(CREATED);
TO_CHAR(TR   COUNT(*)
---------- ----------
2012-01-10         75
2012-01-07       3600
2012-01-09       4650
2012-01-06     987925
2012-01-08       3750
Elapsed: 00:00:00.36
SQL> SELECT TO_CHAR(TRUNC(CREATED), 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TRUNC(CREATED);
TO_CHAR(TR   COUNT(*)
---------- ----------
2012-01-10         75
2012-01-07       3600
2012-01-09       4650
2012-01-06     987925
2012-01-08       3750
Elapsed: 00:00:00.34

如果仅从执行计划和逻辑读上进行分析,两个SQL没有任何区别:

SQL> SET autot ON
SQL> SELECT TO_CHAR(CREATED, 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TO_CHAR(CREATED, 'YYYY-MM-DD');
TO_CHAR(CR   COUNT(*)
---------- ----------
2012-01-07       3600
2012-01-08       3750
2012-01-09       4650
2012-01-06     987925
2012-01-10         75
Elapsed: 00:00:00.43
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 534547868
-----------------------------------------------------------------------------
| Id  | Operation          | Name   | ROWS  | Bytes | Cost (%CPU)| TIME     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |  1294K|    11M|   726   (6)| 00:00:09 |
|   1 |  HASH GROUP BY     |        |  1294K|    11M|   726   (6)| 00:00:09 |
|   2 |   TABLE ACCESS FULL| T_DATE |  1294K|    11M|   694   (1)| 00:00:09 |
-----------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2490  consistent gets
       2487  physical reads
          0  redo SIZE
        754  bytes sent via SQL*Net TO client
        524  bytes received via SQL*Net FROM client
          2  SQL*Net roundtrips TO/FROM client
          0  sorts (memory)
          0  sorts (disk)
          5  ROWS processed
SQL> SELECT TO_CHAR(TRUNC(CREATED), 'YYYY-MM-DD'), COUNT(*) 
  2  FROM T_DATE 
  3  GROUP BY TRUNC(CREATED);
TO_CHAR(TR   COUNT(*)
---------- ----------
2012-01-10         75
2012-01-07       3600
2012-01-09       4650
2012-01-06     987925
2012-01-08       3750
Elapsed: 00:00:00.34
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 534547868
-----------------------------------------------------------------------------
| Id  | Operation          | Name   | ROWS  | Bytes | Cost (%CPU)| TIME     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |  1294K|    11M|   726   (6)| 00:00:09 |
|   1 |  HASH GROUP BY     |        |  1294K|    11M|   726   (6)| 00:00:09 |
|   2 |   TABLE ACCESS FULL| T_DATE |  1294K|    11M|   694   (1)| 00:00:09 |
-----------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2490  consistent gets
       2487  physical reads
          0  redo SIZE
        761  bytes sent via SQL*Net TO client
        524  bytes received via SQL*Net FROM client
          2  SQL*Net roundtrips TO/FROM client
          0  sorts (memory)
          0  sorts (disk)
          5  ROWS processed

但是观察两个SQL的平均执行时间,会发现使用TRUNC方式比TO_CHAR有1/8的性能提升,对于执行计划完全相同的情况而言,这个比率已经很高了。
其实导致问题的原因在于DATE类型的存储,DATE由7个字节组成,分别为世纪、年、月、日、时、分、秒。对于TRUNC函数而言,只是简单的舍弃掉后面三个字节,因此效率最高,而TO_CHAR需要将内部的存储格式转化为字符格式,显然会消耗更多的资源。
两个SQL返回结果顺序的不同也说明了这一点,TRUNC函数进行HASH GROUP的是日期格式,而TO_CHAR函数进行HASH GROUP的是字符类型,导致了最终结果返回顺序的差异性。

Posted in ORACLE | Tagged , , | Leave a comment

ORA-600(16608)错误

客户10.2.0.4环境出现ORA-600(16608)错误。
详细错误信息如下:

Sun DEC 19 11:17:41 2010
Errors IN file /u01/app/oracle/admin/orcl/bdump/orcl_j005_5937.trc:
ORA-00600: internal error code, arguments: [16608], [2], [3], [0x8000002C4FA00DC0], [], [], [], []

检查对应的TRACE文件,发现数据库在进行索引的收缩:

Dump file /u01/app/oracle/admin/orcl/bdump/orcl_j005_5937.trc
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:	Linux
Node name:	DBSERVER
Release:	2.6.28.10-vs1.0
Version:	#1 SMP Thu Jun 30 21:18:27 CST 2011
Machine:	ia64
Instance name: orcl
Redo thread mounted BY this instance: 1
Oracle process NUMBER: 45
Unix process pid: 5937, image: oracle@DBSERVER (J005)
*** ACTION NAME:(AUTO_SPACE_ADVISOR_JOB) 2010-12-19 11:17:41.736
*** MODULE NAME:(DBMS_SCHEDULER) 2010-12-19 11:17:41.736
*** SERVICE NAME:(SYS$USERS) 2010-12-19 11:17:41.736
*** SESSION ID:(1069.3) 2010-12-19 11:17:41.736
*** 2010-12-19 11:17:41.736
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [16608], [2], [3], [0x8000002C4FA00DC0], [], [], [], []
CURRENT SQL statement FOR this SESSION:
ALTER INDEX "U1"."SYS_IQ0000051623$$" shrink SPACE CHECK
----- PL/SQL Call Stack -----
  object      line  object
  handle    NUMBER  name
0x8000002c3fc35960       526  SYS.WRI$_ADV_OBJSPACE_TREND_T
0x8000002c3fc35960      1660  SYS.WRI$_ADV_OBJSPACE_TREND_T
0x8000002c3fea1e98      1535  package body SYS.PRVT_ADVISOR
0x8000002c3fea1e98      1618  package body SYS.PRVT_ADVISOR
0x8000002c3fc7e3a8       186  package body SYS.DBMS_ADVISOR
0x8000002c3fdadcc0      1500  package body SYS.DBMS_SPACE
0x8000002c3fdadcc0      1566  package body SYS.DBMS_SPACE
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+64          ????     ksedst1()            000000000 ?
                                                   600FFFFFFFAF6800 ?
ksedmp()+1344        ????     ksedst()             000000000 ?
                                                   C000000000000C1E ?
                                                   4000000000410140 ?
                                                   000000000 ?
                                                   600FFFFFFFAF6800 ?
                                                   C000000000000185 ?
ksfdmp()+48          ????     ksedmp()             000000003 ?
kgeriv()+432         ????     ksfdmp()             60000000002352B0 ?
                                                   000000003 ?
                                                   C000000000000716 ?
                                                   40000000050614B0 ?
                                                   000000003 ?
                                                   600FFFFFFFAF6BA0 ?
                                                   C000000000000205 ?
                                                   4000000000453EB0 ?
kgeasi()+688         ????     kgeriv()             60000000002352B0 ?
                                                   6000000000236368 ?
                                                   0000040E0 ? 000000003 ?
                                                   600FFFFFFFAF6BF8 ?
kglsscn()+1616       ????     kgeasi()             600FFFFFFFAF6BD0 ?
                                                   600FFFFFFFAF6BE0 ?
                                                   600FFFFFFFAF6BD8 ?
                                                   600FFFFFFFAF6BE8 ?
                                                   000000003 ? 000000000 ?
                                                   000000002 ? 000000000 ?
kqlsscn()+64         ????     kglsscn()            60000000002352B0 ?
                                                   8000002C33FC5D3A ?
                                                   8000002C4FA008F0 ?
                                                   2000000001F1D670 ?
                                                   600FFFFFFFAF7360 ?
ktsk_init_shk_ctx()  ????     kqlsscn()            000000000 ?
+160                                               8000002C4FA008F0 ?
                                                   2000000001F1D670 ?
                                                   600FFFFFFFAF7360 ?
                                                   C0000000000029DB ?
                                                   400000000108DFE0 ?
                                                   60000000002352B0 ?
                                                   8000002C33FC5D3A ?
ktskshk1()+2288      ????     ktsk_init_shk_ctx()  600FFFFFFFAF8C50 ?
                                                   600FFFFFFFAF9140 ?
                                                   8000002C4FA00DC0 ?
                                                   8000002C5699A650 ?
                                                   8000002C4C870D48 ?
                                                   000000000 ?
                                                   600FFFFFFFAF7360 ?
                                                   C0000000000014B1 ?
ain_shk_drv()+5840   ????     ktskshk1()           600FFFFFFFAF9140 ?
                                                   000000000 ?
                                                   600FFFFFFFAF9000 ?
                                                   C000000000001C40 ?
                                                   4000000001660FD0 ?
                                                   60000000001ADE80 ?
                                                   6000000000234930 ?
                                                   000000000 ?

检查发现ORA-600 [16608] On Index Shrink [ID 1277283.1]描述了这个问题,Oracle描述这是一个未发布的Bug 4926805,导致问题的原因是在ASSM表空间中收缩CLUSTER索引段,而目前唯一的解决方案就是升级到11g。
好在这个问题影响的范围非常小,对于绝大部分情况,都可以忽略这个错误。想要避免这个错误,可以避免手工SHRINK CLUSTER索引,并禁止空间管理的SCHEDULER。

Posted in BUG | Tagged , , , , | Leave a comment

ORA-600(ksmals)错误

客户数据库出现ORA-600(ksmals)错误。
错误信息为:
Tue Nov 22 11:39:02 2011
Errors in file /oracle9/app/admin/db/udump/db1_ora_2319324.trc:
ORA-00600: internal error code, arguments: [ksmals], [sql txt in kkslod], [], [], [], [], [], []
查询这个错误,确认是Oracle的bug,详细描述可以参考:ORA-600 [ksmals], [sql txt in kkslod], [] Selecting Against x$kgllk [ID 550066.1]。这个问题影响9.2到11.1之间的所有版本。当查询x$kgllk内部表,或基于这个内部表的视图时,就可能引发这个问题。
从对应的trace文件中可以看到,导致错误的SQL在查询V$OPEN_CURSOR和V$SQL视图:

*** SESSION ID:(2144.35639) 2011-11-22 11:39:02.143
*** 2011-11-22 11:39:02.143
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [ksmals], [SQL txt IN kkslod], [], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
SELECT q.sql_text 
FROM v$open_cursor o, v$sql q
WHERE q.hash_value=o.hash_value AND o.sid = 3379

而查询V$SQL和V$OPEN_CURSOR的视图定义:

SQL> SELECT view_definition FROM v$fixed_view_definition WHERE view_name = 'GV$OPEN_CURSOR';
VIEW_DEFINITION
---------------------------------------------------------------------------
SELECT inst_id,kgllkuse, kgllksnm, user_name, kglhdpar, kglnahsh,
kgllksqlid, kglnaobj, kgllkest,
decode(kgllkexc, 0, to_number(NULL), kgllkexc), kgllkctp
FROM x$kgllk WHERE kglhdnsp = 0 AND kglhdpar != kgllkhdl

显然是由于查询了V$OPEN_CURSOR视图,从而访问了X$KGLLK,进而引发了这个bug。
解决这个问题的办法有很多,比如将数据库版本升级到10.2.0.5,或者安装单独的补丁Patch 5745084。在安装Patch 5745084后,还需要设置EVENT 10778的level 1,才能将这个bug FIXED掉。
除了这些方法外,尝试修改SQL语句也是一个不错的方法,因为并非虽有访问V$OPEN_CURSOR视图的查询都会出现这个错误。适当的改变写法,可能就能绕过这个错误。

Posted in BUG | Tagged , , , , , | Leave a comment

客户数据库升级后出现ORA-30004错误

帮客户将数据库从11.2.0.1升级到11.2.0.3后,数据库运行正常,不过随后出现了ORA-30004错误。
这个错误以前还真没有碰到过,检查后发现感觉问题似乎不一定和升级有关系:

ORA-30004: WHEN USING SYS_CONNECT_BY_PATH FUNCTION, cannot have separator AS part OF COLUMN VALUE 
Cause: A COLUMN VALUE contained the string that the SYS_CONNECT_BY_PATH FUNCTION was TO USE TO separate COLUMN VALUES.
Action: Specify another separator FOR the SYS_CONNECT_BY_PATH FUNCTION TO USE which does NOT occur IN any COLUMN VALUE, THEN retry.

从错误信息看,是SYS_CONNECT_BY_PATH函数导致的错误。而客户出现错误的语句也确实包含SYS_CONNECT_BY_PATH函数。导致错误的原因是SYS_CONNECT_BY_PATH处理的列中包含了分隔列。
为了确认这一点,特别在11.2.0.1环境中再现这个问题:

SQL> SELECT * FROM v$version;
BANNER
--------------------------------------------------------------------------------
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS FOR 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> CREATE USER u1 IDENTIFIED BY u1 DEFAULT tablespace users;
用户已创建。
SQL> GRANT CONNECT, resource TO u1;
授权成功。
SQL> conn u1/u1
已连接。
SQL> CREATE TABLE t_conn (id NUMBER, fid NUMBER, name varchar2(30));
表已创建。
SQL> INSERT INTO t_conn VALUES (1, 0, 'a');
已创建 1 行。
SQL> INSERT INTO t_conn VALUES (2, 1, 'b');
已创建 1 行。
SQL> INSERT INTO t_conn VALUES (3, 2, 'c');
已创建 1 行。
SQL> SELECT sys_connect_by_path(name, ',') FROM t_conn START WITH id = 1 CONNECT BY prior id = fid;
SYS_CONNECT_BY_PATH(NAME,',')
--------------------------------------------------------------------------------
,a
,a,b
,a,b,c
SQL> UPDATE t_conn SET name = 'b,' WHERE id = 2;
已更新 1 行。
SQL> commit;
提交完成。
SQL> SELECT sys_connect_by_path(name, ',') FROM t_conn START WITH id = 1 CONNECT
BY prior id = fid;
ERROR:
ORA-30004: 使用 SYS_CONNECT_BY_PATH 函数时, 不能将分隔符作为列值的一部分
未选定行

显然确认了问题只是由于数据错误所致,而与升级没有任何关系。
根据客户错误的SQL语句,定位了表中的错误数据。将包含分隔符的数据更新后,问题消失。

Posted in NEWS | Tagged , , | Leave a comment

ORA-600(ttcgcshnd-2)错误

客户数据库出现这个错误信息。
以前碰到过一个很老的bug,错误信息和当前十分接近,为ttcgcshnd-1,导致问题的原因是较低的jdbc驱动所致,详细情况可以参考:http://yangtingkun.itpub.net/post/468/461992
当前的问题并不太一样,导致问题的主要原因是用户取消了操作:

Mon DEC 5 10:13:50 2011
Errors IN file /oracle9/app/admin/db/udump/db1_ora_1867892.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-2], [0], [], [], [], [], [], []
ORA-01013: USER requested cancel OF CURRENT operation
Mon DEC 5 10:13:51 2011
Trace dumping IS performing id=[cdmp_20111205101351]

错误信息中包括ORA-1013错误,这个错误是由于用户取消当前操作所致,比如通过CTRL + C中止操作。而这个ORA-600错误显然和这个ORA-1013错误直接相关。
在MOS上查询到,ORA-600 [ttcgcshnd-2] After Ctrl-C (ORA-1013) [ID 956692.1]描述了这个问题。导致问题的原因是在会话连接握手时出现了用户通过CTRL + C中止了操作,这个错误被认为是完全无害的,可以简单忽略。

Posted in BUG | Tagged , , , | Leave a comment