51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: lsekfe
打印 上一主题 下一主题

[你问我来答第30期]:SQL调校(已结束)

[复制链接]

该用户从未签到

41#
发表于 2013-1-22 15:16:19 | 只看该作者
回复 34# bichenlu


   美女的问题很犀利,
1. SQL 调优的步骤,一般对数据库执行比较消耗资源或者引起死锁等瓶颈通过监控工具或者专业的查询瓶颈的代码去定位需要调优的SQL ,如PS的例子

2.对特定的SQL 找到 这条SQL的弊端,根据业务进行针对性的修改

3. 根据修改后的效果进行回归确定其关联效果 是否有改善自己,影响其他的系统瓶颈。

4. 也可以调整 数据库的并发参数 存储的参数  缓冲的命中 内存的使用等等 方式进行调优

PS : exit 和 in的用法1
再来看一下内查询结果集比较大,而外查询较小的时候的情况。

SQL> select /*+ rule */ * from test2
where exists
  2    3        ( select 1 from test1 where test1.object_name = test2.table_name and test1.object_name like 'S%') ;

172 rows selected.

Elapsed: 00:00:00.08

Execution Plan
----------------------------------------------------------
Plan hash value: 833525739

----------------------------------------------
| Id  | Operation          | Name            |
----------------------------------------------
|   0 | SELECT STATEMENT   |                 |
|*  1 |  FILTER            |                 |
|   2 |   TABLE ACCESS FULL| TEST2           |
|*  3 |   INDEX RANGE SCAN | IDX_OBJECT_NAME |
----------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT 0 FROM "TEST1" "TEST1" WHERE
              "TEST1"."OBJECT_NAME"=:B1 AND "TEST1"."OBJECT_NAME" LIKE 'S%'))
   3 - access("TEST1"."OBJECT_NAME"=:B1)
       filter("TEST1"."OBJECT_NAME" LIKE 'S%')

Note
-----
   - rule based optimizer used (consider using cbo)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4837  consistent gets
          0  physical reads
       2596  redo size
      13642  bytes sent via SQL*Net to client
        506  bytes received via SQL*Net from client
         13  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        172  rows processed

SQL> select /*+ rule */ * from test2
  2  where table_name in
  3        ( select object_name from test1 where object_name like 'S%') ;

172 rows selected.

Elapsed: 00:00:00.12

Execution Plan
----------------------------------------------------------
Plan hash value: 2497755124

-------------------------------------------------------
| Id  | Operation                   | Name            |
-------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST2           |
|   2 |   NESTED LOOPS              |                 |
|   3 |    VIEW                     | VW_NSO_1        |
|   4 |     SORT UNIQUE             |                 |
|*  5 |      INDEX RANGE SCAN       | IDX_OBJECT_NAME |
|*  6 |    INDEX RANGE SCAN         | IDX_TABLE_NAME  |
-------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("OBJECT_NAME" LIKE 'S%')
       filter("OBJECT_NAME" LIKE 'S%')
   6 - access("TABLE_NAME"="$nso_col_1")

Note
-----
   - rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       2214  consistent gets
          0  physical reads
       7556  redo size
      13378  bytes sent via SQL*Net to client
        506  bytes received via SQL*Net from client
         13  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        172  rows processed

从理论上分析,当内存查询的结果集比较大,而外查询比较小的时候,应该增加in的cost,对于 exists的filter来说,也应该效率有所提高,所以再这种情况下,我们应该看到exists效率更高。但是在实际的测试中,我们可以看到,这两者并不存在明显的性能上的差异,甚至于用in的效果比exists更好。
总结:
1、在CBO模式下,两者效率一致。
2、在RBO模式下,当外层数据集远大于内层数据集时,使用in的效率比较高。
3、在RBO模式下,当外层数据集远小于内层数据集时,两者效率相差不大。
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2013-1-22 15:18:12 | 只看该作者
如何进行数据库调优呢?需要对数据库调优掌握哪些知识呢?
话说我爱你 发表于 2013-1-18 11:33



    我简单的来说,你要调优
  1。对该数据库的架构比较熟悉
  2。对此系统业务和设计,架构等比较熟悉
  3。对数据库的调优原理很熟悉,扩展开来很多,可以私下找我聊聊
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2013-1-22 15:37:21 | 只看该作者
能否给新手推荐几本关于  基础、提高类别的书籍或视频
回复 支持 反对

使用道具 举报

该用户从未签到

