真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

Oracle面試寶典-等待事件篇

Oracle 面試寶典 - 等待事件篇

創(chuàng)新互聯(lián)專注于崇禮企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。崇禮網(wǎng)站建設(shè)公司,為崇禮等地區(qū)提供建站服務(wù)。全流程定制設(shè)計,專業(yè)設(shè)計,全程項目跟蹤,創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

請問Oracle 數(shù)據(jù)庫中等待事件的作用是什么 ?

一、等待事件由來

因為指標體系的發(fā)展,才導(dǎo)致等待事件的引入??偨Y(jié)一下,Oracle 的指標體系,大致經(jīng)歷了下面三個階段:

(1) 以命中率為主要參考指標

以各種命中率為主要的優(yōu)化入口依據(jù),常見的有” library cache hit radio “等。但這種方式弊端很大,一個命中率為 99% 的系統(tǒng),不一定就比 95% 的系統(tǒng)優(yōu)化的更好。在老的 Oracle 版本中,往往采用這種方式,如 8i 、 9i 等。

命中率是近20 年前系統(tǒng)性能優(yōu)化的一種觀點,后來該觀點被證明有一定的偏差而被同行逐漸棄用,不能說完全錯,命中率只能說是一個參考指標。

20 年后的今天,性能優(yōu)化的理論、實踐和手段,相比之前都有了很大的積累和發(fā)展。現(xiàn)在,對性能問題進行分析和診斷,更注重各方面信息的綜合分析,而不是單純看某個指標。比較典型的,例如:系統(tǒng)的綜合性能情況,可以通過查看 ash 、 awr 、 addm 或 osw 等各種報告進行分析和確定,單個 SQL 語句的性能也主要是結(jié)合具體 SQL 、執(zhí)行計劃及數(shù)據(jù)環(huán)境進行分析,獲取執(zhí)行計劃的方法比較多,但大同小異,本質(zhì)差不多。

至于性能分析診斷的思路和方法,一般是從整體到局部,逐漸細化的方法和步驟。

(2) 以等待事件為主要參考指標

以各種等待事件為優(yōu)化入口依據(jù),常見的有"db file sequential read" 等。可以較直觀的了解,在一段時間內(nèi),數(shù)據(jù)庫主要經(jīng)歷了那些等待。這些 " 瓶頸 " ,往往就是我們優(yōu)化的著手點。在 10g 、 11g 版本中,廣泛使用。

(3) 以時間模型為主要參考指標

以各種資源整體消耗為優(yōu)化入口依據(jù)??梢詮恼w角度了解數(shù)據(jù)庫在一段時間內(nèi)的消耗情況。較等待事件的方式,更有概括性。常見的如"DB Time" 。 Oracle 在不斷加強這個方面的工作。

從上面三個階段可見,等待事件的引入,正是為了解決以命中率為指標的諸多弊端。與后面的時間模型相比,等待事件以更加直觀、細粒度的方式觀察Oracle 的行為,往往作為優(yōu)化的重要入口。而時間模型,更側(cè)重于整體、系統(tǒng)性的了解數(shù)據(jù)庫運行狀態(tài)。兩者的側(cè)重點不同。

請問Oracle 數(shù)據(jù)庫有哪些類型的等待事件?

等待事件可分為空閑的、非空閑的兩大部分。在非空閑的等待事件,又可進一步劃分細的類別。

空閑等待:

空閑等待事件,是指Oracle 正等待某種工作,比如用 sqlplus 登錄之后,但沒有進一步發(fā)出任何命令,此時該 session 就處于 SQL*Net message from/to client 等待事件狀態(tài),等待用戶發(fā)出命令,任何的在診斷和優(yōu)化數(shù)據(jù)庫的時候,一般不用過多注意這部分事件。

非空閑等待:

非空閑等待事件,專門針對Oracle 的活動,指數(shù)據(jù)庫任務(wù)或應(yīng)用運行過程中發(fā)生的等待,這些等待事件是調(diào)整數(shù)據(jù)庫的時候應(yīng)該關(guān)注與研究的。

等待事件分類說明:

select  wait_class ,  wait_class_id ,   count (*)

   from  v$event_name

  group   by  wait_class ,  wait_class_id

  order   by   1 ;

