ETL技術工具kettle入門筆記(一) 之kettle串連oracle rac 報listener does not currently know of sid錯誤的解決

標籤：etl   kettle   jdbc   oracle rac   

1 問題現象：

之前做的kettle 串連某個oracle資料庫 做表抽取

指令碼的表輸入資訊如：

執行時（指令碼上傳到linux機器 用sh命令執行的）表輸入報的錯誤資訊：

但是在機器裡面用sqlplus 命令登入卻可以成功：

2 解決過程：

出現問題後，一開始聯絡  來源資料系統 廠家 看是不是他們那邊資料庫做了 限制。

經過他們查看，他們那邊沒有做限制。這邊也查不到原因 後來參照別的系統 發現

134.64.197.198 是rac一個節點的浮動地址  對應的sid是 iprandb1。而iprandb 是rac的service-name。rac的service-name與sid不一樣。

源系統的 響應服務的執行個體情況：

[[email protected] ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 10-SEP-2014 17:35:09

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.4.0 - Production
Start Date                28-JAN-2014 04:29:12
Uptime                    225 days 13 hr. 5 min. 56 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /opt/app/11.2.0/grid/network/admin/listener.ora
Listener Log File         /opt/app/grid/diag/tnslsnr/iprandb1/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.17.178)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.17.181)(PORT=1521))) 172.16.17.181對應 ip134.64.197.198
Services Summary...
Service "iprandb" has 1 instance(s).
  Instance "iprandb1", status READY, has 1 handler(s) for this service...
Service "iprandbXDB" has 1 instance(s).
  Instance "iprandb1", status READY, has 1 handler(s) for this service...
The command completed successfully

之前sqlplus 命令用 iprandb 可以 可能是因為@後面就是要放著 服務名 service-name

可能 jdbc的串連方式 要求填的資料庫名 更細點 要求到sid

把kettle的表輸入指令碼 裡面的database name 由iprandb改為iprandb1 就好了

因為涉及到源系統和平台配置的好幾個廠家 所以問題拖的時間 很長，在此做記錄。

3 瞭解rac：

之前對rac瞭解很少 只是聽過這個東西，所以 借這個機會 大概瞭解下這個東西。

rac 是Oracle Real Application Cluster的簡寫 ，意思是即時應用叢集， 是 Oracle資料庫支援網格計算環境的核心技術。

自己的理解就是 可以實現負載平衡 和 叢集裡面某個節點 down 之後 可以立即切換到其它 節點 不影響 基於該資料庫的上層應用的正常運行。

一個節點 出現問題後 能夠  自動的轉到另一個節點上 的這個功能 是因為有 vip 這個東西 全稱 virtual ip 他是浮動的ip 可以自動轉換。

然後再說下 

Oracle RAC services 很多人可能都沒搞清楚 oracle服務名 與sid名的區別

（以下內容轉載自http://blog.csdn.net/leshami/article/details/8124232 ）

一、services與service_name

services

       對於用戶端應用程式而言，僅僅需要關心的是資料庫提供了哪些服務，而不需要知道它到底串連是哪個資料庫或者那個執行個體。

       因此在資料庫伺服器端我們可以建立一個或多個services供用戶端時所用，是一個或多個service_name的統稱。

       對於這些提供的服務，Oracle會將其註冊到監聽器以供外部建立串連。

       可以通過lsnrctl status [listener_name] 查看當前的服務下有多少個執行個體為其響應該服務。

       也可以通過lsnrctl service [listener_name] 查看更詳細的資訊，包括當前的串連狀況，ip，連接埠號碼等。

service_name

       指用戶端串連到執行個體的服務名。在Oracle 8i時就有提出service_name的概念，通常用於代替tnsnames.ora中的ORACLE_SID。

       9i之後，Oracle推薦使用service_name而不是SID。

       可以通過定義多不不同的服務名來區分不同的使用者串連，該參數預設的格式為db_name.domain_name。

       下面是一個用戶端的tnsnames.ora，兩個不同的串連標識符下一個使用了ORACLE_SID，一個使用SERVICE_NAME，兩種方式都可行。
       SYBO2SZ_SID=
         (DESCRIPTION=
           (ADDRESS=
             (PROTOCOL=TCP)
             (HOST=192.168.7.2)
             (PORT=1915)
           )
           (CONNECT_DATA=
             (ORACLE_SID=SYBO2SZ)  #此處使用了ORACLE_SID=<>，也可以直接使用SID=<>
           )
         )
  
       SYBO2SZ=
         (DESCRIPTION=
           (ADDRESS=
             (PROTOCOL=TCP)
             (HOST=192.168.7.2)
             (PORT=1915)
           )
           (CONNECT_DATA=
             (SERVICE_NAME=SYBO2SZ) #Oracle 9i之後推薦使用SERVICE_NAME
           )
         )

二、使用services的益處

       如前所述，可以為同一個資料庫建立多個不同的services來為不同的用戶端分組提供服務。對於單一實例而言，儘管可以為其建立多個不同的services，然而提供這些服務始

終是單資料庫單一實例，因此效能體現的並不明顯。

而對於多執行個體的情形下，能夠在不同的時段或根據不同的商業邏輯規則來決定將不同的服務分布到不同的執行個體，以及可以為

services設定首選執行個體，備用執行個體。一旦首選執行個體出現單點故障，則services會自動failover到備用執行個體。

       假如定義當前RAC資料庫有3個節點srv1，srv2，srv3

       有兩個不同的service分別sales.2gotrade.com和settlement.2gotrade.com在當前資料庫運行

       則sales部門通過sales.2gotrade.com服務名來建立串連，settlement部門通過settlement.2gotrade.com服務名來建立串連。

       其次sales部分的負載通常運行在srv1，srv2，而其對應的備用節點則為srv3，即當節點srv1，srv2失敗後，所有基於sales的串連與負載都將轉移到節點srv3。

       假定settlement部門負載通常較小，因此設定首選節點為srv3，備用節點為srv1，則節點srv3單點故障後，則所有settlement部門串連與負載都將轉移到srv1。

      所有串連到當前的兩個部門無需關心當前串連的是哪個資料庫與那個節點上的執行個體。
  
       從上面的描述可知

       各節點串連對於用戶端而言是透明的，使用者根本無需關心串連到的資料庫以及執行個體，撇開了複雜的後台配置。

另外， 1個 service-name 也可以對應多個不同的sid，就像上面 問題 說的那個情況。

ETL技術工具kettle入門筆記(一) 之kettle串連oracle rac 報listener does not currently know of sid錯誤的解決