美女视频软件app大全,免费永久观看美女视频网站网址

、

一、等待事件的相關(guān)知識(shí)

1.1 等待事件主要可以分為兩類，即空閑(IDLE)等待事件和非空閑(NON-IDLE)等待事件。

1). 空閑等待事件指ORACLE正等待某種工作，在診斷和優(yōu)化數(shù)據(jù)庫(kù)的時(shí)候，不用過(guò)多注意這部分事件。
2). 非空閑等待事件專門針對(duì)ORACLE的活動(dòng)，指數(shù)據(jù)庫(kù)任務(wù)或應(yīng)用運(yùn)行過(guò)程中發(fā)生的等待，這些等待事件是在調(diào)整數(shù)據(jù)庫(kù)的時(shí)候需要關(guān)注與研究的。

在Oracle 10g中的等待事件有872個(gè)，11g中等待事件1116個(gè)。可以通過(guò)v$event_name 視圖來(lái)查看等待事件的相關(guān)信息。

1.2 查看v$event_name視圖的字段結(jié)構(gòu)

SQL> desc v$event_name;
名稱是否為空? 類型
----------------------------------------- -------- ---------------
EVENT# NUMBER
EVENT_ID NUMBER
NAME VARCHAR2(64)
PARAMETER1 VARCHAR2(64)
PARAMETER2 VARCHAR2(64)
PARAMETER3 VARCHAR2(64)
WAIT_CLASS_ID NUMBER
WAIT_CLASS# NUMBER
WAIT_CLASS VARCHAR2(64)

1.3 查看等待事件總數(shù)

11gr2:
SQL> select count(*) from v$event_name;
COUNT(*)
----------
1116

10gr2 rac:
sys@ORCL> select count(*) from v$event_name;

COUNT(*)
----------
889

10gr2:
SQL> select count(*) from v$event_name;

COUNT(*)
----------
874

1.4 查看等待事件分類情況

/* Formatted on 6/27/2011 12:54:45 PM (QP5 v5.114.809.3010) */
SELECT wait_class#,
wait_class_id,
wait_class,
COUNT ( * ) AS 'count'
FROM v$event_name
GROUP BY wait_class#, wait_class_id, wait_class
ORDER BY wait_class#;

WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS count
----------- ------------- -------------------- ----------
0 1893977003 Other 717
1 4217450380 Application 17
2 3290255840 Configuration 24
3 4166625743 Administrative 54
4 3875070507 Concurrency 32
5 3386400367 Commit 2
6 2723168908 Idle 94
7 2000153315 Network 35
8 1740759767 User I/O 45
9 4108307767 System I/O 30
10 2396326234 Scheduler 7
11 3871361733 Cluster 50
12 644977587 Queueing 9

1.5 相關(guān)的幾個(gè)視圖

V$SESSION：代表數(shù)據(jù)庫(kù)活動(dòng)的開(kāi)始，視為源起。

V$SESSION_WAIT：視圖用以實(shí)時(shí)記錄活動(dòng)SESSION的等待情況，是當(dāng)前信息。

V$SESSION_WAIT_HISTORY：是對(duì)V$SESSION_WAIT的簡(jiǎn)單增強(qiáng)，記錄活動(dòng)SESSION的最近10次等待。

V$SQLTEXT：當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)瓶頸時(shí)，通?？梢詮腣$SESSION_WAIT找到那些正在等待資源的SESSION，
通過(guò)SESSION的SID，聯(lián)合V$SESSION和V$SQLTEXT視圖就可以捕獲這些SESSION正在執(zhí)行的SQL語(yǔ)句。

V$ACTIVE_SESSION_HISTORY:是ASH的核心，用以記錄活動(dòng)SESSION的歷史等待信息，每秒采樣一次，這部分內(nèi)容記錄在內(nèi)存中，期望值是記錄一個(gè)小時(shí)的內(nèi)容。

WRH#_ACTIVE_SESSION_HISTORY: 是V$ACTIVE_SESSION_HISTORY在AWR的存儲(chǔ)地。

V$ACTIVE_SESSION_HISTORY中的信息會(huì)被定期(每小時(shí)一次)的刷新到負(fù)載庫(kù)中，并缺省保留一個(gè)星期用于分析。

DBA_HIST_ACTIVE_SESS_HISTORY:視圖是WRH#_ACTIVE_SESSION_HISTORY視圖和其他幾個(gè)視圖的聯(lián)合展現(xiàn)，通常通過(guò)這個(gè)視圖進(jìn)行歷史數(shù)據(jù)的訪問(wèn)。

V$SYSTEM_EVENT: 由于V$SESSION記錄的是動(dòng)態(tài)信息，和SESSION的生命周期相關(guān)，而并不記錄歷史信息，所以O(shè)RACLE提供視圖V$SYSTEM_EVENT來(lái)記錄數(shù)據(jù)庫(kù)自啟動(dòng)以來(lái)所有等待事件的匯總信息。通過(guò)這個(gè)視圖，用戶可以迅速獲得數(shù)據(jù)庫(kù)運(yùn)行的總體概況。

二、33個(gè)常見(jiàn)的等待事件

1. Buffer busy waits

從本質(zhì)上講，這個(gè)等待事件的產(chǎn)生僅說(shuō)明了一個(gè)會(huì)話在等待一個(gè)Buffer（數(shù)據(jù)塊），但是導(dǎo)致這個(gè)現(xiàn)象的原因卻有很多種。

常見(jiàn)的兩種是：

