ITPub博客

今天碰到这么个错误：Errors in file /opt/oraodm/admin/ODPLAT/bdump/odplat_j001_17178.trc:ORA-00600: 鍐呴儴閿欒?浠ｇ爜, 鍙傛暟: [13013], [5001], [279086], [578959904], [23], [483351996], [17], []经过查询资料发现下面的内容，这应该是oracle的一个bug，update的时候找不到相应行，重建一下索引就行。ERROR: ORA-600 [13013] [a] [c] [d] [e] [f]VERSIONS: versions 6.0 to 10.1DESCRIPTION: During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable s

听人说dbms_datapump包可以实现从job调用shell，特搜索文章如下：命令行下传输两个数据库的数据：impdp dump_user/dump_user directory=dump_dir logfile=log.log schemas=tests network_link=dump_link sqlfile=dump_dir:expfull.sql table_exists_action=REPLACEloc directory 目录loc logfile 本地生成的日志schemas 要转入的用户，必须和network_link内的用户名一致network_link 将要转入的远端数据库的db linksqlfile 若是没有该文件则生成，若有则使用table_exists_action 如果要导入的对象已经存在的替换PL/SQL API调用：简单的：d

看到一个文档，总结动态性能视图的，总结如下：1 v$sysstat 22 v$sesstat 73 v$sql 94 V$SQL_PLAN 115 V$SQLTEXT 136 V$SQLAREA 147 V$SESSION 158 V$SESSION_WAIT 179 V$SESSION_EVENT 2010 V$PROCESS 2011 V$LOCK 2312 V$LOCKED_OBJECT 2713 V$FILESTAT 2814 V$SESSION_LONGOPS 2915 V$LATCH 3016 V$LATCH_CHILDREN 3317 V$DB_OBJECT_CACHE 3418 V$OPEN_CURSOR 3419 V$PARAMETER&V$SYSTEM_PARAMETER 3619 V$ROLLSTAT 3720 V$ROWCACHE 4021 V$SEGSTAT 4122 V$SEGMENT_STATISTICS 4223 V$SYSTEM_EVENT 4324 V$UNDOSTAT 43[@more@]学习

今天一个朋友问到关于OPTIMIZER_INDEX_COST_ADJ参数的问题，开始不太明白，百度之后发现下面的文章，特此摘录如下：OPTIMIZER_INDEX_COST_ADJ这个初始化参数代表一个百分比,取值范围在1到10000之间.该参数表示索引扫描和全表扫描成本的比较。缺省值100表示索引扫描成本等价转换与全表扫描成本。这些参数对于CBO的执行具有重大影响，其缺省值对于数据库来说通常需要调整。一般来说对于OPTIMIZER_INDEX_CACHING可以设置为90左右对于大多数OLTP系统，OPTIMIZER_INDEX_COST_ADJ可以设置在10到50之间。对于数据仓库和DSS系统，可能不能简单的把

昨天晚上洗澡时新想到一个可以有效测试index rebuild online的方式, 也就是同时使用10046与10704 的trace event再配合lock阻塞的机制来测试index rebuild online的过程. 测试的过程如下.01 --1. 构造一个500w条记录的表. 并创建需要rebuild online的索引. 02 --表的数量设置到这么大,,主要是为了给后续的操作留出手工运行的时间. 03 create table james_t as 04 select rownum id,dbms_random.string('l',20) user_name 05 from dual 06 connect by level <= 5e6; 07 08 create index james_t_pk on james_t (id); 09 10 --2. 在Sessio

今天使用index rebuild online方法重建一个索引，但是重建到一半出错了。当我再次重建的时候，发现报错，不能重建，等了一阵之后才能重建，对于这个问题，当时没在意，后来想了一想，觉得不太对劲，于是上网搜索了一下，才发现已经有人早就想到这种问题了，最后原来是SMON干活了，摘录如下：对于永久表空间上的temporary segment，SMON会三分钟清理一次(前提是接到post)，如果SMON过于繁忙那么可能temporary segment长期不被清理。temporary segment长期不被清理可能造成一个典型的问题是:在rebuild index online失败后，后续执行的rebuil

