|
|
样章读后感：
读了试读样章。作者文笔轻松活泼，由案例循循善诱，不断剖析不同场景下的不同处理心得，武功虽好也要善于灵活应用才是真的好，不然也只是花架子。
其实工作中 大部分的调优工作都是如同读者所述的分不同场景case，了解前因后果，选择最适合的方法解决，切忌一不做二不休的硬处理，这样会有很大的隐患。
要善于使用读取awr和addm报告，对整个系统的性能状况有全局性得到认识。在现在这种大数据的环境下，我们除了关心 top5的 event和 sql 外，正如作者所描述的
关注段和存储对象的使用统计，从IO热点度的方向去调优才能对整个大局有利，现在的硬件水平，SQL的性能限制主要集中在IO这块了，单纯某个sql的调优如果不放在大环境中考虑，
优化结果并不一定达到用户的要求，例如建个索引或者调整了执行计划让原本执行10秒的语句减为1s,但不考虑全局如果当前库的负担整体很重，sql执行频繁的情况，实际还是慢，这样的调优能带给用户多大的满意度呢？针对段、存储的热度合理进行数据库后台的IO搭建调整处理，才能使整个库的性能得到提升，然后基于sql优化就游刃有余。在样章中作者就对此种场景做了总结，有强烈共鸣。
样章中针对gc buffer busy,gc request的事件处理方式，虽然短短几句话，但会让迷茫着有醍醐灌顶之感， 因为这种事件是多节点数据库环境经常出现的问题，而根源其实关系到
前端应用的合理部署问题，一些生产系统为了应对访问压力，将前端系统部署多台应用服务器，访问不同的数据库节点，从而达到性能解决目的，但出现这些等待事件说明了前端部署
存在不合理之处。应该将相关模块行为一类的固定访问某个节点，从而在不增加sga内存的情况下降低此种事件的概率。这对前端的开发布局提出了要求，对数据库和前端的框架定义就要提前
进行合理的部署规划，这样后期的项目维护上线才有稳定可靠得到保证。 作者短短的一个样章就传递出多年的经验积累，让初涉调优行列的读者能少走弯路，加快成熟度非常有帮助。
读了样章，细细思考，获益良多，对全书更是期待拜读为快了。
1． SQL优化可以用到那些性能工具
quest工具，awr,addm,ash报告是获取第一手的资料来源。平时积累的监控事件的脚本能及时获取当前点的库等待问题所在。
其实最好用的工具类就是oralce 提供的报告工具和多种的数据字典，了解它们，熟练它们，实际使用中的不断总结就是最好的优化手段了。
2． 如何缩短SQL调优时间
一定要了解问题出现的时间点，时间点前做过何种操作，才能尽可能的预判断问题可能的根源。
了解当前sql的执行计划？是否存在多个执行计划？索引是否缺失，统计信息是否异常等等。
还可采用固化执行计划的手段降低调整周期，提高响应度。
当然平时对原理的了解，多吸取别人的调优案例，多总结自己的问题集，好记性不如烂笔头。时间一长基本上能做到了然于胸，优化时间自然就缩短了。
比如作者这本书如果通读后，总结实践一下，那也是事半功倍的经验获取。
3． 影响性能的常见因素
抛开设计不合理情况，针对SQL性能影响还存在下列因素：
a.上线功能出现问题临时进行现场调整但没有同步回开发库，后继发布有重现甚至出现新范围的影响。
b.高峰期进行索引的创建，引起大量的阻塞导致性能问题。
c.针对大的临时表进行了大批量的数据操作，但没有及时调整索引碎片和统计信息导致问题。
d.新上线的功能语句在大数据环境测试不充分，导致执行计划异常从而导致性能问题。
e.后台数据库出现了大量的 600 错误，触发了 bug 导致性能问题。
f.数据库双机间出现严重通讯问题，导致的异常sesssion形成性能问题
h.主机的参数设置不合理或存储出现了错误或者光钎卡通路问题导致 IO飙升导致全库性能崩溃。
g.维护人员为了满足客户的临时统计要求建立不合理大索引导致相关表访问的执行计划紊乱导致的性能问题。
i.升级系统后忘记编译失效对象到哦之的性能阻塞访问问题。
j.链路不同甚至是scn 风暴导致的性能问题。
k.表空间不足，消耗完成但未及时处理导致的性能问题。
l.数据库日志目录没有做日常监控，错误 trc 文件没有定期清理导致的数据库挂起性能问题。
m.不合理的数据检索范围太大导致的热点表性能问题。
n.开放的外部接口没有做合理的资源限定导致某一时刻资源消耗过度当值的性能问题。
o.并行建立索引后没能正常关闭导致的并发访问性能问题。
p.一些 JOB不正常执行导致的表锁引起的热点争用引起的SQL性能问题.
q.迁移数据库后关键SQL没有测试执行计划是否正常
4． 学习索引的重要性
索引是一切 sql优化执行的根本，没有索引全表扫描是性能问题之根源。了解索引的结构和检索原理，各种索引的优缺点适用范围。
合理适用排序索引，组合索引。
一张表的索引需要有限制，不是随意增减索引，需要对模块功能涉及的索引合理统筹规划建立。
要合理适用索引就要能正确解读sql的执行计划，可基于执行计划合理选择建立索引。
最核心的原理就是用索引从大范围数据中选取极小的数据集进行处理，这是所有哦SQL调优的核心原则。
5． SQL优化的误区
切忌优化了一条特定sql 带出其他正常sql变不正常。
一些复杂的sQL，要建议开发分拆处理，优化不是万能的。
一些不符合实际需求的 SQL不是优化能处理的，而是在表设计和模块功能设计时就要考虑分析处理的。
SQL优化不是等系统上线后才火热进行的而是在系统设计开始就要考虑各类功能需求和操作，考虑数据量的增长规模，预判数据的分布，然后合理编写高效的SQL，做好大数据环境下的压力测试，及时收集问题SQL进行合理优化处理，
不能等到系统实际上线后才进行优化，一些不合理的功能需要的SQL 到此时基本是无法优化避免的,而是涉及功能改写了。 |
|
楼主: 丸喵喵
IP卡
狗仔卡
发表于 2017-6-12 10:47
显身卡