·當(dāng)一個(gè)會(huì)話試圖修改一個(gè)數(shù)據(jù)塊，但這個(gè)數(shù)據(jù)塊正在被另一個(gè)會(huì)話修改時(shí)。

·當(dāng)一個(gè)會(huì)話需要讀取一個(gè)數(shù)據(jù)塊，但這個(gè)數(shù)據(jù)塊正在被另一個(gè)會(huì)話讀取到內(nèi)存中時(shí)。

Oracle 操作的最小單位是塊（Block），即使你要修改一條記錄，也需要對(duì)這條記錄所在的這個(gè)數(shù)據(jù)塊做操作。當(dāng)你對(duì)這個(gè)數(shù)據(jù)塊做修改時(shí)，其他的會(huì)話將被阻止對(duì)這個(gè)數(shù)據(jù)塊上的數(shù)據(jù)做修改（即使其他用戶修改的不是當(dāng)前用戶修改的數(shù)據(jù)），但是可以以一致性的方式讀取這個(gè)數(shù)據(jù)塊（from undo）。當(dāng)前的用戶修改完這個(gè)數(shù)據(jù)塊后，將會(huì)立即釋放掉加在這個(gè)數(shù)據(jù)塊上的排他鎖，這樣另一個(gè)會(huì)話就可以繼續(xù)修改它。修改操作是一個(gè)非常短暫的時(shí)間，這種加鎖的機(jī)制我們叫Latch。

當(dāng)一個(gè)會(huì)話修改一個(gè)數(shù)據(jù)塊時(shí)，是按照以下步驟來(lái)完成的：

·以排他的方式獲得這個(gè)數(shù)據(jù)塊（Latch）

·修改這個(gè)數(shù)據(jù)塊。

·釋放Latch。

Buffer busy waits等待事件常見(jiàn)于數(shù)據(jù)庫(kù)中存在熱塊的時(shí)候，當(dāng)多個(gè)用戶頻繁地讀取或者修改同樣的數(shù)據(jù)塊時(shí)，這個(gè)等待事件就會(huì)產(chǎn)生。如果等待的時(shí)間很長(zhǎng)，我們?cè)贏WR或者statspack 報(bào)告中就可以看到。

這個(gè)等待事件有三個(gè)參數(shù)。查看有幾個(gè)參數(shù)我們可以用以下SQL:

/* Formatted on 6/27/2011 1:06:09 PM (QP5 v5.114.809.3010) */
SELECT name,
parameter1,
parameter2,
parameter3
FROM v$event_name
WHERE name = 'buffer busy waits';
NAME PARAMETER1 PARAMETER2 PARAMETER3
-------------------- ---------- ---------- ----------
buffer busy waits file# block# class#

在下面的示例中，查詢的方法和這個(gè)一樣，所以其他事件對(duì)參數(shù)的查詢將不做過(guò)多的說(shuō)明。

File#: 等待訪問(wèn)數(shù)據(jù)塊所在的文件id號(hào)。
Blocks：等待訪問(wèn)的數(shù)據(jù)塊號(hào)。
ID：在10g之前，這個(gè)值表示一個(gè)等待時(shí)間的原因，10g之后則表示等待事件的類別。

2. Buffer latch

內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個(gè)hash列表（cache buffer chains）當(dāng)中的。當(dāng)一個(gè)會(huì)話需要訪問(wèn)某個(gè)數(shù)據(jù)塊時(shí)，它首先要搜索這個(gè)hash 列表，從列表中獲得數(shù)據(jù)塊的地址，然后通過(guò)這個(gè)地址去訪問(wèn)需要的數(shù)據(jù)塊，這個(gè)列表Oracle會(huì)使用一個(gè)latch來(lái)保護(hù)它的完整性。當(dāng)一個(gè)會(huì)話需要訪問(wèn)這個(gè)列表時(shí)，需要獲取一個(gè)Latch，只有這樣，才能保證這個(gè)列表在這個(gè)會(huì)話的瀏覽當(dāng)中不會(huì)發(fā)生變化。

產(chǎn)生buffer latch的等待事件的主要原因是：

·Buffer chains太長(zhǎng)，導(dǎo)致會(huì)話搜索這個(gè)列表花費(fèi)的時(shí)間太長(zhǎng)，使其他的會(huì)話處于等待狀態(tài)。

·同樣的數(shù)據(jù)塊被頻繁訪問(wèn)，就是我們通常說(shuō)的熱快問(wèn)題。

產(chǎn)生buffer chains太長(zhǎng)，我們可以使用多個(gè)buffer pool的方式來(lái)創(chuàng)建更多的buffer chains，或者使用參數(shù)DB_BLOCK_LRU_LATCHES來(lái)增加latch的數(shù)量，以便于更多的會(huì)話可以獲得latch，這兩種方法可以同時(shí)使用。

這個(gè)等待事件有兩個(gè)參數(shù)：
Latch addr：會(huì)話申請(qǐng)的latch在SGA中的虛擬地址。
通過(guò)以下的SQL語(yǔ)句可以根據(jù)這個(gè)地址找到它對(duì)應(yīng)的Latch名稱：

/* Formatted on 6/27/2011 1:12:48 PM (QP5 v5.114.809.3010) */
select * from v$latch a,v$latchname b where
addr=latch addr -- 這里的latch addr 是你從等待事件中看到的值
and a.latch#=b.latch#;

chain#： buffer chains hash 列表中的索引值，當(dāng)這個(gè)參數(shù)的值等于s 0xfffffff時(shí)，說(shuō)明當(dāng)前的會(huì)話正在等待一個(gè)LRU latch。

3. Control file parallel write