--- 數(shù)據(jù)庫版本 Oracle 19C, 等待事件數(shù)量 192 0 個 ( 在 Oracle 10g 等待事件有 872 個, 11g 等待事件 1116 個 ) 。

Oracle面試寶典-等待事件篇

管理類-Administrative

此類等待事件是由于DBA 的管理命令引起的,這些命令要求用戶處于等待狀態(tài)(比如,重建索引) 。

例如:

Oracle面試寶典-等待事件篇

應(yīng)用程序類-Application

此類等待事件是由于用戶應(yīng)用程序的代碼引起的(比如,鎖等待)。

例如:

Oracle面試寶典-等待事件篇

群集類-Cluster

此類等待事件和 Oracle RAC 的資源有關(guān)(比如, gc cr block busy 等待事件)。

例如:

Oracle面試寶典-等待事件篇

提交確認類-Commit

此類等待事件只包含一種等待事件—— 在執(zhí)行了一個 commit 命令后,等待一個重做日志寫確認 。

例如:

Oracle面試寶典-等待事件篇

并發(fā)類-Concurrency

此類等待事件是由內(nèi)部數(shù)據(jù)庫資源引起的(比如閂鎖) 。

例如:

Oracle面試寶典-等待事件篇

配置類-Configuration

此類等待事件是由數(shù)據(jù)庫或?qū)嵗牟划斉渲迷斐傻模ū热纾刈鋈罩疚募叽缣?,共享池的大小等)?/p>

例如:

Oracle面試寶典-等待事件篇

空閑類-Idle

此類等待事件意味著會話不活躍,等待工作(比如,sql * net messages from client )。

例如:

Oracle面試寶典-等待事件篇

網(wǎng)絡(luò)類-Network

和網(wǎng)絡(luò)環(huán)境相關(guān)的一些等待事件(比如sql* net more data to dblink )。

例如:

Oracle面試寶典-等待事件篇

其它類-Other

此類等待事件通常比較少見。

例如:

Oracle面試寶典-等待事件篇

調(diào)度類-Scheduler

此類等待事件和資源管理相關(guān)。

例如:

Oracle面試寶典-等待事件篇

系統(tǒng)I/O 類 -System I/O

此類等待事件通過是由后臺進程的I/O 操作引起的(比如 DBWR 等待 -db file paralle write )。

例如:

Oracle面試寶典-等待事件篇

用戶I/O 類 -User I/O

此類等待事件通常是由用戶I/O 操作引起的(比如 db file sequential read ) 。

例如:

Oracle面試寶典-等待事件篇

請描述下你經(jīng)常遇到的10 個等待事件?

一:buffer busy wait

類型:并發(fā)類

發(fā)生原因:

當一個會話將數(shù)據(jù)塊從磁盤讀到內(nèi)存中時,它需要到內(nèi)存中找到空閑的內(nèi)存空間來存放這些數(shù)據(jù)塊,當內(nèi)存中沒有空閑的空間時,就會產(chǎn)生這個等待。除此之外,還有一種情況就是會話在做一致性讀時,需要構(gòu)造數(shù)據(jù)塊在某個時刻的前映像。此時需要申請內(nèi)存塊來存放這些新構(gòu)造的數(shù)據(jù)塊,如果內(nèi)存中無法找到這樣的內(nèi)存塊,也會發(fā)生這個等待事件。

優(yōu)化方向:

根據(jù)產(chǎn)生此等待事件的類別不同,優(yōu)化方向也不太一樣。

如何找出產(chǎn)生此等待事件的對象和對象類型?

在出現(xiàn) buffer busy waits 時查詢V$SESSION 中的 ROW_WAIT_OBJ# 值。例如 :

SELECT  row_wait_obj# FROM  V$SESSION WHERE  EVENT =   'buffer busy waits' ;

要識別爭用的對象和對象類型,可以使用從V$SESSION 返回的 ROW_WAIT_OBJ# 的值來查詢 DBA_OBJECTS 。例如 :

SELECT  owner ,  object_name ,  subobject_name ,  object_type

   FROM  DBA_OBJECTS

  WHERE  data_object_id =  &row_wait_obj ;

或者通過SID 查找對應(yīng)塊號,文件號,類型

select event, sid, p1, p2, p3

  from v$session_wait

 where sid in (69, 75)

   and event like '%buffer busy waits%';

---

P1: File ID

P2: Block ID

P3: Class ID

p1 、 p2 參數(shù)和 dba_extents 進行聯(lián)合查詢得到 block 所在的 segment 名稱和 segment 類型

對象類型: 數(shù)據(jù)塊

某一或某些數(shù)據(jù)塊被多個進程同時讀寫,成為熱點塊,可以通過如下這些辦法來解決這個問題:

(1) 降低程序的并發(fā)度,如果程序中使用了 parallel 查詢,降低 parallel degree ,以免多個 parallel slave 同時訪問同樣的數(shù)據(jù)對象而形成等待降低性能;

(2) 調(diào)整應(yīng)用程序使之能讀取較少的數(shù)據(jù)塊就能獲取所需的數(shù)據(jù),減少 buffer gets 和 physical reads ;

(3) 減少同一個 block 中的記錄數(shù),使記錄分布于更多的數(shù)據(jù)塊中,這可以通過若干途徑實現(xiàn):可以調(diào)整 segment 對象的 pctfree 值,可以將 segment 重建到 block size 較小的表空間中,還可以用 alter table minimize records_per_block 語句減少每塊中的記錄數(shù);

(4) 若熱點塊對象是類似自增 id 字段的索引,則可以將索引轉(zhuǎn)換為反轉(zhuǎn)索引,打散數(shù)據(jù)分布,分散熱點塊 。

優(yōu)化方向: 一般優(yōu)化方向是優(yōu)化SQL ,減少邏輯讀、物理讀;或者是減少單塊的存儲數(shù)據(jù)規(guī)模。

對象類型: 數(shù)據(jù)段頭

進程經(jīng)常性的訪問 data segment header 通常有兩個原因

(1) 獲取或修改 process freelists 信息

進程頻繁訪問process freelists 信息導(dǎo)致 freelist 爭用,我們可以增大相應(yīng)的 segment 對象的存儲參數(shù) freelist 或者 freelist groups ;若由于數(shù)據(jù)塊頻繁進出 freelist 而導(dǎo)致進程經(jīng)常要修改 freelist ,則可以將 pctfree 值和 pctused 值設(shè)置較大的差距,從而避免數(shù)據(jù)塊頻繁進出 freelist ;

(2) 擴展高水位標記

由于該segment 空間消耗很快,而設(shè)置的 next extent 過小,導(dǎo)致頻繁擴展高水位標記,解決的辦法是增大 segment 對象的存儲參數(shù) next extent 或者直接在創(chuàng)建表空間的時候設(shè)置 extent size uniform ;

優(yōu)化方向 : 增加FREELISTS 和 FREELIST GROUPS 。確保 FCTFREE 和 PCTUSED 之間的間隙不是太小,從而可以最小化 FREELIST 的塊循環(huán)。

對象類型: 撤銷塊

undo block 爭用是由于應(yīng)用程序中存在對數(shù)據(jù)的讀和寫同時進行,讀進程需要到 undo segment 中去獲得一致性數(shù)據(jù),解決辦法是錯開應(yīng)用程序修改數(shù)據(jù)和大量查詢數(shù)據(jù)的時間 。

優(yōu)化方向: 應(yīng)用程序,錯峰使用數(shù)據(jù)對象。

對象類型: 撤銷段頭

undo segment header 爭用是因為系統(tǒng)中 undo segment 不夠,需要增加足夠的 undo segment ,根據(jù) undo segment 的   管理 方法,若是手工管理模式,需要修改rollback_segments 初始化參數(shù)來增加 rollback segment ,若是自動管理模式,可以減小 transactions_per_rollback_segment 初始化參數(shù)的值來使 oracle 自動增多 rollback segment 的數(shù)量 。

優(yōu)化方向: 如果是數(shù)據(jù)庫系統(tǒng)管理UNDO 段,一般不需要干預(yù)。如果是自行管理的,可以減少每個回滾段的事務(wù)個數(shù) 。

二:db file sequential read

類型: 用戶I/O 類

發(fā)生原因: db file sequential read 事件和 Single Block I/O 有關(guān)。

