楼主: baikejia

帮忙分析一下spreport,数据库慢死了

[复制链接]
论坛徽章:
5
ITPUB元老
日期:2005-03-15 09:15:43ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44凯迪拉克
日期:2013-12-27 09:30:49
11#
 楼主| 发表于 2005-1-10 19:27 | 只看该作者
最初由 xzh2000 发布
[B]

那你应该是64bit的OS吧?
可以适当地把db_cache_size调大一些,
将共享池调到196m,
然后将cursor_sharing=force. [/B]


没有db_cache_size这个参数阿

使用道具 举报

回复
论坛徽章:
2
ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44生肖徽章2007版:狗
日期:2008-11-17 11:15:41
12#
发表于 2005-1-10 19:30 | 只看该作者
最初由 baikejia 发布
[B]

没有db_cache_size这个参数阿 [/B]



db_cache_size这个参数是9i里面的,8i里面为db_block_buffers*db_block_size,个人认为这里这个参数不是慢的主要原因

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
66
ITPUB元老
日期:2005-07-16 18:49:11授权会员
日期:2005-10-30 17:05:33ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44现任管理团队成员
日期:2011-05-07 01:45:08版主3段
日期:2012-05-15 15:24:11
13#
发表于 2005-1-10 21:14 | 只看该作者
最初由 Lengyu 发布
[B]


个人认为可能正是因为这个值过大,导致CBO采用了全表扫描而没有采用索引,xzh2000兄台是这里的高人,小弟想听听兄台的意见 [/B]


高人谈不上,不过这个参数太大显然在这里不太合适,
可以改成db_file_multiblock_read_count =16试试,当然,
最主要是sql性能不佳的问题。

使用道具 举报

回复
论坛徽章:
5
ITPUB元老
日期:2005-03-15 09:15:43ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44凯迪拉克
日期:2013-12-27 09:30:49
14#
 楼主| 发表于 2005-1-11 12:31 | 只看该作者
修改了db_file_multi_block_count=16
新的report

sp_52_53.txt

71.81 KB, 下载次数: 26

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
66
ITPUB元老
日期:2005-07-16 18:49:11授权会员
日期:2005-10-30 17:05:33ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44现任管理团队成员
日期:2011-05-07 01:45:08版主3段
日期:2012-05-15 15:24:11
15#
发表于 2005-1-11 12:51 | 只看该作者
最初由 baikejia 发布
[B]修改了db_file_multi_block_count=16
新的report [/B]


                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
Begin Snap:         52 11-Jan-05 11:12:29      991
   End Snap:         53 11-Jan-05 12:20:10      991
    Elapsed:                  67.68 (mins)

Cache Sizes
~~~~~~~~~~~
           db_block_buffers:     107668          log_buffer:     163840
              db_block_size:       8192    shared_pool_size:  439765555

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:             16,767.11              4,202.38
              Logical reads:             27,353.64              6,855.71
              Block changes:                102.38                 25.66
             Physical reads:              3,666.67                918.99
            Physical writes:                 11.27                  2.82
                 User calls:                264.06                 66.18
                     Parses:                 48.22                 12.09
                Hard parses:                  7.17                  1.80
                      Sorts:                  3.63                  0.91
                     Logons:                  0.39                  0.10
                   Executes:                159.90                 40.08
               Transactions:                  3.99

  % Blocks changed per Read:    0.37    Recursive Call %:   63.12
Rollback per transaction %:   28.88       Rows per Sort: #######

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.66       Redo NoWait %:   99.99
            Buffer  Hit   %:   86.60    In-memory Sort %:   99.94
            Library Hit   %:   95.26        Soft Parse %:   85.14
         Execute to Parse %:   69.85         Latch Hit %:   99.86
Parse CPU to Parse Elapsd %:    8.43     % Non-Parse CPU:   98.53

Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   73.90   73.05
    % SQL with executions>1:   61.86   64.08
  % Memory for SQL w/exec>1:   59.56   60.39

Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
db file sequential read                         1,598,924    2,339,669   33.15
enqueue                                             5,168    1,557,897   22.07
db file scattered read                          1,172,484    1,361,297   19.29
buffer busy waits                                 374,124      580,520    8.22
log file sync                                      17,811      471,563    6.68

改了之后,还是偏大,就是说与这个参数影响不太.
你有6G的内存,应该是32bit的oracle,结果SGA只能
限制在1.7G以内.

现在要做的就是降低shared_pool_size到144m,然后增加
db_block_buffers=200000blocks,然后就是将共享游标参
数修改cursor_sharing=foce.来降低CPU的使用.

其它的只能是优化SQL.

