建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容主要講解“Oracle AWR內(nèi)容有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Oracle AWR內(nèi)容有哪些”吧!
成都創(chuàng)新互聯(lián)服務項目包括淮濱網(wǎng)站建設、淮濱網(wǎng)站制作、淮濱網(wǎng)頁制作以及淮濱網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，淮濱網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到淮濱省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
1.AWR報告頭信息
| DB Name | DB Id | Unique Name | Role | Edition | Release | RAC | CDB |
|---|---|---|---|---|---|---|---|
| KTDB | 1107793954 | ktdb | PRIMARY | EE | 19.0.0.0.0 | YES | NO |
| Instance | Inst Num | Startup Time |
|---|---|---|
| ktdb2 | 2 | 02-3月 -20 19:35 |
| Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
|---|---|---|---|---|---|
| hn-ekdb2 | Linux x86 64-bit | 80 | 80 | 4 | 753.98 |
| Snap Id | Snap Time | Sessions | Cursors/Session | Instances | |
|---|---|---|---|---|---|
| Begin Snap: | 5339 | 14-5月 -20 08:00:03 | 159 | .5 | 4 |
| End Snap: | 5342 | 14-5月 -20 11:00:14 | 168 | .6 | 4 |
| Elapsed: | 180.17 (mins) | ||||
| DB Time: | 1.23 (mins) |
? DB Name ：數(shù)據(jù)庫名字 DBid: 數(shù)據(jù)庫id
? Elapsed:采樣時間段
? DB Time:用戶操作花費的時間,不包括Oracle后臺進程消耗的時間
? DB Time遠小于Elapsed Time說明數(shù)據(jù)庫比較空閑
在180分鐘里（其間收集了3次快照數(shù)據(jù)），數(shù)據(jù)庫耗時1.23分鐘.
可是對于批量系統(tǒng)，數(shù)據(jù)庫的工作負載總是集中在一段時間內(nèi)。如果快照周期不在這一段時間內(nèi)，或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時間，所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵，要選擇能夠代表性能問題的時間段。
2. Load Profile
Load Profile
| Per Second | Per Transaction | Per Exec | Per Call | |
|---|---|---|---|---|
| DB Time(s): | 0.0 | 1.2 | 0.00 | 0.01 |
| DB CPU(s): | 0.0 | 0.6 | 0.00 | 0.01 |
| Background CPU(s): | 0.1 | 21.8 | 0.03 | 0.00 |
| Redo size (bytes): | 1,495.0 | 256,536.7 | ||
| Logical read (blocks): | 384.5 | 65,979.0 | ||
| Block changes: | 29.3 | 5,026.5 | ||
| Physical read (blocks): | 18.0 | 3,095.9 | ||
| Physical write (blocks): | 0.6 | 93.7 | ||
| Read IO requests: | 3.8 | 656.2 | ||
| Write IO requests: | 0.3 | 53.9 | ||
| Read IO (MB): | 0.1 | 24.2 | ||
| Write IO (MB): | 0.0 | 0.7 | ||
| IM scan rows: | 0.0 | 0.0 | ||
| Session Logical Read IM: | 0.0 | 0.0 | ||
| Global Cache blocks received: | 3.9 | 667.2 | ||
| Global Cache blocks served: | 191.8 | 32,906.7 | ||
| User calls: | 0.6 | 98.2 | ||
| Parses (SQL): | 3.5 | 598.3 | ||
| Hard parses (SQL): | 0.0 | 1.4 | ||
| SQL Work Area (MB): | 0.0 | 3.6 | ||
| Logons: | 0.1 | 18.7 | ||
| User logons: | 0.0 | 0.4 | ||
| Executes (SQL): | 3.7 | 639.6 | ||
| Rollbacks: | 0.0 | 0.0 | ||
| Transactions: | 0.0 |
? Per Second 和Per Transaction：這兩部分是數(shù)據(jù)庫資源負載的一個明細列表，分割成每秒鐘的資源負載和每個事務的資源負載情況
? Redo size：每秒/每個事務 產(chǎn)生的redo量 (單位字節(jié)) 標志數(shù)據(jù)庫的繁忙程度
? logical reads：每秒/每個事務 產(chǎn)生的邏輯讀的塊數(shù)
? block changes：每秒/每個事務 改變的數(shù)據(jù)塊數(shù)
? physical reads：每秒/每個事務 產(chǎn)生的物理讀
? physical writes：每秒/每個事務 產(chǎn)生的物理寫的塊數(shù)
? user calls：每秒/每個事務 用戶的調(diào)用次數(shù)
? parses：每秒/每個事務 分析次數(shù)
? hard parses: 每秒/每個事務 硬分析次數(shù)
? SQL Work Area：每秒/每個事物 排序次數(shù)
? logons: 每秒/每個事務 登錄數(shù)據(jù)庫次數(shù)
? executes: 每秒/每個事務 SQL的執(zhí)行次數(shù)
? rollbacks: 每秒/每個事物回滾次數(shù)
? transactions: 每秒的事務數(shù)
需要注意：
1）logical reads和physical reads，同時也可以得到平均每個邏輯讀導致多少物理讀，即18/384 平均每個事務產(chǎn)生了65979個邏輯讀，這個數(shù)字應該越小越好。
2）parses 和hard parses：從表中可以看到cpu平均每秒進行了3.5個解析（超過100個應該注意），每秒進行0（超過10個應該注意）次硬解析，即cpu每秒要處理0個全新的sql，應該說很閑。
3.instance efficiency Percentages：
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 99.99 | Redo NoWait %: | 100.00 |
| Buffer Hit %: | 95.96 | In-memory Sort %: | 100.00 |
| Library Hit %: | 99.57 | Soft Parse %: | 99.76 |
| Execute to Parse %: | 6.46 | Latch Hit %: | 99.95 |
| Parse CPU to Parse Elapsd %: | 25.76 | % Non-Parse CPU: | 99.74 |
| Flash Cache Hit %: | 0.00 |
? Buffer Nowait%：表示在內(nèi)存獲得數(shù)據(jù)的未等待比例
（不應低于99%）? Buffer Hit%：表示進程從內(nèi)存中找到數(shù)據(jù)塊的比率，內(nèi)存數(shù)據(jù)塊命中率。
（不應低于99%）? Library Hit%：表示共享池中SQL解析的命中率。
(不應低于95%） 如果過小，說明該數(shù)據(jù)庫中可能存在library cache的爭用。? Execute to Parse：是語句執(zhí)行與解析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執(zhí)行的次數(shù)越多。本數(shù)據(jù)庫為6.46%，說明有93.54%的sql為新sql。? Parse CPU to Parse Elapsd：解析總時間中消耗總CPU的時間百分比? Redo NoWait：表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。? In-memory sort%：在內(nèi)存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。（考慮調(diào)大PGA）? Soft Parse%：軟解析的百分比（softs/softs+hards），太低說明SQL重用率不好，則需要調(diào)整應用使用綁定變量。（不應低于百分之95）? Latch Hit：Latch是一種保護內(nèi)存結構的鎖，可以認為是SERVER進程獲取訪問內(nèi)存數(shù)據(jù)結構的許可。（如果此數(shù)值低于95%說明數(shù)據(jù)庫存在嚴重問題）? Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。
4.shared pool statistics：
Shared Pool Statistics
| Begin | End | |
|---|---|---|
| Memory Usage %: | 85.83 | 85.92 |
| % SQL with executions>1: | 91.54 | 92.23 |
| % Memory for SQL w/exec>1: | 85.45 | 86.42 |
? Memory Usage %：對于一個已經(jīng)運行一段時間的數(shù)據(jù)庫來說，共享池內(nèi)存使用率，被使用的部分占shared pool總尺寸的百分比。這個值應保持適中，(如85%）,如果太高，則會引起shared pool中的對象被刷出內(nèi)存，從而導致sql語句的硬解析增加，太低則浪費內(nèi)存；? SQL with executions>1：執(zhí)行次數(shù)大于1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。? Memory for SQL w/exec>1：執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存的占比。
5.event wait
Top 10 Foreground Events by Total Wait Time
| Event | Waits | Total Wait Time (sec) | Avg Wait | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU | 37.8 | 51.4 | |||
| gc cr multi block mixed | 2,606 | 27.5 | 10.55ms | 37.4 | Cluster |
| db file scattered read | 2,217 | 2.8 | 1.27ms | 3.8 | User I/O |
| gc cr block 3-way | 2,674 | 1.3 | 493.28us | 1.8 | Cluster |
| gc cr multi block grant | 2,600 | 1.2 | 461.59us | 1.6 | Cluster |
| db file parallel read | 803 | 1 | 1.25ms | 1.4 | User I/O |
| Sync ASM rebalance | 672 | 1 | 1.47ms | 1.3 | Other |
| IPC send completion sync | 2,206 | .8 | 381.13us | 1.1 | Other |
| enq: PS - contention | 1,173 | .5 | 463.95us | .7 | Other |
| log file sync | 23 | .5 | 19.77ms | .6 | Commit |
按所占等待時間的比例倒序列示。當我們調(diào)優(yōu)時，總希望觀察到最顯著的效果，因此應當從這里入手確定我們下一步做什么。
通常，在沒有問題的數(shù)據(jù)庫中，CPU time總是列在第一個。
6.SQL資源消耗定位：
SQL ordered by Elapsed Time：
記錄了執(zhí)行總和時間的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行時間總和，而不是單次SQL執(zhí)行時間）。
? Elapsed Time(S): SQL語句執(zhí)行用總時長，此排序就是按照這個字段進行的。注意該時間不是單個SQL跑的時間，而是監(jiān)控范圍內(nèi)SQL執(zhí)行次數(shù)的總和時間。單位時間為秒 Elapsed Time = CPU Time + Wait Time? CPU Time(s): 為SQL語句執(zhí)行時CPU占用時間總時長，此時間會小于等于Elapsed Time時間。單位時間為秒。? Executions: SQL語句在監(jiān)控范圍內(nèi)的執(zhí)行次數(shù)總計。? Elap per Exec(s): 執(zhí)行一次SQL的平均時間。單位時間為秒。? % Total DB Time: 為SQL的Elapsed Time時間占數(shù)據(jù)庫總時間的百分比。? SQL ID: SQL語句的ID編號，點擊之后就能導航到下邊的SQL詳細列表中，點擊IE的返回可以回到當前SQL ID的地方。? SQL Module: 顯示該SQL是用什么方式連接到數(shù)據(jù)庫執(zhí)行的，如果是用SQL*Plus或者PL/SQL鏈接上來的那基本上都是有人在調(diào)試程序。一般用前臺應用鏈接過來執(zhí)行的sql該位置為空。? SQL Text: 簡單的sql提示，詳細的需要點擊SQL ID。
SQL ordered by CPU Time:
記錄了執(zhí)行占CPU時間總和時間最長的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占CPU時間總和，而不是單次SQL執(zhí)行時間)。
· %Total - CPU Time as a percentage of Total DB CPU
· %CPU - CPU Time as a percentage of Elapsed Time
· %IO - User I/O Time as a percentage of Elapsed Time
SQL ordered by Gets:
記錄了執(zhí)行占總buffer gets(邏輯IO)的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占Gets總和，而不是單次SQL執(zhí)行所占的Gets).
· %Total - Buffer Gets as a percentage of Total Buffer Gets
SQL ordered by Reads:
記錄了執(zhí)行占總磁盤物理讀(物理IO)的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占磁盤物理讀總和，而不是單次SQL執(zhí)行所占的磁盤物理讀)。
· %Total - Physical Reads as a percentage of Total Disk Reads
SQL ordered by Executions:
記錄了按照SQL的執(zhí)行次數(shù)排序的TOP SQL。該排序可以看出監(jiān)控范圍內(nèi)的SQL執(zhí)行次數(shù)。
SQL ordered by Parse Calls:
記錄了SQL的軟解析次數(shù)的TOP SQL。
SQL ordered by Sharable Memory:
記錄了SQL占用library cache的大小的TOP SQL。
Sharable Mem (b)：占用library cache的大小。單位是bytes。
主要針對ordered by Elapsed time,orderedby CPU time,orderedby gets,orderedby read排名前三SQL進行觀察并調(diào)優(yōu).
7.IO Stats -->Tablespace IO Stats
（在樣例AWR中沒有收集該信息，所以使用一個樣例）
Tablespace | Reads | Av Reads/s | Av Rd(ms) | Av Blks/Rd | Writes | Av Writes/s | Buffer Waits | Av Buf Wt(ms) |
SYSAUX | 9,553 | 0 | 4.07 | 1.65 | 19,729 | 0 | 0 | 0.00 |
UNDOTBS | 7,879 | 0 | 3.21 | 1.00 | 8,252 | 0 | 20 | 5.50 |
SYSTEM | 2,496 | 0 | 4.74 | 1.62 | 4,469 | 0 | 0 | 0.00 |
USERS | 364 | 0 | 3.08 | 1.57 | 4 | 0 | 0 | 0.00 |
TEMP | 34 | 0 | 3.24 | 12.35 | 25 | 0 | 0 | 0.00 |
TEST2 | 4 | 0 | 47.50 | 1.00 | 4 | 0 | 0 | 0.00 |
1）可以找到具有頻繁讀寫活動的表空間或數(shù)據(jù)文件，如果臨時表空間的寫入數(shù)量最高，說明排序太多太大；
2）從AVG BLKS/RD列可以看出，哪些表空間上經(jīng)歷了最多的全表掃描，如果值大于1，則應該將該值與初始化參數(shù)db_file_multiblock_read_count的值進行比較，如果他們越接近，說明在該表空間上進行的大部分是全表掃描；
3）檢查AV RD(MS),該列表明I/O讀的時間，值應該小于20ms，如果過大應該檢查是否將讀寫很頻繁的文件放在了同一個磁盤上。
注意：
對于帶緩存的磁盤I/O時間通常少于1ms.
在init.ora文件中可以設置參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT有助于磁盤讀取時間，該參數(shù)控制在全表掃描時一次I/O中讀入的數(shù)據(jù)塊數(shù)量，這將減少掃描一張表所需的I/O數(shù)量，從而提高全表掃描的性能。但是，設置該參數(shù)的結果是優(yōu)化器可能會執(zhí)行更多的全表掃描，所以需要將OPTIMIZER_INDEX_COST_ADJ設為一個值，例如10，來消除這個問題，并且驅(qū)動索引的使用。
8.Segment Statistics
1）Segments by Logical Reads或Segments by Physical Reads
可以找到邏輯讀或物理讀比較大的對象，并查找原因，是否可以通過創(chuàng)建新索引、或采用分區(qū)表等來降低對象的邏輯讀以及物理讀；
2）Segments by Row Lock Waits
通過這個報表可以找到獲得行級鎖最嚴重的對象，需要跟開發(fā)人員探討解決方法；
3）Segments by ITL Waits
這個報表可以標明獲得ITL等待最嚴重的對象，如果發(fā)現(xiàn)了ITL等待很嚴重的對象，則應該將對象的initrans參數(shù)設置為并發(fā)操作該對象的進程個數(shù)；
4）Segments by Buffer Busy Waits：
Owner | Tablespace Name | Object Name | Subobject Name | Obj. Type | Obj# | Dataobj# | Buffer Busy Waits | % of Capture |
SYS | SYSAUX | SYS_LOB0000007450C00009$$ | SYS_LOB_P4025 | LOB PARTITION | 99696 | 99696 | 2 | 66.67 |
SYS | SYSTEM | SEG$ | TABLE | 14 | 8 | 1 | 33.33 |
獲得buffer busy waits最嚴重的對象。Buffer busy waits產(chǎn)生原因就是數(shù)據(jù)分布問題。解決的關鍵是優(yōu)化那些掃描了過多數(shù)據(jù)塊的sql語句，減少他們要掃描的數(shù)據(jù)塊。如果已經(jīng)優(yōu)化了sql語句，則可以考慮增大pctfree的值，從而減少一個數(shù)據(jù)塊中能夠包含的數(shù)據(jù)行數(shù)，從而將對象的數(shù)據(jù)行分部到更多的數(shù)據(jù)塊里去，或者建立hash分區(qū)表，使數(shù)據(jù)重新分布。
9.實例活動統(tǒng)計數(shù)據(jù)
比較在內(nèi)存中和磁盤中的排序量，如果磁盤排序太高就需要增加PGA_AGGREGATE_TARGET(或者舊版本中增大SORT_AREA_SIZE)
如果磁盤的讀操作較高，表明可能執(zhí)行了全表掃描，如果目前存在大量的較大的對較大表的全表掃描，就應當評估最常用的查詢,并通過增加索引來提高效率。大量的非一致性讀操作意味著使用了過多的索引或者使用了非選擇性索引。如果臟讀緩沖區(qū)數(shù)量高于所請求的空閑緩沖區(qū)的數(shù)量（超過5%），那么說明DB_CACHE_SIZE太小，或者沒有建立足夠多的檢查點。如果葉節(jié)點的分裂數(shù)量很高可以考慮重建已增長或已經(jīng)碎化的索引。
consistent gets:沒有使用select for update子句的查詢在緩沖中訪問的數(shù)據(jù)塊數(shù)量，這個數(shù)量加上DB BLOCK GETS統(tǒng)計信息的值就是邏輯讀操作總數(shù)
DB BLOCK GETS:使用了INSERT UPDATE DELETE OR SELECT FOR UPDATE語句在緩存中訪問的數(shù)據(jù)塊數(shù)量。
PHYSICAL READS:沒有從緩存中度取得數(shù)據(jù)量?？梢詮拇疟P，操作系統(tǒng)緩存或者磁盤緩存中讀取，以滿足SELECT,SELECT FOR UPDATE,INSERT,UPDATE,DELETE語句
LOGICAL READS=CONSISTENT GETS+DB BLOCK GETS.
緩存命中率HIT RATIO=(LOGICAL READS- PHYSICAL READS)/LOGICAL READS *100%
=(CONSISTENT GETS+DB BLOCK GETS- PHYSICAL READS)/(CONSISTENT GETS+DB BLOCK GETS) *100%
緩存命中率應該高于95%，否則需要增加DB_CACHE_SIZE。
DIRTY BUFFERS INSPECTED:從LRU列表中清除掉的臟讀（經(jīng)過修改的）數(shù)據(jù)緩沖區(qū)的數(shù)量，如果此值超過0，可以考慮增加DB_WR進程。
FREE BUFFER INSPECTED:由于是臟讀數(shù)據(jù)、被固定或者正忙等原因兒跳過的緩沖區(qū)數(shù)量。如果數(shù)量很大的話就說明緩沖區(qū)緩存太小了。
PARSE COUNT:一條SQL語句被解析的次數(shù)。
RECURSIVE CALLS:數(shù)據(jù)庫中遞歸調(diào)用的數(shù)量。如果某個進程中的遞歸調(diào)用數(shù)量大于4，就應當檢查數(shù)據(jù)字典緩存的命中率，以及是否有表或者索引的范圍過大。除非使用了大量PL/SQL，否則在用戶調(diào)用中，遞歸調(diào)用所占的比例應該低于10%。
REDO SIZE:寫入日志中，以字節(jié)為單位的重做信息的數(shù)量。該信息將有助于確定重做日志的大小。
SORTS(DISK):磁盤排序的數(shù)量。磁盤排序除以內(nèi)存排序數(shù)量不應該高于5%.否則需要調(diào)整SORT_AREA_SIZE,PGA_AGGREGATE_TARGET的大小
注意：SORT_AREA_SIZE分配的內(nèi)存是面向每個用戶的，PGA_AGGREGATE_TARGET分配的內(nèi)存是面向所有會話的。
SORTS(MEMORY):在內(nèi)存中排序的數(shù)量。
SORTS(ROWS):參加排序的數(shù)據(jù)行的數(shù)量。
TABLE FETCH BY ROWID:通過訪問ROWID訪問的數(shù)據(jù)行的數(shù)量。該值很高通常意味著就獲取數(shù)據(jù)的操作而言，應用程序調(diào)整的不錯。
TABLE FETCH CONTINUED ROW:獲取的數(shù)據(jù)行的數(shù)量，可以是鏈化數(shù)據(jù)行，也可以是遷移的數(shù)據(jù)行。
10.數(shù)據(jù)字典和庫緩存的統(tǒng)計數(shù)據(jù):
如果報表中PCT MISS值很高，你應當提高應用程序中游標的共享程度或者增加共享池的尺寸。
到此，相信大家對“Oracle AWR內(nèi)容有哪些”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
本文標題：OracleAWR內(nèi)容有哪些
網(wǎng)頁網(wǎng)址：http://ef60e0e.cn/article/podsdd.html
