访问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来彻底解决问题的。