44#
发表于 2013-1-22 16:02:47 | 只看该作者
回复 39# makinstall


    目前是黑盒测试
回复 支持 反对

使用道具 举报

该用户从未签到

45#
发表于 2013-1-22 16:31:06 | 只看该作者
请问在我测试的时候通过LR的细分图看出server端的耗时很长,client和网络的耗时很长,那么这个时候我该如何去看这个时间主要是耗在了数据库操作上还是服务器处理上呢?LR发送的http请求到服务器,然后服务器发送给数据库服务器,有什么工具可以监控到服务器发送给数据库服务器这之间的耗时情况么(这之间也应该分分网络时间和数据库服务器处理时间吧)?
回复 支持 反对

使用道具 举报

该用户从未签到

46#
发表于 2013-1-22 21:03:17 | 只看该作者
在某群里看到你让大家来这里提问,所以特提问如下:
我们在做oracle性能调优的时候
如何利用awr报告进行问题定位
更准确的说:如何去阅读awr报告
awr的关注点是哪些?
如何减少硬连接?
如何让更多的查询的数据在共享内存,怎样是设置比较合理的?
……
谢谢解答
回复 支持 反对

使用道具 举报

该用户从未签到

47#
发表于 2013-1-23 12:57:40 | 只看该作者
能否给新手推荐几本关于  基础、提高类别的书籍或视频
晓菜瓜 发表于 2013-1-22 15:37



有关书,我把在ROAD论坛上的推荐的基本书给大家分享下:

.工具 Loadrunner11 性能调优实践 by 云层 基础部分+部分进阶

2.OS 鸟哥的linux私房菜.基础学习篇(第三版)
3.调优 oracle性能调优诊断艺术 by-Christian Antognini 人民邮电出版社
4.编程 http://ideone.com/ 编程网上环境
5.基于LINUX的ORACLE 数据库管理
6.基于LINUX的ORACLE 数据库管理 张佳音
7.教你如何成为10G OCP
8. 高性能网站建设进阶指南
等等
想要更多的找我qq  791959906
回复 支持 反对

使用道具 举报

该用户从未签到

48#
发表于 2013-1-23 13:00:35 | 只看该作者
回复  makinstall


    目前是黑盒测试
wjtest 发表于 2013-1-22 16:02


我觉得可以有很多地方入手,测试基本理论,测试用例如何精简有效,敏捷。。。,环境持续构建 测试自动化  单元测试 等等很多方向供你研究
回复 支持 反对

使用道具 举报

该用户从未签到

49#
发表于 2013-1-23 13:04:26 | 只看该作者
请问在我测试的时候通过LR的细分图看出server端的耗时很长,client和网络的耗时很长,那么这个时候我该如何 ...
opq133 发表于 2013-1-22 16:31


可以用日志进行切块化,总时间和 节点时间你就知道了。
然后通过很多监控工具都可以知道某个服务器的内部状态,如SPOTLIGHT 傻瓜级, nmon等,你是OS功底太差,一般来说直接用系统工具就可以得到想要的结果。如 ORACLE 我们可以用 SQL 查询系统视图,也可以用 EM工具,也可以用AWR等报告,也可以用其他第三方监控工具。

多多学习下OS 和中间件吧, 基础补补
回复 支持 反对

使用道具 举报

该用户从未签到

50#
发表于 2013-1-23 13:08:16 | 只看该作者
在某群里看到你让大家来这里提问,所以特提问如下:
我们在做oracle性能调优的时候
如何利用awr报告进行问 ...
marsliu 发表于 2013-1-22 21:03


很高兴,终于有一个专业点的问题。
有关内容很多
AWR 是 Oracle  10g 版本 推出的新特性, 全称叫Automatic Workload Repository-自动负载信息库, AWR 是通过对比两次快,照(snapshot)收集到的统计信息,来生成报表数据,生成的报表包括多个部分

WORKLOAD REPOSITORY report for
DB Name        DB Id        Instance        Inst num        Release        RAC        Host
ICCI        1314098396        ICCI1        1        10.2.0.3.0        YES        HPGICCI1

        Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        2678        25-Dec-08 14:04:50        24        1.5
End Snap:        2680        25-Dec-08 15:23:37        26        1.5
Elapsed:                 78.79 (mins)                  
DB Time:                 11.05 (mins)                  
DB Time不包括Oracle后台进程消耗的时间。如果DB Time远远小于Elapsed时间,说明数据库比较空闲。
db time= cpu time + wait time(不包含空闲等待) (非后台进程)
说白了就是db time就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间
DB time = cpu time + all of nonidle wait event time
在79分钟里(其间收集了3次快照数据),数据库耗时11分钟,RDA数据中显示系统有8个逻辑CPU(4个物理CPU),平均每个CPU耗时1.4分钟,CPU利用率只有大约2%(1.4/79)。说明系统压力非常小。

