ITPub博客

interval分区，和范围分区类似，不过是自动按照范围分配。oracle中原有的几个分区：hash分区、范围分区、列表分区和混合分区。今天碰到一个问题：Hi Ming, As discussed with you over chat we're testing an Oracle 11g feature called Interval Partitioning. The table partitions are fine and seems to be working as expected, the issue is in the local index when new data is added after the index is created. I've provided some scripts to demonstrate: -- create sample table on daily interval-h

hintalter sessiontable/index degreeQueryselect /*+parallel(a,8)*/ count(1) from table_name a;alter session force query parallel 8;select count(1) from table_name a;alter table table_name parallel 8;select (1) from table_name a;DML默认情况下，parallel dml是禁用的，需要先alter session启用：alter session enable parallel dml;update /*+parallel(a,8)*/ table_name a set col1=1;alter session force parallel dml parallel 8;update table_name a set col1=1;alter session enable parallel dml;alter table table_

今天碰到这么个错误：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

iconv 转换，iconv的命令格式如下：iconv -f encoding -t encoding inputfile比如将一个UTF-8 编码的文件转换成GBK编码iconv -f GBK -t UTF-8 file1 -o file2[@more@]

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）

前几天在小区里来了一个办信用卡的，说是办一个信用卡就能够查看房屋维修基金，忽悠我说查看房屋维修基金必须用这个卡，于是头脑一热就办了一个信用卡。于是麻烦来了，三天两头有个010-57392211的电话给我打电话推销保险，我看到办保险的就烦，原来以为是光大银行将我的客户资料卖出去了，于是打光大银行的客服电话，结果客服说这个电话是光大银行什么保险组的电话，原来是混蛋的光大银行自己推销保险的地方，真操蛋！！！！[@more@]

又碰到一个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