[20141203]分析语句导致阻塞分析表.txt

[20141203]分析语句导致阻塞分析表,分析表导致阻塞sql语句执行分析.txt

--我们知道如果语句连接的表很多,会消耗大量的CPU资源。
http://blog.itpub.net/267265/viewspace-1298186/

--分析sql语句还会导致什么问题呢?昨天看了一篇bloghttp://www.bobbydurrettdba.com/2014/11/24/parsing-blocks-stats-blocks-parsing/,
--重复测试看看。

SCOTT@test> @ver1

PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

--可以下载作者的sql脚本:
1.建立表:
drop table t1 purge;
drop table t2 purge;
create table t1 as select * from dba_tables;
create table t2 as select * from dba_tables;

2.打开3个会话:
--session 1执行如下:
set linesize 1000
set pagesize 1000
set echo on
set termout on

spool chain1.log

set timing on

-- explain plan on query that takes a long time to parse

-- try joining a bunch of tables together so it takes
-- a long time to try all the join orders
-- only two real tables

explain plan into plan_table for
select
count(*)
from
     t1,
     t2,
     t2 t3,
     t2 t4,
     t2 t5,
     t2 t6,
     t2 t7,
     t2 t8,
     t2 t9,
     t2 t10,
     t2 t11,
     t2 t12,
     t2 t13,
     t2 t14,
     t2 t15,
     t2 t16,
     t2 t17,
     t2 t18,
     t2 t19,
     t2 t20,
     t2 t21,
     t2 t22,
     t2 t23,
     t2 t24,
     t2 t25,
     t2 t26,
     t2 t27,
     t2 t28,
     t2 t29,
     t2 t30,
     t2 t31,
     t2 t32,
     t2 t33,
     t2 t34,
     t2 t35,
     t2 t36,
     t2 t37,
     t2 t38,
     t2 t39,
     t2 t40,
     t2 t41,
     t2 t42,
     t2 t43,
     t2 t44,
     t2 t45,
     t2 t46,
     t2 t47,
     t2 t48,
     t2 t49,
     t2 t50,
     t2 t51,
     t2 t52,
     t2 t53,
     t2 t54,
     t2 t55,
     t2 t56,
     t2 t57,
     t2 t58,
     t2 t59,
     t2 t60,
     t2 t61,
     t2 t62,
     t2 t63,
     t2 t64,
     t2 t65,
     t2 t66,
     t2 t67,
     t2 t68,
     t2 t69,
     t2 t70,
     t2 t71,
     t2 t72,
     t2 t73,
     t2 t74,
     t2 t75,
     t2 t76,
     t2 t77,
     t2 t78,
     t2 t79,
     t2 t80,
     t2 t81,
     t2 t82,
     t2 t83,
     t2 t84,
     t2 t85,
     t2 t86,
     t2 t87,
     t2 t88,
     t2 t89,
     t2 t90,
     t2 t91,
     t2 t92,
     t2 t93,
     t2 t94,
     t2 t95,
     t2 t96,
     t2 t97,
     t2 t98,
     t2 t99,
     t2 t100