當(dāng)數(shù)據(jù)庫(kù)中有多個(gè)控制文件的拷貝時(shí)，Oracle 需要保證信息同步地寫(xiě)到各個(gè)控制文件當(dāng)中，這是一個(gè)并行的物理操作過(guò)程，因?yàn)榭刂莆募⑿袑?xiě)，當(dāng)發(fā)生這樣的操作時(shí)，就會(huì)產(chǎn)生control file parallel write等待事件。

控制文件頻繁寫(xiě)入的原因很多，比如：

·日志切換太過(guò)頻繁，導(dǎo)致控制文件信息相應(yīng)地需要頻繁更新。

·系統(tǒng)I/O 出現(xiàn)瓶頸，導(dǎo)致所有I/O出現(xiàn)等待。

當(dāng)系統(tǒng)出現(xiàn)日志切換過(guò)于頻繁的情形時(shí)，可以考慮適當(dāng)?shù)卦龃笕罩疚募拇笮?lái)降低日志切換頻率。

當(dāng)系統(tǒng)出現(xiàn)大量的control file parallel write 等待事件時(shí)，可以通過(guò)比如降低控制文件的拷貝數(shù)量，將控制文件的拷貝存放在不同的物理磁盤上的方式來(lái)緩解I/O 爭(zhēng)用。

這個(gè)等待事件包含三個(gè)參數(shù)：
Files： Oracle 要寫(xiě)入的控制文件個(gè)數(shù)。
Blocks：寫(xiě)入控制文件的數(shù)據(jù)塊數(shù)目。
Requests：寫(xiě)入控制請(qǐng)求的I/O 次數(shù)。

4. Control file sequential read

當(dāng)數(shù)據(jù)庫(kù)需要讀取控制文件上的信息時(shí)，會(huì)出現(xiàn)這個(gè)等待事件，因?yàn)榭刂莆募男畔⑹琼樞驅(qū)懙模宰x取的時(shí)候也是順序的，因此稱為控制文件順序讀，它經(jīng)常發(fā)生在以下情況：

·備份控制文件

·RAC 環(huán)境下不同實(shí)例之間控制文件的信息共享

·讀取控制文件的文件頭信息

·讀取控制文件其他信息

這個(gè)等待事件有三個(gè)參數(shù)：
File#：要讀取信息的控制文件的文件號(hào)。
Block#：讀取控制文件信息的起始數(shù)據(jù)塊號(hào)。
Blocks：需要讀取的控制文件數(shù)據(jù)塊數(shù)目。

5. Db file parallel read
這是一個(gè)很容易引起誤導(dǎo)的等待事件，實(shí)際上這個(gè)等待事件和并行操作（比如并行查詢，并行DML）沒(méi)有關(guān)系。這個(gè)事件發(fā)生在數(shù)據(jù)庫(kù)恢復(fù)的時(shí)候，當(dāng)有一些數(shù)據(jù)塊需要恢復(fù)的時(shí)候，Oracle會(huì)以并行的方式把他們從數(shù)據(jù)文件中讀入到內(nèi)存中進(jìn)行恢復(fù)操作。

這個(gè)等待事件包含三個(gè)參數(shù)：
Files：操作需要讀取的文件個(gè)數(shù)。
Blocks：操作需要讀取的數(shù)據(jù)塊個(gè)數(shù)。
Requests：操作需要執(zhí)行的I/O次數(shù)。

6. Db file parallel write
這是一個(gè)后臺(tái)等待事件，它同樣和用戶的并行操作沒(méi)有關(guān)系，它是由后臺(tái)進(jìn)程DBWR產(chǎn)生的，當(dāng)后臺(tái)進(jìn)程DBWR向磁盤上寫(xiě)入臟數(shù)據(jù)時(shí)，會(huì)發(fā)生這個(gè)等待。

DBWR會(huì)批量地將臟數(shù)據(jù)并行地寫(xiě)入到磁盤上相應(yīng)的數(shù)據(jù)文件中，在這個(gè)批次作業(yè)完成之前，DBWR將出現(xiàn)這個(gè)等待事件。如果僅僅是這一個(gè)等待事件，對(duì)用戶的操作并沒(méi)有太大的影響，當(dāng)伴隨著出現(xiàn)free buffer waits等待事件時(shí)，說(shuō)明此時(shí)內(nèi)存中可用的空間不足，這時(shí)候會(huì)影響到用戶的操作，比如影響到用戶將臟數(shù)據(jù)塊讀入到內(nèi)存中。

當(dāng)出現(xiàn)db file parallel write等待事件時(shí)，可以通過(guò)啟用操作系統(tǒng)的異步I/O的方式來(lái)緩解這個(gè)等待。當(dāng)使用異步I/O時(shí)，DBWR不再需要一直等到所有數(shù)據(jù)塊全部寫(xiě)入到磁盤上，它只需要等到這個(gè)數(shù)據(jù)寫(xiě)入到一個(gè)百分比之后，就可以繼續(xù)進(jìn)行后續(xù)的操作。

這個(gè)等待事件有兩個(gè)參數(shù)：
Requests：操作需要執(zhí)行的I/O次數(shù)。
Timeouts：等待的超時(shí)時(shí)間。

7. Db file scattered read
這個(gè)等待事件在實(shí)際生產(chǎn)庫(kù)中經(jīng)?？梢钥吹剑@是一個(gè)用戶操作引起的等待事件，當(dāng)用戶發(fā)出每次I/O需要讀取多個(gè)數(shù)據(jù)塊這樣的SQL 操作時(shí)，會(huì)產(chǎn)生這個(gè)等待事件，最常見(jiàn)的兩種情況是全表掃描（FTS： Full Table Scan）和索引快速掃描（IFFS： index fast full scan）。

