<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    姿姿霸霸~~!
    貴在堅(jiān)持!
    posts - 106,  comments - 50,  trackbacks - 0
       

    DB Name

    DB Id

    Instance

    Inst num

    Release

    RAC

    Host

    TEST1212

    3399531915

    test1212

    1

    10.2.0.1.0

    NO

    DANDAN

    Snap Id

    Snap Time

    Sessions

    Cursors/Session

    Begin Snap:

    1

    20-12-10 21:01:03

    15

    2.5

    End Snap:

    2

    20-12-10 22:00:52

    17

    5.4

    Elapsed:

    59.81 (mins)

    DB Time:

    0.83 (mins)

    DBid是唯一的數(shù)據(jù)庫的標(biāo)示,rman中也能看到該值

    C:"Documents and Settings"sure>rman target /

    恢復(fù)管理器: Release 10.2.0.1.0 - Production on 星期一 12 20 22:34:01 2010

    Copyright (c) 1982, 2005, Oracle. All rights reserved.

    連接到目標(biāo)數(shù)據(jù)庫: TEST1212 (DBID=3399531915)

    RMAN>

    DB Time不包括Oracle后臺(tái)進(jìn)程消耗的時(shí)間。如果DB Time遠(yuǎn)遠(yuǎn)小于Elapsed時(shí)間,說明數(shù)據(jù)庫比較空閑。計(jì)算公式:

    59分鐘里(其間收集了2次快照數(shù)據(jù)),數(shù)據(jù)庫耗時(shí)0.83分鐘,系統(tǒng)有1個(gè)CPU,平均CPU耗時(shí)0.83分鐘,CPU利用率只有大約1.38%0.83/59.81)。說明系統(tǒng)壓力非常小(該系統(tǒng)啥都沒做J)

    對(duì)于批量系統(tǒng),數(shù)據(jù)庫的工作負(fù)載總是集中在一段時(shí)間內(nèi)。如果快照周期不在這一段時(shí)間內(nèi),或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時(shí)間,所得出的分析結(jié)果是沒有意義的。這也說明選擇分析時(shí)間段很關(guān)鍵,要選擇能夠代表性能問題的時(shí)間段。

    Cache Sizes

    Begin

    End

    Buffer Cache:

    412M

    408M

    Std Block Size:

    8K

    Shared Pool Size:

    156M

    160M

    Log Buffer:

    6,968K

    顯示SGA中每個(gè)區(qū)域的大小,可用來與初始參數(shù)值比較。

    shared pool主要包括library cache和dictionary cache。library cache用來存儲(chǔ)最近解析(或編譯)后SQL、PL/SQL。library cache用來存儲(chǔ)最近引用的數(shù)據(jù)字典。發(fā)生在library cache或dictionary cache的cache miss代價(jià)要比發(fā)生在buffer cache的代價(jià)高得多。因此shared pool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache,也就是盡可能的保持被命中(即傳說中的命中率)。

    Load Profile

    Per Second

    Per Transaction

    Redo size:

    4,600.89

    18,956.88

    Logical reads:

    427.08

    1,759.70

    Block changes:

    29.02

    119.57

    Physical reads:

    1.84

    7.57

    Physical writes:

    0.37

    1.52

    User calls:

    0.11

    0.47

    Parses:

    5.13

    21.14

    Hard parses:

    0.59

    2.44

    Sorts:

    3.03

    12.47

    Logons:

    0.03

    0.14

    Executes:

    17.41

    71.72

    Transactions:

    0.24

    % Blocks changed per Read:

    6.80

    Recursive Call %:

    99.93

    Rollback per transaction %:

    0.00

    Rows per Sort:

    189.64

     

    顯示數(shù)據(jù)庫負(fù)載概況,將之與基線數(shù)據(jù)比較才具有更多的意義,如果每秒或每事務(wù)的負(fù)載變化不大,說明應(yīng)用運(yùn)行比較穩(wěn)定。單個(gè)的報(bào)告數(shù)據(jù)只說明應(yīng)用的負(fù)載情況,絕大多數(shù)據(jù)并沒有一個(gè)所謂“正確”的值,然而Logons大于每秒1~2個(gè)、Hard parses大于每秒100、全部parses超過每秒300表明可能有爭用問題

    Redo size:每秒/每事務(wù)產(chǎn)生的redo大小(單位字節(jié)),可標(biāo)志數(shù)據(jù)庫任務(wù)的繁重程序。

    Logical reads:每秒/每事務(wù)邏輯讀的塊數(shù)

    Block changes:每秒/每事務(wù)修改的塊數(shù)

    Physical reads:每秒/每事務(wù)物理讀的塊數(shù)

    Physical writes:每秒/每事務(wù)物理寫的塊數(shù)

    User calls:每秒/每事務(wù)用戶call次數(shù)

    Parses:SQL解析的次數(shù)

    Hard parses:其中硬解析的次數(shù),硬解析太多,說明SQL重用率不高。

    Sorts:每秒/每事務(wù)的排序次數(shù)

    Logons:每秒/每事務(wù)登錄的次數(shù)

    Executes:每秒/每事務(wù)SQL執(zhí)行次數(shù)

    Transactions:每秒事務(wù)數(shù)

    Blocks changed per Read:表示邏輯讀用于修改數(shù)據(jù)塊的比例

    Recursive Call:遞歸調(diào)用占所有操作的比率

    Rollback per transaction:每事務(wù)的回滾率

    Rows per Sort:每次排序的行數(shù)

     

    Instance Efficiency Percentages (Target 100%)

    Buffer Nowait %:

    100.00

    Redo NoWait %:

    100.00

    Buffer Hit %:

    99.57

    In-memory Sort %:

    100.00

    Library Hit %:

    92.37

    Soft Parse %:

    88.46

    Execute to Parse %:

    70.52

    Latch Hit %:

    99.99

    Parse CPU to Parse Elapsd %:

    84.03

    % Non-Parse CPU:

    80.34

    這一段包含了Oracle關(guān)鍵指標(biāo)的內(nèi)存命中率及其它數(shù)據(jù)庫實(shí)例操作的效率。

    Buffer Hit Ratio:也稱Cache Hit Ratio,Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節(jié)相同,這一節(jié)也沒有所謂“正確”的值,而只能根據(jù)應(yīng)用的特點(diǎn)判斷是否合適。在一個(gè)使用直接讀執(zhí)行大型并行查詢的DSS環(huán)境,20%的Buffer Hit Ratio是可以接受的,而這個(gè)值對(duì)于一個(gè)OLTP系統(tǒng)是完全不能接受的。根據(jù)Oracle的經(jīng)驗(yàn),對(duì)于OLTPT系統(tǒng),Buffer Hit Ratio理想應(yīng)該在90%以上。

    Buffer Nowait:表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。

    buffer hit:表示進(jìn)程從內(nèi)存中找到數(shù)據(jù)塊的比率,監(jiān)視這個(gè)值是否發(fā)生重大變化比這個(gè)值本身更重要。對(duì)于一般的OLTP系統(tǒng),如果此值低于80%,應(yīng)該給數(shù)據(jù)庫分配更多的內(nèi)存。

    Redo NoWait:表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。如果太低(可參考90%閥值),考慮增加LOG BUFFER

    library hit:表示Oracle從Library Cache中檢索到一個(gè)解析過的SQL或PL/SQL語句的比率,當(dāng)應(yīng)用程序調(diào)用SQL或存儲(chǔ)過程時(shí),Oracle檢查Library Cache確定是否存在解析過的版本,如果存在,Oracle立即執(zhí)行語句;如果不存在,Oracle解析此語句,并在Library Cache中為它分配共享SQL區(qū)。低的library hit ratio會(huì)導(dǎo)致過多的解析,增加CPU消耗,降低性能。如果library hit ratio低于90%,可能需要調(diào)大shared pool區(qū)

    Latch Hit:Latch是一種保護(hù)內(nèi)存結(jié)構(gòu)的鎖,可以認(rèn)為是SERVER進(jìn)程獲取訪問內(nèi)存數(shù)據(jù)結(jié)構(gòu)的許可。要確保Latch Hit>99%,否則意味著Shared Pool latch爭用,可能由于未共享的SQL,或者Library Cache太小,可使用綁定變更或調(diào)大Shared Pool解決

    Parse CPU to Parse Elapsd:解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間),越高越好。

    Non-Parse CPU:SQL實(shí)際運(yùn)行時(shí)間/(SQL實(shí)際運(yùn)行時(shí)間+SQL解析時(shí)間),太低表示解析消耗時(shí)間過多。

    Execute to Parse:是語句執(zhí)行與分析的比例,如果要SQL重用率高,則這個(gè)比例會(huì)很高。該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多。

    In-memory Sort:在內(nèi)存中排序的比率,如果過低說明有大量的排序在臨時(shí)表空間中進(jìn)行。考慮調(diào)大PGA。

    Soft Parse:軟解析的百分比(softs/softs+hards),近似當(dāng)作sql在共享區(qū)的命中率,太低則需要調(diào)整應(yīng)用使用綁定變量。

    Shared Pool Statistics

    Begin

    End

    Memory Usage %:

    45.69

    56.15

    % SQL with executions>1:

    52.03

    32.99

    % Memory for SQL w/exec>1:

    87.15

    60.31

    Memory Usage %:對(duì)于一個(gè)已經(jīng)運(yùn)行一段時(shí)間的數(shù)據(jù)庫來說,共享池內(nèi)存使用率,應(yīng)該穩(wěn)定在75%-90%間,如果太小,說明Shared Pool有浪費(fèi),而如果高于90,說明共享池中有爭用,內(nèi)存不足

    SQL with executions>1:執(zhí)行次數(shù)大于1的sql比率,如果此值太小,說明需要在應(yīng)用中更多使用綁定變量,避免過多SQL解析。

    Memory for SQL w/exec>1:執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存的占比。

    Top 5 Timed Events

    Event

    Waits

    Time(s)

    Avg Wait(ms)

    % Total Call Time

    Wait Class

    CPU time

    37

    74.1

    db file sequential read

    3,312

    12

    4

    24.1

    User I/O

    control file parallel write

    1,198

    5

    4

    9.5

    System I/O

    os thread startup

    58

    2

    33

    3.9

    Concurrency

    db file scattered read

    432

    2

    4

    3.4

    User I/O

     


    posted on 2010-12-20 23:06 xrzp 閱讀(641) 評(píng)論(0)  編輯  收藏 所屬分類: oracle-優(yōu)化

    <2010年12月>
    2829301234
    567891011
    12131415161718
    19202122232425
    2627282930311
    2345678

    常用鏈接

    留言簿(4)

    隨筆分類

    隨筆檔案

    好友的blog

    搜索

    •  

    積分與排名

    • 積分 - 117322
    • 排名 - 500

    最新評(píng)論

    閱讀排行榜

    評(píng)論排行榜

    主站蜘蛛池模板: 一级免费黄色大片| 亚洲高清无在码在线无弹窗| 国产精品色午夜视频免费看| 成人免费淫片在线费观看| 18禁网站免费无遮挡无码中文| 91久久精品国产免费直播| 69pao强力打造免费高清| 最近免费中文字幕大全免费版视频 | 色在线亚洲视频www| 亚洲国产精品网站久久| 亚洲一卡2卡4卡5卡6卡在线99| 亚洲最大的黄色网| 亚洲精品自偷自拍无码| 亚洲国产成人久久一区二区三区| 亚洲hairy多毛pics大全| 免费福利在线观看| 久久久久久国产a免费观看不卡| 国产精品成人69XXX免费视频| 亚洲精品无码专区久久| 青草久久精品亚洲综合专区| 黄色一级毛片免费看| 国产无遮挡色视频免费观看性色| 日本视频免费高清一本18| 国产精品免费网站| 国产精品va无码免费麻豆| 亚洲国产精品一区二区九九 | 57pao一国产成永久免费| 99久久精品日本一区二区免费| 国语成本人片免费av无码| 国产成人免费永久播放视频平台| 亚洲最大av无码网址| 亚洲国产第一页www| 精品国产成人亚洲午夜福利| 黄床大片30分钟免费看| 国内精品免费久久影院| 95免费观看体验区视频| 精品免费国产一区二区三区| 在线观看国产区亚洲一区成人| 老汉色老汉首页a亚洲| 亚洲精品无码一区二区| 国产视频精品免费视频|