該等待事件是將數(shù)據(jù)讀到連續(xù)的內(nèi)存( 這里指的是讀到相連的內(nèi)存,不是說讀取的是連續(xù)的數(shù)據(jù)塊 ) 。大多數(shù)情況下讀取一個索引塊或者通過索引讀取一個數(shù)據(jù)塊,會記錄這個等待??赡茱@示表的連接順序不佳,或者不加選擇地進行索引。對于大量事務(wù)處理、調(diào)整良好的系統(tǒng),這一數(shù)值大多是很正常的,但在某些情況下,它可能暗示著系統(tǒng)中存在問題。應(yīng)當將這一等待統(tǒng)計量與性能報告中的已知問題(如效率較低的 SQL )聯(lián)系起來。檢查索引掃描,以保證每個掃描都是必要的,并檢查多表連接的連接順序。

參數(shù)含義:

file# : 代表oracle 要讀取的文件的絕對文件號

block# : 從這個文件中開始讀取的起始數(shù)據(jù)塊塊號

Blocks : 讀取的block 數(shù)量。通常是 1 ,表示單個 block 讀取。

優(yōu)化方向:

這個等待事件,不一定代表一定有問題。如果能確定是有問題,可以按照下面優(yōu)化思路。

1 修改應(yīng)用,避免出現(xiàn)大量IO 的 sql ,或者減少其頻率 或優(yōu)化SQL 。

2 增加data buffer ,提高命中率。

3 采用更好的磁盤子系統(tǒng),減少單個IO 的響應(yīng)時間,防止物理瓶頸的出現(xiàn)。

三: db file scattered read

類型: 用戶I/O 類

發(fā)生原因: Oracle 在執(zhí)行全表掃描 ( Full Table Scan,FTS) 、索引快速全掃描 ( Index Fast Full Scan) 時,為保障性能,盡量一次性讀取多個塊,這稱為 Multi Block I/O 。 每次執(zhí)行 Multi Block I/O ,都會等待物理 I/O 結(jié)束,此時等待 db file scattered read 事件。這里 scattered 指的是讀取的數(shù)據(jù)塊在內(nèi)存中的存放方式。它們被讀取到內(nèi)存中后,是以分散的方式存放在內(nèi)存中,而不是連續(xù)的。

參數(shù)含義:

file# : 代表oracle 要讀取的文件的絕對文件號。

block# : 從這個文件中開始讀取的起始數(shù)據(jù)塊塊號。

Blocks : 讀取的block 數(shù)量。

優(yōu)化方向:

這種情況通常顯示與全表掃描相關(guān)的等待。當全表掃描被限制在內(nèi)存時,它們很少會進入連續(xù)的緩沖區(qū)內(nèi),而是分散于整個緩沖存儲器中。如果這個數(shù)目很大,就表明該表找不到索引,或者只能找到有限的索引。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效,但如果出現(xiàn)這種等待時,最好檢查一下這些全表掃描是否必要。如果是某些SQL 引起的,例如統(tǒng)計信息不準確,沒有索引或使用低效的索引等,可以通過優(yōu)化 SQL ,降低 db file scattered read 。

:direct path read

類型: 用戶I/O 類

發(fā)生原因:

這個等待事件發(fā)生在會話將數(shù)據(jù)塊直接讀取到PGA 當中而不是 SGA 中的情況,這些被讀取的數(shù)據(jù)通常是這個會話私有的數(shù)據(jù),所以不需要放到 SGA 作為共享數(shù)據(jù),因為這樣做沒有意義。這些數(shù)據(jù)通常是來自于臨時段上的數(shù)據(jù),比如一個會話中 SQL 的排序數(shù)據(jù),并行執(zhí)行過程中間產(chǎn)生的數(shù)據(jù),以及 Hash join 、 Merge join 產(chǎn)生的排序數(shù)據(jù),因為這些數(shù)據(jù)只對當前會話的 SQL 操作有意義,所以不需要放到 SGA 當中。 當發(fā)生direct path read 等待事件時,意味著磁盤上有大量的臨時數(shù)據(jù)產(chǎn)生,比如排序、并行執(zhí)行等操作,或者意味著 PGA 中空閑空間不足

在11g 中,全表掃描可能使用 direct path read 方式,繞過 buffer cache ,這樣的全表掃描就是物理讀了。在 10g 中,都是通過 buffer  cache 來讀的,所以不存在direct path read 的問題。