這個(gè)名稱中的scattered( 分散)，可能會(huì)導(dǎo)致很多人認(rèn)為它是以scattered 的方式來(lái)讀取數(shù)據(jù)塊的，其實(shí)恰恰相反，當(dāng)發(fā)生這種等待事件時(shí)，SQL的操作都是順序地讀取數(shù)據(jù)塊的，比如FTS或者IFFS方式（如果忽略需要讀取的數(shù)據(jù)塊已經(jīng)存在內(nèi)存中的情況）。

這里的scattered指的是讀取的數(shù)據(jù)塊在內(nèi)存中的存放方式，他們被讀取到內(nèi)存中后，是以分散的方式存在在內(nèi)存中，而不是連續(xù)的。

這個(gè)等待事件有三個(gè)參數(shù)：
File#：要讀取的數(shù)據(jù)塊所在數(shù)據(jù)文件的文件號(hào)。
Block#：要讀取的起始數(shù)據(jù)塊號(hào)。
Blocks：需要讀取的數(shù)據(jù)塊數(shù)目。

8. Db file sequential read
這個(gè)等待事件在實(shí)際生產(chǎn)庫(kù)也很常見(jiàn)，當(dāng)Oracle 需要每次I/O只讀取單個(gè)數(shù)據(jù)塊這樣的操作時(shí)，會(huì)產(chǎn)生這個(gè)等待事件。最常見(jiàn)的情況有索引的訪問(wèn)（除IFFS外的方式），回滾操作，以ROWID的方式訪問(wèn)表中的數(shù)據(jù)，重建控制文件，對(duì)文件頭做DUMP等。

這里的sequential也并非指的是Oracle 按順序的方式來(lái)訪問(wèn)數(shù)據(jù)，和db file scattered read一樣，它指的是讀取的數(shù)據(jù)塊在內(nèi)存中是以連續(xù)的方式存放的。

這個(gè)等待事件有三個(gè)參數(shù)：
File#：要讀取的數(shù)據(jù)塊鎖在數(shù)據(jù)文件的文件號(hào)。
Block#：要讀取的起始數(shù)據(jù)塊號(hào)。
Blocks：要讀取的數(shù)據(jù)塊數(shù)目（這里應(yīng)該等于1）。

9. Db file single write
這個(gè)等待事件通常只發(fā)生在一種情況下，就是Oracle 更新數(shù)據(jù)文件頭信息時(shí)（比如發(fā)生Checkpoint）。

當(dāng)這個(gè)等待事件很明顯時(shí)，需要考慮是不是數(shù)據(jù)庫(kù)中的數(shù)據(jù)文件數(shù)量太大，導(dǎo)致Oracle 需要花較長(zhǎng)的時(shí)間來(lái)做所有文件頭的更新操作（checkpoint）。

這個(gè)等待事件有三個(gè)參數(shù)：
File#: 需要更新的數(shù)據(jù)塊所在的數(shù)據(jù)文件的文件號(hào)。
Block#：需要更新的數(shù)據(jù)塊號(hào)。
Blocks：需要更新的數(shù)據(jù)塊數(shù)目（通常來(lái)說(shuō)應(yīng)該等于1）。

10. Direct path read
這個(gè)等待事件發(fā)生在會(huì)話將數(shù)據(jù)塊直接讀取到PGA當(dāng)中而不是SGA中的情況，這些被讀取的數(shù)據(jù)通常是這個(gè)會(huì)話私有的數(shù)據(jù)，所以不需要放到SGA作為共享數(shù)據(jù)，因?yàn)檫@樣做沒(méi)有意義。這些數(shù)據(jù)通常是來(lái)自于臨時(shí)段上的數(shù)據(jù)，比如一個(gè)會(huì)話中SQL的排序數(shù)據(jù)，并行執(zhí)行過(guò)程中間產(chǎn)生的數(shù)據(jù)，以及Hash Join，merge join產(chǎn)生的排序數(shù)據(jù)，因?yàn)檫@些數(shù)據(jù)只對(duì)當(dāng)前的會(huì)話的SQL操作有意義，所以不需要放到SGA當(dāng)中。

當(dāng)發(fā)生direct path read等待事件時(shí)，意味著磁盤上有大量的臨時(shí)數(shù)據(jù)產(chǎn)生，比如排序，并行執(zhí)行等操作。或者意味著PGA中空閑空間不足。

這個(gè)等待事件有三個(gè)參數(shù)：
Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話正在等待的一個(gè)direct read I/O。
First dba: descriptor address 中最舊的一個(gè)I/O數(shù)據(jù)塊地址。
Block cnt: descriptor address上下文中涉及的有效的buffer 數(shù)量。

11. Direct path write
這個(gè)等待事件和direct path read 正好相反，是會(huì)話將一些數(shù)據(jù)從PGA中直接寫(xiě)入到磁盤文件上，而不經(jīng)過(guò)SGA。

這種情況通常發(fā)生在：

·使用臨時(shí)表空間排序（內(nèi)存不足）

·數(shù)據(jù)的直接加載（使用append方式加載數(shù)據(jù)）

·并行DML操作。

這個(gè)等待事件有三個(gè)參數(shù)：
Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話正在等待的一個(gè)direct I/O.
First dba: descriptor address 中最舊的一個(gè)I/O數(shù)據(jù)塊地址。
Block cnt: descriptor address 上下文中涉及的有效地 buffer 數(shù)量。

