数据工人

 事情比较蹊跷，数据库是oracle 10.2.0.4的版本，CRS版本也一样，运行平台是IBM P570(power5+), 节点数为四个。

问题：由于业务的需要，客户每周定时重启数据库，有时就发现某个数据库实例（非ASM实例）无法自动启动，然后用SQL*PLUS启动或者srvctl启动都可以成功启动。

本次遇到的问题是swdb2实例没有自动启动。

 首先检查oracle alert log，发现其中根本没有记录启动的信息（也就是说，似乎database根本没被启动）。

检查crsd.log

 2010-08-28 09:41:48.640: [ CRSRES][1]32 startup = 1 2010-08-28 09:41:48.755: [ CRSRES][11338]32startRunnable: setting CLI values 2010-08-28 09:41:48.768: [ CRSRES][11081]32Attempting to start `ora.sisu.ASM1.asm` on member `sisu` 2010-08-28 09:41:48.779: [ CRSRES][11852]32startRunnable: setting CLI values 2010-08-28 09:41:48.781: [ CRSRES][11338]32Attempting to start `ora.sisusz.ASM2.asm` on member `sisusz` 2010-08-28 09:41:48.799: [ CRSRES][11852]32Attempting to start `ora.swdb.swdb2.inst` on member `sisusz` 2010-08-28 09:41:48.821: [ CRSRES][11595]32Attempting to start `ora.swdb.swdb1.inst` on member `sisu` 2010-08-28 09:41:54.830: [ CRSAPP][11852]32StartResource error for ora.swdb.swdb2.inst error code = 1 2010-08-28 09:41:56.904: [ CRSRES][11852]32Start of `ora.swdb.swdb2.inst` on member `sisusz` failed. 2010-08-28 09:41:57.801: [ CRSRES][11595]32Start of `ora.swdb.swdb1.inst` on member `sisu` failed. 2010-08-28 09:42:10.353: [ CRSRES][11338]32Start of `ora.sisusz.ASM2.asm` on member `sisusz` succeeded. 2010-08-28 09:42:12.511: [ CRSRES][11081]32Start of `ora.sisu.ASM1.asm` on member `sisu` succeeded. 2010-08-28 09:42:12.514: [ CRSRES][11359]32Skip online resource: ora.sisu.ons 2010-08-28 09:42:12.548: [ CRSRES][11102]32Attempting to start `ora.sisu.gsd` on member `sisu` 2010-08-28 09:42:13.044: [ CRSRES][11102]32Start of `ora.sisu.gsd` on member `sisu` succeeded. 2010-08-28 09:48:45.660: [ CRSRES][11374]32startRunnable: setting CLI values 2010-08-28 09:48:45.670: [ CRSRES][11374]32Attempting to start `ora.swdb.swdb2.inst` on member `sisusz` 2010-08-28 09:48:47.655: [ CRSRES][11374]32Start of `ora.swdb.swdb2.inst` on member `sisusz` succeeded. 2010-08-28 10:54:38.278: [ CRSRES][11376]32ora.sisusz.LISTENER_SISUSZ.lsnr target set to OFFLINE before stop action 2010-08-28 10:54:38.278: [ CRSRES][11376]32StopResource: setting CLI values 2010-08-28 10:54:38.293: [ CRSRES][11376]32Attempting to stop `ora.sisusz.LISTENER_SISUSZ.lsnr` on member `sisusz` 2010-08-28 10:54:38.512: [ CRSRES][11376]32Stop of `ora.sisusz.LISTENER_SISUSZ.lsnr` on member `sisusz` succeeded.