where
  t1.owner=t2.owner and
  t1.owner=t3.owner and
  t1.owner=t4.owner and
  t1.owner=t5.owner and
  t1.owner=t6.owner and
  t1.owner=t7.owner and
  t1.owner=t8.owner and
  t1.owner=t9.owner and
  t1.owner=t10.owner and
  t1.owner=t11.owner and
  t1.owner=t12.owner and
  t1.owner=t13.owner and
  t1.owner=t14.owner and
  t1.owner=t15.owner and
  t1.owner=t16.owner and
  t1.owner=t17.owner and
  t1.owner=t18.owner and
  t1.owner=t19.owner and
  t1.owner=t20.owner and
  t1.owner=t21.owner and
  t1.owner=t22.owner and
  t1.owner=t23.owner and
  t1.owner=t24.owner and
  t1.owner=t25.owner and
  t1.owner=t26.owner and
  t1.owner=t27.owner and
  t1.owner=t28.owner and
  t1.owner=t29.owner and
  t1.owner=t30.owner and
  t1.owner=t31.owner and
  t1.owner=t32.owner and
  t1.owner=t33.owner and
  t1.owner=t34.owner and
  t1.owner=t35.owner and
  t1.owner=t36.owner and
  t1.owner=t37.owner and
  t1.owner=t38.owner and
  t1.owner=t39.owner and
  t1.owner=t40.owner and
  t1.owner=t41.owner and
  t1.owner=t42.owner and
  t1.owner=t43.owner and
  t1.owner=t44.owner and
  t1.owner=t45.owner and
  t1.owner=t46.owner and
  t1.owner=t47.owner and
  t1.owner=t48.owner and
  t1.owner=t49.owner and
  t1.owner=t50.owner and
  t1.owner=t51.owner and
  t1.owner=t52.owner and
  t1.owner=t53.owner and
  t1.owner=t54.owner and
  t1.owner=t55.owner and
  t1.owner=t56.owner and
  t1.owner=t57.owner and
  t1.owner=t58.owner and
  t1.owner=t59.owner and
  t1.owner=t60.owner and
  t1.owner=t61.owner and
  t1.owner=t62.owner and
  t1.owner=t63.owner and
  t1.owner=t64.owner and
  t1.owner=t65.owner and
  t1.owner=t66.owner and
  t1.owner=t67.owner and
  t1.owner=t68.owner and
  t1.owner=t69.owner and
  t1.owner=t70.owner and
  t1.owner=t71.owner and
  t1.owner=t72.owner and
  t1.owner=t73.owner and
  t1.owner=t74.owner and
  t1.owner=t75.owner and
  t1.owner=t76.owner and
  t1.owner=t77.owner and
  t1.owner=t78.owner and
  t1.owner=t79.owner and
  t1.owner=t80.owner and
  t1.owner=t81.owner and
  t1.owner=t82.owner and
  t1.owner=t83.owner and
  t1.owner=t84.owner and
  t1.owner=t85.owner and
  t1.owner=t86.owner and
  t1.owner=t87.owner and
  t1.owner=t88.owner and
  t1.owner=t89.owner and
  t1.owner=t90.owner and
  t1.owner=t91.owner and
  t1.owner=t92.owner and
  t1.owner=t93.owner and
  t1.owner=t94.owner and
  t1.owner=t95.owner and
  t1.owner=t96.owner and
  t1.owner=t97.owner and
  t1.owner=t98.owner and
  t1.owner=t99.owner and
  t1.owner=t100.owner
/

VARIABLE monitored_sid number;

begin

SELECT sid into :monitored_sid from v$session where audsid=USERENV('SESSIONID');

end;
/

-- cpu usage in seconds

SELECT VALUE/100 "CPU in seconds"
FROM V$SESSION a, V$SESSTAT b
where a.SID = b.SID
and a.SID = :monitored_sid
and b.STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session');

spool off
exit

--session 2执行如下:
set linesize 1000
set pagesize 1000
set echo on
set termout on

spool chain2.log

set timing on

execute dbms_stats.gather_table_stats(NULL,'T1');

VARIABLE monitored_sid number;

begin

SELECT sid into :monitored_sid from v$session where audsid=USERENV('SESSIONID');

end;
/

-- show library cache lock wait time in seconds

SELECT TIME_WAITED/100 "Library cache lock in seconds"
FROM V$SESSION_EVENT a, V$SESSION b
WHERE
a.SID = b.SID and
a.SID= :monitored_sid and
a.event='library cache lock';

spool off

--session 3执行如下:
set linesize 1000
set pagesize 1000
set echo on
set termout on

spool chain3.log

set timing on

select /* comment to force hard parse */ count(*) from T1;

VARIABLE monitored_sid number;

begin

SELECT sid into :monitored_sid from v$session where audsid=USERENV('SESSIONID');

end;
/

-- show library cache lock wait time in seconds

SELECT TIME_WAITED/100 "Library cache lock in seconds"
FROM V$SESSION_EVENT a, V$SESSION b
WHERE
a.SID = b.SID and
a.SID= :monitored_sid and
a.event='library cache lock';

spool off

2.测试1:

--如果在session1 单独执行分区语句:

Elapsed: 00:00:43.78 

SCOTT@40> SELECT VALUE/100 "CPU in seconds"
  2  FROM V$SESSION a, V$SESSTAT b
  3  where a.SID = b.SID
  4  and a.SID = :monitored_sid
  5  and b.STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session');
CPU in seconds
--------------
         43.63

--可以发现主要消耗在'CPU used by this session'.

3.测试2:
--在session1 和session 2执行脚本,session1先执行,马上切换到session2执行。
--session1 结果如下:
Elapsed: 00:00:44.96
SCOTT@40> SELECT VALUE/100 "CPU in seconds"
  2  FROM V$SESSION a, V$SESSTAT b
  3  where a.SID = b.SID
  4  and a.SID = :monitored_sid
  5  and b.STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session');
CPU in seconds
--------------
         44.97

--session2 结果如下:
SCOTT@40> SELECT TIME_WAITED/100 "Library cache lock in seconds"
  2  FROM V$SESSION_EVENT a, V$SESSION b
  3  WHERE
  4  a.SID = b.SID and
  5  a.SID= :monitored_sid and
  6  a.event='library cache lock';
Library cache lock in seconds
-----------------------------
                        40.53

