ITPub博客

偷懒打算用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这个…….