今天遇到一个比较特殊的死锁现象，记录下来

DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00090022-000002ba        15     145     X             15     145           X
session 145: DID 0001-000F-00000019     session 145: DID 0001-000F-00000019
Rows waited on:
Session 145: obj - rowid = 0000E0A3 - AAAOCjAAFAAAAA8AAA
  (dictionary objn - 57507, file - 5, block - 60, slot - 0)
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
Current SQL statement for this session:
UPDATE T SET Y = Y WHERE X = :B1
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
0x67987910         4  CHF.T
===================================================

问题原因：自治事件导致(重现)

drop table t;
create table t ( x int, y int );
create or replace trigger t before update on t
for each row
declare
    pragma autonomous_transaction;
begin
    update t set y = y where x = :new.x;
    commit;
end;
/
insert into t values ( 1, 1 );
commit;
update t set y = y where x = 1;

我见识过的，讲的最好的关于dump相关的文章，这个里面关于dump block,dump index,dump controlfile说的比较详细，看了收获不小，现在贡献出来和大家分享
如何阅读oracle数据块的dump文件
http://www.xifenfei.com/wp-content/uploads/2011/09/read_oracle_dump.pdf

1、发现现象
xunzhi_lgwr_27974.trc文件中
*** 2011-09-14 09:30:04.947
Warning: log write time 500ms, size 0KB
*** 2011-09-14 09:33:41.058
Warning: log write time 560ms, size 3KB
*** 2011-09-14 09:48:55.597
Warning: log write time 820ms, size 0KB
*** 2011-09-14 10:00:50.477
Warning: log write time 870ms, size 0KB
2、Metalink描述[ID 601316.1]
Changes
The problem surfaced after upgrading to 10.2.0.4.
Cause
The above warning messages has been introduced in 10.2.0.4 patchset. This warning message will be generated only if the log write time is more than 500 ms and it will be written to the lgwr trace file .
Solution
These messages are very much expected in 10.2.0.4 database in case the log write is more than 500 ms. This is a warning which means that the write process is not as fast as it intented to be .So probably you need to check if the disk is slow or not or for any potential OS causes. If everything looks fine at the hardware level or OS level then you can safely ignore these messages. The trace file can easily be deleted or truncated.
3、网上解决方案
the error may be suppressed by setting Event 10468 level 4.
alter system set events ‘10468 trace name context level 4’;
取消该trace命令为：
ALTER SYSTEM SET EVENTS ‘10468 trace name context off’;

其实object_id和data_object_id同样是表示数据库对象的一个唯一标志，但是object_id表示的是逻辑id，data_object_id表示的是物理id。如果一些object没有物理属性的话那它就不存在data_object_id，例如procedure,function,package,data type,db link,mv定义,view定义,临时表,分区表定义等等这些object都是没有对应着某个segment，因此它们的data_object_id都为空。

当表刚创建的时候它的object_id和data_object_id都是相等的，但是如果表经过move或truncate等，涉及到segment发生改变后data_object_id将会有变化。

DATA_OBJECT_ID was introduced in 8.0 to track versions of the same segment (certain operations change the version). It is used to discover stale ROWIDs and stale undo records.

SQL> create table xff as select * from dba_objects where rownum<100;
Table created
SQL> select object_id,data_object_id from user_objects where object_name='XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211325         211325
SQL> alter table xff move;
Table altered
SQL> select object_id,data_object_id from user_objects where object_name='XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211325         211326
SQL> truncate table xff;
Table truncated
SQL> create index ind_xff on xff(object_id);
Index created
SQL>  select object_id,data_object_id from user_objects where object_name='IND_XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211328         211328
SQL> ALTER INDEX IND_XFF REBUILD;
Index altered
SQL>  select object_id,data_object_id from user_objects where object_name='IND_XFF';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
    211328         211329

1、监控语句
ALTER INDEX owner.index_name MONITORING USAGE;
2、查看监控情况
select * from v$object_usage;
3、使用sys用户无法查询到监控对象问题解决
3.1）查询建立v$object_usage的语句