从crsd log里，我们看到了启动失败的信息。当然，如果很熟悉启动流程，在这里也能找到问题的端倪，但是很可惜，最开始我没有发现。

 进一步查看在$ORACLE_HOME/log/*/imon_swdb.log中的日志，我们可以看到更详细的原因了：

 2010-08-28 09:29:18.792: [ RACG][1] [120726][1][ora.swdb.swdb2.inst]: racgimon exiting 2010-08-28 09:41:49.819: [ RACG][1] [107422][1][ora.swdb.swdb2.inst]: racgimon started 2010-08-28 09:41:54.800: [ RACG][1286] [107422][1286][ora.swdb.swdb2.inst]: SQL*Plus: Release 10.2.0.4.0 – Production on Sat Aug 28 09:41:52 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Enter user-name: Connected to an idle instance. SQL> ORA-01565: error in identifying file ‘+DG3/swdb/spfileswdb.ora’ 2010-08-28 09:41:54.800: [ RACG][1286] [107422][1286][ora.swdb.swdb2.inst]: ORA-17503: ksfdopn:2 Failed to open file +DG3/swdb/spfileswdb.ora ORA-15077: could not locate ASM instance serving a required diskgroup ORA-01078: failure in processing system parameters SQL> Disconnected

结合前面的crsd.log，我们会看的更清楚一些：

 1. 09:42:10.353: [ CRSRES][11338]32Start of `ora.sisusz.ASM2.asm` on member `sisusz` succeeded

 2. 09:41:54.830: [ CRSAPP][11852]32StartResource error for ora.swdb.swdb2.inst error code = 1

3. 09:41:56.904: [ CRSRES][11852]32Start of `ora.swdb.swdb2.inst` on member `sisusz` failed

ASM实例在9:42:10才启动成功，而database instance启动请求在9:41:54就发起了。在9：41的时候，ASM instance自身还没启动， disk group没有mount，自然spfile也就找不到了，database instance也就启动不了了。

 为什么没有在alert log中记录呢？ 没找到启动所需要的参数文件，这个时候是不会写alert的。 那怎样让它能够在ASM instance启动之后再去启动Database instance呢？ Oracle在OCR里有定义这个启动顺序的，难道是顺序乱了？

使用crs_stat –p，我们可以找到这部分内容：

NAME=ora.swdb.swdb2.inst TYPE=application ACTION_SCRIPT=/u01/app/oracle/product/10.2.0/db/bin/racgwrap ACTIVE_PLACEMENT=0 AUTO_START=1 CHECK_INTERVAL=600 DESCRIPTION=CRS application for Instance FAILOVER_DELAY=0 FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 HOSTING_MEMBERS=sisusz OPTIONAL_RESOURCES= PLACEMENT=restricted REQUIRED_RESOURCES= RESTART_ATTEMPTS=5 SCRIPT_TIMEOUT=600 START_TIMEOUT=0 STOP_TIMEOUT=0 UPTIME_THRESHOLD=7d USR_ORA_ALERT_NAME= USR_ORA_CHECK_TIMEOUT=0 USR_ORA_CONNECT_STR=/ as sysdba USR_ORA_DEBUG=0 USR_ORA_DISCONNECT=false USR_ORA_FLAGS= USR_ORA_IF= USR_ORA_INST_NOT_SHUTDOWN= USR_ORA_LANG= USR_ORA_NETMASK= USR_ORA_OPEN_MODE= USR_ORA_OPI=false USR_ORA_PFILE= USR_ORA_PRECONNECT=none USR_ORA_SRV= USR_ORA_START_TIMEOUT=0 USR_ORA_STOP_MODE=immediate USR_ORA_STOP_TIMEOUT=0 USR_ORA_VIP=

我们看到，required_resources这一项为空。 要重新添加这种依赖关系的命令如下： srvctl modify instance -d -i -s

 今天发生了一件很低级的操作引起的系统瘫痪。

         开发人员做了这么一个动作：

       update global_name set global_name=”;

 结果是，oracle数据库瞬时就crash了。重新启动数据库无法open：

*** SESSION ID:(152.2387) 2010-09-02 20:37:52.973

*** 2010-09-02 20:37:52.973

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [18061], [1403], [], [], [], [], [], []

—– Call Stack Trace —–

calling             call    entry               argument values in hex     

location            type    point               (? means dubious value)    

——————– ——– ——————– —————————-

ksedst()+27         call    ksedst1()            0 ? 1 ?

ksedmp()+557        call     ksedst()            0 ? 118 ? 0 ? BF8359B4 ?

                                                  253B09CB ? 93CCCE1F ?

ksfdmp()+19         call    ksedmp()            3 ? BF8359A0 ? AC152A0 ?

                                                  CBD2D20 ? 3 ? CB84398 ?

起因是一个db link 无法使用了。

这个命令会修改数据字典props$,而在数据库启动时会检查该字典表，并校验global_name字段，如果为空，则无法启动。

这个时候，最好的办法是从之前的备份中，按照基于时间点的方式恢复数据库了。

因为客户的数据量不大，所以我们确实建议客户从历史备份恢复了先前的数据。

同时，数据库内核研究专家同事双全给出了更优的解决办法（但请勿在任何生产或开发环境模拟）

但是，我需要提醒我们的客户们和潜在客户们：
1.不要过于放开系统权限。如果你不知道怎么定制安全守则，可以联系我，我们一起来制订和完善；
2.如果没有做系统备份，请尽快做起来，而且要定期做恢复测试
3.不知道后果的命令，最好打我们的技术咨询热线确认下

要求：中、高级别 Oracle DBA Read the rest of this entry »

20个月的momo思维变得更加活跃了，所以作为父母的言行也就更应该谨慎，因为随便的一个不良习惯都可能遭遇模仿。

之前她刚学走路的时候，不小心摔倒了，我总是让她自己起来，实在起不来我才伸手过去，然后会随嘴说“up，up，来，起来咯..”。
这天中午，她醒来了，看到旁边的巧虎在躺在，她就说，“巧虎，upup，醒来啦！”
然后她妈妈说，“你让巧虎在睡一会吧？”
她答到“巧虎没听见”
然后边喊“up”边把巧虎扶了起来

有个习惯不知道是好不好，晚上睡觉前会喋喋不休，自己重复白天大人跟她的问答。

在RDBMS系统中，发生enqueue等待特别是enqueue TX-contention是再正常不过的了，原因很简单，为了满足ACID原则。但如果是enqueue HW-contention,你遇到的机会就要稍微少一些了，因为这一般只发生在大量数据装载或者是OLTP业务非常繁忙的系统中。

这不，我们的一个银行用好，恰巧就发生了这么一个问题，当大批量数据装载时，系统CPU使用率接近100%（这可是128CPU的HP superdome），而这其中的90%以上，是在等待enqueue HW 。当然，这个系统的架构有其特殊性，每个表只有两个字段，一个number，一个LOB（这个时候，你可能就会发现架构师对性能的影响有多么巨大了）。

HW=HighWatermark，所谓的高水位竞争。就是当数据插入的session过多，对最后一个可用块的竞争，以得到下一个空闲块（或者extent)。

这种情况，如果是普通表，使用alter table <TABNAME> allocate extent 提前多分配extent即可解决。

但是含有LOB（clob）字段的表，据客户反应，用这个方法在loading装载开始后的2分钟之内是有效的，但之后就不灵了，原因和在？ 原因处在lob方式。

解决方式分两种，在ASSM表空间之内的：

 a) As temporary workaround, manually add extra space to the LOB segment
      ALTER TABLE <lob_table>
      MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
   b) It may related Bug 6376915. 
   Refer to Note 6376915.8 “Bug 6376915 HW enqueue contention for ASSM LOB segments”
   In 10.2.0.4 or above, this fix has been included, and can be enabled by setting event 44951 to a value
   between 1 and 1024.  A higher value would be more beneficial in reducing contention.
   EVENT=”44951 TRACE NAME CONTEXT FOREVER, LEVEL < 1 – 1024 >”
OR
  c) Consider partitioning the LOB  in a manner that will evenly distribute concurrent DML across multiple 
      partitions  

使用MSSM的：

a) As temporary workaround, manually add extra space to the LOB segment
    ALTER TABLE <lob_table>    
    MODIFY LOB (<column_name>) (allocate extent (size <extent size>));
OR
     b) Consider partitioning the LOB in a manner that will evenly distribute concurrent DML across multiple
      partitions

 如我先去提到的，由于表的字段只有两个，lob字段中包含的内容实在太复杂，所以partition方式无法处理这个问题。只能是每次装载前，使用批处理的方式，预先分配200G左右的lob extent。

最近一个客户提了这么一个要求：

有两张表，F1,F2,这两张表有3个的关键字:

K1:订单号
K2:订单公司
K3：订单类型

要求是统计F1/F2这两张表相同关键字下的记录数，比较是否一致

我简单做了个模型：

SQL> select * from f1;

        K1         K2         K3         K4
———- ———- ———- ———-
         1          1          1          1
         1          1          1          2
         1          1          2          1
         1          1          2          2
         1          1          2          3

SQL> select * from f2;

        K1         K2         K3         K4
———- ———- ———- ———-
         1          1          1          3
         1          1          1          4
         1          1          1          5
         2          2          2          1
         2          2          2          2
         2          2          2          3
         2          2          2          4

客户要求的输出如下：

       K1         K2         K3    F1COUNT    F2COUNT
——— ———- ———- ———- ———-
        1          1          1          2          3
        1          1          2          3          0
        2          2          2          0          4

歪歪曲曲的写了个”复杂”的SQL语句：

 select f1.k1,f1.k2,f1.k3,f1count,f2count from
　　　 (select f1.k1,f1.k2,f1.k3,f1count,f2.k1,f2.k2,f2.k3,f2count f2count from
　　　　　　　　　　　(select f1.k1,f1.k2,f1.k3,count(1) f1count from f1 group by k1,k2,k3) f1
　　full outer join
　　　　　　　　　　(select f2.k1,f2.k2,f2.k3,count(1) f2count from f2 group by k1,k2,k3) f2 
　　　　　　　　　　on  f1.k1=f2.k1 and f1.k2=f2.k2 and f1.k3=f2.k3)）;

我认为还应该有更简洁的写法，但暂时还没想到。

很多年不写语句了，暂记一下。想到好的再更新上来

我在招聘帖子里说过，我这里提供OCM免费考试机会，当然也欢迎OCM加入我们的团队。

但是，并非是说OCM就真的是Master（大师）了，因为几乎绝大多数考试到了中国后，都可以在5年之内泛滥，OCM也不例外。

最近面试了一些朋友，其中有一个都在09年通过了OCM。但是我的同事们面试过后，却连连摇头。这多少让我有些诧异。

为了安全起见，同一个人，我都会安排2-3个同事先后电话面试，结束前他们不能交流各自的看法。

但是当聚集在会议室的讨论，意见却基本一致————OCM已经失去意义。他们认为，这位朋友的经验和基础能力只能算作中级水平。

其实这不是个案，在这里也不是为了贬低这位朋友。因为老耿在去年5月份考完OCM就曾向我吹嘘，这玩意，三天我就搞定了。

所以，如果有免费的机会参加OCM考试，那不要拒绝，go！

如果自费去，那坚决不要！

如果你看到了OCM，那不要迷信，看看再说！

OCM终归来说，就是一场已经基本透明化的考试而已！

按照机械的步骤，只要你的运气不是太酶，收获率还是大大地！

不过，我要说一句，我不是OCM，也不准备是。

—eof—

这是个挺极端的话题，因为标题中问题的前提是：没有任何备份。

不要抱怨，“命苦不能怪政府，点背不能怨社会” ^_^

而我一个同事，就真正碰上这样的问题。当然，最后也成功恢复了。

有人会想到logminer和archive log，但是sp被删除时archive log并不记录sp的文本内容。当然logminer有用处，起码能定位到准确的删除时间。

存储过程的文本内容通常被记录在source$中。

SQL> conn blue/blue

Connected.

SQL> create or replace procedure sp_test2

2     is

3     begin

4       dbms_output.put_line(‘procedure restore’);

5     end;

6     /

Procedure created.

SQL> conn / as sysdba

Connected.

SQL> select s.obj#,s.source from source$ s,obj$ o

2  where s.obj#=o.obj#

3  and o.name=’SP_TEST’;

OBJ# SOURCE

———- ————————————————–

53258 procedure sp_test

53258    is

53258    begin

53258      dbms_output.put_line(‘procedure restore’);

53258    end;

不过可惜的是，当sp或整个schema被drop后，source$中对应的内容也一并被删除。

21:56:42 SQL> drop procedure blue.sp_test;

Procedure dropped.

21:56:54 SQL> select s.obj#,s.source from source$ s,obj$ o

21:57:20   2  where s.obj#=o.obj#

21:57:20   3  and o.name=’SP_TEST’;

no rows selected

我们想要得到的，是过去某个时间点里source$中的内容。

然而，sys schema下不支持flashback table，Oracle不允许你这么干，如果部分数据字典表被回退到过去的时间点，这全乱套了。

有人用flashback database，没错，这确实可以实现，只是，这也太小题大作了吧？辛辛苦苦几十年，一下回到解放前。

so，why not flashback query？

21:59:53 SQL> select obj#,name from obj$ as of timestamp  sysdate-5/1440

21:59:55   2  where name =’SP_TEST’;

OBJ# NAME

———- ——————————

53258 SP_TEST

22:00:22 SQL> select obj#,source from source$ as of timestamp sysdate-6/1440

22:00:24   2  where obj#=53258;

OBJ# SOURCE

———- ————————————————–

53258 procedure sp_test

53258    is

53258    begin

53258      dbms_output.put_line(‘procedure restore’);

53258    end;

回到最开始的话题，2点警示：

1、制订完善的备份策略并实施

2、规划日常操作

隐式转换是DBA们所不愿意看到的，有人说“I believe implicit conversion to be bad. Badder. Evil. A serious no-no!”

举个例子：

有一条SQL

select * from t_table where id=:1;

说明：t_table记录量在数万条，id varchar2类型，主键。

1.用户用pl/sql等工具执行非常快。

2.在应用中执行该语句非常慢，通过statspack,awr等发现，并且发现是全表扫描。

这种情况很有可能是绑定变量类型不匹配而导致的。

某些情况下，隐式转换会让数据库性能变得很糟糕。有同事处理过这样的案例，在消灭隐式转换后，原本一个需要2小时的业务操作可以在6秒内便可完成。
Oracle也强烈建议使用explicit conversion而不是implicit conversion，explicit conversion相比implicit conversion有如下的好处：

SQL statements are easier to understand when you use explicit datatype conversion functions.

Implicit datatype conversion can have a negative impact on performance, especially if the datatype of a column value is converted to that of a constant rather than the other way around.

Implicit conversion depends on the context in which it occurs and may not work the same way in every case. For example, implicit conversion from a datetime value to a VARCHAR2 value may return an unexpected year depending on the value of the NLS_DATE_FORMAT parameter.

Algorithms for implicit conversion are subject to change across software releases and among Oracle products. Behavior of explicit conversions is more predictable.

在发生隐式转换SQL的诊断过程中，我们使用一些第三方的工具看到的执行计划往往没有异常。因为在使用这些工具的时候，解释的是用户手工输入的而不是应用程序产生的SQL.

那么，如何确定应用程序的SQL是不是发生了隐式转换呢？

在Oracle 10g提供过滤谓词的信息当中，包含了是否发生转换。

查看过滤谓词的方式较多，比如autotrace  、explain plan、utlxpls、dbms_xplan等。

前面3种方法需要手工输入SQL文本，所以看到的同样不是我们需要的结果。而10g中dbms_xplan可以通过指定SQLID来查看用户关心的特定SQL。

SQL> select /*+ hint1 */hiredate from scott.emp where    hiredate between ’17-DE

