1 / 21

Oracle 性能调整方法论

Oracle 性能调整方法论. hotline@happyit.net. Chao_ping. 数据库用来做什么. 存储业务数据 完成业务交易 (OLTP) 企业数据分析 (OLAP). Ratio Based Tuning － 1 . 传统的理论，使用基于命中率的性能调整 起始与很早的 Oracle 版本 (Oracle 6) 有大量的参考资料 对应的 Oracle 提供的工具： Utlbstat/estat. Ratio Based Tuning － 2 . 基于命中率的调整： 只是从数据库级别来分析问题 很多的命中率参数，复杂

tasha-adams
Download Presentation

Oracle 性能调整方法论

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Oracle性能调整方法论 hotline@happyit.net Chao_ping

  2. 数据库用来做什么 • 存储业务数据 • 完成业务交易(OLTP) • 企业数据分析(OLAP) HappyIT Technical Service

  3. Ratio Based Tuning－1 • 传统的理论，使用基于命中率的性能调整 • 起始与很早的Oracle 版本(Oracle 6) • 有大量的参考资料 • 对应的Oracle 提供的工具：Utlbstat/estat HappyIT Technical Service

  4. Ratio Based Tuning－2 基于命中率的调整： • 只是从数据库级别来分析问题 • 很多的命中率参数，复杂 • 需要反复重起数据库，逐渐发现问题真正原因 • 不能准确发现真正的瓶颈所在，调整费时费力 • 纯粹的实例级别的调整，往往很难有明显的效果 • 随着服务器硬件技术的发展和数据库的扩张，已经成了过时的技术 HappyIT Technical Service

  5. HappyIT的调整思路 • 命中率与业务没有直接关系 • 业务的需求是 • 在尽量短的时间内,完成业务 • 业务响应时间由下面两个部分构成 • 数据库处理业务时间 • 数据库等待资源可用的时间 • 降低花费在等待资源上的时间，就可以提高处理速度 HappyIT Technical Service

  6. Wait Event Based Tuning • 我们如何调整 • Oracle提供了相应的调整工具：Statspack • Oracle调整秘诀：Event 10046 HappyIT Technical Service

  7. Wait Event Based Tuning(Case 1) • 背景介绍: • 上海某网站,发展非常迅速,系统访问量持续增加 • 一段时间,发现中间件持续报队列堵塞,前端响应时间变慢,网络流量和页面访问量徘徊不变 • 怀疑系统出现了性能瓶颈 HappyIT Technical Service

  8. Wait Event Based Tuning(Case 1) • 我们分析原因,认为数据库已经成为系统瓶颈,无法及时响应中间件请求 Top 5 Wait Events ~~~~~~~~~~~~~~~~~ Wait % Total Event Waits Time (cs) Wt Time -------------------------------------------- ------------ ------------ ------- log file sync 3,393,727 89,905,731 70.56 db file sequential read 3,440,829 15,955,199 12.52 db file parallel write 368,903 8,120,966 6.37 log file parallel write 1,144,385 7,868,575 6.18 log file sequential read 233,769 1,819,270 1.43 业务高峰时间段,IO子系统常常是100% Busy • Vmstat ,iostat 报告 HappyIT Technical Service

  9. Wait Event Based Tuning(Case 1) • 如何调整Logfile Sync • 使用单独的Raid1磁盘作为Redo 存放点 • 使用Raw Device来存放Redo Log • 减小log buffer size • 调整应用,减少Commit次数 • IOT技术 • Batch Commit • Separate Table HappyIT Technical Service

  10. Wait Event Based Tuning(Case 1) • 调整结果 • 磁盘子系统: 20-50% Busy • Wait Event:log file sync大大降低(30%) • 系统响应时间大大降低, 访问量开始继续上升 HappyIT Technical Service

  11. Wait Event Based Tuning(Case 2) • 背景：某移动的项目，将老系统移植到新的硬件中。新老系统都为ORACLE8.1.7.4。由于是实时在线系统，影响非常大。 • 问题描述: • 移植后整个系统性能下降（并无个别应用特别慢，而是整个应用都慢），但两个系统硬件差别不大，且老系统的负荷是新系统的三倍。 • 通过两个系统进行相同的查询操作对比发现，负荷小的系统反而慢。 HappyIT Technical Service

  12. Wait Event Based Tuning(Case 2) • 对比操作：select count(*) from billing.g_inlocal_cdr5; 在S7a服务器中需要跑15分钟，而类似性能的服务器S85中，只需要跑5分钟。 • 排除其他状况： 比较两个阵列的I/O整体能力接近 • 异常现象： 通过设置Oracle 性能事件，Event 10046 ,我们观察到系统的主要的等待事件是GLOBAL CACHE CR REQUEST HappyIT Technical Service

  13. Wait Event Based Tuning(Case 2) • 调整操作： • 针对每个文件的I/O状况，将其分成三类 • 调整GC_FILES_TO_LOCKS， • 调整结果：用户的大多数操作，响应时间在两个机器中基本一致 HappyIT Technical Service

  14. Response Time Based Tuning • 数据库是为了满足客户的需要，及时提供用户需要的数据，完成业务 • 响应时间：＝ 系统处理时间 ＋ 系统等待资源可用时间 • 从整个业务系统的更高角度，分析系统响应时间 • 结合操作系统，网络，数据库和应用程序联合分析 HappyIT Technical Service

  15. 响应时间的分解 • 客户端程序的响应时间 • 网络的响应时间 • 中间件的处理时间 • 数据库服务器的响应时间 • 数据库处理时间 • 数据库在CPU上的运行 • 数据库等待资源可用的时间 • 等待锁 • 数据库等待磁盘IO • 索引读取 • 全表扫描 HappyIT Technical Service

  16. 网络延迟0.1秒 Apache处理时间0.15秒 Tuxedo处理时间0.1秒 等待时间 20秒 CPU处理 1.65秒 锁等待 2秒 I/O等待 18秒 读取索引 0.1秒 全表扫描 17.9秒 PC浏览器 响应时间22秒 Apache服务器响应时间21.9秒 Tuxedo 响应时间21.75秒 从用户点击浏览器开始,总共用了22秒,才得到他需要的结果 数据库服务器 响应时间21.65秒 HappyIT Technical Service

  17. 数据库优化 • 优化系统构架 • Bind Variable And Parse • Tune the Core Business Logic • 合理使用Oracle New Feature • 优化SQL语句 • 理解优化器 • Explain Plan & Tkprof & SQL_TRACE • Tune Join • Tune Index HappyIT Technical Service

  18. Response Time Based Tuning(Case 1) • 系统有些部分响应时间很慢，但是Oracle系统没有Wait Event Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- CPU time 2,733 96.83 global cache cr request 80,125 67 2.36 SQL*Net more data to client 384,026 8 .30 buffer busy global CR 55 7 .23 control file sequential read 9,907 3 .12 模块名称 10-11点 执行次数/平均运行时间 11-12 点 执行次数/平均运行时间 GdsLst_EndDesc 2502/0.21 2714/0.27 GdsLst_NewDesc 937/0.16 1151/0.19 GdsLst_EndC 561/0.31 675/0.34 GdsLst_HotC 299/0.43 327/0.50 HappyIT Technical Service

  19. Response Time Based Tuning(Case 1) • 分析慢的应用模块，看时间花在网络,中间件,还是数据库 • 分析数据库，CPU时间都消耗在Logical IO上面 • 会话执行大量Logical IO(内存读取) • 如何调整: • 设法降低Oracle的逻辑读 • 使用高效率的索引 • 使用Materialized View • 修改结果： • 修改前：GdsLst_HotC 210/0.43 • 修改后：GdsLst_HotC 222/0.01 HappyIT Technical Service

  20. 调整前： SVCNAME 12n-1p 13p-14p TOTALS Num/Avg Num/Avg Num/Avg --------------- -------- -------- ------- GdsLst_EndDesc 2796/0.28 3221/0.34 6017/0.31 GdsLst_NewDesc 1080/0.13 1138/0.15 2218/0.14 GdsLst_EndC 683/0.34 825/0.39 1508/0.37 GdsLst_NewC 541/0.04 572/0.05 1113/0.05 GdsLst_HotDesc 366/0.80 362/0.62 728/0.71 GdsLst_HotC 209/0.01 229/0.01 438/0.01 调整后： SVCNAME 12n-1p 13p-14p TOTALS Num/Avg Num/Avg Num/Avg --------------- -------- -------- ------- GdsLst_EndDesc 2805/0.10 1990/0.10 4795/0.10 GdsLst_NewDesc 1196/0.10 822/0.10 2018/0.10 GdsLst_EndC 652/0.02 502/0.02 1154/0.02 GdsLst_NewC 605/0.01 415/0.01 1020/0.01 GdsLst_HotDesc 314/0.02 260/0.02 574/0.02 GdsLst_HotC 188/0.01 146/0.01 334/0.01 HappyIT Technical Service

  21. 结束 Q&A HappyIT Technical Service

More Related