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%之間

 

建議嚮導，能夠解決

 

 

 

 

 

 

 

 

 

 

 

 

 

 

二、