oracle 12c 新增的LREG程式及其動態註冊的過程

darren__chan發表於2020-01-17

因剛好遇到12c 監聽註冊的問題,現將以前關於oracle 12c lreg程式的一些學習文章分享下:


oracle 資料庫中 pmon  程式一直承擔著較多的工作,例如清理程式以及監聽註冊等 , 這相當於一個人需要同時做好幾件工作, 而當其中一件讓他應接不暇時,也許這會影響它負責的其他工作,曾經在 11g r2 版本的資料庫遇到過 pmon  程式因忙於清理異常中斷的會話而導致服務更新 和服 註冊出現異常的情況。

oracle12c 以前的版本中服務註冊一直都是由 PMON 程式負責 , 12c oracle 引入了 LREG (listener registration) 後臺程式接管了這部分工作從而減輕 PMON 的工作。

一. Oracle 監聽及服務註冊:

Oracle 中,監聽器是一個監測連入客戶端連線請求並建立和管理會話的伺服器端程式。這在當資料庫例項啟動後不同時間裡,資料庫例項與監聽器聯絡並建立了一條到該例項的通訊路徑。

服務註冊讓監聽器能夠確定資料庫服務及其 service handlers (服務處理程式)是否可用。在註冊期間,服務註冊程式向 listener 提供例項名稱,資料庫服務名稱以及 service handlers 的型別 ( 專用或共享 ) 和地址。

oracle 12c 以前,負責服務註冊的是 pmon 程式:

而在 12c 以後,負責服務註冊的換成了 LREG 程式:

監聽沒有啟動 LREG 程式不能註冊服務 , 但是 LREG 程式會定時嘗試註冊 , 如果 local_listener 沒有配置 ,LREG 會嘗試連線預設的 1521 , 直到監聽程式啟動 在監聽啟動後 LREG 進行週期註冊前 , 同樣也可以使用 ”alter system register” 立即註冊服務 .litener 的註冊資訊。實際這個過程是動態註冊的過程。

另一個需要注意的是如果 LREG  程式死了,會同樣和 pmon  一樣,資料庫例項也會 crash 12c  直接報出的 ora-500,ora-500 則是監聽註冊程式死掉。

二.動態註冊的工作過程研究:

1. 使用 oradebug Event 10257 trace name context forever, level 1 6   來將 lreg dump 出來。可以初步看出 lreg 的工作過程:

dump  出來的資訊可以看出, lreg 程式每 3 秒更新一次狀態,而到約每 60 秒時便會例項資訊進行註冊。以下在監聽沒有啟動的情況下, LREG woken up to process network events after 0 cs 之後成功的數量依然為 0 ,說明此時無法註冊成功。

   而當將監聽啟動後,在 60 秒後的下一個註冊是便可以成功註冊。

2. 使用 strace  追蹤 lreg 程式的工作過程

當資料庫運作時其背後發生了很多事,資料庫也是一個應用軟體,其背後的這一切都可以追溯到作業系統的工作原理。 在對 lreg 程式進行追蹤可能需要先了解 orcle 監聽動態註冊中的兩個概念:檔案描述符和   Sockets 檔案

當監聽程式啟動時,它會在 /var/tmp/.oracle 下建立兩個套接字檔案。  

這些檔案均是  socket  檔案, 且 s#12214.1  中的 12214  為程式號,則應為監聽的程式號,這些 socket  文被用作本地客戶端使用程式間通訊協議( ipc )和不同的 oracle 的程式通訊,而這些程式包括: tns  監聽, css  crs evm  守護程式;甚至資料庫和 asm  例項。這些 socket  主動監聽 的程式建立。在這裡 oracle  監聽建立這些 socket  檔案主要使用用作 lreg 和  tnslsnr   通訊。

   同時,會在 /proc 目錄下相應程式號檔案下建立幾個檔案描述符,這些檔案描述符( file descriptor )是核心為了高效管理已被開啟的檔案所建立的索引,其是一個非負整數(通常是小整數),用於指代被開啟的檔案,所有執行 I/O 操作的系統呼叫都透過檔案描述符。