參數(shù)含義:

file# : 文件號

first block# : 讀取的起始塊號

block count : 以first block 為起點,連續(xù)讀取的物理塊數(shù)

優(yōu)化方向:

有了這個等待事件,需要區(qū)分幾種情況。一個方向是增大排序區(qū)等手段,一個方向是減少讀取IO 量或判斷是否通過緩沖區(qū)讀的方式更加高效。

direct path read 可能出現(xiàn)的問題:

在Oracle 11g 中有一個新特性,為了保護已經(jīng)緩存在 buffer cache 的數(shù)據(jù),當出現(xiàn)全表掃的查詢時會判斷該表的大小。如果該表過大,則使用直接路徑讀( Direct Path Read )來獲取數(shù)據(jù)。避免大量冷數(shù)據(jù)對 Buffer Cache 的沖擊。通過直接路徑讀的方式繞過 SGA 從存儲上獲取數(shù)據(jù)。由于沒有 SGA 的緩存,每一次查詢都需要從存儲讀取產(chǎn)生了大量的物理讀,可能會導(dǎo)致 I/O 負載過高。

新特性中如何判斷全表掃的大小呢?

下面看一個隱含參數(shù):_small_table_threshold

該參數(shù)默認為Buffer Cache 的 2% ,如果表大于 5 倍 _small_table_threshold 就觸發(fā)該特性。自動會使用 DPR 替代 FTS 。

可以通過設(shè)置10949 事件屏蔽這個特性,返回到 Oracle 11g 之前的模式上:

alter session set events '10949 trace name context forever, level 1';

小表受到隱含參數(shù):_small_table_threshold 影響。如果表大于 5 倍的小表限制,則自動會使用 DPR 替代 FTS 。 可以設(shè)置初始化參數(shù): _serial_direct_read 來禁用串行直接路徑讀。

Oracle面試寶典-等待事件篇

五: db file single write

類型: 用戶I/O 類

發(fā)生原因: 其中一種情況,Oracle 更新數(shù)據(jù)文件頭信息時(比如發(fā)生 CheckPoint )會出現(xiàn)這種等待事件。要考慮數(shù)據(jù)庫中的數(shù)據(jù)文件數(shù)量太大,導(dǎo)致 Oracle 需要花較長的時間來做所有文件頭的更新操作( CheckPoint )。

這個等待事件包含三個參數(shù):

file# :要讀取的數(shù)據(jù)塊所在數(shù)據(jù)文件的文件號。

block# :讀取的起始數(shù)據(jù)塊號。

blocks :需要讀取的數(shù)據(jù)塊數(shù)目。(通常來說在這里應(yīng)該等于 1 )

六:direct path write

類型: 用戶I/O 類

發(fā)生原因: 這個等待事件和direct path read 正好相反, 發(fā)生在oracle 直接從 PGA 寫數(shù)據(jù)到數(shù)據(jù)文件或臨時文件,這個操作可以繞過 SGA 。 可以執(zhí)行 direct path writes 的操作包括 磁盤排序、并行DML 操作、直接路徑插入、并行 create table as select 操作以及一些LOB 操作 。 對于這種情況應(yīng)該找到操作最為頻繁的數(shù)據(jù)文件( 如果是排序,很有可能是臨時文件 ) ,分散負載。

參數(shù)含義:

file# :文件號

first block# :讀取的起始塊號

block count :以 first block 為起點,連續(xù)寫入的物理塊數(shù)

優(yōu)化方向:減少IO 寫入規(guī)模。

七:log file sync

類型: 提交類

發(fā)生原因:

這是一個用戶會話行為導(dǎo)致的等待事件。當一個會話發(fā)出一個commit 命令時, LGWR 進程會將這個事務(wù)產(chǎn)生的 redo log 從 redo log buffer 里寫到 redo log file 磁盤上,以保證用戶提交的信息被安全地記錄到數(shù)據(jù)庫中。會話發(fā)出 commit 指令后,需要等待 LGWR 將這個事務(wù)產(chǎn)生的 redo 成功寫入到磁盤之后,才可以繼續(xù)進行后續(xù)的操作,這個等待事件就叫做 log file sync 。當系統(tǒng)中出現(xiàn)大量的 log file sync 等待事件時,應(yīng)該檢查數(shù)據(jù)庫中是否有用戶在做頻繁的提交操作。這種等待事件通常發(fā)生在 OLTP 系統(tǒng)上。 OLTP 系統(tǒng)中存在很多小的事務(wù),如果這些事務(wù)頻繁被提交,可能引起大量 log file sync 的等待事件。