列出下面这两个来做解释:
Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)

Report B:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 40 16.4
Elapsed: 59.63 (mins)
DB Time: 19.49 (mins)
服务器是AIX的系统,4个双核cpu,共8个核:
/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7
先说Report A,在snapshot间隔中,总共约60分钟,cpu就共有60*8=480分钟,DB time为466.37分钟,则:
cpu花费了466.37分钟在处理Oralce非空闲等待和运算上(比方逻辑读)
也就是说cpu有 466.37/480*100% 花费在处理Oracle的操作上,这还不包括后台进程
看Report B,总共约60分钟,cpu有 19.49/480*100% 花费在处理Oracle的操作上
很显然,2中服务器的平均负载很低。
从awr report的Elapsed time和DB Time就能大概了解db的负载。


可是对于批量系统,数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内,或者快照周期跨度太长而包含了大量的数据库空闲时间,所得出的分析结果是没有意义的。这也说明选择分析时间段很关键,要选择能够代表性能问题的时间段。

Report Summary
Cache Sizes
        Begin        End               
Buffer Cache:        3,344M        3,344M        Std Block Size:        8K
Shared Pool Size:        704M        704M        Log Buffer:        14,352K
显示SGA中每个区域的大小(在AMM改变它们之后),可用来与初始参数值比较。
shared pool主要包括library cache和dictionary cache。library cache用来存储最近解析(或编译)后SQL、PL/SQL和Java classes等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。

Load Profile
        Per Second        Per Transaction
Redo size:        918,805.72        775,912.72
Logical reads:        3,521.77        2,974.06
Block changes:        1,817.95        1,535.22
Physical reads:        68.26        57.64
Physical writes:        362.59        306.20
User calls:        326.69        275.88
Parses:        38.66        32.65
Hard parses:        0.03        0.03
Sorts:        0.61        0.51
Logons:        0.01        0.01
Executes:        354.34        299.23
Transactions:        1.18         
% Blocks changed per Read:        51.62        Recursive Call %:        51.72
Rollback per transaction %:        85.49        Rows per Sort:        ########
显示数据库负载概况,将之与基线数据比较才具有更多的意义,如果每秒或每事务的负载变化不大,说明应用运行比较稳定。单个的报告数据只说明应用的负载情况,绝大多数据并没有一个所谓“正确”的值,然而Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。
Redo size:每秒产生的日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。Logical reads:每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB Block Gets
Block changes:每秒/每事务修改的块数
Physical reads:每秒/每事务物理读的块数
Physical writes:每秒/每事务物理写的块数
User calls:每秒/每事务用户call次数
Parses:SQL解析的次数.每秒解析次数,包括fast parse,soft parse和hard parse三种数量的综合。 软解析每秒超过300次意味着你的"应用程序"效率不高,调整session_cursor_cache。在这里,fast parse指的是直接在PGA中命中的情况(设置了session_cached_cursors=n);soft parse是指在shared pool中命中的情形;hard parse则是指都不命中的情况。
Hard parses:其中硬解析的次数,硬解析太多,说明SQL重用率不高。每秒产生的硬解析次数, 每秒超过100次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force,该参数默认值为exact。但该参数设置为similar时,存在bug,可能导致执行计划的不优。
Sorts:每秒/每事务的排序次数
Logons:每秒/每事务登录的次数
Executes:每秒/每事务SQL执行次数
Transactions:每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。

Blocks changed per Read:表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。
Recursive Call:递归调用占所有操作的比率.递归调用的百分比,如果有很多PL/SQL,那么这个值就会比较高。
Rollback per transaction:每事务的回滚率.看回滚率是不是很高,因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
Rows per Sort:每次排序的行数
注:
Oracle的硬解析和软解析
  提到软解析(soft prase)和硬解析(hard prase),就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程:
  1、语法检查(syntax check)
  检查此sql的拼写是否语法。
  2、语义检查(semantic check)
  诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。
  3、对sql语句进行解析(prase)
  利用内部算法对sql进行解析,生成解析树(parse tree)及执行计划(execution plan)。
  4、执行sql,返回结果(execute and return)
  其中,软、硬解析就发生在第三个过程里。
  Oracle利用内部的hash算法来取得该sql的hash值,然后在library cache里查找是否存在该hash值;
  假设存在,则将此sql与cache中的进行比较;
  假设“相同”,就将利用已有的解析树与执行计划,而省略了优化器的相关工作。这也就是软解析的过程。
  诚然,如果上面的2个假设中任有一个不成立,那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。
  创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析。
