ITPub博客

今天为A 系统09年一季度的Partitioned Table加新的Partitions.正在加new tablespace的时侯，ORA-00059: maximum number of DB_FILES exceeded[@more@]SQL> show parameter db_files;NAME TYPE VALUE------------------------------------ ----------- ------------------------------db_files integer 200恩，我承认我第一反应是去Alter database backup controlfile to trace 看Controlfile去了。结果一看MAX 4096没事，才去Show Parameter.SQL> alter sy

今天回想这中间的过程：这句SQL 导致Parse，execute占用大量资源，Parse的过程需要一直持有Library Cache，而Library Cache Latch的个数是有限的，这点引起了Library Cache的竞争。而Library Cache Pin的Contention有点疑惑，这可能也是一个我概念比较模糊的地方，今天又上Metalink和PUB上找了很多。借这次的现象整理了一下（顺便兼带Library Cache Lock）：[@more@]Library Cache Pin/Lock 和 Library Cache Pin Latch是什么？这是我经常感到疑惑的，很多人讲了很多，看完却也觉得说不清。上午看到PUB上今年6月份的关于Latch的帖子，其中

上周，Production DB A的user 反应他们作业的速度变得很慢。这台DB用的是IBM X3850 16Core 2.93Ghz 16GB Memory AMS Storage，平时Performance表现十分良好，甚至可以支持一部分Report的作业。[@more@]SSH连接上去之后，打开TOP,IOSTAT观察：IO在正常范围，最大IOWAIT不超过5%。CPU Utilization 比一般要高，时有冲到50%整的现象。对SMP System而言，这可以认为有Process持续消耗大量CPU。这是初步印象。连入Oracle,观察了下v$session_wait：select * from v$session_wait where event not in (select event from stats$idle_event)发现很

DBMS_STATS.GATHER_SYSTEM_STATS[@more@]不建立Stattab:ShXXXX SQL> show parameter job; NAME TYPE VALUE------------------------------------ ----------- ------------------------------_job_queue_interval integer 60job_queue_processes integer 4SQL> exec dbms_stats.gather_system_stats(gathering_mode=>'INTERVAL',interval=>20,statid=>'REALTIME');PL/SQL procedure successfully completed.查看

前日，Production DB N突然反应变慢(RHEL4UP4,9208,64bit,MTS mode)用top –d 1 察看，发现CPU usage大约在40%~70%间浮动，IOWAIT大约在4%~9%左右。Sys使用量1%~3%，和平常一样。再用iostat –x 1 看了下各个mount point的IO，发现/u04的IOPS很重，使用率一直在100%。[@more@]Hash join semi带来的temp tablespace使用过度问题。前日，Production DB N突然反应变慢(RHEL4UP4,9208,64bit,MTS mode)用top –d 1 察看，发现CPU usage大约在40%~70%间浮动，IOWAIT大约在4%~9%左右。Sys使用量1%~3%，和平常一样。再用iostat –x 1 看了下各个mo

周末作了一天的Partitioned Table旧有资料的归档。主要是用Partitioned Table的Exchange功能。[@more@]基本步骤：1． 构造能用来做exchange的table A。2． 进行exchange3． 将segments从物理上转移到归档用的tablespace.4． Drop 被exchange出的Partition5． 被drop 的Partition的Tablespace—〉drop6． Rebuild A中被mark unusable的Index.Exchange是Partitioned Table 技术中一个非常有用的功能，尤其是当需要将旧资料进行归档的时侯。Exchange的限制：Range-Hashßà hashRange-Listßà ListRange/HASH/LIST ßànon-p

Oracle 中or是可以用union/union all来作优化的[@more@]SQL Tuning之 OR的优化。今天公司某Production DB时常LOADING飚起来，Monitor下发现一个很high的SQL:SELECT COUNT(A.ISN) FROM MO_ROUTE A,MO B WHERE (A.ROUTE = :B2 OR A.ROUTE = 'LNBR') AND A.GRP = 'AI1' AND (A.MO LIKE 'NFPQ%' OR A.MO LIKE 'NF1Q%' OR A.MO LIKE 'NF6Q%') AND A.MO = B.MO(+) AND A.INTIME BETWEEN :B1 - 1 AND :B1 AND B.CDATE BETWEEN :B1 - 1 AND :B1其PLAN如下：Execution Plan---------------------------------------------------------- 0 SE

