weblogic配置JDBC資料來源

一.概述

二.Link意在何處？
題目中的Link意為WebLogic連線DB的方式，這裡的連線自然是JDBC Thin方式連線的，WebLogic是J2EE的容器，自身也是由Java語言編寫。
至今WebLogic提供了五種配置對於Jdbc Thin方式連線Oracle RAC，如下：
1.GridLink Data Sources 
2.Configuring Connections to Services on Oracle RAC Nodes（XA）
3.Configuring Connections to Services on Oracle RAC Nodes（No-XA）
4.Multi Data Sources with Global Transactions
5.Multi Data Sources without Global Transactions
其中GridLink Data Sources方式支援使用services，實現Load Balancing（負載均衡）和Failover（故障轉移）。在Oracle Database 10g引入Automatic Workload Management，即資料庫服務，區別與傳統的資料庫服務。
 
三.GridLink的真面目
WLS GridLink是WLS10.3.4新推出的Data Source型別，提供了針對Oracle RAC資料庫與WLS之間的連線功能。GridLink通過Oracle通知服務（ONS）來獲取Oracle RAC例項的狀態變化。WLS可以通過Oracle RAC靈活的資料庫服務設計來滿足其需求，也可以由資料庫服務的增加而擴充套件而不需要關注RAC 叢集中的物理結構變化。
連線示意圖如下：
GridLink提供了以下功能：
1.簡化和統一了對RAC連線配置的模組。
2.支援Fast Connection Filover（FCF）。
3.支援Runtime Connection Load Balancing（RCLB）。
4.支援Single  Client Access Name（SCAN）。
5.Oracle RAC停機的正常處理。
本篇文章為概述，此係列文章將對上面特性做一 一分析和配置嚮導。
 
四.Oracle ONS（Oracle NOtification Service）和FAN（Fast Application Notification）
Oracle RAC通知服務（ONS）是由叢集維護的，為nodeapps組。如：
檢視ons服務狀態
$crsctl status resource ora.ons
AME=ora.ons
TYPE=ora.ons.type
TARGET=ONLINE    , ONLINE
STATE=ONLINE on rac1, ONLINE on rac2
$srvctl status nodeapps
ONS daemon is running on node: gwrac1
ONS daemon is running on node: gwrac2
ONS服務，由srvctl工具來維護，另外onsctl工具也可以維護，還可以跟蹤ons的資訊。下面是檢視ons配置資訊：
$srvctl config nodeapps -s
ONS daemon exists. Local port 6100, remote port 6200
 
Oracle RAC FAN為RAC applications和client提供叢集狀態和節點負載的情況，通過ONS將這些事件釋出給Java client和Oracle的客戶端，讓它們得知當前RAC的情況，做出相應的處理，例如：客戶端請求的分佈。
基於以上的特性，Oracle稱其為高可用性、高可靠性、高可擴充套件性的，這個形容太響了。

 

Bea被Oracle收購以後，我們可以看到WebLogic和Oracle資料庫之間的更緊密結合。

剛剛合併以後推出的10gR3(10.3.0)版本中，原來Bea使用的Data Direct Driver被放棄，官方推薦使用Oracle的thin driver：
Note:    The WebLogic Type 4 JDBC Oracle driver described in this document has been deprecated as of release 10.3 of WebLogic Server. It will be removed in the next release of WebLogic Server. Instead of this deprecated driver, use the Oracle Thin Driver that is also provided with WebLogic Server.

現在在WebLogic 10.3.4中，為了增強對RAC的支援，Oracle推出了Gridlink Data Source，取代原先的Multi Data Source：
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13737/jdbc_intro.htm#BHCBACAG

Enhanced Oracle RAC Support
This release provides a new data source type, a GridLink Data Source, to provide enhanced support for Oracle RAC. 
Multi Data Source

原來的Multi Data Source的工作原理是為每臺RAC的結點配置一個Datasource，然後把所有的這些Datasource聚合起來配置一個Multi Data Source。雖然Multi Data Source也提供Failover（容錯）和Load Balancing（負載均衡），但是功能相對有限。