Physical Reads  Executions  Reads per Exec % Total  Hash Value
--------------- ------------ -------------- ------- ------------
        963,318          126        7,645.4     6.5   1820587167
SELECT "SITE_ID" FROM "D_ASK_LIST" WHERE ("ASK_ID" IS NULL)

        799,031          110        7,263.9     5.4   3920706031
SELECT "STAFF_ID" FROM "D_ASK_LIST" WHERE ("ASK_ID" IS NULL)

        714,579            5      142,915.8     4.8   3207605478
SELECT "ASK_ID","OP_TYPE","BRANCH_NO" FROM "D_ADSL_ASK" "E" WHER
E "OP_TYPE"='1'

        209,355            3       69,785.0     1.4   1342134103
SELECT "NAME" FROM "D_NUM_PUBLIC_ASK" WHERE ("DISTRICT_NO" = :"W
PH1" AND "ASK_ID" IS NULL)

        181,958           12       15,163.2     1.2   2500482218
SELECT /*+ FIRST_ROWS */  "ASK_ID", "BUSI_DETAIL_ID", "ASK_DATE"
, "DISTRICT_NO", "NUM_ID", "SITE_ID", "STAFF_ID", "COMPLETION",
"ARCHIVE_DATE", "BEFOR_ID", "AFTER_ID", "ASK_GRADE", "ALL_ID", "
NOTES", "PREASK_FLAG", "CHECK_FLAG", "COMPLETE_DATE", "SELF_COMP
_DATE", "INSTALL_BRANCH" FROM "D_ASK_LIST" WHERE (("ASK_DATE" >=

        116,843           11       10,622.1     0.8   2112985494
SELECT /*+ FIRST_ROWS */  "ASK_ID", "BUSI_DETAIL_ID", "ASK_DATE"
, "DISTRICT_NO", "NUM_ID", "SITE_ID", "STAFF_ID", "COMPLETION",
"ARCHIVE_DATE", "BEFOR_ID", "AFTER_ID", "ASK_GRADE", "ALL_ID", "
NOTES", "PREASK_FLAG", "CHECK_FLAG", "COMPLETE_DATE", "SELF_COMP
_DATE", "INSTALL_BRANCH" FROM "D_ASK_LIST" WHERE (("ARCHIVE_DATE

         91,417            1       91,417.0     0.6   1354302601
select count(*) from d_sheet_his where dept_type like 'K7' and s
heet_statu in ('1','2','4','5','8','9','a') and branch_no like '
130000' and build_no like '%' and line_test_no like '%' and  sen
d_date>=to_date('2005.01.11 00:00:00','yyyy.mm.dd hh24:mi:ss') a
nd send_date<=to_date('2005.01.11 23:59:59','yyyy.mm.dd hh24:mi:

         91,163            1       91,163.0     0.6     91298319
select count(*) from d_sheet_his where dept_type like 'K7' and s
heet_statu in ('1','2','4','5','8','9','a') and branch_no like '
H08000' and build_no like 'H08100' and line_test_no like '%' and
  send_date>=to_date('2004.11.21 00:00:00','yyyy.mm.dd hh24:mi:s
s') and send_date<=to_date('2004.12.20 23:59:59','yyyy.mm.dd hh2

         90,810            7       12,972.9     0.6   3249724588
SELECT /*+ FIRST_ROWS */  "ASK_ID", "BUSI_DETAIL_ID", "ASK_DATE"
, "DISTRICT_NO", "NUM_ID", "SITE_ID", "STAFF_ID", "COMPLETION",
"ARCHIVE_DATE", "BEFOR_ID", "AFTER_ID", "ASK_GRADE", "ALL_ID", "
NOTES", "PREASK_FLAG", "CHECK_FLAG", "COMPLETE_DATE", "SELF_COMP
_DATE", "INSTALL_BRANCH" FROM "D_ASK_LIST" WHERE ("ASK_ID" NOT L

         90,439            1       90,439.0     0.6   3374848123
SELECT /*+ FIRST_ROWS */  "SHEET_NO", "CIRCUIT_NO", "DEPT_TYPE",
"ASK_ID", "PROJECT_NO", "SHEET_TYPE", "SHEET_STATU", "SEND_TYPE
", "INSTALL_FLAG", "DISTRICT_NO", "BRANCH_NO", "BUILD_NO", "LINE
_TEST_NO", "BUSI_DETAIL_ID", "USER_NUM", "NUM_TYPE_ID", "CREAT_S
HEET_DATE", "SHEET_SITE_ID", "SHEET_STAFF_ID", "SEND_STAFF_ID",
SQL ordered by Reads for DB: SJ97  Instance: sj97  Snaps: 52 -53
-> End Disk Reads Threshold:    1000

Physical Reads  Executions  Reads per Exec % Total  Hash Value
--------------- ------------ -------------- ------- ------------

         87,827            1       87,827.0     0.6    404771571
select count(*) from d_sheet_his where dept_type like 'K7' and s
heet_statu in ('6','7','b') and  branch_no like 'H08000' and bui
ld_no like 'H08100' and line_test_no like '%' and send_date>=to_
date('2004.11.21 00:00:00','yyyy.mm.dd hh24:mi:ss') and send_dat
e<=to_date('2004.12.20 23:59:59','yyyy.mm.dd hh24:mi:ss')

         87,058            1       87,058.0     0.6   3562340104
select count(*) from d_sheet_his where dept_type like 'K7' and s
heet_statu in ('6','7','b') and  branch_no like '130000' and bui
ld_no like '%' and line_test_no like '%' and send_date>=to_date(
'2005.01.11 00:00:00','yyyy.mm.dd hh24:mi:ss') and send_date<=to
_date('2005.01.11 23:59:59','yyyy.mm.dd hh24:mi:ss')

你的这些SQL都不是好对付的,每个物理读都特大。

        963,318          126        7,645.4     6.5   1820587167
SELECT "SITE_ID" FROM "D_ASK_LIST" WHERE ("ASK_ID" IS NULL)

        799,031          110        7,263.9     5.4   3920706031
SELECT "STAFF_ID" FROM "D_ASK_LIST" WHERE ("ASK_ID" IS NULL)

这个地方明显很有问题.is null是不走索引的.
这个地方只要稍稍处理一下就可以达到相当好的效果.

使用道具 举报

回复
论坛徽章:
131
2006年度最佳技术回答
日期:2007-01-24 12:58:48福特
日期:2013-10-24 13:57:422014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:142013年新春福章
日期:2013-02-25 14:51:24
16#
发表于 2005-1-11 12:53 | 只看该作者
Buffer hit有点低,可能的话提高一些db_block_buffers。
另外,为小表设置keep buffer_pool
把太大的表扔到recycle pool也是一种选择。

当然,对几个 get per exec > 1,000,000 的TOP SQL 进行tuning也势在必行的。

使用道具 举报

回复
论坛徽章:
5
ITPUB元老
日期:2005-03-15 09:15:43ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44凯迪拉克
日期:2013-12-27 09:30:49
17#
 楼主| 发表于 2005-1-13 13:14 | 只看该作者
建了几个索引,大家看看速度

sp_83_84.txt

69.87 KB, 下载次数: 7

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
66
ITPUB元老
日期:2005-07-16 18:49:11授权会员
日期:2005-10-30 17:05:33ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44现任管理团队成员
日期:2011-05-07 01:45:08版主3段
日期:2012-05-15 15:24:11
18#
发表于 2005-1-13 13:56 | 只看该作者
最初由 baikejia 发布
[B]建了几个索引,大家看看速度 [/B]


不要期忘这几个索引可以达到很大的效果,
象你这种病入膏王的数据库,
需要很长时间的调整的,目前由于你快照收集的
随意性,两个报表之间的可比性很差.

使用道具 举报

回复
论坛徽章:
10
授权会员
日期:2005-10-30 17:05:332010年世界杯参赛球队:科特迪瓦
日期:2010-04-15 12:20:472010年世界杯参赛球队:智利
日期:2010-04-13 17:15:21生肖徽章2007版:蛇
日期:2009-09-24 13:54:11生肖徽章2007版:龙
日期:2009-09-22 13:56:012009日食纪念
日期:2009-07-22 09:30:00生肖徽章2007版:龙
日期:2009-02-10 13:45:15生肖徽章2007版:狗
日期:2009-02-03 13:53:34会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB十周年纪念徽章
日期:2011-11-01 16:20:28
19#
发表于 2005-1-13 15:49 | 只看该作者
看了大师们的讲解,对STATSPACK报告里面的数据和一些数据库参数的用法有了些感性的认识。

使用道具 举报

回复
论坛徽章:
2
ITPUB 11周年纪念徽章
日期:2012-10-09 18:05:372013年新春福章
日期:2013-02-25 14:51:24
20#
发表于 2005-1-13 16:04 | 只看该作者
这个最典型的是要优化你的SQL语句,你的数据库慢是大量的全表扫描语句引起的,只有消除了这些全表扫描,你才能根本解决慢的问题。

PS:千万不要寄希望别人给你调一两个参数就把你的数据库调的很快,还是要扎实的去优化你的应用!

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表