--可以发现session1的分析sql语句阻塞了session2的分析表,导致session 2大量的时间花在'library cache lock'。
--必须等待session1 完成分析,session2才能获取library cache lock,完成分析表的过程。

4.测试3:
--在session1 和session 3执行脚本,session1先执行,马上切换到session3执行。
--session1 结果如下:
Elapsed: 00:00:44.58
SCOTT@40> SELECT VALUE/100 "CPU in seconds"
  2  FROM V$SESSION a, V$SESSTAT b
  3  where a.SID = b.SID
  4  and a.SID = :monitored_sid
  5  and b.STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session');
CPU in seconds
--------------
         44.56

--session3 结果如下:
Elapsed: 00:00:00.18

--可以发现session 3马上执行完成。也就是讲分析sql语句并不会阻塞其他相关sql语句的执行。

5.测试4:
--在session1 ,session2和session 3执行脚本,session1先执行,再执行session2 ,再session3执行。
--session1 结果如下:
Elapsed: 00:00:42.91
SCOTT@40> SELECT VALUE/100 "CPU in seconds"
  2  FROM V$SESSION a, V$SESSTAT b
  3  where a.SID = b.SID
  4  and a.SID = :monitored_sid
  5  and b.STATISTIC# = (SELECT STATISTIC# FROM V$STATNAME WHERE NAME='CPU used by this session');
CPU in seconds
--------------
         42.98
        
--session2 结果如下:
Elapsed: 00:00:38.33
SCOTT@40> SELECT TIME_WAITED/100 "Library cache lock in seconds"
  2  FROM V$SESSION_EVENT a, V$SESSION b
  3  WHERE
  4  a.SID = b.SID and
  5  a.SID= :monitored_sid and
  6  a.event='library cache lock';
Library cache lock in seconds
-----------------------------
                        37.01

--session3 结果如下:
Elapsed: 00:00:30.01
SCOTT@40> SELECT TIME_WAITED/100 "Library cache lock in seconds"
  2  FROM V$SESSION_EVENT a, V$SESSION b
  3  WHERE
  4  a.SID = b.SID and
  5  a.SID= :monitored_sid and
  6  a.event='library cache lock';
Library cache lock in seconds
-----------------------------
                        30.01

                       
--可以发现session1的分析sql语句阻塞了session2的分析表,导致session 2大量的时间花在'library cache lock'。
--而session2分析表要获取'library cache lock',导致session3 的sql语句也出现'library cache lock'。

当然在实际上这种情况在实际的生产系统很难遇到。不过还是要特别注意复杂sql导致的分析时间太长的问题。
另外也学习一个判断分析sql的方法,explain plan,虽然可能执行计划不可信。

$cat a.sql
explain plan for SELECT   f.constraint_name, f.owner, f.r_owner, p.table_name, SYS.all_cons_columns.column_name, f.delete_rule
    FROM SYS.all_constraints f, SYS.all_cons_columns, SYS.all_constraints p
   WHERE f.owner = 'SCOTT'
     AND f.table_name = 'EMP'
     AND f.constraint_type = 'R'
     AND SYS.all_cons_columns.constraint_name = f.constraint_name
     AND SYS.all_cons_columns.table_name = 'EMP'
     AND SYS.all_cons_columns.owner = 'SCOTT'
     AND p.owner = f.r_owner
     AND p.constraint_name = f.r_constraint_name
ORDER BY f.constraint_name, SYS.all_cons_columns.POSITION;

SCOTT@test> set timing on
SCOTT@test> @a
Explained.
Elapsed: 00:00:03.83

SCOTT@test> @a
Explained.
Elapsed: 00:00:03.81

SCOTT@test> @a
Explained.
Elapsed: 00:00:03.87

--每次都是3.XX秒。

$cat b.sql
explain plan for SELECT  /*+ OPTIMIZER_FEATURES_ENABLE('8.0.4') */  f.constraint_name, f.owner, f.r_owner, p.table_name, SYS.all_cons_columns.column_name, f.delete_rule
    FROM SYS.all_constraints f, SYS.all_cons_columns, SYS.all_constraints p
   WHERE f.owner = 'SCOTT'
     AND f.table_name = 'EMP'
     AND f.constraint_type = 'R'
     AND SYS.all_cons_columns.constraint_name = f.constraint_name
     AND SYS.all_cons_columns.table_name = 'EMP'
     AND SYS.all_cons_columns.owner = 'SCOTT'
     AND p.owner = f.r_owner
     AND p.constraint_name = f.r_constraint_name
ORDER BY f.constraint_name, SYS.all_cons_columns.POSITION;

SCOTT@test> set timing on
SCOTT@test> @b
Explained.
Elapsed: 00:00:00.27

SCOTT@test> @b
Explained.
Elapsed: 00:00:00.25

