weblogic连接池配置_weblogic连接scan ip_weblogic长连接(4)

上面的结果是5秒左右的会话采样数据。再一次提醒，涉及到时间，特别要精确到毫秒的，不一定很精确，我们主要是看数据之间的对比。从上面的数据来看，会话请求了382次IO请求，单块读和多块读一共耗时4219.17ms（4.17s+49.17ms），平均每次IO耗时11ms。这个单次IO速度对这套系统的要求来说相对较慢，但也不是慢得很离谱。weblogic连接scan ipdata blocks consistent reads - undo records applied这个统计值表示进行一致性读时，回滚的UNDO记录条数。

比这个统计值可以很明显地看出，这条SQL在执行时，为了得到一致性读，产生了大量的UNDO记录回滚。那么很显然，在这条SQL语句开始执行的时候，表上有很大的事务还没有提交。当然还有另一种可能是SQL在执行之后有新的很大的事务（不过这种可能性较小一些，因为那样的话这条SQL可能比较快就执行完了）。询问发测试的人员，称没有什么大事务运行过，耳听为虚，眼见为实：

SQL> select object_id from dba_objects where object_name='MOBILE_CALL_1204_OLD';

 OECT_ID
----------
     75858

SQL> select * from v$lock where id1=75858;

no rows selected

SQL> select * from dba_tab_modifications where table_name=upper('MOBILE_call_1204_OLD');

   INSERTS    UPDATES    DELETES TIMESTAMP           TRU DROP_SEGMENTS
---------- ---------- ---------- ------------------- --- -------------
         0  162696447          0 2012-05-21 22:00:02 NO              0

这张表目前没有事务，但是曾经update了超过1.6亿条记录。最后一次DML的时间正是这条执行很慢的SQL开始运行之后的时间（这里不能说明最后一次事务量很大，也不能说明最后一次修改对SQL造成了很大影响，但是这里证明了这张表最近的确是修改过，并不是像测试人员说的那样没有修改过）。

实际上对于这张表要做的操作，我之前是类似的表上是有看过的。这张表的总行数有上亿条，而这张表由于进行数据的人工处理，需要update掉绝大部分的行，update时使用并行处理。那么这个问题到，从时间顺序上来讲，应该如下：

在表上有很大的事务，但是还没有提交。

问题SQL开始执行查询。

事务提交。

在检查SQL性能问题时，表上已经没有事务。

由于update量很大，那么UNDO占用的空间也很大，但是可能由于其他活动的影响，很多UNDO块已经刷出内存，这样在问题SQL执行时，大量的块需要将块回滚到之前的状态（虽然事务开始于查询SQL，但是是在查询SQL开始之后才提交的，一致性读的SCN比较是根据SQL开始的SCN与事务提交SCN比较的，而不是跟事务的开始SCN比较），这样需要访问到大量的UNDO块，但是UNDO块很多已经不在内存中，就不得不从磁盘读入。

对于大事务，特别是更新或DELETE数千万记录的大事务，在生产系统上尽量避免单条SQL一次性做。这造成的影响特别大，比如：

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-30053-4.html