性能优化介绍
1.性能计划
-
增加硬件配置；应用系统设计改善
-
良好的应用设计可以更好的适应负载变化，而增加硬件在可以暂时缓解，但是持续性差。
2.实例调优
-
识别性能瓶颈然后采取一定措施去改变或减少瓶颈。
-
参照的基线包括：事务量，响应时间，数据库统计信息，操作系统统计信息，磁盘统计信息，网络统计信息
-
症状包括：Slow physical I/O，latch 征用，CPU过载
调优时机：
1）事前监控如：主机资源监控工具，数据库诊断工具如EM2）消除瓶颈如：修改应用，修改ORACLE参数,调整硬件配置
3.Sql调优
SQL语句的执行依赖于统计信息，准确的统计信息才能找到更适合的执行计划。同样开发和维护人员更了解SQL执行的步骤才能书写出更高效的sql语句。
4.性能优化工具
-
自动性能调优
AWR,ADDM,ASH,SQL TUNING ADVISTOR,SQL ACCESS ADVISTOR……etd -
数据库附加组件
V$ Performance views 具体参见文档
设计与开发性能
1.理解投资选择
硬件投资见效快，不可持续；性能应该是设计到系统中。
2.理解系统扩展性
扩展性是系统处理更高负载的能力，如果负载加倍，是否使用加倍的资源就能满足要求?
举例：
1）用户大量增加导致并发量
2）增加大量锁
3）增加操作系统负载
4）数据体量增加导致事务请求时间长
5）BAD SQL和索引导致大量逻辑IO
6）数据对象需要更长时间维护到时可用性减小
7）硬件过载
8）大事务量的扫描导致不必要IO资源短缺
9）过量的网络请求
10）内存分配导致分页或换出
11）过多的进程或线程
应用程序设计阶段就应该考虑系统的扩展性
3.扩展性影响因素
1)应用设计不合理，如不好的对象设计导致BAD SQL
2）不好的事务导致锁问题，不好的连接管理导致响应时间下降
3）硬件选择问题
4）所有的软件都有扩展性和资源使用限制
5）硬件的使用限制
4.系统架构
-
硬件组件
CPU,MEMORY,I/O SUBSYSTEM,NETWORK -
软件组件
用户前端程序，业务逻辑核心，用户请求和资源管理，数据库核心
依需求配置更合理的系统架构:
1)流程驱动系统
2)多用户驱动系统
例如：
a.多少用户使用该系统，少量几个，中量，无限制用户
b.用户在哪，如何交互，网络速度，访问的数据量
c.是否只读访问，相应时间要求，是否24小时在线，是否允许异步，数据库大小
5.应用设计的原则
- 简单原则
表过于复杂，sql过长，重复索引，大量非认证请求 - 数据模型
使用数据模型来进行前期设计 - 表和索引的设计
1)表的设计要在性能和灵活性上折中，适当的添加冗余字段有助于提高性能
2)专注于核心表的设计，非核心的表在日后迭代开发的时候较容易优化
3)索引设计也是一个迭代的过程:
a.复合索引或索引组织表，相对逻辑读少
b.不同的索引类型，例如B-TREE\BITMAP\FUNCTION-INDEX\分区索引\反序索引
c.索引的维护代价也很大，是把双刃剑
d.索引序列化问题是指使用时间或序列做索引列，这样会造成倾斜，是索引处于非平衡的状态。
e.索引列的顺序，也同样对索引的效率起到关键影响
- SQL高效的执行
1)连接管理，因为连接是昂贵的
2)游标的使用和管理，众所周知的硬解析和软解析甚至快速软解析
3)一次解析多次执行是非常好的游标使用方式，绑定变量的使用同样也是影响系统扩展的关键
- 应用系统的实现方式
1)开发环境，语言或组件的选择不能限制性能
a.业务逻辑使用JAVA或PL/SQL移植性好；
b.如果选择第三方软件，不能使用绑定变量和连接管理的，尽量不用2
2)业务逻辑与sql要尽量分开
3)如果条件可以尽量使用缓存技术，select sysdate from dual会增加60%的工作负载
- 负载的测试与实施
1)索引和表大小的估计，索引的碎片情况存储空间的监控和管理
2)负载的估计和压力测试，压力测试可以较为准确的反应io子系统性能
3)测试与验证应用，使用ADDM、记录所有SQL和执行计划
- 发布行的应用系统
发布应用可以采用渐进割接或一步到位的割接方式
性能检查项目如下:
1)控制文件设置
2)设置最小化的初始化参数，尽量使用DEFAULT设置
3)合理设置中间件连接池
4)验证应用的SQL语句正确使用CURSOR
5)一旦系统成功上线，建议建立基线
性能改善方法
性能优化首先是发现瓶颈，然后依次解决瓶颈，在解决第一个瓶颈的时候性能不一定立刻就得到提升，因为第二个瓶颈的出现也许覆盖了上一次的优化结果。优化是一个迭代的过程不断发现不断修改。如我要在3个小时内完成1,000,000个账户处理；在系统的高峰时间，系统的响应时间不能超过5s；1点种的处理单量在25,000笔等。
- 通用性能改善
通用步骤如下：
前提：同用户沟通得到反馈
1)获得系统全方面的统计数据，操作系统，数据库，中间件
2)全方位从操作系统角度检查系统相关的硬件信息，是否有错误和诊断
3)查看系统top10错误，可以使用ADDM查看，选其中相关性高的进一步分析
4)记录分析查看的内容，找到其中线索进一步分析
5)提出改进方法，并评估风险对系统的影响，一次做一个动作，然后观察变化
6)通常系统的宕机时间有限制，有时候需要一次做出多个动作，原则上保证每个动作有隔离性。
7)检查系统是否达到了预期，关键是用户的感知，否则继续查找另一个瓶颈然后迭代
分析步骤举例：
1）可以使用ADDM作为性能分析的入口
2）可以采用手动方式最后汇总性能问题
a.在单用户操作的时候，响应时间或批量时间是否满足要求？
b.CPU使用率使用情况，先查看SYSCPU使用率，然后查看非数据库进程的，最后查看数据库
c.CPU没有过载话，系统存在串行或不可扩展的等待，找到等待解决
3）Top10 Mistakes
a.Bad connections
b.Bad cursor uses
c.Bad sql
d.错误的使用了隐含参数
e.IO子系统设计缺陷
f.日志文件过小或过少
g.使用非ASSM管理表，数据库访问串行
h.长时间全表扫描
i.过高的递归SQL
j.应用系统的发布或迁移，缺少索引或同级信息等
- 紧急情况性能改善
数据库从稳定的运行状态转变到用户感知受限的状态，需要DBA介入迅速的分析问题并解决问题。在处理过程中尽量记录诊断信息以备事后继续分析。
一般步骤:
概述性能问题同时收集相关症状
1)听取用户反馈
2)询问是否有新部署或外部环境发生变化
3)使用自动诊断管理
4)全面检查硬件层面的指标，磁盘，内存，cpu，网络，最后是应用系统
5)判断是CPU问题还是等待时间问题
a.是否会话数达到操作系统限制
b.相应的活动回话是否执行了过多的逻辑读
c.SQL语句执行计划是否选择了一个非最优的
d.初始化参数设置错误
e.部署了新应用造成的问题
6)在实施处理方法的时候，可能包括应用重启或限制应用请求等方法
7)检查系统是否趋于稳定，然后根据上述的优化步奏对系统做进一步分析。
数据库等待问题，根据oracle OWI进行进一步诊断，具体参照ORACLE 手册
