JDBC连接Oracle数据库常见问题及解决⽅法
本⽂是斑⽵从版摘录⼴⼤站友的提问以及各种解答整理⽽来，如果您认为本⽂的内容已触犯了您的权益，请联系管理员进⾏修改。
1. Jbuilder正确连接 oracle 9i需要注意的⼏个问题
oracle8以上的应该都使⽤classes12.jar⽂件作为jdbc驱动；
正确设置windows的classpath和jbuilder中的enterprise setup 、configure libraries，将casses12.jar路径正确添加
到上述需要设置的地⽅；
进⼊database pilot，在database pilot中，file---new 在driver列表中如果oracle的驱动是红⾊的，就说明你的oralce 在jb中加载失败；
若③没有错，则新建⼀个url：jdbc:oracle:thin:@（yourhostname）:1521:（your sid）
连接数据库的Username/password
⼤部分站友的jbuilder连接oracle的问题都是由于没有正确配置classpath等引起的。
2. 使⽤⾮XA⽅式连接ORACLE数据库
在windows下配置Oracle_XA时要注意两点：
#ORACLE 10
Oracle_XA;xaosw;%ORACLE_HOME% dbms oraxa10.lib%ORACLE_HOME%precompibmsvcorasql10.lib
#oracle 9
Oracle_XA;xaosw;%ORACLE_HOME% dbms oraxa9.lib%ORACLE_HOME%precompibmsvcorasql9.lib
Unix下
Oracle_XA:xaosw:....
第⼀：在windows 下 ORACLE_XA 和xaosw后⾯的是分号";"，不是冒号":"
第⼆：上⾯的这些LIB写在⼀⾏上，中间⽤空格分开，如果没有在系统的环境变量中设置ORACLE_HOME，就写绝对路径。
3. JDBC操作ORACLE数据库时出现‘java.sql.SQLException:IO异常，不在流模式下'
1. ⽤OracleStatment，，不要⽤java.sql.Statment
2. 如果对已有连接进⾏setAutoCommit失败，则关闭该连接并重新建⽴⼀个连接
3. 到ORACLE站点下载⼀个最新的JDBC Driver，如果操作LOB类型，⽤ORACLE⾃带的接⼝和类
4. weblogic连接oracle问题：The Network Adapter could not establish the connection
可能是服务器的监听停掉了，是数据库的问题，与应⽤⽆关；应该先检查⼀下oracle是否正常，⽤sql*plus连接⼀下数据库，看能否正常连接；
5. Weblogic中使⽤Oracle连接池及Oracle备份的注意事项
使⽤HP-UNIX，Weblogic 8.1,Oracle 9.2.0.5
配置了⼀个普通的连接池，驱动程序采⽤oracle的Oracle's Driver(Thin) version 9.0.1, 9.2.0
错误情况：
结果使⽤数据库连接池时报错，说没有连接池资源了。实际上数据库的连接池完全空闲，并且测试也是对的，Oracle也是正常可以连接、使⽤的。
问题根源：
通过层层排错，发现原来后台在使⽤Oracle的exp备份⼀个只有同义词的⽤户，导致exp进程僵死。
杀死exp、重启Oracle等⽆法解决问题，最终重启UNIX，禁⽌备份只有同义词的⽤户，问题解决。
总结：
应该是Oracle9的exp BUG导致连接池问题，不要使⽤exp倒出同义词
6. 连接Oracle时抛出如下异常：java.sql.SQLException: Io exception:The Network Adapter could not establish connection
⼀种产⽣原因
Oracle Database Connection (from oracle)
PROBLEM
You are attempting to connect to an Oracle instance using JDBC and you are receiving the following error.
java.sql.SQLException: Io exception:
The Network Adapter could not establish connection
SQLException: SQLState (null) vendor code (17002)
Any or all of the following conditions may also apply:
1) You are able to establish a SQL*Plus connection from the same
client to the same Oracle instance.
2) You are able to establish a JDBC OCI connection, but not a Thin
connection from the same client to the same Oracle instance.
3) The same JDBC application is able to connect from a different
client to the same Oracle instance.
4) The same behavior applies whether the initial JDBC connection
string specifies a hostname or an IP address.
REDISCOVERY
To verify whether you are hitting this problem, verify whether the Oracle instance is configured for Multithreaded Server (MTS). If the Oracle instance is not configured for MTS, you are probably encountering a different problem. Otherwise, continue. Try forcing the JDBC connection to use a dedicated server instead of a shared server. This can be accomplished in several ways. For JDBC OCI or Thin, this can be done by reconfiguring the server for dedicated connections only. This approach, however, may not be feasible in many cases. In such cases, the following options apply: For JDBC OCI:
1) Add the (SERVER=DEDICATED) property to the TNS connect string
stored in a file on the client.
2) Set the user_dedicated_server=ON a on the client.
For JDBC Thin:
You must specify a full name-value pair connect string (the same as it might appear in a file) instead of the short JDBC Thin syntax. For example, instead of
"jdbc:oracle:thin::port:sid"
you would need to use a string of the form
"jdbc:oracle:thin:@(DESCRIPTION="                    +
"(ADDRESS_LIST="              +
"(ADDRESS=(PROTOCOL=TCP)" +
"(HOST=host)"    +                                      =
"(PORT=port)"    +
")"                      +
")"                          +
"(CONNECT_DATA="              +
"(SERVICE_NAME=sid)"      +
"(SERVER=DEDICATED)"      +
")"                          +
")"
If the connection works fine after having made these changes, it is very likely that this is the problem you are encountering. In this case, one last test will help to verify this fact.
Log into the remote host on which the Oracle instance is running and execute the appropriate command to determine what the server 'thinks' its hostname is (i.e. the name that was configured when the server was installed and configured). For example, on a Unix host the 'hostname' command can be used for this purpose.
Using the name displayed (e.g. by the hostname command), exactly as it appeared (i.e. if the output from the hostname command had the domain name included, then include it), return to the client which was unable to connect and try pinging the server.
NOTE: It is critical that you attempt to ping the server using EXACTLY the same hostname you got from the server.
If you are unable to ping the server via this hostname, then you almost certainly hitting this problem. If not, this may be a new issue, but at least you will have found a workaround (i.e. use a dedicated connection).
EXPLANATION
To understand why this problem occurs, one must first understand the differences in how the listener handles connections to shared servers versus dedicated servers.
When connecting to a dedicated server, the client connects to the listener (via hostname or IP address). The listener then spawns a dedicated server process and hands off the socket used to accept the client connection to that server. The client and server then start communicating via the endpoints established by the initial connection. NOTE: There is only one connection in this case. When connecting to a shared server, the initial client connection to the listener is the same. However, with MTS, there is no need to spawn a new server process; a pool of shared processes already exists. Also, clients do not communicate directly with the server processes in MTS; rather, they communicate
with a dispatcher.
For this reason, when setting up an MTS connection, the listener sends a redirect message back to the client asking the client to close the connection to the listener and connect to a dispatcher. The information in this message includes the hostname and a port number for the appropriate dispatcher. The redirect message will ALWAYS specify a hostname,
even if the client initially provided an IP address.
If, for any reason, the hostname provided to the listener (e.g. by the 'hostname' or another command) doesn't agree with the hostname by which the server is known on the client, the connection fails.
On the other hand, if "(SERVER=DEDICATED)" already appears in the TNS connect string a or if "use_dedicated_server=ON" already appears in a file, you may find that SQL*Plus and/or JDBC OCI work fine, while JDBC Thin fails.
SOLUTION
Obviously, one solution is to use dedicated servers. However, this may not always be feasible.
The key is to make sure the hostname on both the client and server agree. This can be accomplished by reconfiguring either the client or the server, but there are things to be aware of in both cases.
If the server is configured to return a different hostname, then it is possible that other clients which used to work will now fail.
In some cases, it may not be feasible to reconfigure the client. For example, if the server version of the hostname does not include the domain, you would need to remove the domain portion of the hostname on the client; but, if the client needs to connect to more than one server with the same base name in different domains, this may not be possible, as the hostname may be ambiguous.
REFERENCES
oracle数据库自动备份方法bug:1269734 java.sql.SQLException: Io exception: The Network Adapter could not be found.
7. 连接ORACLE数据库报错：javax.naming.NameNotFoundException: Unable to resolve oracThin. Resolved: ''
Unresolved:'oracThin' ; remaining name ''
问题描述：配置完JDBC后，打开页⾯的时候，报出如下错误信息：
javax.naming.NameNotFoundException: Unable to resolve oracThin. Resolved: '' Unresolved:'oracThin' ; remaining name ''
JDBC配置如下：
Connection Pools(连接池)
Name:OracThin
URL:jdbc:oracle:thin.0.0.1:LYSIMIS
Driver Classname:oracle.jdbc.driver.OracleDriver
Properties:
user=system
password=manager
dll=ocijdbc8
protocol=thin
数据源配置如下：
Name:OracThin
JNDI Name:OracThin
Pool Name:OracThin
当程序执⾏到这⼀步时出错。
ctx = new InitialContext();
ds = (javax.sql.DataSource)ctx.lookup ("OracThin");
问题解决后汉字是乱码
错误产⽣原因及解决办法：
URL:jdbc:oracle:thin:.0.0.1:1521:LYSIMI，thin后⾯加:,127.0.0.1后⾯加端⼝号
注意名字⼤⼩写.
target 到server上
再看看pool是否起来了，没起来的话，重起weblogic
乱码问题（Java是基于Unicode）：
在JSP ⽂件中加⼊<%@ page contentType="text/html; charset=GBK" %>
在l⽂件的<jsp-descriptor>部分加⼊
<jsp-descriptor>
<jsp-param>
<param-name>compilerSupportsEncoding</param-name>
<param-value>true</param-value>
</jsp-param>
<jsp-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</jsp-param>
</jsp-descriptor>
8. oracle XA的疑惑
问题描述：Oracle_XA;xaosw;D:oracleora92 dbmsXAORAXA9.lib C:msvcoraSQL9.lib中
xaosw是什么意思
解答：可以参考ORACLE的XA部分的⽂档。
9. oracle与weblogic⾃动启动与停⽌
问题描述：每次重新启动服务器时oracle数据库若没有关闭，则必须先关闭后在重新启动redhat advance server，oracle 才能够正常运⾏
原因及解决办法参见：
本⽂整理的只是本版⽂章的⼀⼩部分，如果这⾥没有解答您的问题，请查阅本版的精华区，也可以使⽤论坛的搜索功能。
整理⽇期2005.9.26
作者简介
dev2dev ID: lhbing, dev2dev论坛版主，WebLoigc以及Java技术爱好者

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。