当前位置:Gxlcms > mysql > Oracle数据库三种连接方式

Oracle数据库三种连接方式

时间:2021-07-01 10:21:17 帮助过:222人阅读

访问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

人气教程排行