ORALCE---优化

优化的分类：（实例优化+库的优化=数据库优化）

1、实例的优化

2、库的优化

3、sql的优化

数据库性能问题，95%由用户所写的sql引发，其余由库引发。

优化步骤：

一、定位问题

1>经过v$ 动态试图

2>经过oem性能菜单

3>经过awr出一个报表

4>oracle内部的一些sql报表

5>oracle内部的addm工具

6>外部工具spoolgnignt

7>本身写一些脚本，定位数据库的一些问题

二、优化

1>程序设计阶段去优化----程序上线以前对数据库进行优化，代价最低，效果最好

指定表空间的大小，表空间的对象能够放到不一样的磁盘空间，列的主外键。是否须要设置为自动增加。数据文件放到写性能比较好的磁盘，日志文件也放到写性能比较好的磁盘，控制文件放到读写性能比较好的磁盘

2>程序上线时进行优化

建立索引，建立分区表

3>系统上线之后进行优化 ---基本处理的都是这一阶段，代价高，效果不必定很好

网络的优化，数据库的内存不合理

三、如何优化

从上到下的优化，首先优化应用程序---实例（SGA|PGA）---系统---优化硬件（内存）

四、谁来优化---优化是大调整，须要多部门参与

应用程序有问题------程序开发人员-----DBA告诉他怎么改，问题在哪里

swap设置不合理----系统工程师的参与-----须要达到什么要求，必须告诉系统工程师

数据文件，日志文件的迁移----存储工程师-----将数据库从一个地方迁移到另外一个地方

数据库有迁移，必须告诉架构工程师，若是数据库用的DG，或者RAC，也必须告诉网络工程师，怎样设计带宽比较合适。

五、如何去优化

1>一次只优化一个地方，找到问题最严重的地方去优化(如消耗资源最多，执行时间最长)

六、优化步骤

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%以上，若是未达到，一、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%之间

 

建议向导，能够解决

 

 

 

 

 

 

 

 

 

 

 

 

 

 

二、