可以看到有幾個檔案描述符,因此,確定有 為進 建的檔案描述符和 sockets

那麼 LREG 過程(以前的版本 PMON 行的 動態 註冊與檔案描述符和 sockets 檔案相關的 程是怎 的呢?

這些程式透過系統呼叫來檢視監聽器是否啟動,如果沒有發現監聽程式,則等待,並且在 3000 毫秒之後重新 嘗試 。直到 聽啟 動時 ,檔案描述符被 聽開啟,並被 定以建立彼此之 接。

要找到 LREG 程正在做什麼,我使用 STRACE OS 用程式來跟蹤它的工作。  11g 中的 PMON 程的 出不是完全相同的,因 它不是一個 專門 用於在 聽器中註冊 例的 程。另一方面, LREG 的唯一目的就是 動態 註冊, 這樣 可以解 兩個 程之 使用的系 統調 用之 的差異。

以下是 STRACE LREG 程式的日誌:  

  從以上 strace 日誌可以看到主要呼叫 epoll_wait()  函式 函式表示通 檔案描述符來等待某個 I/O 事件發生的 時間 實際 就是一個持 等待某個 IO 事件的 生,而表 到資料 庫層 面, 應該 就可以理解 為監視監聽程式是否啟動的過程,在 epoll_wait(7, {}, 1024, 3000) 的最後一個 引數 示的 時間 以毫秒 3000 毫秒 為單 位(也就是 3 秒)。

關於epoll_wait的解釋:


接下來的兩行 getrusage ()函式表示 源使用消耗,而後面 times() 時間 函式返回 時間 ,在前面的 時間 列印很明 可以看出是每 3 行一次函式。

 再繼續往下看是 socket 函式其後面的值為 10 ,表示使用一個 socket 函式來處理檔案描述符 10 。猜測這是用來與監聽器程式建立連線的檔案描述符。這裡使用的套接字是 NETLINK ,用於建立核心和網路層之間的連線。

進一步檢視下面的函式, 是對前面函式返回的檔案描述符 10 進行嘗試繫結。

在接下來的幾行中,這個檔案描述符將被用於與 PID 2582 的連線,而這個 PID 2582 LREG 程式的 PID

正在嘗試與 IP 地址 127.0.0.1 建立 接,埠號是 1521

由於沒有啟動監聽程式,並且還沒有檔案描述符 10 與程式 LREG 相關聯,因此連線被拒絕,即也沒有建立的連線。

而在啟動監聽之後, lreg 發現監聽,並可以正常建立連線後則沒有沒有報出被拒絕的錯誤 

在以上lreg程式活動的日誌可以看出 較多的 epoll_ctl與 epoll_wait函式呼叫,epoll在這裡epoll貌似一種不斷來觸發監聽並操作某些檔案描述的過程,lreg呼叫 epoll_wait  每3秒來監測監聽程式是否啟動,當發生註冊時使用 epoll_ctl去新增刪除某個檔案描述符。具體的確實一時 無法 瞭解清楚。

   

    在監聽程式啟動後,可以使用 lsof –i TCP:1521 命令 來看 lreg 程式與tnslsnr程式的連線。

     ESTABLISHED的意思是建立連線。表示兩個程式正在通訊。    ncube-lm是  nCube License Manager (即ncube管理的一個許可證明),意思是被允許,被認證開放的意思,這是tnslnr開啟的並處於LISTEN狀態。


三.總結:

      oracle 12c  除了服務註冊方面,其網路服務架構在資料庫並沒有變化。在以前的版本中,服務註冊是透過PMON程式來完成。現在 由LREG(listener registration)來處理。LREG 是一個例項級別的後臺程式並且是非常重要, 一旦該程式被殺掉,將導致資料庫例項崩,它會 做一切 PMON 過去在例項註冊的方面執行的,例如:在監聽日誌 listener.log 裡 service_update, service_register, service_died 。

      由於工作被專屬化,這裡我們可以更清晰的瞭解其工作的過程,例如每3秒一次的監測,每60秒一次的嘗試註冊等,都可以清楚的看到。



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29863023/viewspace-2673861/,如需轉載,請註明出處,否則將追究法律責任。

相關文章