CREATE OR REPLACE FORCE VIEW v$object_usage (index_name,
table_name,
MONITORING,
used,
start_monitoring,
end_monitoring
)
AS
SELECT io.NAME, t.NAME, DECODE (BITAND (i.flags, 65536), 0, 'NO', 'YES'),
DECODE (BITAND (ou.flags, 1), 0, 'NO', 'YES'), ou.start_monitoring,
ou.end_monitoring
FROM SYS.obj$ io, SYS.obj$ t, SYS.ind$ i, SYS.object_usage ou
WHERE io.owner# = USERENV ('SCHEMAID')
AND i.obj# = ou.obj#
AND io.obj# = ou.obj#
AND t.obj# = i.bo#;

3.2）从该语句中发现，只有当前用户才可以查询到index的监控情况，即使sys也不能查看到
3.3）解决sys可以查询到index监控情况可以除掉io.owner# = USERENV (‘SCHEMAID’)即可

SELECT *
  FROM (SELECT USERNAME OWNER,
               IO.NAME INDEX_NAME,
               T.NAME TABLE_NAME,
               DECODE(BITAND(I.FLAGS, 65536), 0, 'NO', 'YES') MONITORING,
               DECODE(BITAND(OU.FLAGS, 1), 0, 'NO', 'YES') USED,
               OU.START_MONITORING START_MONITORING,
               OU.END_MONITORING END_MONITORING
          FROM SYS.OBJ$         IO,
               SYS.OBJ$         T,
               SYS.IND$         I,
               SYS.OBJECT_USAGE OU,
               DBA_USERS        U
         WHERE I.OBJ# = OU.OBJ#
           AND IO.OBJ# = OU.OBJ#
           AND T.OBJ# = I.BO#
           AND U.USER_ID = IO.OWNER#)
--USED='YES'--表示有使用
--USED='NO'--表示没使用
 WHERE USED = 'YES';

如果想查询方便，可以创建sys下面的下个视图
4、停止监控
ALTER INDEX owner.index_name NOMONITORING USAGE;

一、SCN类型
1).System Checkpoint SCN
当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。
我们可以通过下面SQL语句查询：
select checkpoint_change# from v$database;
2).Datafile Checkpoint SCN
当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件中.
我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN号。
select name,checkpoint_change# from v$datafile;
3).Start SCN (启动SCN)
checkpoint完成后，将产生的checkpoint SCN 写入数据文件头(称之为start scn).这个SCN用于检查数据库启动过程是否需要做media recovery.
我们可以通过以下SQL语句查询：
select name,checkpoint_change# from v$datafile_header;
注意：数据文件头中的检查点SCN(start SCN) 与控制文件中记录的数据文件检查点SCN号含义是一样的。 也就是说，一旦发生全局范围以及文件级别的检查点时，不仅会将这时的检查点SCN号记录到控制文件，还会记录在检查点作用的数据文件头部。
4).End SCN号(stop scn, 终止SCN)
这个SCN号用于检查数据库启动过程是否需要做instance recovery.
我们可以通过以下SQL语句查询：
select name,last_change# from v$datafile;
在正常的数据库操作过程中，所有正处于联机读写模式下的数据文件的终止scn都为null.
二、各SCN之间关系
1）数据库运行期间的scn值
在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.
2）数据库正常关闭的scn值
在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。
3）数据库重启过程中scn作用
在数据库重新启动的时候, Oracle将文件头中的那个启动scn与数据库文件检查点scn(控制文件中)进行比较，如果这两个值相互匹配，那么不需要Media Recovery， oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn, 如果这两个值也一致，就意味着所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作(即不需要实例恢复)，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。
还需要注意的是:
在数据库重新启动的时候, Oracle首先比较(每个)文件头中的那个启动scn (start SCN) 与控制文件中记录的 (每个) 数据库文件检查点scn， 如果他们都相互匹配，那么不需要Media Recovery. 但是如果只是控制文件中记录的数据文件检查点(多个数据文件，对应多个SCN), 与 (对应的) 数据文件头中的启动SCN (start scn) 相同 , 而在每个在线的可读可写的数据文件“之间”，他们的检查点SCN不相同， 那么也要求Media Recovery .