優(yōu)化方向:

下面優(yōu)化建議,有助于減少log file sync 等待:

(1)  優(yōu)化 LGWR 速度,以獲得良好的磁盤吞吐量。例如: redo log file 不要放在 RAID 5 上 ( 可以考慮 RAID 0 或 RAID 1+0) ;

(2)  如果有大量小事物,最好可以批量提交,減少提交次數(shù);

( 3 )  特定場景可以考慮使用 NOLOGGING / UNRECOVERABLE 選項 ( 謹慎使用 ) ;

( 4 )  保證 redolog 足夠大,確保日志切換間隔在 15-20 分鐘;

( 5 )  使用穩(wěn)定版本數(shù)據(jù)庫避免 bug ,具體 bug 修復(fù)的版本參考文檔;

( 6 )  在 11.2.0.3 版本中, Oracle 默認啟用 _use_adaptive_log_file_sync 參數(shù),使得 LGWR 進程寫日志的方式能自動在 post/wait 和 polling 兩種方式之間進行取舍,可能會導(dǎo)致比較嚴重的寫日志等待( log file sync 的平均單次等待時間較高) , 建議關(guān)閉此功能。

參考命令:alter system set "_use_adaptive_log_file_sync"=FALSE;

八: Log File Parallel Write

類型: 系統(tǒng)I/O

發(fā)生原因:

1 、 Log File Sync 是從提交開始到提交結(jié)束的時間。 Log File Parallel Write 是 LGWR 開始寫 Redo File 到 Redo File 寫 結(jié)束的時間。明確了這一點,可以知道,Log file sync 包含了 log file parallel write 。所以, log file sync 等待時間一出,必先看 log file parallel write 。如果 log file sync 平均等待時間(也可稱為提交響應(yīng)時間)為 20ms , log file parallel write 為 19ms ,那么問題就很明顯了, Redo file I/O 緩慢,拖慢了提交的過程。   2 、 Log File Sync 的時間不止 log file parallel write 。服務(wù)器進程開始提交,到通知 LGWR 寫 Redo , LGWR 寫完 Redo 通知進程提交完畢,來回通知也是要消耗 CPU 的。除去來回通知外, Commit 還有增加 SCN 等等操作,如果 log file sync 和 log file parallel write 差距很大,證明 I/O 沒有問題,但有可能是 CPU 資源緊張,導(dǎo)致進程和 LGWR 來回通知或其他的需要 CPU 的操作,得不到足夠的 CPU ,因而產(chǎn)生延遲 。

優(yōu)化方向 : 考 慮的是如何在單個LGWR 進程的前提下讓寫的日志量不超過當前的 LGWR 寫能力。這個可以從兩個方面來考慮 :

1 : 考慮是否在應(yīng)用中產(chǎn)生了太多無意義的重做日志,導(dǎo)致日志產(chǎn)生量太大,從而使日志的產(chǎn)生量超出了LGWR 的寫能力,如果是這樣,那么考慮通過一些方法限制重做日志的產(chǎn)生。

2 : 考慮如果日志產(chǎn)生量確定的情況下,如何讓LGWR 進程寫日志能夠?qū)懙酶喔?,這主要取決于兩個方面,一個是 LGWR 在寫日志的時候是否發(fā)生了 I/O 競爭,另一方面是重做日志文件所在的磁盤速度是否過低,如果是競爭引起的,移動重做日志文件到其他的磁盤上,如果是磁盤速度引起的,那么選擇高速磁盤存放重做日志。

:library cache lock

類型: 并發(fā)類

發(fā)生原因:

這個等待事件發(fā)生在不同用戶在共享池中由于并發(fā)操作同一個數(shù)據(jù)庫對象導(dǎo)致的資源爭用的時候。比如當一個用戶正在對一個表做DDL 操作時,其他的用戶如果要訪問這張表,就會發(fā)生 library cache lock 等待事件,它要一直等到 DDL 操作完畢后,才能繼續(xù)操作。

