我也遇到同样的问题了。
经测试,肯定已经连接到1251端口,且SID的确存在,但在校验用户帐号,口令就抛出异常了。
我看了国外的论坛,说是和Oracle提供的MTS服务相关。问题是我访问Win2000上的Oracle,也是共享模式,可以访问。难道Linux上的Oracle 和 Win2000上的Oracle在实现MTS时的不同机制导致了这样的问题?

解决方案 »

  1.   

    From: Jon Haugsand <[email protected]>
    Date: 19 Nov 2001 10:47:25 +0100
    Message-ID: <[email protected]>
    Subject: [suse-oracle] Jdbc thin driver problem solved (was: jdbc thin driver: connection refused
    Short summary: If you have problems with connecting your NT client to 
    your Linux server using jdbc thin client, be sure that the server 
    machine name as known at the server exists at the client (and is the 
    same name). 
    Long story: 
    * Jon Haugsand 
    > To all who have tried to help me, thanks. I have now gotten some help 
    > from Oracle and though they could not find the cause of my problem, 
    > they found a way to live with it. (They suspect some bad 
    > configuration.) Here is a summary of the problem and the suggested 
    > cure, just in case others should struggle with the same problem. 

    > I have two Oracle servers, one Linux and one NT. I have two Oracle 
    > clients, one Linux and one NT. All in all, four machines 
    > interconnected through tcp/ip. Each client attempts to connect to 
    > each server using both standard protocol (?), e.g. using sqlplus and 
    > the jdbc thin driver, all in all I have 8 connection scenarios. 

    > Oracle on Linux is 8.1.7 (both server and client). 
    > Oracle on NT is 8.1.6 (both server and client). 
    > Several jdbc thin drivers are tested, including the latest downloaded 
    > from Oracle. 

    > Linux server NT server 
    > ------------------------------------------------------------ 
    > Linux sqlplus OK OK 
    > Linux jdbc thin OK OK 
    > NT sqlplus OK OK 
    > NT jdbc thin fails OK 

    > Driver is oracle.jdbc.driver.OracleDriver 

    > The connection string used: jdbc:oracle:thin:@192.168.22.35:1521:ora8 

    > The NT jdbc thin client failed with: 
    > java.sql.SQLException: Io exception: The Network Adapter could 
    > not establish the connection 
    > at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180) 
    > at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:222) 
    > at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:335) 
    > at 
    > oracle.jdbc.driver.OracleConnection.<init> 
    > (OracleConnection.java:361) at 
    > oracle.jdbc.driver.OracleDriver.getConnectionInstance 
    > (OracleDriver.java:442) 
    > at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:321) 
    > at java.sql.DriverManager.getConnection(DriverManager.java:517) 
    > at java.sql.DriverManager.getConnection(DriverManager.java:177) 
    > at Nytest.main(Nytest.java:54) 
    > java.lang.RuntimeException: SQL Exception Io exception: 
    > The Network Adapter could not establish the connection 
    > at Nytest.main(Nytest.java:70) 


    > Failed connection enters the listener which does not complain, but no 
    > activity is found on the server. (That is, I do not know how to 
    > measure such things. The trace and log files were almost, but not 
    > completely, empty and obscure.) 

    > A curious observation is that if I restart the listener at the Linux 
    > server, the NT jdbc thin client works for a few minutes, and then 
    > fails again. 

    > -------------------------------- 
    > OK, then the CURE: 

    > The Oracle support suggested I use the following (white space free) 
    > connection string (structured here for readability): 

    > jdbc:oracle:thin:@(DESCRIPTION= 
    > (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP) 
    > (HOST=192.168.22.35) 
    > (PORT=1521))) 
    > (CONNECT_DATA=(INSTANCE_NAME=ora8) 
    > (SERVICE_NAME=sil2002.norges.bank.no))) 

    > Lo and behold, this works. Thanks again for all helpfullness on this 
    > email list. 
    (Just after I sent this information, I discovered something. The 
    following is a copy of what I sent to the Oracle team.) 
      
    I have now discovered what might be the cause of the problem, and 
    I suggest that you test this out, and eventually report this to the 
    network development folks in your company. 
    What have been the situation up to now is that the Linux server has 
    not been a part of the local DNS i our company. That is, the server 
    name (banklab3) was not known as such at the NT client. Therefore, I 
    had to use the IP address. However, the server itself, and the Linux 
    client, uses the /etc/hosts file to be able to map from number to name 
    and vica versa. 
    Today, we inserted the Linux server banklab3 into the local DNS server such 
    that the NT client now knows that banklab3 has the matching IP address. 
    Today we have no problems with using the jdbc thin client as we had before. 
    Can it be so that the Oracle server at the Linux machine does not 
    "feel comfortable" with numbers and maps the IP address to its name 
    and returns this to the client, which does not accept this because it 
    does not know anything about this name? 
    If so, this is ceratinly not a preferred behaviour of the server, who 
    should respect the clients view of the world. (I humbly still admit 
    that there may also be some configuration problems with our Linux 
    server that makes this really a complex multi cause problem.)