一、诡异dblink起源
今天开发拿过来一条sql，说有诡异现象，sql如下

INSERT INTO TAB_CS_CALLLOG
select c.user_logon,/*工号*/c.user_name,/*姓名*/a.call_id,/*通话id*/
      a.caller_nbr,/*主叫号码*/a.called_nbr,/*被叫号码*/d.start_time,/*呼入时间*/
      b.call_time,/*接听时间*/b.end_time,/*结束时间*/b.call_dura,/*时长*/
      to_number(b.call_time-d.start_time)*24*3600,/*等待时长*/
      decode(c.user_logon,null,0,1),/*类型*/
case
        when substr (a.CALLED_NBR,7, 2) = '00'
          then '广东移动'
        when substr (a.CALLED_NBR,7, 2) = '01'
          then '浙江移动'
        when substr (a.CALLED_NBR,7, 2) = '02'
          then '福建'
        when substr (a.CALLED_NBR,7, 2) = '03'
          then '四川'
        when substr (a.CALLED_NBR,7, 2) = '04'
          then '河南'
        when substr (a.CALLED_NBR,7, 2) = '05'
          then '湖北'
        when substr (a.CALLED_NBR,7, 2) = '06'
          then '北京CSIP'
        when substr (a.CALLED_NBR,7, 2) = '07'
          then '陕西'
        when substr (a.CALLED_NBR,7, 2) = '08'
          then '吉林'
        when substr (a.CALLED_NBR,7, 2) = '09'
          then '江西'
        when substr (a.CALLED_NBR,7, 2) = '10'
          then '宁夏'
        when substr (a.CALLED_NBR,7, 2) = '11'
          then '太原'
        when substr (a.CALLED_NBR,7, 2) = '12'
          then '江苏移动'
        when substr (a.CALLED_NBR,7, 2) = '13'
          then 'e掌管'
        when substr (a.CALLED_NBR,7, 2) = '15'
          then 'e多商'
        when substr (a.CALLED_NBR,7, 2) = '18'
          then '江苏联通'
      end 区域
from cscnew.a@cs a,cscnew.b@cs b,cscnew.c@cs c,cscnew.d@cs d
where a.call_serial=b.call_serial(+)
and b.call_serial=d.call_serial(+)
and b.user_id=c.user_id(+)
and substr(a.CALLED_NBR,1, 6) = '951654'
and  length (a.CALLED_NBR) = 15
and b.fail_reason is null
and a.end_time>=to_date('20110822000000','yyyymmddhh24miss')
and a.end_time<to_date('20110823000000','yyyymmddhh24miss');

然后我进行了测试，证实了她所说的诡异：
1、直接执行select语句需要1.7S左右，但是加上insert inot后，执行时间需要6分钟
2、直接select结果集为602条，加上insert into后，结果集为598条（少4条），如果直接执行select，除掉and b.fail_reason is null限制条件也刚好602条
二、查询相关资料，得到dblink的一些解释
1、dblink执行有两种方式，一种是在远处数据库执行完，然后结果返回，另一种是把远程的表下载到本来，然后执行
2、如果把远程的表下载到本地，空值或者null可能会发生变化（怀疑是空值转化为null，未证实）
三、根据这些解释，进行猜想
1、只执行select的时候，应该是在远程执行完，传输结果回来；而执行insert into的时候，是把远程的表全部下载到本地，然后执行出结果，而数据量本身比较大，所以比较慢
2、在把表从远程下载到本地的过程中，fail_reason 列的null值可以发生了变化，或者空值变为了null，所以数据多了4条
四、事实证明猜想
1、查询远程表大小，发现a表50m，b表400m，c表10m，d表100m左右，传输过来需要一定的时间
2、既然猜测是由于要把表传输到本地而导致这样的结果产生，那么处理方法就是让程序在远程计算出结果，然后传输到本地，查询了一些资料，上面说insert into会导致driving_site提示无效，那么我想到一个用视图的办法解决这个问题：在目标端建立一个关于本查询中无参数的视图，然后在本地通过dblink调用视图，这样总该先在远程执行出结果传输到本地了吧。
2.1）建立目标端视图

