從去年開始便一直使用的是 ogg 19c，但今年年中時候發現 Oracle 官方居然將 Linux x64 位的 ogg 下載鏈接下架了，不知為何無法下載到這個版本了（PS：有需要的可點擊這里下載：http://m.sunline.cc/download/761440），微服務版本也沒有了，現在只能從官網看到 21c 的安裝包。
http://www.oracle.com/technetwork/middleware/goldengate/downloads/index.html
取而代之的是如下 21.3 的安裝包。
查看 OGG 19c 版本的生命周期呢也和數據庫是一樣的長期支持版本，怎么突然就下載不到了呢，郁悶……
所以呢，也緊跟官方步伐，試試 OGG 21c，安裝方法無差別，據說可以遠程復制，不用和數據庫綁定到同一主機了，不過我這里是和數據庫同主機同用戶部署的，然后就遇到了今天要說的第一個問題：
1）dblogin 無法登錄到 OGG，ORA-12154 TNS 錯誤
不管我在 Oracle 11g 中，還是在新建的 Oracle 19c 中都會出現這個問題，最初是在八月初的時候打算使用 ogg 21c 來捕獲 Oracle 11g 的數據，但安裝完后就報了登錄錯誤的問題，總感覺是環境變量的問題，反復查找了半天，終究沒有找到問題所在，由于時間緊，故當時采取的措施就是先卸載了 21c 用 ogg 19c 保證沒有問題。
GGSCI (oracle19c) 18> dblogin userid ogg@TEST,password ogg
2022-10-14 17:07:23 INFO OGG-03542 Failed to connect to the database. Verify that the connection string and following environment variables are correct:
LD_LIBRARY_PATH = /u01/app/oracle/product/19.0.0/dbhome_1/lib:/lib:/usr/lib.
Error: OCI Error ORA (status = 12154-ORA-12154: TNS:could not resolve the connect identifier specified
)
GGSCI (oracle19c) 19> dblogin userid ogg,password ogg
2022-10-14 17:07:47 INFO OGG-03542 Failed to connect to the database. Verify that the connection string and following environment variables are correct:
LD_LIBRARY_PATH = /u01/app/oracle/product/19.0.0/dbhome_1/lib:/lib:/usr/lib.
Error: OCI Error ORA (status = 12545-ORA-12545: Connect failed because target host or object does not exist
)
查看認證列表，OGG21c 對 11.2.0.4 版本的數據庫也是支持的。
出現問題的原因：
OGG 21c 集成了 Oracle 輕量級客戶端工具 instantclient，所以才可以獨立部署，遠程捕獲。不然需要借助 Oracle 客戶端 TNS_ADMIN 配置的連接串遠程登錄。
$ tree instantclient
instantclient
+-- libclntshcore.so.21.1
+-- libclntsh.so.21.1
+-- libnnz21.so
+-- libocci.so.21.1
+-- libociei.so
+-- libocijdbc21.so
+-- liboramysql.so
+-- libsqlplusic.so
+-- libsqlplus.so
+-- sqlplus
解決辦法：
修改環境變量
修改 .bash_profile 環境變量，指定 TNS_ADMIN 的具體路徑，然后在此路徑下配置 tns 遠程連接地址即可使用 dblogin userid user@tns passwd 登錄到數據庫。
export TNS_ADMIN=$ORACLE_HOME/network/admin
Goldengate DBLOGIN Issue OCI Error ORA (status = 12545-ORA-12545 (Doc ID 2847434.1)
對于 GoldenGate 21c，該軟件包含數據庫客戶端庫。優點是您只有一個 GoldenGate 軟件可以連接到 11gR2、12c、18c、19c 和 21g 數據庫版本。在早期版本（19c 及更低版本）中，每個數據庫版本都有一個特定的 GoldenGate 構建。此外，如果您在中間層（HUB 模型）中運行 GoldenGate，則不必安裝 Oracle 數據庫客戶端軟件。因此，您必須使用 TNS 連接限定符（別名）來連接到任何數據庫。這意味著 TNS 別名的相應信息是 tnsnames.ora 的一部分。通常，您的地址條目包含主機名、端口、協議和服務名稱等信息。
GGSCI 1> dblogin userid user@ABCD 密碼
當然如果 ogg 21c 獨立于數據庫單獨部署時，又因為集成了客戶端，所以也不需要單獨安裝 Oracle 客戶端，配置免密登錄即可。在 ogg 12c 及以上的版本中， 增強了數據的安全性， 提供了密碼登錄功能，具體可以這樣：
---創建身份證明
ggsci
add credentialstore
alter credentialstore add user ogg@192.168.76.15:11521/test,password ogg alias source_11g
alter credentialstore add user ogg@192.168.221.75:11521/test4db,password ogg alias target_19c
INFO CREDENTIALSTORE
--登錄數據庫
dblogin useridalias source_11g
2) ogg 19c 啟動捕獲進程運行一段時間后報錯 OGG-00663 OCI Error ORA-03113
由于前面使用了 ogg 19c，在正常捕獲期間源端 ext1 有這個錯誤,OGG-00663 OCI Error ORA-03113: end-of-file on communication channel，可直接 start ext1 但半小時不到又報同樣錯。這里順便說下這并不是 OGG 的問題，只是運行期間剛好出現，那就一起說說。
問題原因
感覺是數據庫和客戶端交互時直接中斷了，類似于直接在數據庫服務器上殺掉所有會話，這顯然是不太可能的，即使是測試環境我們也沒有人去這么做。網絡方面也不會去動這塊，再說了也是位于同一主機，那么問題可能還是出在配置上。
解決辦法
先按照 MOS 的參考建議修改系統參數，原先這三個意味著 TCP 保持連接進程在發送第一個保持連接探測之前要為套接字活動等待兩個小時(7200秒)，然后每 75 秒重新發送一次。只要 TCP/IP 套接字通信在進行并處于活動狀態，就不需要保持連接包。將以下三個參數間隔值調小一些：
vim /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 60 ###1 分鐘后開始發送 keepalive 空包
net.ipv4.tcp_keepalive_intvl = 10 ###在第一次保持連接探測后每 10 秒重新發送一次
net.ipv4.tcp_keepalive_probes = 6 ###在連接超時之前要發送的探測數量
sysctl -p 使其生效。
參考文檔：Extract Executable Failed to Abend during a Network Outage (文檔 ID 2699295.1)
后面大概又運行了半個小時多的樣子，又中斷了，報錯還是一樣，看來還是沒有得到解決。繼續排查中發現，在 sqlnet.ora 配置中有如下一些配置，最后兩行參數不知道何時加的，誰加上去的，已經不得而知了。先注釋掉 sqlnet.ora 這兩參數后面問題就解決了，一直運行正常。
那么這兩個參數是什么意思呢？官方文檔上有個簡單的解釋。
關于 SQLNET.RECV_TIMEOUT 和 SQLNET.SEND_TIMEOUT ，我們可以在客戶端和服務器端配置它們。
例如，如果我們在服務器端設置 SQLNET.RECV_TIMEOUT=120 ，這意味著如果數據庫在 120 秒內沒有收到來自客戶端的請求包交換，則與該客戶端的連接被終止，超時。如果 SQLNET.SEND_TIMEOUT=120 且數據庫無法在 120 秒內完成向客戶端的發送操作，則連接超時。例如，如果客戶端異常關閉，數據庫試圖發送的信息在 120s 內沒有收到響應，則操作超時。很大原因是有人之前設置過這兩個參數又沒有及時取消才導致了 OGG 在捕獲一段時間后中斷。
有關這些參數的更多信息，請參閱以下文檔：
http://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#CIHCCCHD
http://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF182
http://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF227
SQLNET.RECV_TIMEOUT：指定數據庫服務器在建立連接后等待客戶端數據的時間（以秒為單位）。客戶端必須在時間間隔內發送一些數據。對于客戶端偶爾或異常關閉的環境，建議設置該參數。如果客戶端沒有在指定的時間內發送任何數據，那么數據庫服務器會記錄 ORA-12535: TNS:operation timed out和 ORA-12609: TNS: Receive timeout occurred 在 sqlnet.log 文件的消息。如果沒有此參數，數據庫服務器可能會繼續等待來自可能已關閉或遇到困難的客戶端的數據。
您也可以在客戶端設置此參數，以指定客戶端在連接建立后等待來自數據庫服務器的響應數據的時間，以秒為單位。如果沒有這個參數，客戶端可能會等待很長一段時間來等待來自請求飽和的數據庫服務器的響應。如果您選擇設置該值，則將該值設置為初始低值并根據系統和網絡容量進行調整。如有必要，將此參數與 SQLNET.SEND_TIMEOUT 參數一起使用。
SQLNET.SEND_TIMEOUT:指定數據庫服務器在建立連接后完成向客戶端發送操作的時間（以秒為單位）。對于客戶端偶爾或異常關閉的環境，建議設置該參數。如果數據庫服務器無法在指定的時間內完成發送操作，那么它會記錄 ORA-12535: TNS:operation timed out和ORA-12608: TNS: Send timeout occurred 消息到 sqlnet.log 文件。如果沒有此參數，數據庫服務器可能會繼續向由于計算機停機或忙碌狀態而無法接收數據的客戶端發送響應。
您也可以在客戶端設置此參數，以指定客戶端在連接建立后完成向數據庫服務器發送操作的時間，以秒為單位。如果沒有這個參數，客戶端可能會繼續向已經被請求飽和的數據庫服務器發送請求。如果您選擇設置該值，則將該值設置為初始低值并根據系統和網絡容量進行調整。如有必要，將此參數與 SQLNET.RECV_TIMEOUT 參數一起使用。
3） ogg 21c EXTRACT 進程無法正常啟動報錯 OGG-02022
當在源端 11g 配置好 extract 進程后,無法啟動查看日志則報此錯誤“ERROROGG-02022 Logmining server does not exist on this Oracle database",在源庫找不到日志挖掘服務。這個問題比較簡單，是由于沒有將 extract 注冊到數據庫。
使用如下命令注冊。
注意：先要登錄到數據庫。
GGSCI (oggtest) 4> add credentialstore
Credential store created.
GGSCI (oggtest) 5> alter credentialstore add user ogg@192.168.76.15:11770/jiekexu,password test alias source_11g
Credential store altered.
GGSCI (oggtest) 6> info credentialstore
Reading from credential store:
Default domain: OracleGoldenGate
Alias: source_11g
Userid: ogg@192.168.76.15:11770/jiekexu
GGSCI (oggtest) 7> dblogin useridalias source_11g
Successfully logged into database.
GGSCI (oggtest as ogg@jiekexu) 9> register extract ext1 database
2022-10-14 20:55:31 INFO OGG-02003 Extract group EXT1 successfully registered with database at SCN 607680081.
--添加進程 EXTRACT
ADD EXTRACT ext2 INTEGRATED TRANLOG,BEGIN NOW
add exttrail /ogg21c/dirdat/T4, extract ext2, megabytes 1024
--刪除進程 EXTRACT
UNREGISTER extract ext2 database
delete extract EXT2
4） ogg 21c EXTRACT 進程無法正常啟動報錯 OGG-02912
當在源端 11g 配置好 extract 進程后,無法啟動查看日志則報此錯誤“ERROR OGG-02912 Patch 17030189 is required on your Oracle mining database for trail format RELEASE 12.2 or later”
在 MOS 中，文檔 Doc ID 2304095.1 “ERROR OGG-02912 Patch 17030189 is required on your Oracle mining database for trail format RELEASE 12.2 or later” 的描述中. 在 OGG 家目錄下存在 “prvtlmpg.plb” 腳本，可以在源庫執行 @/ogg21c/prvtlmpg.plb 此問題也可以解決。版本 12.2 或更高版本的 Oracle 挖掘數據庫需要補丁 17030189。
當然按照提示找到 17030189 這個補丁，運用到數據庫中也是可以解決這個問題的。下面就來說說這種小補丁的更新和回退方法。
到 MOS 上下載這個補丁上傳到源端數據庫服務器。
$ unzip p17030189_11204170418_Generic.zip -d <PATCH_TOP_DIR>
$ export PATH=.:$PATH:$HOME/.local/bin:$HOME/bin:$ORACLE_HOME/OPatch:$ORACLE_HOME/bin
$ opatch lsinventory
$ opatch version
$ cd <PATCH_TOP_DIR>/17030189
$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ --該報告將指出與此補丁沖突的補丁，以及當前17030189為超集的補丁。
安裝補丁
- 將當前目錄設置為補丁所在的目錄，然后輸入以下命令運行OPatch實用程序:
$ cd <PATCH_TOP_DIR>/17030189
$ opatch apply
2.運行命令驗證補丁是否安裝成功。
$ opatch lsinventory
以下步驟將修改后的 SQL 文件加載到數據庫中。對于 RA C環境，只在一個節點上執行這些步驟。
- 對于在打了補丁的 Oracle 主服務器上運行的每個數據庫實例，使用 SQL*Plus 連接到數據庫。以 SYSDBA 身份連接并運行以下腳本，如下所示:
$ sqlplus / nolog
SQL > connect / as sysdba
SQL> @?/sqlpatch/17030189/postinstall.sql
2.檢查輸出是否有錯誤。
卸載補丁
- 執行如下命令卸載補丁。
$ opatch rollback -id 17030189
2.確保您驗證了 Oracle Inventory，并將輸出與補丁安裝之前運行的輸出進行比較，并重新應用作為該補丁應用的一部分而回滾的任何補丁。驗證庫存，運行命令如下:
$ opatch lsinventory
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @?/sqlpatch/17030189/postdeinstall.sql
SQL> select * from registry$history order by id;
OGG 21c 新特性
OGG 21.1 中的主要新功能
- 多個 Oracle 數據庫版本的簡化安裝
單個獨立部署，捆綁數據庫客戶端并支持從 11.2 到 21c 的所有 Oracle 數據庫版本。 - 自治數據庫 ATP/ADW 捕獲（僅限共享數據庫）
- 更安全：Kerberos Authentication
全文完，希望可以幫到正在閱讀的你，如果覺得此文對你有幫助，可以分享給你身邊的朋友，同事，你關心誰就分享給誰，一起學習共同進步~~~
?? 歡迎關注我的公眾號【JiekeXu DBA之路】，一起學習新知識！
————————————————————————————
公眾號：JiekeXu DBA之路
CSDN ：https://blog.csdn.net/JiekeXu
墨天輪：http://m.sunline.cc/u/4347
騰訊云：https://cloud.tencent.com/developer/user/5645107
————————————————————————————
