1. 首页
  2. IT资讯

[20200111]浅谈exadata oltp系统的优化.txt

[20200111]浅谈exadata oltp系统的优化.txt

–//最近做exadata数据库优化,自己有许多感想。
–//链接:http://blog.itpub.net/267265/viewspace-2672368/=>[20201007]exadata存储索引.txt

> @ sql_id 5yqm7qry03mcg
SQL_ID        SQLTEXT
————- ———————————————————————————————–
5yqm7qry03mcg WITH x AS (
                          … –/trunc
                         )
                    SELECT x.*,y.xtsj
                     FROM x,emr_yzbczrz y WHERE x.yzbxh = y.yzbxh AND (y.czjs = 2 OR (y.czjs = 1 AND y.czlx = 5))  
                     and y.xtsj  >=to_date(:1,'yyyy-mm-dd hh24:mi:ss') and y.xtsj <=to_date(:2,'yyyy-mm-dd hh24:mi:ss')

–//通过建立emr_yzbczrz表的xtsj索引,可以不走全表扫描,不利用exadata的存储索引。这样优化后对比:
–//优化前:
> @ d_buffer 5yqm7qry03mcg 60
 EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1
———— ———— ————- —————
       89722      4999857   44930492814         1435496

1 row selected.

… sleep 60 , waiting ….

 EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2
———— ———— ————- —————
       89724      8188024   44931515542         1435596

1 row selected.

总buffer_gets 每次buffer_gets 执行次数   总执行时间 每次执行时间 总处理记录数 平均处理记录数
————- ————— ——– ———— ———— ———— ————–
      3188167       1594083.5        2      1022728       511364          100             50
1 row selected.

–//建立索引后优化:
> @ d_buffer 5yqm7qry03mcg 60
 EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1
———— ———— ————- —————
       89745     22989971   44942090061         1436189

1 row selected.
… sleep 60 , waiting ….
 EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2
———— ———— ————- —————
       89747     23066613   44942854509         1436302
1 row selected.

总buffer_gets 每次buffer_gets     执行次数   总执行时间 每次执行时间 总处理记录数 平均处理记录数
————- ————— ———— ———— ———— ———— ————–
        76642           38321            2       764448       382224          113           56.5
1 row selected.
–//使用.38秒,仅仅节约一点点时间,像这种情况是建立索引还是不需要建立索引非常纠结。
–//做这样优化非常没有成就感,我大概节省了 (0.511-0.382)*67 = 8.643 秒,感觉跟没做没有什么区别。

–//但是with里面的内容没有优化,事后我继续优化,效果如下:
> @ d_buffer 5yqm7qry03mcg 60
EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1
———– ———— ————- —————
       2234     89241076     816675931           42511

1 row selected.

… sleep 60 , waiting ….

EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2
———– ———— ————- —————
       2235     89241783     816681538           42519

1 row selected.

总buffer_gets 每次buffer_gets   执行次数 总执行时间 每次执行时间 总处理记录数 平均处理记录数
————- ————— ———- ———- ———— ———— ————–
          707             707          1       5607         5607            8              8
1 row selected.

–//达到这样的效果已经非常理想了。当然我仅仅在60秒抓取1次执行,处理记录数很小,仅仅8条记录。
–//不过也可以看出问题,exadata对于OLTP"毫无用处",就好像拿大炮打蚊子,也许说的有点过^_^。

–//我自己再次仔细阅读<性能神化,聊聊Exadata 的"七宗罪">,链接:
–//http://blog.itpub.net/22034023/viewspace-2153518/

–//exadata可能并不适合OLTP系统,或者讲许多客户使用它,更多是掩盖自身软件应用设计的缺陷,至少我认为我们现在的应用就是这样。
–//当然好处就是至少我不会担心系统运行缓慢,整天忙于应付这些sql语句的优化问题。

–//对于"纯"OLTP类型数据库,也许应该不要考虑在exadata运行的假设,按照原有的模式优化sql语句,该建的索引还是要建立,
–//感觉这样才是比较合适的选择,达到理想的优化效果。

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

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/183082.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code