C-80′ and ’20-FEB-81′ ;

HIREDATE

———

17-DEC-80

20-FEB-81

SQL> col sql_id for a20

SQL> select sql_id,sql_text from v$sql where sql_text like ‘%hint1%’;

SQL_ID

——————–

SQL_TEXT

——————————————————————————–

2k4kk1zvp8jz1

select /*+ hint1 */hiredate from scott.emp where    hiredate between ’17-DEC-80′

and ’20-FEB-81′

28n8kr51sv6s6

select sql_id,sql_text from v$sql where sql_text like ‘%hint1%’

SQL> select * from table(dbms_xplan.display_cursor(‘&SQLID’));

Enter value for sqlid: 2k4kk1zvp8jz1

old   1: select * from table(dbms_xplan.display_cursor(‘&SQLID’))

new   1: select * from table(dbms_xplan.display_cursor(’2k4kk1zvp8jz1′))

PLAN_TABLE_OUTPUT

——————————————————————————-

SQL_ID  2k4kk1zvp8jz1, child number 0

————————————-

select /*+ hint1 */hiredate from scott.emp where    hiredate between

’17-DEC-80′ and ’20-FEB-81′

Plan hash value: 3896240783

—————————————————————————

| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |

—————————————————————————

|   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |

PLAN_TABLE_OUTPUT