1） 配置比較複雜
需要為每一個RAC 結點手動配置一個Data Source，新增和刪除節點都需要WebLogic管理員手動操作。

2） Failover是data source級別的，不是connection 級別的
Multi Data Source需要開啟Test Reserved Connections (TestConnectionsOnReserve)功能。這個功能開啟以後，當應用向一個Data Source申請一個Connection的時候，WebLogic server需要先測試這個Connection再返回。如果這個測試失敗，WebLogic會重建一個連線。如果重建再失敗，Data Source就會被標識成dead，然後WebLogic自動Failover到下一個Multi Data Source裡面的Data Source。當一個Data Source被標識成dead以後，WebLogic會主動的每隔一段時間（預設120秒）查詢資料庫結點。如果測試成功，這個Data Source會被重新啟用。
對一個已經獲得並在使用的connection，WebLogic無法實現Failover。

3）Load Balancing僅僅是簡單的round robin
如果一個應用開啟了多個Connection，那麼根據round robin的原則，這多個Connection可能會來自多個不同的資料庫結點。這個實際上有效能上的影響。
Gridlink Data Source
新推出的Gridlink Data Source相對來說更有效率，因為它很大程度上藉助了資料庫的功能。它使用了Oracle的ONS（Oracle Notification Service）的特徵。看下圖：
資料庫RAC端的ONS服務採集RAC結點的執行資料。這些資料傳給Gridlink Data Source的ONS監聽客戶端。UCP-RAC模組分析這些資料並給出建議，Gridlink Data Source通過這些資料/建議來實現連線池的Failover，Load Balancing和其他的一些特性。

我們來看看Gridlink Data Source的一些改進功能：

1）首先，配置變得簡單了

你只需要配置一個Gridlink Data Source，它就會處理與後臺的RAC資料庫的通訊。相對Multi Data Source，WebLogic管理員的工作量減少很多。

如果你配置了Oracle的SCAN服務就更簡單了，RAC結點的新增刪除都是自動完成，因為對Gridlink Data Source來說，它只知道一個SCAN地址就好了。就好象一個域名一樣，你不需要知道後面用了多少IP來實現。

2）更快速有效的Failover
使用ONS，Gridlink Data Source可以實時的捕捉到RAC端的資訊。如果有結點出錯，Gridlink Data Source很快將與其對應的Connection標識為不可用。這樣就避免了Multi Data Source中需要不斷主動測試Connection所帶來的overhead。

3）實時的Load Balancing
同樣因為ONS的資料，Gridlink Data Source可以知道哪些RAC結點很忙，哪些很閒，於是它可以有效的將哪些來自空閒RAC的Connection分配給應用請求，實現實時的Load Balancing。

4）沉穩應對RAC結點的關閉
如果是有計劃的關閉，Gridlink Data Source會等當前Active的事務結束再關閉Connection。新的Connection請求將被髮送到其他的RAC結點。
如果是突發的RAC結點關閉，Gridlink Data Source也會沉著的將當前的事務rollback，然後將新的Connection請求傳送到其他的RAC結點。

5）全域性事務的Connectoin會儘量在一臺RAC結點上
前面講過Multi Data Source的Round Robin策略會造成同一個事務的多個Connection被髮送到不同的RAC結點上。
Gridlink Data Source在一個事務的第一個Connection建立後會將該事務的所以後續Connection請求傳送到同一個RAC結點上。這樣可以減少後臺同步處理，提高全域性事務的執行效率。
建立Gridlink Data Source
建立的過程不復雜，和一個普通的Data Source差不多，都從這裡開始：

1.名字之類的配置，注意資料庫型別就是Oracle，呵呵，當然了，RAC就是Oracle的：
2.XA的配置頁面掠過，到了輸入RAC地址的頁面
3.其實兩個選擇都一樣，一個是一個一個的新增server，然後由WebLogic生成JDBC URL：
一個是自己輸入JDBC URL：
沒有區別，怕寫錯就讓WebLogic生成，掠過測試頁面，下一步就是關鍵的ONS客戶端配置：
如果您使用SCAN的話，這裡可以就輸入SCAN的地址。
Wallet可以用來加密ONS的通訊，這裡不表。
掠過測試頁面，只要target一下就好了

