主頁(yè) > 知識(shí)庫(kù) > Oracle中常見(jiàn)的33個(gè)等待事件小結(jié)

Oracle中常見(jiàn)的33個(gè)等待事件小結(jié)

熱門(mén)標(biāo)簽:征服者火車(chē)站地圖標(biāo)注 開(kāi)封智能外呼系統(tǒng)廠家 阿爾巴尼亞地圖標(biāo)注app 美圖秀秀地圖標(biāo)注 人工智能地圖標(biāo)注自己能做嗎 百度地圖標(biāo)注素材 征服眼公司地圖標(biāo)注 外呼線路外顯本地號(hào)碼 word地圖標(biāo)注方向
一. 等待事件的相關(guān)知識(shí)

1.1 等待事件主要可以分為兩類(lèi),即空閑(IDLE)等待事件和非空閑(NON-IDLE)等待事件。
1). 空閑等待事件指ORACLE正等待某種工作,在診斷和優(yōu)化數(shù)據(jù)庫(kù)的時(shí)候,不用過(guò)多注意這部分事件。
2). 非空閑等待事件專(zhuān)門(mén)針對(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;
 名稱(chēng)                   是否為空? 類(lèi)型
 ----------------------------------------- -------- ---------------
 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 查看等待事件分類(lèi)情況
/* 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í),通常可以從V$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è)視圖,用戶(hù)可以迅速獲得數(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ù)做修改(即使其他用戶(hù)修改的不是當(dāng)前用戶(hù)修改的數(shù)據(jù)),但是可以以一致性的方式讀取這個(gè)數(shù)據(jù)塊(from undo)。當(dāng)前的用戶(hù)修改完這個(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è)用戶(hù)頻繁地讀取或者修改同樣的數(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#

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

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

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名稱(chēng):
/* 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)榉Q(chēng)為控制文件并行寫(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ù)量,將控制文件的拷貝存放在不同的物理磁盤(pán)上的方式來(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ū)懙?,所以讀取的時(shí)候也是順序的,因此稱(chēng)為控制文件順序讀,它經(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è)等待事件和并行操作(比如并行查詢(xún),并行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)等待事件,它同樣和用戶(hù)的并行操作沒(méi)有關(guān)系,它是由后臺(tái)進(jìn)程DBWR產(chǎn)生的,當(dāng)后臺(tái)進(jìn)程DBWR向磁盤(pán)上寫(xiě)入臟數(shù)據(jù)時(shí),會(huì)發(fā)生這個(gè)等待。

DBWR會(huì)批量地將臟數(shù)據(jù)并行地寫(xiě)入到磁盤(pán)上相應(yīng)的數(shù)據(jù)文件中,在這個(gè)批次作業(yè)完成之前,DBWR將出現(xiàn)這個(gè)等待事件。如果僅僅是這一個(gè)等待事件,對(duì)用戶(hù)的操作并沒(méi)有太大的影響,當(dāng)伴隨著出現(xiàn)free buffer waits等待事件時(shí),說(shuō)明此時(shí)內(nèi)存中可用的空間不足,這時(shí)候會(huì)影響到用戶(hù)的操作,比如影響到用戶(hù)將臟數(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ě)入到磁盤(pán)上,它只需要等到這個(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è)用戶(hù)操作引起的等待事件,當(dāng)用戶(hù)發(fā)出每次I/O需要讀取多個(gè)數(shù)據(jù)塊這樣的SQL 操作時(shí),會(huì)產(chǎn)生這個(gè)等待事件,最常見(jiàn)的兩種情況是全表掃描(FTS: Full Table Scan)和索引快速掃描(IFFS: index fast full scan)。

這個(gè)名稱(chēng)中的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í),意味著磁盤(pán)上有大量的臨時(shí)數(shù)據(jù)產(chǎn)生,比如排序,并行執(zhí)行等操作?;蛘咭馕吨鳳GA中空閑空間不足。

這個(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ě)入到磁盤(pán)文件上,而不經(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 的名稱(chēng)和類(lèi)型。
Mode: enqueue的模式。

可以使用如下SQL 查看當(dāng)前會(huì)話等待的enqueue名稱(chēng)和類(lèi)型:
/* 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';

Oracle 的enqueue 包含以下模式:

模式代碼
解釋
1
Null (NULL)
2
Row-S(SS)
3
Row-X(SX)
4
Share(S)
5
S/Row-X(SSX)
6
Exclusive(X)

Oracle的enqueue 有如下類(lèi)型:
Enqueue 縮寫(xiě)
縮寫(xiě)解釋
BL
Buffer Cache management
BR
Backup/Restore
CF
Controlfile transaction
CI
Cross-instance Call Invocation
CU
Bind Enqueue
DF
Datafile
DL
Direct Loader Index Creation
DM
Database Mount
DR
Distributed Recovery Process
DX
Dirstributed Transaction
FP
File Object
FS
File Set
HW
High-water Lock
IN
Instance Number
IR
Instance Recovery
IS
Instance State
IV
Library Cache Invalidation
JI
Enqueue used during AJV snapshot refresh
JQ
Job Queue
KK
Redo Log “Kick”
KO
Multiple Object Checkpoint
L[A-p]
Library Cache Lock
LS
Log start or switch
MM
Mount Definition
MR
Media recovery
N[A-Z]
Library Cache bin
PE
Alter system set parameter =value
PF
Password file
PI
Parallel slaves
PR
Process startup

Parallel slave synchronization
Q[A-Z]
Row Cache
RO
Object Reuse
RT
Redo Thread
RW
Row Wait
SC
System Commit Number
SM
SMON

Sequence Number
SQ
Sequence Number Enqueue
SR
Synchronized replication

Sort segment
ST
Space management transaction
SV
Sequence number Value
TA
Transaction recovery
TC
Thread Checkpoint
TE
Extend Table
TM
DML enqueue
TO
Temporary Table Object Enqueue
TS
Temporary Segement(also TableSpace)
TT
Temporary Table
TX
Transaction
UL
User-defined Locks
UN
User name
US
Undo segment, Serialization
WL
Being Written Redo Log
XA
Instance Attribute Log
XI   
Instance Registration Lock

 
關(guān)于enqueue 可以參考如下的連接:
Wait Events - Enqueue Waits
http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/WE1/Default.aspx

 
13. Free buffer waits
當(dāng)一個(gè)會(huì)話將數(shù)據(jù)塊從磁盤(pán)讀到內(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ě)到磁盤(pán)中以釋放空間

這個(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ā)生在不同用戶(hù)在共享中由于并發(fā)操作同一個(gè)數(shù)據(jù)庫(kù)對(duì)象導(dǎo)致的資源爭(zhēng)用的時(shí)候,比如當(dāng)一個(gè)用戶(hù)正在對(duì)一個(gè)表做DDL 操作時(shí),其他的用戶(hù)如果要訪問(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名稱(chēng)。

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ì)象被其他的用戶(hù)特有,就會(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名稱(chēng)。

 
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è)等待事件的瓶頸,主要的原因可能是磁盤(pán)I/O性能不夠或者REDO 文件的分布導(dǎo)致了I/O爭(zhēng)用,比如同一個(gè)組的REDO 成員文件放在相同的磁盤(pán)上。

這個(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ě)入到磁盤(pán)中的redo log 數(shù)量,必須等待LGWR 完成寫(xiě)入磁盤(pán)的操作,LGWR必須確保redo log寫(xiě)到磁盤(pán)成功之后,才能在redo buffer當(dāng)中重用這部分信息。

如果數(shù)據(jù)庫(kù)中出現(xiàn)大量的log buffer space等待事件,可以考慮如下方法:
(1)增加redo buffer的大小。
(2)提升磁盤(pán)的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ě)到磁盤(pán)上(checkpoint),這樣做的原因是,如果一個(gè)在線日志文件的信息被覆蓋,而依賴(lài)這些redo 信息做恢復(fù)的數(shù)據(jù)塊尚未被寫(xiě)到磁盤(pán)上(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è)用戶(hù)會(huì)話行為導(dǎo)致的等待事件,當(dāng)一個(gè)會(huì)話發(fā)出一個(gè)commit命令時(shí),LGWR進(jìn)程會(huì)將這個(gè)事務(wù)產(chǎn)生的redo log從log buffer里面寫(xiě)到磁盤(pán)上,以確保用戶(hù)提交的信息被安全地記錄到數(shù)據(jù)庫(kù)中。

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

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

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

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

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

這個(gè)等待事件包含兩個(gè)參數(shù):
Driver id: 服務(wù)器和客戶(hù)端連接使用的協(xié)議信息。
Break?:零表示服務(wù)端向客戶(hù)端發(fā)送一個(gè)重置(reset)信息,非零表示服務(wù)器端向客戶(hù)端發(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ù)器和客戶(hù)端連接使用的協(xié)議信息。
Break?:零表示服務(wù)端向客戶(hù)端發(fā)送一個(gè)重置(reset)信息,非零表示服務(wù)器端向客戶(hù)端發(fā)送一個(gè)斷開(kāi)(break)消息。

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

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

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

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

這個(gè)等待事件有兩個(gè)參數(shù):
Driver id: 服務(wù)器端和客戶(hù)端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端向客戶(hù)端發(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ù)器端和客戶(hù)端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端通過(guò)dblink發(fā)送給另一個(gè)服務(wù)器消息的字節(jié)數(shù)。

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

這個(gè)等待時(shí)間包含兩個(gè)參數(shù):
Driver id: 服務(wù)器端和客戶(hù)端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端從客戶(hù)端接收到消息的字節(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í)行操作。

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

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

這個(gè)等待時(shí)間包含兩個(gè)參數(shù):
Driver id: 服務(wù)器端和客戶(hù)端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端向客戶(hù)端發(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等待事件。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù):
Driver id: 服務(wù)器端和客戶(hù)端連接使用的協(xié)議信息。
#bytes: 服務(wù)器端通過(guò)dblink發(fā)送給另一個(gè)服務(wù)器消息的字節(jié)數(shù)。
您可能感興趣的文章:
  • oracle 常見(jiàn)等待事件及處理方法

標(biāo)簽:海北 宜春 淮南 葫蘆島 酒泉 泰安 孝感 六安

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《Oracle中常見(jiàn)的33個(gè)等待事件小結(jié)》,本文關(guān)鍵詞  Oracle,中,常見(jiàn),的,33個(gè),等待,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《Oracle中常見(jiàn)的33個(gè)等待事件小結(jié)》相關(guān)的同類(lèi)信息!
  • 本頁(yè)收集關(guān)于Oracle中常見(jiàn)的33個(gè)等待事件小結(jié)的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章