原文:DBA的思想天空 p15-16
应用要访问 Oracle数据库，可以通过三种方式:
第一种方式是应用进程直接访问数据库实例的共享内存，
第二种方式是通过 beg协议在本机上访问，
第三种方式是通过网络协议访问。
首先，后两种访问数据库的方式都是基于two-task结构的，都需要在数据库服务器上建立个服务进程(server进程，或者前台进程)来为客户端应用服务(在这里我们只讨论独立服务器模式，共享服务器模式十分类似，我们将在后面进行专题描述)。two-task架构下访问数据库，首先需要在服务器端创建一个进程，这个进程启动时先要映射共享内存,然后才能够通过共享内存中的内部数据结构完成会话的初始化工作。
在本机上不经过
SQL*Net 连接数据库，前台进程和用户进程之间通过IPC机制进行通信，通信协议就是著名的 Bequeath 协议，简称 BEQ协议。而如果通过
SQL*Net连接数据库，那么就需要使用网络协议。现在TCPP协议已经成为使用最为广泛的协议，因此我们主要面对的是TCP/IP 协议，而10多年前，著名的SPX协议、DECnet协议、Token Ring协议等都曾经是 DBA进程配置的协议。使用 SOL*Net协议的前台进程和用户进程之间的通信采用 Socket通信。实际上，在服务器上,我们也可以使用 SQL*Net连接数据库,只不过我们很少会去这样做,因为 BEO协议在效率上高于 Socket 通信。
除了使用的协议不同，在本机上通过 BEO协议连接数据库实例和通过
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翻译后的P地址，而重定向的时候，监听器要求客户端连接到真实的地址上，这样就会出现连接超时导致的失败。这种情况一般的解决方案是使用 connect manager(CMAN)，老白也曾经碰到过几个这样的客户，最后都是通过 CMAN 来彻底解决问题的。