12. Enqueue
Enqueue 這個(gè)詞其實(shí)是lock 的另一種描述語(yǔ)。

當(dāng)我們?cè)贏WR 報(bào)告中發(fā)現(xiàn)長(zhǎng)時(shí)間的enqueue 等待事件時(shí)，說(shuō)明數(shù)據(jù)庫(kù)中出現(xiàn)了阻塞和等待，可以關(guān)聯(lián)AWR報(bào)告中的enqueue activity部分來(lái)確定是哪一種鎖定出現(xiàn)了長(zhǎng)時(shí)間等待。

這個(gè)等待事件有2個(gè)參數(shù)：
Name： enqueue 的名稱和類型。
Mode： enqueue的模式。

可以使用如下SQL 查看當(dāng)前會(huì)話等待的enqueue名稱和類型：

/* Formatted on 6/27/2011 1:31:48 PM (QP5 v5.114.809.3010) */
SELECT CHR (TO_CHAR (BITAND (p1, -16777216)) / 16777215)
|| CHR (TO_CHAR (BITAND (p1, 16711680)) / 65535)
'Lock',
TO_CHAR (BITAND (p1, 65535)) 'Mode'
FROM v$session_wait
WHERE event = 'enqueue';

13. Free buffer waits

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

當(dāng)數(shù)據(jù)庫(kù)中出現(xiàn)比較嚴(yán)重的free buffer waits等待事件時(shí)，可能的原因是：

（1）data buffer 太小，導(dǎo)致空閑空間不夠
（2）內(nèi)存中的臟數(shù)據(jù)太多，DBWR無(wú)法及時(shí)將這些臟數(shù)據(jù)寫(xiě)到磁盤中以釋放空間

這個(gè)等待事件包含2個(gè)參數(shù)：
File#：需要讀取的數(shù)據(jù)塊所在的數(shù)據(jù)文件的文件號(hào)。
Block#：需要讀取的數(shù)據(jù)塊塊號(hào)。

14. Latch free
在10g之前的版本里，latch free 等待事件代表了所有的latch等待，在10g以后，一些常用的latch事件已經(jīng)被獨(dú)立了出來(lái)：

11gr2:
SQL> select name from v$event_name where name like 'latch%' order by 1;
NAME
----------------------------------------------------------------
latch activity
latch free
latch: Change Notification Hash table latch
latch: In memory undo latch
latch: MQL Tracking Latch
latch: PX hash array latch
latch: Undo Hint Latch
latch: WCR: processes HT
latch: WCR: sync
latch: cache buffer handles
latch: cache buffers chains
latch: cache buffers lru chain
latch: call allocation
latch: change notification client cache latch
latch: checkpoint queue latch
latch: enqueue hash chains
latch: gc element
latch: gcs resource hash
latch: ges resource hash list
latch: lob segment dispenser latch
latch: lob segment hash table latch
latch: lob segment query latch
latch: messages
latch: object queue header operation
latch: parallel query alloc buffer
latch: redo allocation
latch: redo copy
latch: redo writing
latch: row cache objects
latch: session allocation
latch: shared pool
latch: undo global data
latch: virtual circuit queues
已選擇33行。

10gr2 rac:
sys@ORCL> select name from v$event_name where name like 'latch%' order by 1;

NAME
--------------------------------------------------
latch activity
latch free
latch: Change Notification Hash table latch
latch: In memory undo latch
latch: KCL gc element parent latch
latch: MQL Tracking Latch
latch: Undo Hint Latch
latch: cache buffer handles
latch: cache buffers chains
latch: cache buffers lru chain
latch: checkpoint queue latch
latch: enqueue hash chains
latch: gcs resource hash
latch: ges resource hash list
latch: library cache
latch: library cache lock
latch: library cache pin
latch: messages
latch: object queue header heap
latch: object queue header operation
latch: parallel query alloc buffer
latch: redo allocation
latch: redo copy
latch: redo writing
latch: row cache objects
latch: session allocation
latch: shared pool
latch: undo global data
latch: virtual circuit queues

29 rows selected.

所以latch free 等待事件在10g以后的版本中并不常見(jiàn)，而是以具體的Latch 等待事件出現(xiàn)。

這個(gè)等待事件有三個(gè)參數(shù)：
Address: 會(huì)話等待的latch 地址。
Number： latch號(hào)，通過(guò)這個(gè)號(hào)，可以從v$latchname 視圖中找到這個(gè)latch 的相關(guān)的信息。
SQL> select * from v$latchname where latch#=number;
Tries: 會(huì)話嘗試獲取Latch 的次數(shù)。

15. Library cache lock
這個(gè)等待事件發(fā)生在不同用戶在共享中由于并發(fā)操作同一個(gè)數(shù)據(jù)庫(kù)對(duì)象導(dǎo)致的資源爭(zhēng)用的時(shí)候，比如當(dāng)一個(gè)用戶正在對(duì)一個(gè)表做DDL 操作時(shí)，其他的用戶如果要訪問(wèn)這張表，就會(huì)發(fā)生library cache lock等待事件，它要一直等到DDL操作完成后，才能繼續(xù)操作。

這個(gè)事件包含四個(gè)參數(shù)：
Handle address: 被加載的對(duì)象的地址。
Lock address：鎖的地址。
Mode：被加載對(duì)象的數(shù)據(jù)片段。
Namespace：被加載對(duì)象在v$db_object_cache 視圖中namespace名稱。

10gr2 rac:
sys@ORCL> select name from v$event_name where name like 'library%' order by 1;