SCOTT@test> @b
Explained.
Elapsed: 00:00:00.26

--可以发现加入提示后很快。仅仅0.2X秒。

时间: 2024-11-05 22:35:00

[20141203]分析语句导致阻塞分析表.txt的相关文章

一条insert语句导致的性能问题分析(二)

今天对之前描述的问题一条insert语句导致的性能问题分析(一) 进行了进一步的补充. 有一条insert语句的主要性能瓶颈在于insert子句中的查询语句,查询中的主要资源消耗在于对两个表进行了多次关联 语句主要的结构如下: insert into xxxxx   (select * from TEST_vip_new minus select * from TEST_vip_new_bak         ) a left join TEST_vip_new_bak b         on

一条sql语句导致的数据库宕机问题及分析

之前分享过一篇博文,是一条sql语句"导致"的数据库宕机,上次是另有原因,这次真碰到一个案例,而且是在重要的环境上,希望大家引以为戒. 数据库是基于Linux64的版本,版本是11.2.0.2.0,已经打了最新的psu. 数据库的访问用户数大约在1000左右,当时查看服务器的cpu已经是100%了,有大约10个进程都是cpu 100%,数据库逻辑读也是超高,一秒钟大约是接近百兆的情况,sga是12G,已用了sga的自动管理(sga_target=0), 查看内存组件时发现buffer_

系统无法找到AWStats分析日志后写分析文件的目录导致的问题

'DirData' parameter (./data) does not exist问题的解决 [root@localhost cgi-bin]#./awstats.pl -update -config=123 Error: AWStats database directory defined in config file by 'DirData' parameter (./data) does not exist or is not writable. Check config file,

MySQL使用profile分析语句性能消耗

MySQL使用profile分析语句性能消耗 --查看profile是否开启mysql> show variables like '%profil%';+------------------------+-------+| Variable_name          | Value |+------------------------+-------+| profiling              | OFF   |         --开启SQL语句剖析功能                

一条简单的sql语句导致的系统问题

新年,给大家拜年了.祝大家工作顺利,万事如意. 今天照例简单检查了系统的情况,发现在客户的服务器在下午的3-5点这个时间段,数据库负载略有上升,但是幅度不大,因为生产的awr抓取频率是10分钟,所以还是能够通过awr分析出一些问题. 负载情况如下: 抓取了一个最新时间段的awr报告. 查看数据库负载,比平时的负载要高一些. Host Name Platform CPUs Cores Sockets Memory (GB) xxxxx Linux x86 64-bit 80 40 4 346.22

SQL语句判断已知表是否存在

  怎样用SQL语句来判断已知表是否存在 答:具体解决方法如下: 注释:以下代码为通常的引用Dao做的一模块 Function fExistTable(strTableName As String) As Integer Dim db As Database Dim i As Integer Set db = DBEngine.Workspaces(0).Databases(0) fExistTable = False db.TableDefs.Refresh For i = 0 To db.T

蓝屏dump分析教程 使用WinDbg分析工具

  一.WinDbg是什么?它能做什么? WinDbg是在windows平台下,强大的用户态和内核态调试工具.它能够通过dmp文件轻松的定位到问题根源,可用于分析蓝屏.程序崩溃(IE崩溃)原因,是我们日常工作中必不可少的一个有力工具,学会使用它,将有效提升我们的问题解决效率和准确率. 三.设置符号表: 符号表是WinDbg关键的"数据库",如果没有它,WinDbg基本上就是个废物,无法分析出更多问题原因.所以使用WinDbg设置符号表,是必须要走的一步. 1.运行WinDbg软件,然后

merge语句导致的CPU使用率过高的优化(二)

之前分享过一篇关于merge语句导致的CPU使用率过高优化的案例.的http://blog.itpub.net/23718752/viewspace-1819471/ 后续的跟进没有补充,也"秀"一张图,红色的火焰是原来的系统负载,右边的部分是最近的逻辑读情况,不过惭愧的是,这个不是优化的效果,因为应用的高峰期已经处理完了,后面的sql调用频率极低,所以感觉不到任何的压力.所以通过这个图也可以看出,给一张差别巨大的图也不一定是系统优化的效果,也可能是其它外在因素. 那么既然要说跟进,后

Oracle批量执行sql语句之禁用所有表的外键_oracle

在转移数据库,进行数据导入的时候,遇到一件麻烦事,就是表间外键约束的存在,导致insert频频报错,批量执行sql语句又是顺序执行,没办法我只好手动输入. 然后输入到一半灵光一闪,为什么不先把外键约束全部禁用先呢? 于是我百度到以下资料: oracle 删除(所有)约束 禁用(所有)约束 启用(所有)约束 执行以下sql生成的语句即可 1删除所有外键约束 select 'alter table '||table_name||' drop constraint '||constraint_name