這裡的JNDI與web.xml中對應res-ref-name的節點值相同。
這裡有必要說一下什麼是JNDI

JNDI是 Java 命名與目錄介面（Java Naming and Directory Interface），在J2EE規範中是重要的規範之一，不少專家認為，沒有透徹理解JNDI的意義和作用，就沒有真正掌握J2EE特別是EJB的知識。
那麼，JNDI到底起什麼作用？
要了解JNDI的作用，我們可以從“如果不用JNDI我們怎樣做？用了JNDI後我們又將怎樣做？”這個問題來探討。
沒有JNDI的做法：
程式設計師開發時，知道要開發訪問MySQL資料庫的應用，於是將一個對 MySQL JDBC 驅動程式類的引用進行了編碼，並通過使用適當的 JDBC URL 連線到資料庫。
就像以下程式碼這樣：
Connection conn=null;  
try {
  Class.forName("com.mysql.jdbc.Driver", 
                true, Thread.currentThread().getContextClassLoader()); 
  conn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=qingfeng&password=mingyue"); 
  /* 使用conn並進行SQL操作 */ 
  ...... 
  conn.close(); 
}
catch(Exception e) {
  e.printStackTrace(); 
}
finally {
  if(conn!=null) {
    try {
      conn.close(); 
    } catch(SQLException e) {}
  }
}這是傳統的做法，也是以前非Java程式設計師（如Delphi、VB等）常見的做法。這種做法一般在小規模的開發過程中不會產生問題，只要程式設計師熟悉Java語言、瞭解JDBC技術和MySQL，可以很快開發出相應的應用程式。

沒有JNDI的做法存在的問題：
1、資料庫伺服器名稱MyDBServer 、使用者名稱和口令都可能需要改變，由此引發JDBC URL需要修改；
2、資料庫可能改用別的產品，如改用DB2或者Oracle，引發JDBC驅動程式包和類名需要修改；
3、隨著實際使用終端的增加，原配置的連線池引數可能需要調整；
4、......

解決辦法：
程式設計師應該不需要關心“具體的資料庫後臺是什麼？JDBC驅動程式是什麼？JDBC URL格式是什麼？訪問資料庫的使用者名稱和口令是什麼？”等等這些問題，程式設計師編寫的程式應該沒有對 JDBC 驅動程式的引用，沒有伺服器名稱，沒有使用者名稱稱或口令 —— 甚至沒有資料庫池或連線管理。而是把這些問題交給J2EE容器來配置和管理，程式設計師只需要對這些配置和管理進行引用即可。

由此，就有了JNDI。

用了JNDI之後的做法：
首先，在在J2EE容器中配置JNDI引數，定義一個資料來源，也就是JDBC引用引數，給這個資料來源設定一個名稱；然後，在程式中，通過資料來源名稱引用資料來源從而訪問後臺資料庫。
具體操作如下（以JBoss為例）：
1、配置資料來源
在JBoss的 D:/jboss420GA/docs/examples/jca 資料夾下面，有很多不同資料庫引用的資料來源定義模板。將其中的 mysql-ds.xml 檔案Copy到你使用的伺服器下，如 D:/jboss420GA/server/default/deploy。
修改 mysql-ds.xml 檔案的內容，使之能通過JDBC正確訪問你的MySQL資料庫，如下：
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
    <jndi-name>MySqlDS</jndi-name>
    <connection-url>jdbc:mysql://localhost:3306/lw</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>root</user-name>
    <password>rootpassword</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
</local-tx-datasource>
</datasources>

這裡，定義了一個名為MySqlDS的資料來源，其引數包括JDBC的URL，驅動類名，使用者名稱及密碼等。

2、在程式中引用資料來源：

