来源:http://edu.136z.com/DataBase/28631.html
作者:佚名
Oracle Net 工具(命令)tnsping,是一个OSI会话层的工具,它用来:
1)验证名字解析(name resolution,当然是oracle自己的网络服务名)
2)远程的listener是否启动
在验证上面两项功能方面,它是DBA手头上一个比较得心应手的工具。Oracle 网络接口支持不同的网络与传输协议,其中我们最熟悉的就是TCP/IP。这篇文章只描述TCP/IP 协议族,然而,在oracle网络接口支持的其它协议下,tnsping的功能是一样的。
Tnsping 可以用在多个网络协议上,但是本文只讨论TCP/IP网络协议
—————————————————————————–
ORACLE TNSPING
—————————————————————————–
Oracle的tnsping测试程序,在通讯时使用TCP协议。TCP 是面向连接的OSI传输层协议。面向连接的协议在初始建立连接的阶段需要进行初始的序列号的交换,这就是我们通常所指的三次握手。即tnsping测试程序在与listener进行通讯时会产生三次握手现象。
当在命令行中发出了tnsping命令后,会执行oracle 网络别名(即网络服务名,主机连接字符串)的解析工作。这个解析工作会在本地的tnsnames.ora文件或ORACLE的命令服务器或ORACLE LDAP(目录服务)中进行。解析的目的是得到目标listener所在的机器名(IP地址)和listener侦听的端口号。
一旦得到listener的机器名与端口号,就可以打开一个到目标机器与端口的TCP连接。为了打开这个TCP连接,listener的机器名必须被解析为ip地址(当然这只有在解析出的listener的连接地址为机器名时才这样做),然后TCP/IP执行三次握手来完成这次连接。
在连接建立之后,Tnsping工具然后就发送一个Oracle TNS 连接包给Oracle Listener,Listener然后就回应一个TNS 拒绝包(Refuse packet),在两个机器间的TCP/IP连接就结束了。从oracle 网络别名的解析到结束TCP/IP连接之间的总的耗费的时间就显示在tnsping命令的输出中。
一个例子:
C:\>tnsping V817 4
TNS Ping Utility for 32-bit Windows:
Version 8.1.7.0.0 – Production on 18-MAY-2001 14:27:57
(c) Copyright 1997 Oracle Corporation. All rights reserved.
Attempting to contact
ADDRESS=(PROTOCOL=TCP)(HOST=abadah.us.oracle.com)(PORT=1521))
OK (1770 msec)
OK (10 msec)
OK (0 msec)
OK (10 msec)
上面这个例子显示第一次tnsping需要1770毫秒,这些时间由在tnsnames.ora文件中解析V817网络别名需要的时间、利用DNS解析listener机器名“ abadah”需要的时间,三次TCP/IP握手需要的时间、TNS Connect 和Refuse packets传输需要的时间、断开TCP/IP连接需要的时间组成。第二次tnsping只花费了10毫秒,这是因为所有的信息 (V817别名与IP地址)都已经在cache中了,然而Tnsping程序仍然做 TCP的连接与断开操作。
—————————————————————————–
TCP/IP PING
—————————————————————————–
Transmission Control Protocol/Internet 协议族 (TCP/IP) 有一个称为ping的工具。它是到TCP/IP 协议族中ICMP(Internet Control Message Protocol)协议的命令行接口。
根据RFC 792:
“有时候,一个网关或目的地址需要同源地址进行通讯,如:为了给源地址一个关于在处理数据报的过程中产生的错误。为了这种目的,就需要使用ICMP协议。 ICMP需要网际协议(IP)的支持,这使它看起来就像一个更高层的协议,然而,ICMP实际上是IP的一个组成部分,在IP的每个模块中必须实现它。”
Ping命令的作用之一就是收集不同大小的IP数据包在网络上传输一个来回需要的时间。这可以用来估计网络的大体性能和响应时间。
Ping命令使用IP,而不是TCP,这样就不需要TCP的3次握手机制,当运行ping命令时,它只发送与接收一个ip数据包,这比oracle的tnsping程序运行时需要更少的数据包。
Ping的第一个的response time经常比平均response time要长,这是因为第一次一般需要对ping的机器名进行解析。这个解析可以通过本地的hosts文件、DNS服务器或其它方法实现。
一个ping的例子:
Pinging abadah.us.oracle.com [144.25.223.156] with 32 bytes of data:
Reply from AAA.BBB.CCC.DDD: bytes=32 time<40ms TTL=255 Reply from AAA.BBB.CCC.DDD: bytes=32 time<10ms TTL=255 Reply from AAA.BBB.CCC.DDD: bytes=32 time<10ms TTL=255 Reply from AAA.BBB.CCC.DDD: bytes=32 time<10ms TTL=255 上面的例子显示第一次的ping时间需要40毫秒,这包括DNS解析的时间。 从上面的介绍我们可以得出: 1.tnsping需要使用TCP,所以需要3次握手建立连接,而ping只使用IP,所以不需要3次握手,这也就解释了为什么有的机器不能ping通,但是用tnsping确能测试通。 2.Tnsping通,并不能说明客户端能与数据库建立连接。因为 Tnsping通只能说明客户端能解析listener的机器名,而且lister也已经启动,但是并不能说明数据库已经打开,而且tsnping的过程与真正客户端连接的过程也不一致。 但是如果不能用tnsping通,则肯定连接不到数据库。 关于第2条可以用tns-12545错误来说明: TNS-12545 (ORA-12545): Connect failed because target host or object does not exist 原因: 客户端不能正确解析服务器的机器名。该错误一般出现在客户端没有设置或没有正确设置域名服务器的情况下出现。 解决办法: 疑问:出现这种情况时,有时可以用tnsping 测程序测试网络服务名可以通过,但还是不能用程序连接数据库,你会感到很奇怪。有时即使将客户端的tnsnames.ora中的服务器的机器名换为ip地址,还是会报错,这会令人感到更加疑惑,会不会系统有问题? 要真正解决这个问题,需要知道客户端与服务器端在建立连接时所的数据流。并需要了解redirect session的概念。 当一个客户端连接在window上的数据库,或以共享连接的模式连接在unix上的数据库时(此时数据库为MTS模式),客户端的连接会发生重定向现象,也就是listener在接受客户端的连接后,会发送一个重定向的包给客户端,然后客户端利用这个重定向包中提供的信息(服务器的ip(或机器名)和端口等信息)重新发起一个真正的到数据库的连接。当将客户端的tnsnames.ora中的服务器的机器名换为ip地址,客户端的连接还是会报ora- 12545错的罪魁祸首就是这个重定向包中的内容。 当客户端连接window上的数据库,或以共享连接的模式连接在unix上的数据库时,因为tnsnames.ora中为服务器的ip地址,所以不存在名字解析的问题,客户端的连接请求会到达listener,这也就是tnsping 测试程序测试网络服务名可以通过的原因,因为tnsping测试程序不会产生重定向问题。在listener接受客户端的连接后,会跟据客户请求的连接模式(专用连接还是共享连接)和操作系统对socket的实现的情况,决定是否需要将客户端的连接进行重定向,如果需要进行重定向,则会产生一个重定向包,该包中包含的服务器的地址信息为从listener.ora文件中得到的listener侦听的地址(根据listener.ora中的配置可能为服务器的机器名,也可能为服务器的ip地址),该包中还包含客户端应该重定向连接的端口信息(同listener侦听的端口可能不为同一个),客户端在收到这个重定向包后,解析出应该重新连接的服务器地址(机器名或ip)和端口,重新利用解析出的信息建立一个新的连接,此时如果客户端得到的为服务器的机器名并且没有配置域名解析,就会因为解析不出服务器的ip地址,从而导致产生ora-12545错误。 所以,如果如果要彻底解决ora-12545错误,需要: 1) 配置一个域名服务器,并正确的设置客户端机器的域名服务器 2) 将服务器的机器名与ip配置在客户端的hosts文件中。 3) 将客户端tnsnames.ora和listener.ora中的地址部分都改为ip地址,而不是用机器名 4) 将客户端的连接改为专用连接,这样会避免redirect 现象。(适用与客户端tnsnames.ora中为服务器的ip地址的情况下)
Sorry, the comment form is closed at this time.
No comments yet.