共计 4465 个字符，预计需要花费 12 分钟才能阅读完成。
最近整合了几个测试环境，都放入了 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 的数据迁移也更加有底。问题的解决也不是一方拍板，还是需要多方配合，缺少任何一环，都会使得问题的解决周期加长。
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-11/136633.htm
