ITPub博客

前几天在清理了Statspack的表后出现了ORA-12012: error on auto execute of job 1[@more@]ORA-12012: error on auto execute of job 1ORA-00001: unique constraint (PERFSTAT.STATS$SQL_SUMMARY_PK) violatedORA-06512: at "PERFSTAT.STATSPACK", line 1361ORA-06512: at "PERFSTAT.STATSPACK", line 2442ORA-06512: at "PERFSTAT.STATSPACK", line 91ORA-06512: at line 1版本是9208。即使是再次把资料清空也是一样的错误。BAIDU一下，据说是有BUG, 不过仔细看看又和我的版本不太对。只好从Perfstat本身的

前几日，海的那边的AP TEAM发来一份script，说是程序的权限控制要大改，请这边的DBA执行一下，我打开看了下，确实对很多objects的grants有很大变动。先在一个库执行了一下，顺利，10分钟run完。然后在第二个库，开始run。我习惯性的观察TOP状况的变动，忽然发现s012之后的process出现在TOP中，然后竟然发现s30也出现了( 我们用Shared_server, 默认开12个，最大32个)，这可不是好兆头。[@more@]赶紧检查session wait, 发现了大量library cache pin，赶紧Cancel掉。恢复正常。为什么grant会产生大量library cache pin.，我还真没好好思考过。

今天下午，User突然反应数据都没法删除，收到他们的截图看，是ORA-00376 file 2 cannot be read at this time[@more@]然后file 2 是什么呢，一看是UNDO…去Alert.log看了下：CF: write/open error block=0x69 online=1 file=5 /data2/hhsas/undotbs02.dbf file=2 /data1/hhsas/undotbs01.dbf error=27061 txt: 'Linux-x86_64 Error: 30: Read-only file system error=27061 txt: 'Linux-x86_64 Error: 30: Read-only file systemAdditional information: -1Additional information: -1Additional information: 8192'Addit

10.2.0.4的一个Data Warehouse, 最近listener常挂...[@more@]OS: RHEL4kernel: tnslsnr[5512]: segfault at 0000000000000018 rip 000000358126870d rsp 0000007fbfff8f70 error 4Listener.ora:TNS-12518: TNS:listener could not hand off client connection TNS-12547: TNS:lost contact TNS-12560: TNS:protocol adapter error TNS-00517: Lost contact Linux Error: 32: Broken pipeMetalink上给了3个解法：1． 增加物理内存2． 上1个patch3． 用Huge Page这套系统是64bit, 24GB物理内存，各项指标目前都还好，看起来上个pat

偷懒打算用Standby DB Copy到另一台Server上做test DB.结果Failover时候发生ORA-16139 ...这个系统是Oracle9i, 10GR2之后已经不用再skip了...[@more@]Oracle的DataGard Concepts没发现异样，上Metalink搜索了下：原来如此.Cause~~~~~~~If you are using standby redologs and they are being used then you should be able to use the command :sql>recover managed standby database finishHowever, if you did not have Standby redolog defined or they were not being used, then you need another approach.Fix~~~~You can do the

昨天下午5点有一台Production DB Crash, 去Alert.log察看发现是ORA-00600 [2103]这个ERROR我是第一次见到。[@more@]----------------------------------------------------Wed Jun 3 01:17:45 2009ARC1: Unable to archive log 3 thread 1 sequence 1935 Log actively being archived by another processWed Jun 3 01:17:46 2009Creating archive destination LOG_ARCHIVE_DEST_1: '/u01/archive/ems/arc1_1935.dbf'ARCH: Completed archiving log 3 thread 1 sequence 1935Wed Jun 3 02:52:20 2009Errors in file /u01/app/orac

Oracle多表关联更新的方式选择。环境：Oracle 10.2.0.3 on RHEL4 X86_64SQL> desc test_a; Name Null? Type ----------------------------------------- -------- ---------------------------- C1 NUMBER C2 VARCHAR2(32)测试表2SQL> desc test_b; Name Null? Type ----------------------------------------- -------- -----------------

某Production DB, 主要是OLTP和一部分Report。最近由于盘点经常要出一个Report，这个Report会用对List里的COA_ITEM的每个值去捞取资料。但这个Report经常要跑很长时间。[@more@]其中一个重要相关SQL如下：SELECT count(*)FROM mo_d d, coa_sn_d sWHERE s.flag = 'Z'AND d.isn = s.isnAND d.grp <> 'YYY'AND s.coa_item = 'XXXXXXXX'AND s.companyid = 'FFFPC';Report的Developer在搞出这个Report后发现执行时间大大超出预期，有时要1小时才能出全部结果，但检查一些List里的COA_ITEM的值又发现都执行很快。然后这个问题交到我手上。

周三 AP 人员准备对一个千万级的Table A进行Update, 要求A表中，每一行的Column MO的值要和B表中的MO值想等，对应的逻辑是A.SN=B.SN, SN是Unique。[@more@]本来他们想一个SQL搞定（怎么可能…），后来觉得不可以，之后又来找我们商量要怎么做，因为毕竟是一个7X24的系统，CPU Loading比较重 最后确定的方案是用PL/SQL分批Update，同时用批量绑定的方式。下面是当时作的测试对比。测试平台是一套空载的10gR2 RAC，存储是ISCSI。测试表COA_SN_D，是一个百万级的Table，作为A表；便于测试，提出其COA_SN和MO构造出测试表UPD_COA (B)，然后

这个问题首先是在TAOBAO DBA的BLOG上看到丹臣写的关于Like和INSTR的性能问题。不过他只是给出了结果。我对这个函数性能感到有趣，之前一直没有关注过，遂自己详细测试了下。[@more@]Oracle 9208:SQL> select count(*) from item; COUNT(*)---------- 2781806SQL> select count(*) from item where item like '%A0'; COUNT(*)---------- 9036Elapsed: 00:00:04.03Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1134 Card=1 Bytes=16

有一台Report DB，原先一直用本地磁盘，146G * 6 Raid 5。最近终于撑不住了，因为它的Production已经快到700GB。现在的暂行策略是把Report也放到Production上做。Production经过元旦期间的大调整，现时的表现非常之好。即使是把Report也放上去之后，OLTP Client也没受到影响（主要是把Business搞得很透了，在元旦期间做的业务I/O分离很成功，这对IO Bound系统， 是个大利好）但是AP的Leader还是不放心，决定还是要把最重的一部份Report单独拿出来跑。应对这样的需求，像SAN这种贵重的物品自然是申请不到，何况还在经济危机。所以，充分利用

这个例子很简单，9i to 10g只有一个Table, Single Master Site。是近期的一个应用需求，顺便把当时的一些步骤记录下。而且测试下了，GLOBAL_NAME=FALSE也是可以的，但跟一个资深DBA聊起来的时侯，他说，一般的应用这样没问题，但是用到Procedure的地方可能会出事，但是他想不起来具体的例子了...[@more@]1． Production AS à Production AY. Only one table ITEM.2． AS: 9208 AY:102033． Initialization Parameters:Compatible > 9.0.0.1 VGlobal_Names=True 我打算试试False可不可以—结果是可以的Job_Queue_Processes 7Open_Links

遇到关于Sequence的 ORA-08002[@more@]ORA-08002: sequence SEQ_TEST_ID.CURRVAL is not yet defined in this session.查了下，原来是这原因。ORA-08002: sequence string.CURRVAL is not yet defined in this session Cause: sequence CURRVAL has been selected before sequence NEXTVAL Action: select NEXTVAL from the sequence before selecting CURRVAL这个…….

今天为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