昨晚遇到很囧的问题ORA-07445。[@more@]晚上正在洗衣服，听到手机响了。擦干手跑去接电话，刚好对方挂了，一看是公司MVPN的号码，再一看是X厂 ITS的负责人，当下感觉不妙（此人来电话必有事请发生）。火速连线至相关DB，果然Instance Crash。翻了下ALERT：Errors in file /u01/app/oracle/admin/shanb1/bdump/shanb1_s000_8678.trc:ORA-07445: exception encountered: core dump [ptmak()+144] [SIGSEGV] [Address not mapped to object] [0x000000010] [] []Mon Jun 23 22:06:33 2008found dead shared server 'S000', pid = (12, 1)再接

E8300ASUS 8800GTSASUS P5Q这几天在忙着OC，过些日子将积累的技术文章一起放上来。[@more@]

真是诡异的ORA-03113[@more@]今日接到AP开发人员反映：W系统的DB（9208，在RHEL4上）里没权限修改SP。先连接进去了解了下该用户的权限和要修改的SP，发现SP就在此用户account的schema下。应该不是权限问题。用User的account试了一把，发现原来是只要Create or replace procedure, shared_server就会死掉，而SQL Navigate则会挂起。将TNSNAMES改为Dedicated连入，则直接报ORA-03113错误。在Server端用SYS登入，尝试compile这个SP，竟然也出ORA-03113。仔细察看Alert.log，发现并没有ORA-或者是Warning，BDUMP&UDUMP也没有新增纪录。接下

早晨刚上班，产线就来催,说昨晚迁移后，Production DB DN连不上。了解了一下情况：Ping可以Ping通Server，Tnsping连不上，报没有listener。登进DB Server看了下listener却是起来的，我也能tnsping到DB想到是双网卡，产线从另一个网段连入。于是去看listener的configration, host对应的是IP。答案就出来了：Listener只能监听到一个网段。昨晚负责迁移的DBA在configure新Listener的时侯只是用了IP。于是把host改成主机名，问题解决。顺带补一下双网卡Listener的配置1． 一、Client会用自己hosts里的IP去解析tnsnames.ora里的host，这是本次的

生产系统MOKP表，100多万rows。SISN+EISN是Index。[@more@]生产系统MOKP表，100多万rows。SISN+EISN是Index。SISN列和EISN列都是前半段字母+后半段数字。原SQL：SELECT COUNT(*) INTO v_CNT2 FROM MOKP WHERE SISN <= p_DATA AND EISN >= p_DATA AND LENGTH(SISN) = LENGTH(p_DATA)。结果Cost=1800up，consistent gets=12000多，走INDEX_FFS。由于执行次数较多，这句便成为整个库第二大buffer gets的SQL。Tuning的任务摆在面前，我观察了半天，Index 合适阿，又观察了下MOKP的数据分布：最主要是SISN<

上周日，Production DB用上了HDS的AMS200，随之改变的是datafile存放的目录。但是Report DB的结构并没有变。结果在Production DB上为一Partion Table增加一个datafile后，Report DB重起Apply log时侯就开始报ORA-01157: cannot identify/lock data file 114 - see DBWR trace fileORA-01111: name for data file 114 is unknown - rename to correct fileORA-01110: data file 114: '/u01/app/oracle/product/9.2.0/dbs/UNNAMED00114'但是$ORACLE_HOME下的dbs里又没有UNAMED00114,估计只是dictionary里会生成这样的纪录。将standby file m

