一个简单的解决sql慢的过程。。。

最新推荐文章于 2024-05-20 23:56:18 发布
最新推荐文章于 2024-05-20 23:56:18 发布
阅读量116 收藏
点赞数
今天从statspack发现bw开发服务器上有个语句很慢，打了个trace发现每个表都实际返回很多行，挺奇怪的，因为开发机器上，测试数据几乎很少，目前刚建立，查找后发现，只是因为有一个表，原来的数据为空，开发人员导入数据后没对表进行分析造成的，过程如下。
1、语句如下： 
SELECT /*+ STAR_TRANSFORMATION FACT( T_00 )  */
 T_07."SID_0BASE_UOM" "S____163",
 T_02."S__0P_PLANT" "S____524",
 T_03."SID_0CALMONTH2" "S____372",
 T_03."SID_0CALYEAR" "S____016",
 COUNT(*) "1ROWCOUNT",
 SUM(T_00."/BIC/Z1CL") "Z1CL"
  FROM "/BIC/EZ1PP_C01"  T_00,
       "/BIC/DZ1PP_C011" T_01,
       "/BI0/XSTOR_LOC"  T_02,
       "/BIC/DZ1PP_C01T" T_03,
       "/BI0/XMATERIAL"  T_04,
       "/BIC/SZ1PZ"      T_05,
       "/BIC/DZ1PP_C01P" T_06,
       "/BIC/DZ1PP_C01U" T_07
 WHERE (T_00."KEY_Z1PP_C011" = T_01."DIMID")
   AND (T_01."SID_0STOR_LOC" = T_02."SID")
   AND (T_00."KEY_Z1PP_C01T" = T_03."DIMID")
   AND (T_00."KEY_Z1PP_C013" = T_04."SID")
   AND (T_04."S__Z1PZ" = T_05."SID")
   AND (T_00."KEY_Z1PP_C01P" = T_06."DIMID")
   AND (T_00."KEY_Z1PP_C01U" = T_07."DIMID")
   AND T_05."/BIC/Z1PZ" BETWEEN '30' AND '37'
   AND T_06."SID_0RECORDTP" = 0
   AND T_06."SID_0REQUID"
2、trace的结果： 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.02       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      3.91       3.87        577     657265          0          20
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      3.93       3.90        577     657265          0          20

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 22  

Rows     Row Source Operation
-------  ---------------------------------------------------
     20  SORT GROUP BY (cr=657265 r=577 w=0 time=3873966 us)
  15818   NESTED LOOPS  (cr=657265 r=577 w=0 time=3841369 us)
  31329    NESTED LOOPS  (cr=625934 r=577 w=0 time=3648891 us)
  31329     NESTED LOOPS  (cr=531945 r=577 w=0 time=3373027 us)
 106271      NESTED LOOPS  (cr=425672 r=577 w=0 time=2670467 us)
 106271       NESTED LOOPS  (cr=319399 r=576 w=0 time=2005590 us)
 106271        NESTED LOOPS  (cr=213126 r=576 w=0 time=1397401 us)
 106271         NESTED LOOPS  (cr=106853 r=576 w=0 time=738057 us)
 106271          TABLE ACCESS FULL /BIC/EZ1PP_C01 (cr=580 r=576 w=0 time=133818 us)
 106271          TABLE ACCESS BY INDEX ROWID /BIC/DZ1PP_C01U (cr=106273 r=0 w=0 
		     time=429803 us)
 106271           INDEX UNIQUE SCAN /BIC/DZ1PP_C01U~0 (cr=2 r=0 w=0 time=122681 us)
		    (object id 77024)
 106271         TABLE ACCESS BY INDEX ROWID /BIC/DZ1PP_C01P (cr=106273 r=0 w=0 
		   time=476292 us)
 106271          INDEX UNIQUE SCAN /BIC/DZ1PP_C01P~0 (cr=2 r=0 w=0 time=117356 us)
		  (object id 77018)
 106271        TABLE ACCESS BY INDEX ROWID /BIC/DZ1PP_C011 (cr=106273 r=0 w=0 
		 time=435359 us)
 106271         INDEX UNIQUE SCAN /BIC/DZ1PP_C011~0 (cr=2 r=0 w=0 time=123499 us)
		  (object id 77006)
 106271       TABLE ACCESS BY INDEX ROWID /BI0/XSTOR_LOC (cr=106273 r=1 w=0 
		 time=467451 us)
 106271        INDEX UNIQUE SCAN /BI0/XSTOR_LOC~0 (cr=2 r=0 w=0 time=138641 us)
		 (object id 70503)
  31329      TABLE ACCESS BY INDEX ROWID /BIC/DZ1PP_C01T (cr=106273 r=0 w=0 
		time=558104 us)
 106271       INDEX UNIQUE SCAN /BIC/DZ1PP_C01T~0 (cr=2 r=0 w=0 time=141684 us)
		(object id 77021)
  31329     TABLE ACCESS BY INDEX ROWID /BI0/XMATERIAL (cr=93989 r=0 w=0
		 time=216730 us)
  31329      INDEX UNIQUE SCAN /BI0/XMATERIAL~0 (cr=62660 r=0 w=0 time=113759 us)
		(object id 75574)
  15818    TABLE ACCESS BY INDEX ROWID /BIC/SZ1PZ (cr=31331 r=0 w=0 time=139109 us)
  31329     INDEX UNIQUE SCAN /BIC/SZ1PZ~001 (cr=2 r=0 w=0 time=39654 us)
		(object id 53555)
