當12C PDB遇上JDBC (r10筆記第59天)
最近整合了幾個測試環境，都放入了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> 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.parorg.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的錯誤，和開發反饋的是一致的。
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.xx:1521:oracle12c" "jdbc:oracle:thin:@192.168.xx:1521/oracle12c"
重點在後面，一個是 :oracle12c 一個是/oracle12c 帶著一絲的驚喜和開發的同學進行溝通，他們帶著疑惑的態度進行了修改和測試，從我的監控來看，連線正常了。他們很快反饋問題的原因還確實是這個，但是疑問就出來了，之前一直是使用jdbc:oracle:thin:@192.168.75.131:1521:oracle12c的形式，也一直沒有問題，為什麼這種就出問題呢。和開發的同學大體聊了下，這是一個12c的資料庫，使用了容器的方式，連線方式上會有一些差別，當然這種方式應該對低版本也是可行的，建議開發的同學也這樣測試一番，他們也蠻配合，確實測試了一把，發現這種方式"jdbc:oracle:thin:@192.168.75.131:1521/oracle12c"也是可行的。對於低版本也是相容的。 所以明白這一點之後，對於PDB的資料遷移也更加有底。問題的解決也不是一方拍板，還是需要多方配合，缺少任何一環，都會使得問題的解決週期加長。