-
Recent Posts
Recent Comments
- yangtingkun on 非空字段空值对查询的影响
- Eric Zong on 非空字段空值对查询的影响
- Kamus on Oracle Ace Director
- 设置全局死锁优先级 | yangtingkun on RAC全局死锁检测时间
- ORA-600(krbounotread_noctx)错误 | yangtingkun on ORA-600(krboReadBitmap_badbitmap)错误
Archives
- December 2020
- February 2019
- December 2018
- November 2018
- October 2018
- July 2018
- June 2018
- May 2018
- July 2016
- July 2013
- June 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
Categories
Meta
Category Archives: ORACLE
ORA-600(unable to load XDB library)错误
AIX上的9206数据库出现这个错误。 在alert文件中发现大量的类似错误： Mon DEC 19 16:43:13 2011 Errors IN file /oracle9/app/admin/db/udump/db1_ora_15400980.trc: ORA-00600: internal error code, arguments: [unable TO LOAD XDB library], [], [], [], [], [], [], []Mon Dec 19 16:43:13 2011 Errors in file /oracle9/app/admin/db/udump/db1_ora_15400980.trc: ORA-00600: internal error code, … Continue reading
Posted in BUG
Tagged aix, LD_LIBRARY_PATH, LIBPATH, ORA-600, unable to load XDB library
Leave a comment
ORA-600(17087)错误
客户数据库出现这个ORA-600错误。 错误信息为： Mon Jun 28 10:27:07 2010 Errors IN file /oracle/admin/ccicdb/udump/ccicdb_ora_767494.trc: ORA-00600: internal error code, arguments: [17087], [0x70000076C3E8E90], [], [], [], [], [], []Mon Jun 28 10:27:07 2010 Errors in file /oracle/admin/ccicdb/udump/ccicdb_ora_767494.trc: ORA-00600: internal error code, arguments: [17087], [0x70000076C3E8E90], [], … Continue reading
ORA-7445(kcrfw_update_blk_list)错误
客户的11.2数据库测试环境中碰到了ORA-7445(kcrfw_update_blk_list)错误。 详细的错误信息如下： Tue DEC 20 22:00:02 2011 BEGIN automatic SQL Tuning Advisor run FOR special tuning task "SYS_AUTO_SQL_TUNING_TASK" Tue DEC 20 22:00:46 2011 Exception [TYPE: SIGBUS, Non-existent physical address] [ADDR:0x62652000] [PC:0x216E0C4, kcrfw_update_blk_list()+196] [flags: 0x0, COUNT: 1] Errors IN file /u01/app/oracle/diag/rdbms/fhacdb/fhacdb/trace/fhacdb_lgwr_24506.trc … Continue reading
JDBC使用INSERT RETURN语句报错ORA-439
在给客户开发人员讲解LOB列的访问方式后，开发人员尝试在JDBC中使用包含RETURN的INSERT语句，但是出现了ORA-439错误。 检查后发现客户的程序使用的还是PreparedStatement语句，而RETURNING语句，则是Oracle扩展的SQL语法，因此在声明语句的时候必须使用OraclePreparedStatement方式进行声明。 除了修改SQL语句外，使用OraclePreparedStatement声明语句变量外，还需要注册输出参数，类似的代码如下： OraclePreparedStatement sqlstmt = (OraclePreparedStatement)conn.prepareStatement ("insert into t_lob values (?, ?, empty_clob()) returning contents into ?"); sqlstmt.setInt(1, 1); sqlstmt.setString(2, "a"); sqlstmt.registerReturnParameter(3, OracleTypes.CLOB); sqlstat.executeUpdate(); ResultSet resset = sqlstmt.getReturnResultSet(); IF (resset.next()) { CLOB contents = (CLOB)resset.getClob(2); … }OraclePreparedStatement sqlstmt = … Continue reading
Posted in ORACLE
Tagged getReturnResultSet, JDBC, lob, ORA-439, OraclePreparedStatement, registerReturnParameter, RETURN
Leave a comment
插入LOB对象的方法
其实以前写过类似的文章，但是都是在其他例子中，没有专门针对这个问题进行过描述，最近发现，还有很多人不清楚，插入一个包含LOB对象的记录需要几个步骤。 在客户的环境中，发现插入一条包含LOB的记录，居然用了四个步骤： SQL> CREATE TABLE T_LOB (ID NUMBER, NAME VARCHAR2(30), CONTENTS CLOB); 表已创建。 SQL> DECLARE 2 V_CLOB CLOB; 3 V_STR VARCHAR2(32767) := LPAD(’A’, 4000, ‘A’); 4 BEGIN 5 INSERT INTO T_LOB 6 VALUES (1, ‘A’, EMPTY_CLOB()); 7 SELECT CONTENTS 8 … Continue reading
批量加载性能案例
客户在大量加载数据是遇到性能问题，检查后发现客户采用的是单条插入单条提交这种最缓慢的方式，为了给客户说明优化效果，现场做了几个代码。 最简单的优化方式莫过于减少COMMIT频度，而最优化的方式是采用批量插入的方式，简单的测试代码如下： SQL> CREATE TABLE T_INSERT (ID NUMBER, NAME VARCHAR2(30)); TABLE created. SQL> SET TIMING ON SQL> BEGIN 2 FOR I IN 1..100000 LOOP 3 INSERT INTO T_INSERT VALUES (I, ‘A’ || I); 4 COMMIT; 5 END LOOP; 6 END; … Continue reading
创建ASM启动SPFILE报错ORA-17502
客户的数据库的ASM启动存在问题，通过手工创建PFILE，解决了ASM启动的问题，但是尝试利用PFILE生成SPFILE时报错。 详细错误信息为： [grid@rptdb ~]$ sqlplus / AS sysasm SQL*Plus: Release 11.2.0.2.0 Production ON Tue DEC 20 19:05:33 2011 Copyright (c) 1982, 2010, Oracle. ALL rights reserved. Connected. SQL> shutdown abort ASM instance shutdown SQL> startup pfile=/home/grid/init+ASM.ora ASM instance started Total … Continue reading
ACTIVE DATAGUARD上的ORA-1555错误
11g的ACTIVE DATAGUARD极大的增强了物理STANDBY的功能，可惜任何新特性都很难避免bug的产生，ACTIVE DATAGUARD同样也不例外。 已经有多个客户反应ACTIVE DATAGUARD上执行报表查询出现ORA-1555错误，错误和初始化参数UNDO_RETENTION的设置没有直接关系。而且如果打开了USING CURRENT LOG选项，不但可能导致SNAPSHOT TOO OLD错误，还可能导致整个STANDBY数据库性能越来越慢，以至于完全不可用，最终不得不重启。 查询了一下MOS，发现Oracle确认了这个bug：ORA-01555 on Active Data Guard Standby Database [ID 1273808.1]。 解决这个问题，出了应用对应的补丁10018789之外，也可以考虑将数据库升级到11.2.0.2.2以上。如果是Windows环境，那么比较升级到11.2.0.2.3以上。
RAC环境关闭CLUSTER后导致连接缓慢
客户的四节点RAC在停掉三个后，发现连接RAC明显变慢。 数据库环境是4节点的10.2 RAC for Linux X86-64。由于心跳存在问题，目前将三个节点上的CLUSTER关闭，但是随后不久，客户反应数据库访问变慢。 虽然本来4个节点繁忙程度都不高，但是将4个实例上的压力集中到1个实例上，那么性能有所下降也是正常的。不过检查数据库的工作状态，并未发现异常，无论是从后台cpu忙闲程度，还是从awr报告中查看，似乎并没有太大的压力。 询问客户是查询变慢还是登录变慢，客户也搞不清其中的差别，于是在尝试连接数据库，结果发现，无论是tnsping还是sqlplus登录，有时登录很快，有时要经历3秒到6秒的等待，这应该就是客户反应慢的原因。 检查登录数据库的TNSNAMES.ORA中的配置，客户默认4个节点作为LOAD BALANCE和静态FAILOVER，这种配置方式在节点关闭后并不会导致错误，但是有可能由于需要等待超时而经受性能问题。 检查服务器上CLUSTER的状态，发现4个节点上，有两个VIP的服务都停掉了，应该是用户关闭整个CLUSTER服务是导致的。在此情况下，静态FAILOVER发挥作用，但是会引入超时的问题。而由于配置了LOAD_BALANCE，Oracle会轮训4个VIP地址，这就导致了有时候连接很快完成，而有时连接需要等待3秒以上。 由于存在众多的客户端，无法一一修改客户端使用的TNS配置，那么最简单的解决办法就是将CLUSTER启动，只是关闭其他三个节点的数据库，这样所有的VIP都处于启动状态，即使连接到没有提供的服务的节点，也可以快速的重新启动到启动节点上。 将其他两个VIP关闭的CLUSTER启动，保持DB关闭状态，数据库连接缓慢的问题就此解决。
ORA-600(kcbshlc_1)和ORA-7445(kggchk)错误
以前同时记录两个ORA-600错误，多半是由于这个两个错误在同时，是同一次故障的不同表现，而这次两个错误则是分别出现。 客户的10.2.0.4的逻辑STANDBY备库上前后几次出现了这两个错误： Thu Jun 16 13:45:05 2011 Errors IN file /u01/app/oracle/admin/db/bdump/db_pmon_27660.trc: ORA-07445: exception encountered: core dump [kggchk()+77] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] [] Thu Jun 16 13:45:13 2011 CKPT: terminating instance due TO error 472 Instance TERMINATED … Continue reading