最近整合了幾個測試環境，都放入了12c的容器數據庫中。今天本來計劃再整合幾個測試庫進來，結果因為碰到了JDBC的問題給耽擱了。
遷移數據庫的步驟，因為數據量不大，數據結構較為復雜，所以直接采用了DataPump來做，而且因為測試環境，所以很多問題有充足的時間去排除和分析。
首先我創建了一個PDB
CREATE PLUGGABLE DATABASE tbillmob ADMIN USER pdb_mgr IDENTIFIED BY oracle file_name_convert=('/home/U01/app/oracle/oradata/testdb/pdbseed','/home/U01/app/oracle/oradata/testdb/pdb/tbillmob');
然后切換到這個容器
SQL> alter session set container=tbillmob;
SQL>? grant dba to pdb_mgr;
查看數據文件的情況
SQL> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/home/U01/app/oracle/oradata/testdb/pdb/tbillmob/system01.dbf
/home/U01/app/oracle/oradata/testdb/pdb/tbillmob/sysaux01.dbf
創建數據文件USERS,就不要那么多細小的表空間文件了。
SQL> create tablespace users datafile '/home/U01/app/oracle/oradata/testdb/pdb/tbillmob/users01.dbf' size 4G;
創建目錄：
SQL> create directory dp_dir as '/home/oracle/dp_dir';
然后在源庫中導出一個parfile
SQL> select 'remap_tablespace='||tablespace_name||':'||'USERS'from dba_tablespaces;
在目標端的PDB中導入即可。
impdp pdb_mgr/oracle@tbillmob directory=dp_dir dumpfile=tbillmob.dmp full=y logfile=impdp.log? EXCLUDE=SCHEMA:\"IN \(\'OUTLN\', \'ANONYMOUS\',\'OLAPSYS\',\'SYSMAN\',\'MDDATA\',\'MGMT_VIEW\',\'APEX_030200\',\'SYSTEM\',\'SCOTT\'\)\" parfile=remap_ts.par
整個步驟都是輕車熟路，但是過了一會開發的同學給我反饋，說應用連接報錯了。

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory

一看這個錯誤我就想，開發的同學應該是把遷移后的IP改過來。這個很明顯看出來數據庫是沒啟動。我把源端的數據庫已經停了，自然是連不進去了。
但是開發的同學反饋說，IP已經修改了。那么這個問題就和DB層面的配置有關了。
比如我配置了一個1525的端口。listener.ora的文件內容如下：
LISTENER_12c_1525=
? (DESCRIPTION=
??? (ADDRESS_LIST=
????? (ADDRESS=(PROTOCOL=tcp)(HOST=teststd.oracle.com)(PORT=1525)
?)
?)
)
SID_LIST_LISTENER_12c_1525=
(SID_LIST=
????? (SID_DESC=
????? (GLOBAL_DBNAME=testdb)
????? (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1)
????? (SID_NAME=testdb)
???? )????
???? (SID_DESC=
????? (GLOBAL_DBNAME=tbillmob)
????? (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1)
????? (SID_NAME=tbillmob)
???? )
)
如上的配置加粗的部分是錯誤的，SID_NAME應該是testdb，GLOBAL_DBNAME是PDB的名稱。
tnsnames.ora的配置如下：
tbillmob =
? (DESCRIPTION =
??? (ADDRESS = (PROTOCOL = TCP)(HOST = teststd.oracle.com)(PORT = 1525))
??? (CONNECT_DATA =
????? (SERVER = DEDICATED)
????? (SERVICE_NAME = tbillmob)
??? )
? )
如此一來，發現原來是我這邊的配置問題，修改之后以為就萬事大吉了，但是查看v$session沒有對應的會話，開發同學說這次錯誤變了。

SQLNestedException: Cannot create PoolableConnectionFactory (Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
如此一來，我就感到有些奇怪了，服務端的配置是沒有任何問題了，是不是開發的同學哪里沒有配置好。
和他們確認，他們說只修改了配置文件中IP的部分，其它的都沒有改動。
那么這個問題怎么進一步分析確認呢，我和開發的同學聊了下，因為是測試環境，就建議她先切換IP到源數據庫，看看是否正常，如果不正常，說明他們的配置文件有問題。
結果很快就得到了開發的確認和反饋，修改IP到原來的服務器IP就沒有任何錯誤了。
這個問題就開始有些困擾我了，我從開發那里得到的連接信息如下：
jdbc:oracle:thin:@10.127.xx.xx:tbillmob? --連接串信息
app_accmobxxx?? --用戶名信息
app_R#m^accmob02@abcdef? --密碼信息

從提供的信息來看沒有發現問題。那我來你自己測試一下。
使用TNS的方式來連接沒有問題
SQL>? conn app_accmobxxx/"app_R#m^accmob02@abcdef"@tbillmob
Connected
使用直連的方式，也沒有問題
SQL>? conn app_accmobxxx/"app_R#m^accmob02@abcdef"@10.127.xxx:1525/tbillmob
Connected.
所以從上面的測試可以看出這個網絡配置應該是沒有問題的。
但是這樣一來問題就陷入了僵局，DBA沒有發現問題，開發的配置文件也經過確認沒有問題，那么問題到底出在哪里了呢。
我回過頭來開始查看監聽日志,可以明顯看到TNS-12505的錯誤，和開發反饋的是一致的。
TNS-12505: TNS:listener does not currently know of SID given in connect descriptor
21-OCT-2016 13:55:46 * (CONNECT_DATA=(SID=tbillmob)(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=mrdTomcat))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.127.1.xxx)(PORT=52574)) * establish * tbillmob * 12505
TNS-12505: TNS:listener does not currently know of SID given in connect descriptor
21-OCT-2016 13:55:49 * (CONNECT_DATA=(SID=tbillmob)(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=mrdTomcat))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.127.1.xxx)(PORT=52606)) * establish * tbillmob * 12505
TNS-12505: TNS:listener does not currently know of SID given in connect descriptor

由此可見可能我們的測試還是有一些欠缺之處，但是問題到底在哪里還是無法定位。
我已經打算下一個Java程序來進行驗證了。但是程序寫完之后，先查看了一下是否有相關的文章，還真找到一篇。原來是url兼容性導致。
jdbc連接cdb數據庫時,url兼容2種模式:

? "jdbc:oracle:thin:@192.168.75.131:1521:oracle12c"

? "jdbc:oracle:thin:@192.168.75.131:1521/oracle12c"

重點在后面，一個是 :oracle12c? 一個是/oracle12c
帶著一絲的驚喜和開發的同學進行溝通，他們帶著疑惑的態度進行了修改和測試，從我的監控來看，連接正常了。他們很快反饋問題的原因還確實是這個，但是疑問就出來了，之前一直是使用jdbc:oracle:thin:@192.168.75.131:1521:oracle12c的形式，也一直沒有問題，為什么這種就出問題呢。和開發的同學大體聊了下，這是一個12c的數據庫，使用了容器的方式，連接方式上會有一些差別，當然這種方式應該對低版本也是可行的，建議開發的同學也這樣測試一番，他們也蠻配合，確實測試了一把，發現這種方式"jdbc:oracle:thin:@192.168.75.131:1521/oracle12c"也是可行的。對于低版本也是兼容的。
??? 所以明白這一點之后，對于PDB的數據遷移也更加有底。問題的解決也不是一方拍板，還是需要多方配合，缺少任何一環，都會使得問題的解決周期加長。

總結

以上是生活随笔為你收集整理的当12C PDB遇上JDBC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。