Home >Database >Mysql Tutorial >Oracle数据库三种连接方式

Oracle数据库三种连接方式

WBOY
WBOYOriginal
2016-06-07 17:26:162127browse

访问Oracle数据库,可以通过三种方式:第一种方式是应用进程直接访问数据库实例的共享内存,第二种方式是通过beq协议在本机上访问

访问Oracle数据库,可以通过三种方式:第一种方式是应用进程直接访问数据库实例的共享内存,第二种方式是通过beq协议在本机上访问,第三种方式是通过网络协议访问。第一种方式使用的场合很少,我们不做讨论。下面着重讨论通过第二种和第三种方式访问数据库。

首先,后两种访问数据库的方式都是基于two-task结构的,都需要在数据库服务器上建立一个服务进程(server进程,或者前台进程)来为客户端应用服务(在这里我们只讨论独立服务器模式,共享服务器模式十分类似,我们将在后面进行专题描述)。two-task架构下访问数据库,首先需要在服务器端创建一个进程,这个进程启动时先要映射共享内存,然后才能够通过共享内存中的内部数据结构完成会话的初始化工作。

在本机上不经过SQL*Net连接数据库,前台进程和用户进程之间通过IPC机制进行通信,通信协议就是著名的Bequeath协议,简称BEQ协议。而如果通过SQL*Net连接数据库,那么就需要使用网络协议。现在TCP/IP协议已经成为使用最为广泛的协议,因此我们主要面对的是TCP/IP协议,而10多年前,著名的SPX协议、DECnet协议、Token Ring协议等都曾经是DBA进程配置的协议。使用SQL*Net协议的前台进程和用户进程之间的通信采用Socket通信。实际上,在服务器上,我们也可以使用SQL*Net连接数据库,只不过我们很少会去这样做,因为BEQ协议在效率上高于Socket通信。

除了使用的协议不同,在本机上通过BEQ协议连接数据库实例和通过SQL*Net连接数据库实例还有什么不同吗?很多DBA可能会感觉有所不同,因为在本机上直接连接数据库协议,前台进程是shell进程产生的子进程;而通过SQL*Net连接数据库实例,server进程是LISTENER(tnslsnr)产生的子进程,如果监听器进程的属性不同,那么产生的子进程会和shell直接产生的子进程有所不同。这一点不同在早期的Oracle版本中确实存在,而自从$ORACLE_HOME/bin/oracle这个映像文件被设定为s属性后,这个问题就不存在了。Oracle映像通过s属性可以将子进程的属性转为Oracle用户。

不过使用BEQ协议和网络协议在服务进程方面还是有所不同的,BEQ协议通过IPC通信,因此不需要使用Socket,而通过网络协议(SQL*Net)连接,客户进程最初连接的是tnslsnr进程,tnslsnr进程接受了连接请求后,为其创建一个子进程,然后通知客户端进程重新连接到子进程上继续工作。在这个时候,就存在一个Socket重定向的问题。监听器产生子进程时会为新的连接分配一个未被使用的端口号,,这个子进程启动后就在该端口上侦听,同时监听器会通知客户端进程,要求其重定向到新的端口号。此时客户端进程会关闭老的Socket,并打开一个新的Socket,完成登录操作。

可能有些DBA对上面的讨论感到有些迷茫了,怎么讨论实例的问题,一下子又转到了监听器的工作机制上了,这些知识对于DBA又有什么作用呢?我们刚才一直在强调实例是客户端访问数据库的通道,因此讨论客户端如何通过监听器连接数据库就十分有意义了。

首先第一点,现在很多客户对系统安全性要求很高,因此服务器上大量的网络端口是被封掉的,只有必须使用的才会被开放。那么对于Oracle数据库来说,我们只需要开放监听器所需要的端口就可以了吗?事实上不是这样的,除了开放类似1521的监听端口外,我们还需要开放一些高端口,这些端口将被用于Socket重定向。

可能很多用户在客户端连接数据库的过程中经常会碰到TNS-12535之类的错误,开始的时候总是从网络超时的角度去分析,不过这样分析往往很难找到真正的故障原因。这类问题在一个存在防火墙的环境中,往往是由于在防火墙环境下的Socket重定向引起的,特别是在有NAT功能的防火墙上,这类问题很容易出现。客户端连接的是一个NAT翻译后的IP地址,而重定向的时候,监听器要求客户端连接到真实的IP地址上,这样就会出现连接超时导致的失败。这种情况一般的解决方案是使用connect manager(CMAN),老白也曾经碰到过几个这样的客户,最后都是通过CMAN来彻底解决问题的。

linux

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn