|
查看上一个主题 :: 查看下一个主题
|
| 作者 |
信息 |
sandip_mainframe
警告：2
新的用户
已加入：2006年9月20日
帖子：63
地点：浦那
|
|
|
|
大家好，
我们有一项日常运行的工作，在此工作中，该程序中调用了一个程序，以下查询占用大量资源
执行时间，大约浪费了95-96％的时间在I / O调用上。请提出如何优化此查询的建议。
请在此处找到所需的详细信息。
| 码： |
执行SQL
SELECT IFNULL(SUM(X_AMT),0)
INTO :WS-IS-CURNT
FROM XYZ_ABC
WHERE XX_NUM = :XYZ-ABC.XX-NUM (Table host variables)
AND YY_NUM = :XYZ-ABC.YY-NUM (Table host variables)
AND X_YEAR = :WS-YEAR-CUR (工作存储变量)
AND Y_MONTH = :WS-MONTH-CUR (工作存储变量)
GROUP BY YY_NUM，XX_NUM，
X_YEAR, Y_MONTH
结束执行。
|
索引列：
| 码： |
YY_NUM
XX_NUM
X_YEAR
Y_MONTH
光盘 |
表格详情：
| 码： |
XX_NUM CHAR 12
YY_NUM CHAR 12
X_YEAR DECIMAL 02
Y_MONTH十进制 02
光盘 CHAR 02 |
X_AMT十进制11
APPTUNE的建议：
| 码： |
此选择语句已执行 报告期间1605K次
间隔。
语句的平均SQL耗时 00:00.00486 AND THE
每个语句的平均SQL Server 中央处理器时间 00:00.00011.
此语句平均所需的获取页数 3.42,
哪个很棒(LESS THAN 10 ). 0.00 PAGES, OR 0.0 %, ARE
从缓冲区池中检索而不会增加I / O的成本。
此缓冲池命中率很差(少于或等于50％).
此语句仅在I / O中花费97.9％的时间
最长的时间组件。
记录日志:
呼叫 SECT STMT + --- SQL-+ +-总SQL时间-+
类型 没有。 NO. CALLS ERRS ELAPSED CPU GETPAGES
-------- ----- ------ ------ ----- ----------- --------- ---------
选择 30 15505 1502K 0 2:17:03.163 02:26.77652 5243681
平均S: 00:00.00548 00:00.00010 3
|
此查询的EXPLIAN如下
| 码： |
STMTNO COST * RATE SQL语句
15505 6.096961 选择 IFNULL ( 和 ( X_AMT ) , 0 )
|
查询的详细信息如下-
| 码： |
声明类型...。静态 分布类型.... N / P
呼叫 类型......... 选择 要求的位置。 N / P
事件 总 SQL 呼叫
----------------------------------- ------------ --- ---------
SQL 呼叫S..........................: 1501547
IN-SQL ELAPSED ....................................: 2:17:03.163 00:00.00548
IN-SQL 中央处理器 ........................: 02:26.77652 00:00.00010
IN-SQL ZIIP ...........................: 00:00.00000 00:00.00000
GETPAGE COUNT ......................: 5243681 3
AVERAGE PE
事件 总 SQL CAL
IN-SQL 中央处理器时间...: 02:26.77652 00:00.00010
同步I / O时间..................: 1:42:41.312 00:00.00410
ASYNC I / O TIME ................................: 31:47.87067 00:00.00127
锁定时间.........................: 00:00.17485 00:00.00000
其他等待时间......................: 00:00.00000 00:00.00000
未归类.....................: 00:07.02914 00:00.00000
-------------------------------------------------- - 前高后低
HIGH
中央处理器.............................................: 00:00.00094
耗时....................................: 00:00.70539
获取页面.........................................................: 8
同步读取I / OS ..............................: 6
AVERAGE
缓冲区统计 TOTAL PER 呼叫
------------------------------------------- ------- --------
SQL 呼叫S.................................: 1501547
GETPAGE REQUEST ...........................: 5243681 3
GETPAGE Failure ................: 0 0
预取要求.............................: 651374 0
连续....................................: 0 0
列表....................................: 0 0
动态.................................: 651374 0
阅读整页......................: 14885K 10
BPOOL更新......................................: 0 0
TOTAL TOTAL
类型 OF WAIT NUMBER WAIT TIME
-------------------------------------------------- --------- ----------
I / O等待
同步I / O ...........................................: 2127219 1:42:41.31
异步读取I / O ............................: 542510 31:47.8706
异步写I / O ............................: 0 N/
日志写入I / O ...............................: 0 N/
提交阶段1写入I / O等待....................: 0 N/
存档日志.....................................: 0 N/
磁带存档读取......................: 0 N/ |
|
|
| 回到顶部 |
|
 |
恩里科·索里切蒂
高级主持人
已加入：2007年3月14日
帖子：10715
所在地：意大利
|
|
|
|
该语句被执行了约150万次
I / O本身并不取决于查询，而是取决于<data/row> access pattern and <data/row> distribution
如果访问的数据是<uniformly>分布在整个数据库/表中
没有查询/缓冲优化可以摆脱I / O，
除非您使缓冲池能够容纳...
选择时间返回的行数1500000,
但是那你在其他地方会遇到问题 |
|
| 回到顶部 |
|
|
盖伊
高级会员
已加入：2009年8月11日
帖子：1281
地点：比利时
|
|
|
|
如果x_amt不经常更新，则可能的解决方案是在索引中添加x_amt作为包含列。
您没有提到索引的聚类比率，也没有提到是否允许您操纵输入记录/变量的顺序。 |
|
| 回到顶部 |
|
|
迪克·谢勒
主持人荣誉
已加入：2006年11月23日
帖子：19245
位置：矩阵内部
|
|
|
|
您好，
表中有几行？过程必须“触摸”这些行中的多少行？
有时，从平面文件中卸载数据并进行处理要比一遍又一遍的查询或某些“怪兽查询”要好得多。您自己看来并不是一个“怪兽”，但处决次数肯定会增加成本。
如果您简要说明整个过程以及此特定查询对该过程的作用，则可能会帮助某人。可能还有其他选择。 。 。
编辑：没有看到Guy的帖子。 。 。  |
|
| 回到顶部 |
|
|
|
|