3、查询表相关信息： 
TABLE_NAME                       NUM_ROWS LAST_ANAL     BLOCKS
------------------------------ ---------- --------- ----------
/BI0/XMATERIAL                     202031 18-OCT-06       2702
/BI0/XSTOR_LOC                        456 18-OCT-06          2
/BIC/DZ1PP_C011                        34 18-OCT-06          1
/BIC/DZ1PP_C01P                         2 18-OCT-06          1
/BIC/DZ1PP_C01T                       559 18-OCT-06          3
/BIC/DZ1PP_C01U                         2 18-OCT-06          1
/BIC/EZ1PP_C01                          0 18-OCT-06          1
/BIC/SZ1PZ                             57 18-OCT-06          1
4、查询表实际数据，发现/BIC/EZ1PP_C01 表，实际数据发生明显变化： 
SQL>
select '/BIC/EZ1PP_C01' table_name,count(*) from "/BIC/EZ1PP_C01"  T_00 union
select '/BIC/DZ1PP_C011',count(*) from "/BIC/DZ1PP_C011" T_01 union
select '/BI0/XSTOR_LOC' ,count(*) from "/BI0/XSTOR_LOC"  T_02 union
select '/BIC/DZ1PP_C01T',count(*) from "/BIC/DZ1PP_C01T" T_03 union
select '/BI0/XMATERIAL',count(*) from "/BI0/XMATERIAL"  T_04 union
select '/BIC/SZ1PZ',count(*) from "/BIC/SZ1PZ"      T_05 union
select '/BIC/DZ1PP_C01P',count(*) from "/BIC/DZ1PP_C01P" T_06 union
select '/BIC/DZ1PP_C01U',count(*) from "/BIC/DZ1PP_C01U";   

TABLE_NAME        COUNT(*)
--------------- ----------
/BI0/XMATERIAL      202038
/BI0/XSTOR_LOC         463
/BIC/DZ1PP_C011         34
/BIC/DZ1PP_C01P          1
/BIC/DZ1PP_C01T        559
/BIC/DZ1PP_C01U          2
/BIC/EZ1PP_C01      106271
/BIC/SZ1PZ              57
5、对/BIC/EZ1PP_C01 表收集信息： 
SQL> exec dbms_stats.gather_table_stats(user,'/BIC/EZ1PP_C01',cascade=>true);

PL/SQL procedure successfully completed.
6、重新打一个trace发现，语句不再很慢： 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.08       0.06          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        3      0.86       1.25       2113       3308          0          20
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      0.94       1.32       2113       3308          0          20

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 22  

Rows     Row Source Operation
-------  ---------------------------------------------------
     20  SORT GROUP BY (cr=3308 r=2113 w=0 time=1254067 us)
  15818   HASH JOIN  (cr=3308 r=2113 w=0 time=1223458 us)
    463    TABLE ACCESS FULL /BI0/XSTOR_LOC (cr=4 r=2 w=0 time=8125 us)
  15818    HASH JOIN  (cr=3304 r=2111 w=0 time=1195118 us)
    151     TABLE ACCESS FULL /BIC/DZ1PP_C01T (cr=5 r=1 w=0 time=2245 us)
  56813     HASH JOIN  (cr=3299 r=2110 w=0 time=1145395 us)
     34      TABLE ACCESS FULL /BIC/DZ1PP_C011 (cr=3 r=1 w=0 time=11102 us)
  56813      HASH JOIN  (cr=3296 r=2109 w=0 time=1066244 us)
      2       TABLE ACCESS FULL /BIC/DZ1PP_C01U (cr=3 r=0 w=0 time=28 us)
  56813       HASH JOIN  (cr=3293 r=2109 w=0 time=1003396 us)
      1        TABLE ACCESS FULL /BIC/DZ1PP_C01P (cr=3 r=0 w=0 time=23 us)
  56813        HASH JOIN  (cr=3290 r=2109 w=0 time=941190 us)
  24135         HASH JOIN  (cr=2710 r=2109 w=0 time=747362 us)
      8          TABLE ACCESS BY INDEX ROWID /BIC/SZ1PZ (cr=2 r=0 w=0 time=60 us)
      8           INDEX RANGE SCAN /BIC/SZ1PZ~0 (cr=1 r=0 w=0 time=33 us)
	          (object id 53554)
 202038          TABLE ACCESS FULL /BI0/XMATERIAL (cr=2708 r=2109 w=0 
		 time=612287 us)
 106271         TABLE ACCESS FULL /BIC/EZ1PP_C01 (cr=580 r=0 w=0 time=59987 us)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25702/viewspace-464273/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25702/viewspace-464273/