Connection conn=null;
try {
  Context ctx=new InitialContext();
  Object datasourceRef=ctx.lookup("java:MySqlDS"); //引用資料來源
  DataSource ds=(Datasource)datasourceRef;
  conn=ds.getConnection();
  /* 使用conn進行資料庫SQL操作 */
  ......
  c.close();
} 
catch(Exception e) {
  e.printStackTrace();
} 
finally {
  if(conn!=null) {
    try {
      conn.close(); } catch(SQLException e) { }
  }
}

直接使用JDBC或者通過JNDI引用資料來源的程式設計程式碼量相差無幾，但是現在的程式可以不用關心具體JDBC引數了。
在系統部署後，如果資料庫的相關引數變更，只需要重新配置 mysql-ds.xml 修改其中的JDBC引數，只要保證資料來源的名稱不變，那麼程式原始碼就無需修改。

由此可見，JNDI避免了程式與資料庫之間的緊耦合，使應用更加易於配置、易於部署。

JNDI的擴充套件：
JNDI在滿足了資料來源配置的要求的基礎上，還進一步擴充了作用：所有與系統外部的資源的引用，都可以通過JNDI定義和引用。

所以，在J2EE規範中，J2EE 中的資源並不侷限於 JDBC 資料來源。引用的型別有很多，其中包括資源引用（已經討論過）、環境實體和 EJB 引用。特別是 EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一項關鍵角色：查詢其他應用程式元件。

EJB 的 JNDI 引用非常類似於 JDBC 資源的引用。在服務趨於轉換的環境中，這是一種很有效的方法。可以對應用程式架構中所得到的所有元件進行這類配置管理，從 EJB 元件到 JMS 佇列和主題，再到簡單配置字串或其他物件，這可以降低隨時間的推移服務變更所產生的維護成本，同時還可以簡化部署，減少整合工作。 外部資源”。 

總結：
J2EE 規範要求所有 J2EE 容器都要提供 JNDI 規範的實現。JNDI 在 J2EE 中的角色就是“交換機” —— J2EE 元件在執行時間接地查詢其他元件、資源或服務的通用機制。在多數情況下，提供 JNDI 供應者的容器可以充當有限的資料儲存，這樣管理員就可以設定應用程式的執行屬性，並讓其他應用程式引用這些屬性（Java 管理擴充套件（Java Management Extensions，JMX）也可以用作這個目的）。JNDI 在 J2EE 應用程式中的主要角色就是提供間接層，這樣元件就可以發現所需要的資源，而不用瞭解這些間接性。

在 J2EE 中，JNDI 是把 J2EE 應用程式合在一起的粘合劑，JNDI 提供的間接定址允許跨企業交付可伸縮的、功能強大且很靈活的應用程式。這是 J2EE 的承諾，而且經過一些計劃和預先考慮，這個承諾是完全可以實現的。


oracle  驅動區別

oracle's driver thin
oracle's driver thin XA
oracle's (OCI XA)
oracle's (OCI)
weblogic's Oracle (Type 2 XA)
weblogic's Oracle (Type 2)
DataDirect's Oracle Driver (Type 4 XA)
DataDirect's Oracle Driver (Type 4) 

這四類的區別是使用的驅動程式不一樣

第一個是thin驅動
第二個是普通的驅動，這都是Oracle自己提供的
第三個是weblogic提供的驅動
第四個是第三方驅動，由DataDirect提供

而每一種驅動可以配置兩種資料來源
沒有XA的就是普通資料來源
有XA的是支援JTA事務的資料來源
建立連線池時，不帶事務的開發兩種驅動都可以選擇；帶事務的開發必須選擇XA型別的資料庫驅動


jdbc:oracle:thin:@192.168.6.100:1521:TestDB12


這裡的JDBC正確的是部署到cluster上，而不是配置到代理伺服器上，群裡的哥說了，部署代理應用的時候，部署到代理節點，部署生產應用部署到其他的節點，（我的實驗專案部署到代理）然後資料來源目標是cluster裡面的所有節點就可以了


sqlplus@hostname是sqlplus登入上來的會話，scott再用sqlplus登錄兩個會話之後變成如下。               

plsqldev.exe是plsql developer登入上來的，還是如果誰登入username就是誰

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30208428/viewspace-1993577/，如需轉載，請註明出處，否則將追究法律責任。