oracle中可以建立临时表临时表有两种建立方式：1.create global TEMPORARY table test_temp_bbb (a varchar2(10))ON COMMIT DELETE ROWS;当commit之后，数据就消失了，但表结构还在。2.create global TEMPORARY table test_temp_ccc (a varchar2(10))ON COMMIT preserve ROWS;当commit之后，数据不消失，session退出后，表结构还在，但数据消失。下面是别人写的： 在临时表上的操作比在一般的表上的操作要快。因为：1创建临时表不需要往编目表中插入条目，临时表的使用也不需要访问编目表，因此也没有对编目表的争用。2仅有创建临时表的ap

不让程序对表进行insert操作今天碰到这么一个问题，应用在向一个表插入数据，每天插入很多数据，但是这个表一点用处都没有，又不能停掉应用，所以就想了个方法阻塞insert操作。我使用的是oracle的trigger进行操作的，trigger具有一个instead of方法，但这个方法只能对view使用，所以我将原来的表rename，然后建立一个同名的view，再在这个view上建立一个trigger，实现了该操作。具体方法如下：实施操作：alter table FS_PCS_BSSADD rename to FS_PCS_BSSADD_1;create view FS_PCS_BSSADD as select MSISDN, IMSI, DEVICE_ID,

好久没用dbms_job包了，怕忘了，特地把用法记录一下：begin sys.dbms_job.submit(job => :job, what => 'myProc;myProcs;myProcss(''测试'');',//用分号将多个存储过程分开，有参数的话直接写就可以了 next_date => to_date('07-04-2011 22:00:00', 'dd-mm-yyyy hh24:mi:ss'), interval => 'sysdate+1'); commit;end;[@more@]

今天网友介绍，可以用正则表达式将字符串拆分，挺好用的，记录如下：select regexp_substr('1324,1341,43143,43143,14314','[^,]+',1,rownum) from dualconnect by rownum<=5结果如下13241341431434314314314[@more@]

tkprof 的目的是将sql trace 生成的跟踪文件转换成用户可以理解的格式 格式 tkprof inputfile outputfile [optional | parameters ] 参数和选项： explain=user/password 执行explain命令将结果放在SQL trace的输出文件中 table=schema.table 指定tkprof处理sql trace文件时临时表的模式名和表名 insert=scriptfile 创建一个文件名为scriptfile的文件，包含了tkprof存放的输出sql语句 sys=[yes/no] 确定系统是否列出由sys用户产生或重调的sql语句 print=number 将仅生成排序后的第一条sql语句的输出结果

这两天频繁使用index rebuild online。原来我一直以为index rebuild会阻塞查询，后来做了一个实验，发现在rebuild的同时还能够使用索引查询。打碎了我以前想当然的一些想法，特记录一下，做事还是要严谨，不能想当然，多做实验才是正解！！！[@more@]

今天又碰到一个ora-00600错误，应该又是一个由于索引引起的错误，找到相关索引rebuild online，解决：ORA-00600: internal error code, arguments: [6002], [0], [30], [2], [0], [], [], []资料如下：ORA-600 [6002] "Index block check" [ID 47449.1]Note: For additional ORA-600 related information please read Note:146580.1PURPOSE: This article discusses the internal error "ORA-600 [6002]", what it means and possible actions. The information here is only applicable to the ver

《【SQL_TRACE】SQL优化及性能诊断好帮手》http://space.itpub.net/519536/viewspace-616240中简单的提到了使用TKPROF工具格式化SQL_TRACE的输出信息的方法，并没有对输出的内容做比较清楚的描述，通过这个小文儿，展示一下TKPROF对trace文件格式化的魅力，这里只给出具体输出信息含义的描述，不展示真实的性能诊断案例。1.与之上次使用到的SQL_TRACE功能相比，我们这次将使用更高级的trace命令（10046）来做演示。我们先启用“高级”的10046事件生成一份待格式化的trace文件1）连接到普通用户secsys@ora10g> conn sec/secConnected.2）

又碰到一个oracle600错误，这次和位图索引有关系。ORA-00600: internal error code, arguments: [qknAddSib1], [], [], [], [], [],[], []感觉简单处理方式就是重建位图索引，由于是别人维护的数据库，所以没去实验。所以他们打补丁，下面是这个bug在metalink中的具体说明。Bug 属性类型B - Defect已在产品版本中修复11.2严重性2 - Severe Loss of Service产品版本10.2.0.3状态80 - Development to Q/A平台59 - HP-UX PA-RISC (64-bit)创建时间30-Mar-2008平台版本11.23更新时间04-Jan-2011基本 Bug-数据库版本10.2.0.3影响平台 Generic产

今天碰到这么个问题：运行删除语句出现通信通道错误。 delete dmo_bssadd_2 where batch ='MII2011060710000190023.xml'查看发现dmo_bssadd_2这个表有500多万条记录，这个语句一下要删除100万条数据，查看解释计划，发现走的是索引范围扫描，将语句加上hint，让他强制走全表扫描，然后再执行语句，发现还出现通信通道错误。于是觉得原因不在于此，就查询alert log，发现有这么个错误。ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []Tue Jun 14 17:20:07 2011Errors in file /opt/oraodm/admin/ODPLAT

SQL Server、Oracle、MySQL和Vertica数据库常用函数对比Vertica数据库是HP公司新收购的用于BI方面的数据库。[@more@] SQL Server、Oracle、MySQL和Vertica数据库常用函数对比Vertica数据库是HP公司新收购的用于BI方面的数据库。1. 绝对值S:select abs(-1) valueO:select abs(-1) value from dualM:select abs(-1) value from dualV:select abs(-1)2. 向上取整S:select ceiling(-1.001) valueO:select ceil(-1.001) value from dualM:select ceil(-1.001) value from dualV:select ceil(-1.001)3. 向下取整S:select floo

backup as compressed backupset incremental level 1 cumulative device type disk database include current controlfile spfile format '/orabak/rman/backup_%d_%U_%p_%c' ;就是增加as compressed参数10G用的是bzip2算法11G默认也是这种算法，但可以修改成ZLIB算法，这种算法压缩比没有bzip2高，但是压缩速度快。修改算法的方法：configure compression algorithm ‘ZLIB’;我没有具体做实验，下面是别人的实验结果，有点奇怪的是不压缩的时间居然是最长的，有可能和数据输出比较大有关系，有机会我要亲自做一次测试。不压缩： 文件大

诊断事件大体上可以分为四类： a． 转储类事件（immediate dumps）：它们主要用于转储Oracle的一些结构，例如转储一下控制文件、数据文件头等内容。 b． 捕捉类事件(conditional dumps)：它们用于捕捉一些Error事件的发生，例如捕捉一下ORA-04031发生时一些Rdbms信息，以判断是Bug还是其它原因引起的这方面的问题。 c． 改变执行途径类事件(events that change database behaviour)：它们用于改主一些Oracle内部代码的执行途径，例如设置10269将会使Smon进程不去合并那些Free的空间。 d． 跟踪类事件(trace dumps)：主要用于获取一些跟

一、Oracle跟踪文件　　Oracle跟踪文件分为三种类型，一种是后台报警日志文件，记录数据库在启动、关闭和运行期间后台进程的活动情况，如表空间创建、回滚段创建、某些alter命令、日志切换、错误消息等。在数据库出现故障时，应首先查看该文件，但文件中的信息与任何错误状态没有必然的联系。后台报警日志文件保存 BACKGROUND_DUMP_DEST参数指定的目录中，文件格式为SIDALRT.LOG。另一种类型是DBWR、LGWR、SMON等后台进程创建的后台跟踪文件。后台跟踪文件根据后台进程运行情况产生，后台跟踪文件也保存在BACKGROUND_DUMP_DEST参数指定的目