OGG-投遞程序端口簡要說明

一、目标

本篇部落格講述OGG投遞程序端口之間的關系，梳理清楚後，便于問題排查及問題定位。

二、OGG相關程序端口

2.1 OGG MGR占用什麼端口？ 

Mgr參數配置中
PORT 7809 
這個就是MGR程序占用的端口
1.目标庫OGG MGR程序stop 情況下,源端投遞程序abend，提示無法tcp傳輸！ 
2.如果OGG部署在RAC上面，并且使用ACFS\NFS等檔案系統，可能遇到MGR在某個節點IP啟用，與源端投遞程序對應的IP不一緻！進而也是無法正常投遞過去的！      

2.2 MGR 動态端口幹啥用的？

參考學習這篇文章：
GoldenGate 如何在源提取泵和目标伺服器/收集器之間配置設定端口？（文檔 ID 965270.1）

Configuration:
An Extract pump will have the RMTHOST parameter which is generally configured simply as:
RMTHOST <target IP>, MGRPORT <target manager port number>
Example: RMTHOST REMOTESERVER, MGRPORT 7809 
To control port usage on a machine (the target in this case) generally most sites have the Manager DYNAMICPORTLIST parameter that
 restricts OGG into using a range of ports.
Please refer to the reference manual for the RMTHOST,PORT and DYNAMICPORTLIST parameterS for more details.
Example of manager parameters:
PORT 7809
DYNAMICPORTLIST 8000-8010
也就是說，OGG在指定的動态端口清單中，對OGG進行配置設定端口！ 并且通過這個參數限制了OGG能使用的端口範圍，及端口數量！！！      

2.3 OGG是如何配置設定這些動态端口的？

How does GoldenGate allocates ports between Source Extract pump and Target Server/collector?  
When an Extract pump starts it requests a link to the target node using the port number as specified in RMTHOST. 
RMTHOST REMOTESERVER, MGRPORT 7809
The manager process would be running in node REMOTESERVER and listening on port 7809. 
The target manager will start a collector and pass to the collector if configured the DYAMICPORTLIST range of ports. If this is

 not configured random ports will be used.
The target manager tend goes back to listening on port 7809.
The collector will try to use (calling TCP/IP BIND) each port in sequence until it finds one that works. The collector will
 communicate back to the Extract pump and instructs the Extract pump to use this port for communication.
Notes:
You can check which ports are used on the target using the GGSCI > SEND MGR GETPORTINFO. 
Prior to Version 11, the manager searched for a port for the server instead of the server locating a useable port.
對于OGG來說，OGG的端口是與OGG的投遞程序相關的，投遞程序跨主機網絡進行傳輸資料，需要使用程式的端口來進行溝通！
那麼對于投遞程序參數中的目标OGG端口寫誰？  一般是寫OGG 目标環境的MGR PORT端口，目标庫OGG MGR PORT作為一個監聽端口。
動态端口的使用基本是按照順序依次配置設定使用，是以端口不夠用的情況下，達到門檻值後，就報TCP無法傳輸的情況。      

2.4 如何診斷OGG端口的問題？

一、案例一，OGG MGR可以認為目标庫沒有啟動,導緻源端OGG投遞程序投遞IP+ OGG MGR PORT在對應主機端口不通！
首選OGG投遞程序可用的情況是，目标庫OGG MGR 端口在主機層面是存在的，程式MGR程序沒啟動則端口并沒有開啟！
OGG Troubleshooting TCP/IP Errors In Open Systems (Doc ID 966227.1)
主機層面确認OGG MGR端口已開啟

二、案例二，動态端口清單不足，端口占滿了，導緻投遞程序失敗！
有個朋友之前溝通過這個問題，沒有截圖保留。 這個問題如何排查呢？
OGG GGS Error 150: No Dynamic Ports Available Orphan Ports Server Collector (Doc ID 965356.1)
1）如下方式查詢端口使用的情況      

# netstat -tunlp|grep 784

如果可用，“lsof”指令可能更易于使用。例如，給定“DYNAMICPORTLIST 7841-7899”，使用：

lsof -ni:7890-7919

SEND MGR GETPORTINFO detail

send mgr childstatus debug

這些方法都是輔助，從側面得到端口的使用情況；

  2）驗證

将一個正常投遞到目标主機OGG的投遞程序關閉，釋放占用的端口後；

之前報錯的源端OGG投遞程序啟動，如果正常啟動。 基本上可以确認是端口不足導緻的！

另外一個問題，OGG一個投遞程序占用一個端口嗎？  不是的

三、案例三，MOS 截取，端口不通！ 源端到目标端MGR端口不通也會導緻這個問題！

防火牆 Or 端口沒開都會導緻這個情況。

$ telnet remote_system_name 7890

 MOS建議網絡問題排查很費勁的情況下，直接開啟雙向的目标端端口就行！省事

四、案例四，MOS截取，MGR端口異常

If running, check that MGR is responding to connection requests and commands:

GGSCI (remote_system) 4> send mgr getportinfo detail

Sending GETPORTINFO, request to MANAGER ...

Dynamic Port List

Starting Index 0

Reassign Delay 3 seconds

Entry Port Error Process Assigned Program

----- ----- ----- ---------- ------------------- -------

0 7891 0

1 7892 0

2 7893 0

3 7894 0

4 7895 0

5 7896 0

6 7897 0

7 7898 0

8 7899 0

If the comand times out, kill and restart MGR:

執行MGR端口清單查詢，正常的指令執行逾時，那麼MOS建議Kill mgr,重新open

五、其它可能性

If none of the above help identify the problem, contact your network administrator to check firewall settings and make sure the ports are

open both ways.

An often overlooked issue is that any error that kills the server collector process appears as a TCP error to the sending extract. 
If a server does not have write privileges to the trail or if a disk is full, the server dies. A dying server looks like a lost connection to TCP.
 The user should always verify the ability to write trails as part of the troubleshooting process. This is particularly applicable for the case:      

"The "dynamic" Server/Collector process terminated immediately after starting"

空間滿了，沒權限啥的也會導緻源端投遞程序報錯。