NAME
--------------------------------------------------
library cache load lock
library cache lock
library cache pin
library cache revalidation
library cache shutdown

16. Library cache pin
這個(gè)等待事件和library cache lock 一樣是發(fā)生在共享池中并發(fā)操作引起的事件。通常來(lái)講，如果Oracle 要對(duì)一些PL/SQL 或者視圖這樣的對(duì)象做重新編譯，需要將這些對(duì)象pin到共享池中。如果此時(shí)這個(gè)對(duì)象被其他的用戶特有，就會(huì)產(chǎn)生一個(gè)library cache pin的等待。

這個(gè)等待事件也包含四個(gè)參數(shù)：
Handle address: 被加載的對(duì)象的地址。
Lock address：鎖的地址。
Mode：被加載對(duì)象的數(shù)據(jù)片段。
Namespace：被加載對(duì)象在v$db_object_cache 視圖中namespace名稱。

17. Log file parallel write
后臺(tái)進(jìn)程LGWR 負(fù)責(zé)將log buffer當(dāng)中的數(shù)據(jù)寫(xiě)到REDO 文件中，以重用log buffer的數(shù)據(jù)。如果每個(gè)REDO LOG組里面有2個(gè)以上的成員，那么LGWR進(jìn)程會(huì)并行地將REDO 信息寫(xiě)入這些文件中。

如果數(shù)據(jù)庫(kù)中出現(xiàn)這個(gè)等待事件的瓶頸，主要的原因可能是磁盤I/O性能不夠或者REDO 文件的分布導(dǎo)致了I/O爭(zhēng)用，比如同一個(gè)組的REDO 成員文件放在相同的磁盤上。

這個(gè)等待事件有三個(gè)參數(shù)：
Files：操作需要寫(xiě)入的文件個(gè)數(shù)。
Blocks：操作需要寫(xiě)入的數(shù)據(jù)塊個(gè)數(shù)。
Requests：操作需要執(zhí)行的I/O次數(shù)。

18. Log buffer space
當(dāng)log buffer 中沒(méi)有可用空間來(lái)存放新產(chǎn)生的redo log數(shù)據(jù)時(shí)，就會(huì)發(fā)生log buffer space等待事件。如果數(shù)據(jù)庫(kù)中新產(chǎn)生的redo log的數(shù)量大于LGWR 寫(xiě)入到磁盤中的redo log 數(shù)量，必須等待LGWR 完成寫(xiě)入磁盤的操作，LGWR必須確保redo log寫(xiě)到磁盤成功之后，才能在redo buffer當(dāng)中重用這部分信息。

如果數(shù)據(jù)庫(kù)中出現(xiàn)大量的log buffer space等待事件，可以考慮如下方法：
（1）增加redo buffer的大小。
（2）提升磁盤的I/O性能

19. Log file sequential read
這個(gè)等待事件通常發(fā)生在對(duì)redo log信息進(jìn)行讀取時(shí)，比如在線redo 的歸檔操作，ARCH進(jìn)程需要讀取redo log的信息，由于redo log的信息是順序?qū)懭氲?，所以在讀取時(shí)也是按照順序的方式來(lái)讀取的。

這個(gè)等待事件包含三個(gè)參數(shù)：
Log#：發(fā)生等待時(shí)讀取的redo log的sequence號(hào)。
Block#：讀取的數(shù)據(jù)塊號(hào)。
Blocks：讀取的數(shù)據(jù)塊個(gè)數(shù)。

20. Log file single write
這個(gè)等待事件發(fā)生在更新redo log文件的文件頭時(shí)，當(dāng)為日志組增加新的日志成員時(shí)或者redo log的sequence號(hào)改變時(shí)，LGWR 都會(huì)更新redo log文件頭信息。

這個(gè)等待事件包含三個(gè)參數(shù)：
Log#：寫(xiě)入的redo log組的編號(hào)。
Block#：寫(xiě)入的數(shù)據(jù)塊號(hào)。
Blocks：寫(xiě)入的數(shù)據(jù)塊個(gè)數(shù)。

21. Log file switch(archiving needed)
在歸檔模式下，這個(gè)等待事件發(fā)生在在線日志切換（log file switch）時(shí)，需要切換的在線日志還沒(méi)有被歸檔進(jìn)程（ARCH）歸檔完畢的時(shí)候。當(dāng)在線日志文件切換到下一個(gè)日志時(shí)，需要確保下一個(gè)日志文件已經(jīng)被歸檔進(jìn)程歸檔完畢，否則不允許覆蓋那個(gè)在線日志信息（否則會(huì)導(dǎo)致歸檔日志信息不完整）。

出現(xiàn)這樣的等待事件通常是由于某種原因?qū)е翧RCH 進(jìn)程死掉，比如ARCH進(jìn)程嘗試向目的地寫(xiě)入一個(gè)歸檔文件，但是沒(méi)有成功（介質(zhì)失效或者其他原因），這時(shí)ARCH進(jìn)程就會(huì)死掉。如果發(fā)生這種情況，在數(shù)據(jù)庫(kù)的alert log文件中可以找到相關(guān)的錯(cuò)誤信息。

這個(gè)等待事件沒(méi)有參數(shù)。

22. Log file switch(checkpoint incomplete)
當(dāng)一個(gè)在線日志切換到下一個(gè)在線日志時(shí)，必須保證要切換到的在線日志上的記錄的信息（比如一些臟數(shù)據(jù)塊產(chǎn)生的redo log）被寫(xiě)到磁盤上（checkpoint），這樣做的原因是，如果一個(gè)在線日志文件的信息被覆蓋，而依賴這些redo 信息做恢復(fù)的數(shù)據(jù)塊尚未被寫(xiě)到磁盤上（checkpoint），此時(shí)系統(tǒng)down掉的話，Oracle將沒(méi)有辦法進(jìn)行實(shí)例恢復(fù)。

在v$log 視圖里記錄了在線日志的狀態(tài)。通常來(lái)說(shuō)，在線日志有三種狀態(tài)。

Active: 這個(gè)日志上面保護(hù)的信息還沒(méi)有完成checkpoint。
Inactive：這個(gè)日志上面保護(hù)的信息已完成checkpoint。
Current：當(dāng)前的日志。

Oracle 在做實(shí)例恢復(fù)時(shí)，會(huì)使用狀態(tài)為current和Active的日志進(jìn)行實(shí)例恢復(fù)。

如果系統(tǒng)中出現(xiàn)大量的log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志組太少，所以解決的方法是，增加日志文件的大小或者增加日志組的數(shù)量。

這個(gè)等待事件沒(méi)有參數(shù)。

23. Log file sync
這是一個(gè)用戶會(huì)話行為導(dǎo)致的等待事件，當(dāng)一個(gè)會(huì)話發(fā)出一個(gè)commit命令時(shí)，LGWR進(jìn)程會(huì)將這個(gè)事務(wù)產(chǎn)生的redo log從log buffer里面寫(xiě)到磁盤上，以確保用戶提交的信息被安全地記錄到數(shù)據(jù)庫(kù)中。

會(huì)話發(fā)出的commit指令后，需要等待LGWR將這個(gè)事務(wù)產(chǎn)生的redo 成功寫(xiě)入到磁盤之后，才可以繼續(xù)進(jìn)行后續(xù)的操作，這個(gè)等待事件就叫作log file sync。

當(dāng)系統(tǒng)中出現(xiàn)大量的log file sync等待事件時(shí)，應(yīng)該檢查數(shù)據(jù)庫(kù)中是否有用戶在做頻繁的提交操作。

這種等待事件通常發(fā)生在OLTP系統(tǒng)上。OLTP 系統(tǒng)中存在很多小的事務(wù)，如果這些事務(wù)頻繁被提交，可能引起大量的log file sync的等待事件。

這個(gè)等待事件包含一個(gè)參數(shù)：
Buffer#: redo buffer 中需要被寫(xiě)入到磁盤中的buffer。

24. SQL*Net break/reset to client
當(dāng)出現(xiàn)這個(gè)等待事件時(shí)，說(shuō)明服務(wù)器端在給客戶端發(fā)送一個(gè)斷開(kāi)連接或者重置連接的請(qǐng)求，正在等待客戶的響應(yīng)，通常的原因是服務(wù)器到客戶端的網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的。

這個(gè)等待事件包含兩個(gè)參數(shù)：

Driver id: 服務(wù)器和客戶端連接使用的協(xié)議信息。
Break？：零表示服務(wù)端向客戶端發(fā)送一個(gè)重置（reset）信息，非零表示服務(wù)器端向客戶端發(fā)送一個(gè)斷開(kāi)（break）消息。

25. SQL*Net break/reset to dblink
這個(gè)等待事件和SQL*Net break/reset to client 相同。不過(guò)它表示的是數(shù)據(jù)庫(kù)通過(guò)dblink訪問(wèn)另一臺(tái)數(shù)據(jù)庫(kù)時(shí)，他們之間建立起一個(gè)會(huì)話，這個(gè)等待事件發(fā)生在這個(gè)會(huì)話之間的通信過(guò)程中，同樣如果出現(xiàn)這個(gè)等待事件，需要檢查兩臺(tái)數(shù)據(jù)庫(kù)之間的通信問(wèn)題。

這個(gè)等待事件有兩個(gè)參數(shù)：
Driver id: 服務(wù)器和客戶端連接使用的協(xié)議信息。
Break？：零表示服務(wù)端向客戶端發(fā)送一個(gè)重置（reset）信息，非零表示服務(wù)器端向客戶端發(fā)送一個(gè)斷開(kāi)（break）消息。

26. SQL*Net message from client
這個(gè)等待事件基本上是最常見(jiàn)的一個(gè)等待事件。當(dāng)一個(gè)會(huì)話建立成功后，客戶端會(huì)向服務(wù)器端發(fā)送請(qǐng)求，服務(wù)器端處理完客戶端請(qǐng)求后，將結(jié)果返回給客戶端，并繼續(xù)等待客戶端的請(qǐng)求，這時(shí)候會(huì)產(chǎn)生SQL*Net message from client 等待事件。

很顯然，這是一個(gè)空閑等待，如果客戶端不再向服務(wù)器端發(fā)送請(qǐng)求，服務(wù)器端將一直處于這個(gè)等待事件狀態(tài)。

這個(gè)等待事件包含兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端接收到的來(lái)自客戶端消息的字節(jié)數(shù)。

27． SQL*Net message from dblink
這個(gè)等待事件和SQL*Net message from client相同，不過(guò)它表示的是數(shù)據(jù)庫(kù)通過(guò)dblink 訪問(wèn)另一個(gè)數(shù)據(jù)庫(kù)時(shí)，他們之間會(huì)建立一個(gè)會(huì)話，這個(gè)等待事件發(fā)生在這個(gè)會(huì)話之間的通信過(guò)程中。

這個(gè)等待事件也是一個(gè)空閑等待事件。

這個(gè)事件包含兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端通過(guò)dblink 收到的來(lái)自另一個(gè)服務(wù)器端消息的字節(jié)數(shù)。