回复 支持 反对

使用道具 举报

该用户从未签到

51#
发表于 2013-1-23 13:12:10 | 只看该作者
在某群里看到你让大家来这里提问,所以特提问如下:
我们在做oracle性能调优的时候
如何利用awr报告进行问 ...
marsliu 发表于 2013-1-22 21:03


内容太多,我给你连接下载好了
http://5itest.net/bbs/dispbbs.asp?boardid=16&Id=363
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2016-2-26 15:39
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    52#
    发表于 2013-1-23 16:10:20 | 只看该作者
    你好,现在公司准备将性能这块的测试交给我来进行,但是不知道从哪里入手,性能方面新手,请指教,谢谢。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    53#
    发表于 2013-1-24 10:15:08 | 只看该作者
    回复 48# makinstall


      前辈有没有这方面的书 推荐下,谢谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    54#
    发表于 2013-1-24 14:11:49 | 只看该作者
    您好!

    一个系统内嵌的邮件收发列表,客户提出邮件超过80封时,系统运行会很卡,需要做性能调优!!请问该如何着手处理呢?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-1-10 15:21
  • 签到天数: 32 天

    连续签到: 1 天

    [LV.5]测试团长

    55#
    发表于 2013-1-24 14:20:39 | 只看该作者
    BI 的测试 注重 数据的准确性和逻辑性, 对于BI 个人认为你要对业务熟悉且在大数据量分析方面和数 ...
    makinstall 发表于 2013-1-22 15:04


    那请问专家,当这个系统连所需要的数据都没有的时候是怎么去测试的呢?是要测试人员自己去造数据吗?那又是怎么造数据的呢?
    还有是怎么去注重 数据的准确性和逻辑性?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2014-10-29 10:40
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    56#
    发表于 2013-1-24 15:06:34 | 只看该作者
    你好,现在公司准备将性能这块的测试交给我来进行,但是不知道从哪里入手,性能方面新手,请指教,谢谢。
    changli_dong 发表于 2013-1-23 16:10

    性能测试涉及到的知识很多 需要有 网络、操作系统、中间件、数据库  等知识的储备。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2013-1-24 20:15:44 | 只看该作者
    性能测试涉及到的知识很多 需要有 网络、操作系统、中间件、数据库  等知识的储备。
    yangemil 发表于 2013-1-24 15:06



        呵呵,谢谢yangemil帮我回答问题

    做性能测试,需要掌握评估系统压力状态,如并发人数,TPS 吞吐量,
                制定该系统通过的的标准SLA: 如TPS多少秒算可以,事物失败率达到万分之一等。
                需要掌握压力的正确生成,即制造适量能模拟真实情况的虚拟用户的脚本。
                有多个不同操作系统或中间件的知识积累,能够顺藤摸瓜,找到问题的症结点,定位系统瓶颈。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2013-1-24 20:26:41 | 只看该作者
    那请问专家,当这个系统连所需要的数据都没有的时候是怎么去测试的呢?是要测试人员自己去造数据吗?那 ...
    ashelywen 发表于 2013-1-24 14:20

    问题1:数据没有怎么办
        1.数据没有需要自己造,或者让SA或者DBA从线上数据库中拉出来。
        2.如果是自己制造数据 得根据系统的特点,业务特性,数据库表之间的关系来制作,写SQL过程 或者其他工作来制作。 如datafactory 之类的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    59#
    发表于 2013-1-24 20:31:50 | 只看该作者
    回复  makinstall


      前辈有没有这方面的书 推荐下,谢谢
    wjtest 发表于 2013-1-24 10:15



        黑盒?软件测试的策略,测试用例设计,SCRUM等等自己找找看看吧:) 当当查查 呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2013-1-24 20:33:20 | 只看该作者
    那请问专家,当这个系统连所需要的数据都没有的时候是怎么去测试的呢?是要测试人员自己去造数据吗?那 ...
    ashelywen 发表于 2013-1-24 14:20



        数据准确性和逻辑性,这个要看你的SQL 功底和业务功底 以及对数据库表之间的设计了解程度了
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-22 18:58 , Processed in 0.085656 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表