參數(shù)含義:

Handle address : 被加載的對象的地址。

Lock address : 鎖的地址。

Mode : 被加載對象的數(shù)據(jù)片段。

Namespace : 被加載對象在v$db_object_cache 視圖中的 namespace 的名稱。

優(yōu)化方向:優(yōu)化方向是查看鎖定對象,減少爭用。

十: SQL*Net Events

類型:

應(yīng)用類:

SQL*Net break/reset to client

如果運行的代碼中包含某種可能的錯誤,且在調(diào)用中觸發(fā)了的話,服務(wù)器端本地的服務(wù)進程有義務(wù)對遠程客戶端告知該信息,這個告知的過程中服務(wù)進程就處于 SQL*Net break/reset to client 等待中,直到客戶端收到問題信息為止。

SQL*Net break/reset to dblink

這個等待事件和SQL*Net more data to client 等待事件基本相同,只不過等待發(fā)生在分布式事務(wù)中,即本地數(shù)據(jù)庫需要將更多的數(shù)據(jù)通過 dblink 發(fā)送給遠程數(shù)據(jù)庫。由于發(fā)送的數(shù)據(jù)太多或者網(wǎng)絡(luò)性能問題,就會產(chǎn)生 SQL*Net more data to dblink 等待事件。  

空閑類:

SQL*Net vector message from dblink

SQL*Net vector message from client

SQL*Net message from client

表示服務(wù)端等待著Cilent 發(fā)來請求讓它處理,這時就會產(chǎn)生 SQL*Net message from client 等待事件。

網(wǎng)絡(luò)類:

SQL*Net more data from dblink

SQL*Net vector data to client

SQL*Net vector data from client

SQL*Net vector data to dblink

SQL*Net vector data from dblink

SQL*Net message from dblink

SQL*Net more data from client

服務(wù)器端等待用戶端發(fā)出更多的數(shù)據(jù)以便完成操作,比如一個大的SQL 文本,導(dǎo)致一個 SQL*Net 數(shù)據(jù)包無法完成傳輸,這樣服務(wù)器端會等待客戶端把整個 SQL 文本發(fā)過來在做處理。

SQL*Net more data to dblink

這個等待事件和SQL*Net more data to client 等待事件基本相同,只不過等待發(fā)生在分布式事務(wù)中,即本地數(shù)據(jù)庫需要將更多的數(shù)據(jù)通過 dblink 發(fā)生給遠程數(shù)據(jù)庫。由于發(fā)送的數(shù)據(jù)太多或者網(wǎng)絡(luò)性能問題導(dǎo)致的等待。

SQL*Net more data to client

這說明數(shù)據(jù)庫在向客戶端不停發(fā)送 太多 的數(shù)據(jù)。如果網(wǎng)絡(luò)狀況不好,或者網(wǎng)絡(luò)流量過大,都可能導(dǎo)致這一等待非常顯著 。

SQL*Net message to client

這個等待事件發(fā)生在服務(wù) 端 向客戶端發(fā)送消息或數(shù)據(jù)的時候,一般意味著網(wǎng)絡(luò)瓶頸或不正確的TCP 連接配置。當然它不能做為對網(wǎng)絡(luò)延遲的準確評估或量化。

SQL*Net message to dblink

這個等待事件發(fā)生在會話在等待一個遠程數(shù)據(jù)庫一個確認信息,確認其發(fā)送的數(shù)據(jù)遠程數(shù)據(jù)庫是否收到,該數(shù)據(jù)通過dblink 發(fā)送,一般是由于目標服務(wù)器無法及時接受信息。

參考:

https://dbaplus.cn/news-10-777-1.html

http://www.itpub.net/thread-2102514-1-1.html

http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html

http://www.itpub.net/thread-1777234-1-1.html

https://www.linuxidc.com/Linux/2015-09/122732.htm

歡迎關(guān)注我的微信公眾號"IT小Chen",共同學(xué)習(xí),共同成長?。?!

Oracle面試寶典-等待事件篇

Oracle面試寶典-等待事件篇


網(wǎng)頁題目:Oracle面試寶典-等待事件篇
文章轉(zhuǎn)載:http://weahome.cn/article/pjsiec.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部