28. SQL*Net message to client
這個(gè)等待事件發(fā)生在服務(wù)器端向客戶端發(fā)送消息的時(shí)候。當(dāng)服務(wù)器端向客戶端發(fā)送消息產(chǎn)生等待時(shí)，可能的原因是用戶端太繁忙，無(wú)法及時(shí)接收服務(wù)器端送來(lái)的消息，也可能是網(wǎng)絡(luò)問(wèn)題導(dǎo)致消息無(wú)法從服務(wù)器端發(fā)送到客戶端。

這個(gè)等待事件有兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端向客戶端發(fā)送消息的字節(jié)數(shù)。

29. SQL*Net message to dblink
這個(gè)等待事件和SQL*Net message to client 相同，不過(guò)是發(fā)生在數(shù)據(jù)庫(kù)服務(wù)器和服務(wù)器之間的等待事件，產(chǎn)生這個(gè)等待的原因可能是遠(yuǎn)程服務(wù)器繁忙，而無(wú)法及時(shí)接收發(fā)送過(guò)來(lái)的消息，也可能是服務(wù)器之間網(wǎng)絡(luò)問(wèn)題導(dǎo)致消息無(wú)法發(fā)送過(guò)來(lái)。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端通過(guò)dblink發(fā)送給另一個(gè)服務(wù)器消息的字節(jié)數(shù)。

30. SQL*Net more data from client
服務(wù)器端等待用戶發(fā)出更多的數(shù)據(jù)以便完成操作，比如一個(gè)大的SQL文本，導(dǎo)致一個(gè)SQL*Net 數(shù)據(jù)包無(wú)法完成傳輸，這樣服務(wù)器端會(huì)等待客戶端把整個(gè)SQL 文本發(fā)過(guò)來(lái)在做處理，這時(shí)候就會(huì)產(chǎn)生一個(gè)SQL*Net more data from client 等待事件。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端從客戶端接收到消息的字節(jié)數(shù)。

31. SQL*Net more data from dblink
在一個(gè)分布式事務(wù)中，SQL 分布在不同的數(shù)據(jù)庫(kù)中執(zhí)行，遠(yuǎn)程數(shù)據(jù)庫(kù)執(zhí)行完畢后將結(jié)果通過(guò)dblink返給發(fā)出SQL的數(shù)據(jù)庫(kù)，在等待數(shù)據(jù)從其他數(shù)據(jù)庫(kù)中通過(guò)dblink傳回的過(guò)程中，如果數(shù)據(jù)在遠(yuǎn)程數(shù)據(jù)庫(kù)上處理時(shí)間很久，或者有大量的結(jié)果集需要返回，或者網(wǎng)絡(luò)性能問(wèn)題都會(huì)產(chǎn)生SQL*Net more data from dblink 等待事件，它的意思是本地?cái)?shù)據(jù)庫(kù)需要等到所有的數(shù)據(jù)從遠(yuǎn)程處理完畢通過(guò)dblink傳回后，才可以在本機(jī)繼續(xù)執(zhí)行操作。

32. SQL*Net more data to client
當(dāng)服務(wù)器端有太多的數(shù)據(jù)需要發(fā)給客戶端時(shí)，可能會(huì)產(chǎn)生SQL*Net more data to client等待事件，也可能由于網(wǎng)絡(luò)問(wèn)題導(dǎo)致服務(wù)器無(wú)法及時(shí)地將信息或者處理結(jié)果發(fā)送給客戶端，同樣會(huì)產(chǎn)生這個(gè)等待。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù)：
Driver id: 服務(wù)器端和客戶端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端向客戶端發(fā)送消息的字節(jié)數(shù)。

33. SQL*Net more data to dblink
這個(gè)等待事件和SQL*Net more data to client 等待時(shí)間基本相同，只不過(guò)等待發(fā)生在分布式事務(wù)中，即本地?cái)?shù)據(jù)庫(kù)需要將更多的數(shù)據(jù)通過(guò)dblink發(fā)送給遠(yuǎn)程數(shù)據(jù)庫(kù)。由于發(fā)送的數(shù)據(jù)太多或者網(wǎng)絡(luò)性能問(wèn)題，就會(huì)出現(xiàn)SQL*Net more data to dblink等待事件。

終極折扣進(jìn)行時(shí)！盛宴，不容錯(cuò)過(guò)！

作為國(guó)內(nèi)數(shù)據(jù)庫(kù)與大數(shù)據(jù)領(lǐng)域最大規(guī)模的技術(shù)盛宴，2016第七屆中國(guó)數(shù)據(jù)庫(kù)技術(shù)大會(huì)(DTCC)將于2016年5月12日-14日召開(kāi)。

大會(huì)云集了國(guó)內(nèi)外頂尖專家，共同探討MySQL、智能數(shù)據(jù)平臺(tái)、數(shù)據(jù)治理、大數(shù)據(jù)創(chuàng)業(yè)、大數(shù)據(jù)深度學(xué)習(xí)等領(lǐng)域的前瞻性熱點(diǎn)話題與技術(shù)，為數(shù)據(jù)庫(kù)人群、大數(shù)據(jù)從業(yè)人員、廣大互聯(lián)網(wǎng)人士及行業(yè)相關(guān)人士提供最具價(jià)值的交流平臺(tái)。

最后折扣期！4月20日前，訂購(gòu)DTCC大會(huì)門票可享8.8折優(yōu)惠！團(tuán)購(gòu)更有折上折！

本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊舉報(bào)。

国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看