oracle 12c 新增的LREG進程及其動態注冊的過程

因剛好遇到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秒一次的嘗試注冊等，都可以清楚的看到。