create or replace view v_tab
select c.user_logon,/*工号*/c.user_name,/*姓名*/a.call_id,/*通话id*/
      a.caller_nbr,/*主叫号码*/a.called_nbr,/*被叫号码*/d.start_time,/*呼入时间*/
      b.call_time,/*接听时间*/b.end_time,/*结束时间*/b.call_dura,/*时长*/
      to_number(b.call_time-d.start_time)*24*3600,/*等待时长*/
      decode(c.user_logon,null,0,1),/*类型*/
case
        when substr (a.CALLED_NBR,7, 2) = '00'
          then '广东移动'
        when substr (a.CALLED_NBR,7, 2) = '01'
          then '浙江移动'
        when substr (a.CALLED_NBR,7, 2) = '02'
          then '福建'
        when substr (a.CALLED_NBR,7, 2) = '03'
          then '四川'
        when substr (a.CALLED_NBR,7, 2) = '04'
          then '河南'
        when substr (a.CALLED_NBR,7, 2) = '05'
          then '湖北'
        when substr (a.CALLED_NBR,7, 2) = '06'
          then '北京CSIP'
        when substr (a.CALLED_NBR,7, 2) = '07'
          then '陕西'
        when substr (a.CALLED_NBR,7, 2) = '08'
          then '吉林'
        when substr (a.CALLED_NBR,7, 2) = '09'
          then '江西'
        when substr (a.CALLED_NBR,7, 2) = '10'
          then '宁夏'
        when substr (a.CALLED_NBR,7, 2) = '11'
          then '太原'
        when substr (a.CALLED_NBR,7, 2) = '12'
          then '江苏移动'
        when substr (a.CALLED_NBR,7, 2) = '13'
          then 'e掌管'
        when substr (a.CALLED_NBR,7, 2) = '15'
          then 'e多商'
        when substr (a.CALLED_NBR,7, 2) = '18'
          then '江苏联通'
      end 区域
from cscnew.a a,cscnew.b b,cscnew.c c,cscnew.d d
where a.call_serial=b.call_serial(+)
and b.call_serial=d.call_serial(+)
and b.user_id=c.user_id(+)
and substr(a.CALLED_NBR,1, 6) = '951654'
and  length (a.CALLED_NBR) = 15
and b.fail_reason is null

2.2）本地调用远程视图

INSERT INTO TAB_CS_CALLLOG
select * from v_tab@cs a where
a.end_time>=to_date('20110822000000','yyyymmddhh24miss')
and a.end_time<to_date('20110823000000','yyyymmddhh24miss');

2.3）执行结果2.3S完成数据插入，而且条数也是598条，证明我的猜想是正确的，更重要的是解决了今天这个让人疑惑的问题

1、建立
1.1）emd_maintenance包
exec sysman.emd_maintenance.submit_em_dbms_jobs;
commit;
1.2）创建job

DECLARE
  X NUMBER;
BEGIN
  SYS.DBMS_JOB.SUBMIT
  ( job       => X
   ,what      => 'EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();'
   ,next_date => to_date('18/08/2011 21:59:17','dd/mm/yyyy hh24:mi:ss')
   ,interval  => 'SYSDATE + 1 / (24 * 60)'
   ,no_parse  => FALSE
  );
  SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x));
COMMIT;
END;

2、停止和启动
2.1）停止
EXEC DBMS_JOB.BROKEN(job#,TRUE);
commit;
2.2）启用
EXEC DBMS_JOB.BROKEN(job#,FALSE);
commit;
3、删除
2.1）emd_maintenance包
exec sysman.emd_maintenance.remove_em_dbms_jobs;
commit;
3.2）删除job
dbms_job.remove(job#);
commit;
注：因为EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS是sysman用户下面用于收集em相关信息，如果要进行操作，最好使用sysman用户进行