congshanlan2358
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
SQL server服务显示远程过程调用失败的解决方法
12-15
刚刚打开SQL Server 2008，想要新建一个数据库，却发现出现了一个问题，这个问题由于之前没有遇到过，所以下面整理解决SQL server服务远程调用失败的几个方法，供大家参考，具体内容如下 先看看出现的问题： 出现...
Sql存储过程游标循环的用法及sql如何使用cursor写一个简单的循环
09-10
以下是一个简单的例子： ```sql DECLARE @A1 VARCHAR(10), @A2 VARCHAR(10), @A3 INT; DECLARE CURSOR YOUCURNAME FOR SELECT A1, A2, A3 FROM YOUTABLENAME; OPEN YOUCURNAME; FETCH NEXT FROM YOUCURNAME INTO...
慢SQL解决方案
wu_noah的博客
11-28 5620
1. 背景 慢SQL是稳定性中重要的一部分，一般指查询时间超过1s或扫描行数百万的SQL操作，可以通过show variables like 'long_query_time'查看。对于交易这类对稳定性要求很高的业务来说治理慢SQL格外重要。这里总结下交易中不同业务存在的慢SQL问题，以及一些通用的解决方案 慢SQL发现方式有：SRS慢SQL治理平台、CloudDBA慢SQL日志、交易慢SQL报表（离线表cda_sql.das_slowsql_detail_aligroup） 2. 危害 响应时
慢sql的解决思路
pige666的博客
01-10 456
需要发散下思维，往架构方向思考。
7个常见的SQL慢查询问题及其解决方法
最新发布
csdn1561168266的博客
05-20 1388
大家好，得益于摩尔定律，计算机性能已大幅提升，加上数据库的进步以及微服务所倡导的各种反模式设计，因此现在编写复杂SQL查询的机会越来越少。业界已经开始提倡不要进行专门的SQL优化，因为节省下来的资源并不足以抵消员工的工资成本。本文将介绍7个常见的SQL慢查询语句，并解释如何优化它们的性能。
遇见慢sql怎么办？
weixin_41888013的博客
02-24 173
如何解决慢sql
[干货] 如何解决慢SQL？详细分析和优化实践！
DevCorner的Pro技术博客
06-10 4318
简单来说，慢SQL指的是执行时间较长的SQL语句。在数据库中，一个查询的运行时间往往会受到多种因素的影响，例如表结构、数据量和索引等。如果一条SQL语句的执行时间较长，就会降低数据库的整体性能和用户体验。因此，我们需要对慢SQL进行分析和优化，使得这些语句能够更快地执行并节省资源。慢SQL的优化是一个持续不断的过程，并没有最佳结果，需要不断借助工具进行监控分析、针对实际情况进行调整。
清除sqlserver无效的视图及存储过程
01-05
以下是一个简单的示例，用于查找未使用的存储过程： ```sql SELECT o.name FROM sys.objects o WHERE o.type = 'P' -- 查找存储过程 AND NOT EXISTS (SELECT 1 FROM sys.dm_sql_referencing_entities(o.object_id, ...
ahwen：一个简单SQL数据库
02-06
`ahwen` 是一个轻量级的、用Kotlin语言编写的简单SQL数据库解决方案。它旨在为小型应用或快速原型开发提供方便的数据存储功能，尤其适合那些对关系型数据库有基本需求但又不想引入大型ORM框架的项目。`ahwen` 的设计...
SQL Server存储过程在C#中调用的简单实现方法
08-19
例如，创建一个名为`sp_Transfer`的存储过程，接受两个输入参数`@fromAcc`和`@toAcc`，以及一个输出参数`@result`表示转账结果： ```sql CREATE PROCEDURE sp_Transfer @fromAcc INT, @toAcc INT, @result BIT...
SQL语句查询速度慢的48个原因
06-02
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足
SQL响应慢如何分析解决
Zichen_Lin的博客
10-16 800
创建自定义函数之前，需要设置数据库服务信任我们自定义的函数或触发器，即设置为ON。创建生成随机数的函数可以分析当前会话中mysql都做了什么，以及资源消耗的情况，可以用于sql调优的测量。默认情况是处于关闭状态，并保存最近15次的运行结果。此功能开启后，我们可以通过由上可见，我们在当前会话中执行过的sql可以通过all：显示所有的开销信息。block io：显示块io开销。context switches： 上下文切换开销。cpu：显示cpu开销信息。
mysql如何获取慢SQL，以及慢查询的解决方式
热门推荐
MrLQD
02-07 2万+
浅谈MySQL中优化sql语句查询常用的30种方法 1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。  2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。  3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：  sel...
mysql处理慢sql
yy_2011的专栏
04-23 1232
1 查看MySQL是否启用了查看慢SQL的日志文件（1） 查看慢SQL日志是否启用mysql> show variables like 'log_slow_queries'; +------------------+-------+| Variable_name    | Value |+------------------+-------+| log_slow_queries | ON  ...
慢SQL 到底应该如何优化？
cpown的博客
08-18 7247
在应用的的开发过程中，由于初期数据量小，开发人员写 SQL 语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多 SQL 语句开始逐渐显露出性能问题，对生产的影响也越来越大，此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化，本章将详细介绍在 MySQL 中优化 SQL 语句的方法。 当面对一个有 SQL 性能问题的数据库时，我们应该从何处入手来进行系统的分析，使得能够尽快定位问题 SQL 并尽快解决问题。 一、查看sql的执行频率 MySQL
慢 SQL 问题经验总结
Franco的博客
08-21 1万+
1、 导致慢 SQL 的原因 在遇到慢 SQL 情况时，不能简单的把原因归结为 SQL 编写问题(虽然这是最常见的因素)，实际上导致慢 SQL 有很多因素，甚至包括硬件和 mysql 本身的 bug。根据出现的概率从大到小，罗列如下： SQL编写问题 锁 业务实例相互干绕对 IO/CPU 资源争用 服务器硬件 MYSQL BUG   2、 由 ...
SQL 查询速度慢原因及优化方法（转载）
漠效的博客
03-25 2万+
前言 下面是网络中流传最广的一篇sql查询速度慢的原因及解决方法的文章，其对于处理mysql的慢查询有借鉴作用。由于此文转载多次，很难找到最开始的原文链接，就附送本人最先看到此文的链接:http://www.cnblogs.com/zhangwc/p/6431865.html sql查询速度慢的原因 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量...
解决sql server查询速度慢11个方法
冲浪小子专栏
06-08 1129
在网页制作过程中经常可以遇到SQL Server数据库查询速度慢的的情况，通过总结发现其原因主要有以下几种： 　　1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 　　2、I/O吞吐量小，形成了瓶颈效应。 　　3、没有创建计算列导致查询不优化。 　　4、内存不足 　　5、网络速度慢 　　6、查询出的数据量过大(可以采用多次查询，其他的方法降低数据量) 　　7、锁或者死锁(这
SQL Server 2012 安装部署
07-14
综上所述，SQL Server 2012的安装部署过程相对简单，只需要注意安装环境的要求和一些常见问题的解决方案即可顺利完成安装。希望本文提供的信息能够帮助读者更好地了解SQL Server 2012的安装部署过程，同时也能够为...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值