优化的分类：（实例优化+库的优化=数据库优化）
一、实例的优化
二、库的优化
三、sql的优化
数据库性能问题，95%由用户所写的sql引起，其他由库引起。
优化步骤：
1、定位问题
1>通过v$ 动态试图
2>通过oem性能菜单
3>通过awr出一个报表
4>oracle内部的一些sql报表
5>oracle内部的addm工具
6>外部工具spoolgnignt
7>自己写一些脚本，定位数据库的一些问题
2、优化
1>程序设计阶段去优化----程序上线之前对数据库进行优化，代价最低，效果最好
指定表空间的大小，表空间的对象可以放到不同的磁盘空间，列的主外键。是否需要设置为自动增长。数据文件放到写性能比较好的磁盘，日志文件也放到写性能比较好的磁盘，控制文件放到读写性能比较好的磁盘
2>程序上线时进行优化
创建索引，创建分区表
3>系统上线以后进行优化 ---基本处理的都是这一阶段，代价高，效果不一定很好
网络的优化，数据库的内存不合理
3、如何优化
从上到下的优化，首先优化应用程序---实例（SGA|PGA）---系统---优化硬件（内存）
4、谁来优化---优化是大调整，需要多部门参与
应用程序有问题------程序开发人员-----DBA告诉他怎么改，问题在哪里
swap设置不合理----系统工程师的参与-----需要达到什么要求，必须告诉系统工程师
数据文件，日志文件的迁移----存储工程师-----将数据库从一个地方迁移到另一个地方
数据库有迁移，必须告诉架构工程师，如果数据库用的DG，或者RAC，也必须告诉网络工程师，怎样设计带宽比较合适。
5、如何去优化
1>一次只优化一个地方，找到问题最严重的地方去优化(如消耗资源最多，执行时间最长)
6、优化步骤
1>准确定位问题---高级DBA才能达到的级别，中级和初级基本凭运气
2>制定处理问题的解决方案
3>实施制定方案，到数据库中执行优化
4>验证优化是否达到效果
5>优化完成后生成一个基线（即快照，当前数据库的性能状况）
AWR------AUTO WORKLOAD REPOSITORY 自动负载资源库，记录了数据库的性能状况
10G----保留7天，ARW报表每天晚上10-2点去收集数据库的变化信息，星期六，星期天全天收集
11G-----awr报表信息默认保留8天
SQL> show parameter timed_statistics;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
timed_statistics boolean TRUE //true表示打开统计信息
SQL> show parameter statistics_level;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL //如果值为basic表示关闭统计信息，typical表示收集自上次收集以来改变的统计信息，all表示所有的统计信息都要收集
SQL> show parameter job;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes integer 1000
SQL>
SQL> show parameter aq;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
aq_tm_processes integer 1 //为0的话，表示关闭统计信息
SQL> desc dba_hist_snapshot; //快照的信息，根据每晚统计的信息来打的快照，一般一个小时会打一个快照
dbms_workload_repository //通过调用包，记录数据库每个小时的运行状态
在数据库最忙的时候做快照一般15min-30min做一次快照，才能真正体现出数据库的性能
SQL> exec dbms_workload_repository.create_snapshot; //手动建快照
PL/SQL procedure successfully completed.
SQL> select snap_id from dba_hist_snapshot ; //查询我们建的快照
exec dbms_workload_repository.drop__snapshot_range(103,199) ; //删除快照
exec dbms_workload_repository.modify__snapshot_settings(15*24*60,15);//快照15分钟做一次，默认保留15天
exec dbms_workload_repository.modify__snapshot_settings（8*24*60，60）；//改回快照默认值，60分钟一次，保留8天SQL> select baseline_id,baseline_name from dba_hist_baseline; //查看数据库的基线
BASELINE_ID BASELINE_NAME
----------- ----------------------------------------------------------------
0 SYSTEM_MOVING_WINDOW
exec dbms_worload_repository.create_baseline(start_sanp_id=>167,end_snap_id=>172,baseline_name=>'b1') //手动创建基线
exec dbms_worload_repository.drop_baseline //删数基线
数据库运行状态的报表：
运行脚本
sql>>@ /opt/u01/oracle/11g/rdbms/admin/awrrpt.sql
>输入类型：html/text
>输入查看那几天的：【今天输1】
>输入要查看开始快照：
>输入要查看结束快照：
>输入报表的名字，绝对路径：
报表中查看的内容：
load profile ---加载资源文件
逻辑读：表示每一秒钟读取的数据，如果值比较大，表示在内存中都能读到数据
物理读：值越小越好，表示用户在DCL，DQL操作在磁盘文件中读取
物理写：值很大表示DML操作很多
分析：硬分析和软分析的总和
硬分析：值越小越好
rollbacks:用户执行的错误操作比较多
instance efficiency percentages:
buffer nowait:理想值为 100%，说明内存中没有出现等待，如果不是100%，说明databuffercache 设置过小，或者是databuffercache的链路出现问题，dbwr进程过少，或者dbwr进程足够，但是磁盘I/O性能不够
buffer hit：表示databuffer cache 命中比较高，逻辑读。值越高越好，值小于95%，就需要调整databuffer cache的大小，或者将数据块keep到内存中。
library hit :库缓冲区，共享的sql,plsql执行计划，需要到到90%以上，如果未达到，1、sharpool设置有问题，2.再不就是用户的语句没有绑定变量，每次都使用的硬分析
execute to parse :执行to分析，执行和分析的百分比，要求在80%左右
分析占用CPU的大小，这个值越小越好
redo nowait:必须达到100%，日志缓冲区设置过小，或者日志缓冲区的链路过少，磁盘I/O出现性能瓶颈
in-memory sort :使用内存排序，最好达到100%，如果没有达到100%需要调整PGA中的排序区
soft parse:软分析的值最好达到95%，如果没有达到就会使用硬分析
latch hit：内存锁 100% ，用户在执行DML操作时出现了锁定冲突，或则死锁，需要DBA处理
non_parse cpu: cpu 的占用，没有占用最好
TOP 5 timed foreground events //出现的最严重的5个性能问题，数据库性能没问题也会出现top5，如果性能出现了问题，一定会出现在top5中
DB CPU :占用数据库cpu
log file sync: 日志链路出了问题
undo segment extension:
shared Pool statistics:
Memory usage :95%-70%之间
建议向导，可以解决
2、
来源：oschina
链接：https://my.oschina.net/u/2918364/blog/812191