——————————————————————————-

|*  1 |  FILTER            |      |       |       |            |          |

|*  2 |   TABLE ACCESS FULL| EMP  |     1 |     8 |     3   (0)| 00:00:01 |

—————————————————————————

Predicate Information (identified by operation id):

—————————————————

1 – filter(TO_DATE(’17-DEC-80′)<=TO_DATE(’20-FEB-81′))

2 – filter((“HIREDATE”<=’20-FEB-81′ AND “HIREDATE”>=’17-DEC-80′))

21 rows selected.

SQL>

然而9i的过滤谓词没这么详细的信息，v$sql 视图中不包含SQLID信息，dbms_xplan中也不提供display_cursor这样的function。就是说，9i不能用以上的方法来辅助判断。

那Oracle 9i下怎么办呢？

试试10046吧，部分级别的10046 trace内容中包含了绑定变量及其变量类型dty信息。

Trace文件可能会包含类似内容：

bind 3: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=01 oacfl2=0 size=0 offset=72

bfp=ffffffff7f5500f0 bln=11 avl=11 flg=01

value=

Dump of memory from 0xFFFFFFFF7F5500F0 to 0xFFFFFFFF7F5500FB

FFFFFFFF7F5500F0 78640101 0A353619 08B10000           [xd...56.....]