一个Distinct的优化。[@more@]一个Distinct的优化。ISN有3000万笔，SCARTON有600万笔原SQL：16:07:02 SQL> set autotrace on;16:07:19 SQL> SELECT COUNT(DISTINCT(SCARTON.SCARNO)) MAX_SCARTON 16:07:59 2 FROM SCARTON,ISN WHERE SCARTON.SO='NB1P813740' AND SCARTON.SOLINE=1 AND SCARTON.SCARNO=ISN.SCARNO;192Elapsed: 00:00:00.93Execution Plan----------------------------------------------------------0 SELECT STATEMENT Optimizer=CHOOSE (Cost=67 Card=1 Bytes=34)1 0 SORT (GROUP BY)2 1 NESTED LOOPS (Cost=67 Ca

工作中的经验。此文写得仓促，较为完整的探讨在http://karsus.itpub.net/post/36558/470885[@more@]1.SELECT MAX(SEQ) FROM MO_ROUTE WHERE ISN=UPPER('NF1S6500020029' ) AND STEP <> '0';是在OMS的 TOP SQL按Disk IO排序出最高的SQL.2.select SEQ FROM MO_ROUTE WHERE ISN=UPPER('NF1S6500020029' ) AND STEP <> '0' and rownum=1 order by seq desc;是改写之后的.2比1的效能好很多，几乎完全消除了physical reads. consistent gets也少很多。按我的经验，MAX/MIN 类这样改写效能都会比原先好（包括SQL Server也是如此,rown

RHEL4下的版本。copy到任何目录都可执行。因为上次的shell并不严谨，在某些情况会有遗漏，遂重新写之。[@more@]Oracle ENV先声明。#Some VariablesBTIME=`date`;ARCH_FOLDER=/u04/arch/SHxxx1;SH_DIR=$(cd "$(dirname "$0")"; pwd);DBA="J A "#INIT FOLDRif [ -f $SH_DIR/applied.lst ]then rm -f $SH_DIR/applied.lstfiif [ -f $SH_DIR/compared.lst ]then rm -f $SH_DIR/compared.lstfiif [ -f $SH_DIR/copy.lst ]then rm -f $SH_DIR/copy.lst ]fiif [ -f $SH_DIR/SHXXX02.lst ]then rm -f $SH_DIR/SHXXX

今天早晨遇到的问题[@more@]一早来上班就收到User的反应，说有些数据查不到，看了他们的截图，发现可能遇到corrupted block了。赶紧上去看一下严重程度先。08:23:11 SQL> select * from ISN where ISN='NS1S82038200461';select * from ISN where ISN='NS1S82038200461' *ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 16, block # 68845)ORA-01110: data file 16: '/u02/app/oracle/oradata/shxxx1/isn0807_data01.dbf'08:25:00 SQL> select file#,NAME from v$datafile where file#=16; 1

原先的report在Production DB上跑，已经使得其不堪重负。User多次反映有时速度很慢，影响工作效率。 [@more@]Standby Database for report。原先的report在Production DB上跑，已经使得其不堪重负。User多次反映有时速度很慢，影响工作效率。RHEL4 + 9IR2目前已经有一台Physical Standby Database，但主要目的是备援，不适合用来做Report DB。因此需要另外再搭建一台standby database for report.详细搭建不多说，这台Report DB的LOG传输和LOG apply完全靠OS上的机制。9ir2的Standby database本可以从另一个standby DB上接收Archived log,

如何找出存在FTS的Table ？ 可以采用这样的SQL[@more@]如何找出存在FTS的Table ？可以采用这样的SQL：SELECT s.segment_name,s.segment_type,s.ownerFROM dba_extents s,x$bh xWHERE s.segment_type='TABLE' AND x.dbarfil=s.file_id AND x.dbablk between s.block_id and s.block_id+s.blocks-1AND standard.bitand(x.flag,524288)>0 AND owner<>'SYS';不过这样的语句可能会十分缓慢，性能视图本身一般也是多个table/view的结合。可以采用这样：SELECT o.object_name,o.object_type,o.ownerFROM dba_objects o,x$bh xWH

optimizer_index_cost_adj的测试。关于optimizer_index_cost_adj这个参数，起初并没有太多注意，在9i下其default值100一直工作得很合适。不过偶然看到一个家伙把DB从9i->10g后，默认的100使得很多SQL的execution plan发生了变化。这说明10g和9i的CBO算法是有变化的。因此对这个参数产生了兴趣，[@more@]就按Tim Gorman的观点，每个系统有它自己合适的optimizer_index_cost_adj的值。下面来看生产系统E的optimizer_index_cost_adj的值应该设多少。生产环境是RHEL4up4+Oracle 9i.按照Tim Gorman的算法。这个值大致应该是V$system_event中