1 環境

oracle 11.2.0.4 RAC（2 nodes），centos 6.8，實體機

2 問題

線上環境執行一條sql

sql> select ST_AsText(ST_Geometry('POINT (10 10)', 0)) from dual;

session第一連次接耗時穩定20秒，後面消耗毫秒級，前期開發已經進行排除index，碎片等問題

執行計劃如下：
SQL> select ST_AsText(ST_Geometry('POINT (10 10)', 0)) from dual;

ST_ASTEXT(ST_GEOMETRY('POINT(1010)',0))
--------------------------------------------------------------------------------
POINT  ( 10.00000000 10.00000000)


Execution Plan
----------------------------------------------------------
Plan hash value: 1388734953

-----------------------------------------------------------------
| Id  | Operation         | Name | Rows        | Cost (%CPU)| Time        |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |        |     1 |     2   (0)| 00:00:01 |
|   1 |  FAST DUAL         |        |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------


Statistics
----------------------------------------------------------
       2092  recursive calls
        208  db block gets
       3232  consistent gets
         16  physical reads
          0  redo size
       1167  bytes sent via SQL*Net to client
        949  bytes received via SQL*Net from client
          5  SQL*Net roundtrips to/from client
        113  sorts (memory)
          0  sorts (disk)
          1  rows processed

3 解決思路

線上環境經過執行sql，發現每一次初始session連線的時候，該執行都會花費穩定20秒（凡是呼叫這個外部lib庫的sql）

測試環境執行該sql，沒有發現任何異常，返回都是毫秒級

於是對2個環境進行對比（系統，網路，架構，以及oralce引數檔案）

　　　　　　　　測試　　　　　　　　　　　　　　線上

系統　　　　　　centos6.8 虛擬機器   　　　　　　　centos6.8 實體機

oracle版本 　　11.2.0.4.0 - Production 　　　　　　11.2.0.4.0 - Production

例項　　　　　　RAC 2nodes　　　　　　　　　　RAC 2nodes

然後是測試環境的cp，expdp的檔案匯入線上的環境，除了網路ip和記憶體等大小，其他引數幾乎都一樣

這個時候，只好拿出2邊的AWR報告來對比了（--可以參考一篇關於awr的文章）

測試環境的awr報告

檢查線上的awr報告，發現，紅圈標註

--此事件 External Procedure initial connection 穩定花費20秒，於是就基本確認是這個呼叫lib庫的問題。

期間查詢網路文件，很少有相關的資料，於是就重新上傳lib庫檔案，發現問題依舊，然後在本地環境試著匯入測試的expdp檔案，發現還是不能復現線上的問題

奮戰到11點，今早上來，發現帖子有人回（newkid大神)

http://www.itpub.net/thread-2106999-1-1.html

引用的連結https://community.oracle.com/thread/2490921，在昨天的同事也發過一次（以為是grid的sqlnet檔案，發現是正常的，而且線上和測試環境的配置都是一樣的），這裡再稍微仔細的看了一遍。

抱著測試的心態，先在本地環境oracle rdbms home的路徑加了該檔案，2個節點都新增，然後重啟監聽

--因為是11.2.0.4的rac環境，監聽是grid使用者在管理，

[[email protected] ~]$ cat /u01/app/11.2.0/grid/network/admin/listener.ora
LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) # line added by Agent
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent

[[email protected] ~]$ cat /u01/app/11.2.0/grid/network/admin/sqlnet.ora
# sqlnet.ora.rac2 Network Configuration File: /u01/app/11.2.0/grid/network/admin/sqlnet.ora.rac2
# Generated by Oracle configuration tools.

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

ADR_BASE = /u01/app/grid

[[email protected] ~]$ cat /u01/app/11.2.0/grid/network/admin/endpoints_listener.ora
LISTENER_RAC2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=rac2vip)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=10.15.7.12)(PORT=1521)(IP=FIRST)))) # line added by Agent

[[email protected] ~]$ cat /u01/app/oracle/product/11.2.0/db_1/network/admin/tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.2.0/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

a =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scanip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = abc)
)
)

[[email protected] ~]$ cat /u01/app/oracle/product/11.2.0/db_1/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)

發現問題消失，然後經過幾次測試，都是毫秒級返回。然後就在線上機器上進行修改並進行測試，發現問題消失，問題消失，問題消失

--事後疑問：本地環境，測試環境都沒有新增檔案/u01/app/oracle/product/11.2.0/db_1/network/admin/sqlnet.ora ，但是沒有出現呼叫外部lib庫的sql執行緩慢的問題，為什麼線上環境就出現了

--線上環境，這裡即將上線的，所以可以進行一定的修改和重啟（正式線上的環境建議慎重修改--足夠的測試和選擇時間等。。）

--結合官方文件（https://docs.oracle.com/cd/E11882_01/network.112/e41945/toc.htm），對oralce的監聽檔案，listener.ora,sqlnet.ora,tnsname.ora進行學習了一遍