bind 4: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=01 oacfl2=0 size=0 offset=88

bfp=ffffffff7f550100 bln=11 avl=11 flg=01

value=

下表为Oracle内部的数据类型代码

一个技术较好的同事，是部门里的干将之一，经常被客户指明要求去服务，出台较多多。但最近由于不堪某客户的态度，出于对该职业的悲观情绪，出离愤怒的想要辞职了。

这是一个很好的同事，有着技术工程师最重要的学习能力和技术爱好。因此，这引起了我的思考。

于是杜撰了如下故事：

一群身强力壮的男人进了一家夜总会，然后老鸨带着很多小姐过来了。其中一个人，是老板，但是身上有很严重的狐臭，隔老远都能闻到。很自然的，老板先挑。小姐们一批批的来，一批批的去，终于，这家夜总会的镇店之宝，文成公主，出现了，老板满意之。

然，公主一被搂入怀中，就猛打喷嚏。

她会怎么做呢？

为什么故事里要是一群男人，且该男子是老板。代表甲方是强势群体。

如果是一两个人，遇到这种情况，我猜想，文成公主有可能直接发飙，怒斥该男子。但是，一群人，她就得掂量掂量，一发飙可能会被揍死。

那么，这种情况，最好的选择似乎是小姐就只好自认倒霉。

如果接二连三的发生这种情况，这公主是不是就考虑从良或自尽呢?

唐太宗（夜总会老板）是否可以帮助这位文成公主么？

不得而知，不能入眠。仅记之200910110335。