您将获得两个进程：

oracle    6339  6185  0 13:06 pts/0    00:00:00 sqlplus
oracle    6340  6339  0 13:06 ?        00:00:00 oracleDBA102 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 

第一个进程您之前已经看到，即 SQL*Plus 会话进程。 第二个进程的 ID 为 6340，它是 Oracle 为用户创建的服务器进程。 请注意，该进程的父进程 ID 为 6339，是 SQL*Plus 会话的进程 ID。

进程名称为“oracleDBA102 (DESCRIPTION=(LOCAL=YES) (ADDRESS=(PROTOCOL=beq)))”，其中包含了许多有用的信息。 首先，子句 LOCAL=YES 的存在表明该进程由于与数据库本身在同一个服务器上本地运行的另一个进程而启动。 名称中的 PROTOCOL=beq 还意味着该连接是通过 bequeath 连接构建的。

您还可以从动态视图中找到关于该服务器进程的信息。

select spid
from v$session s, v$process p
where s.sid = (select sid from v$mystat where rownum <2)
and p.addr = s.paddr;

上述查询返回的值是服务器进程的进程 ID。 如果客户端进程在另一个服务器上（例如，某人在连接到数据库的笔记本电脑上运行 SQL*Plus），这是获得进程 ID 的唯一方法。

现在，假设用户通过稍有改动的方式进行连接。 她不是直接在服务器上连接，而是使用了 TNS 字符串。 假设 TNS 字符串类似以下内容（在服务器 oradba 上）。

DBA102 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradba)(PORT = 1521))
   )
(CONNECT_DATA =
(SERVER = DEDICATED)
     (SERVICE_NAME = DBA102)
   )
 )

现在，用户按照以下方式进行连接（在同一服务器 oradba 上）：

sqlplus arup/arup@dba102

从动态视图中检查进程 ID：

SQL> select spid
 2  from v$session s, v$process p
 3  where s.sid = (select sid from v$mystat where rownum <2)
 4  and p.addr = s.paddr
 5  /

SPID
------------
6428

进程 ID 为 6428。在服务器上搜索该进程：

$ ps -aef|grep sqlplus | grep -v grep
oracle    6426  6185  0 13:20 pts/0    00:00:00 sqlplus

现在，当在数据库服务器上搜索服务器进程时：

$ ps -aef|grep 6426 | grep -v grep
oracle 6426 6185 0 13:20 pts/0 00:00:00 sqlplus

....您不会看到服务器进程。 用户进程 6426 没有子进程。但是，从动态性能视图，您可以知道服务器进程为 6428，那么该进程的父进程是什么？

$ ps -aef|grep 6428 | grep -v grep
oracle    6428     1  0 13:20 ? 00:00:00 oracleDBA102 (LOCAL=NO) 

父进程为“1”。 但是为什么不是 6426 呢？

要理解该答案，需要了解不同的 Oracle 服务器进程的创建方式。 在第一种情况下，当用户未使用 TNS 连接字符串时，连接被直接路由到数据库，而不是首先经过监听程序。 数据库创建了一个用户进程，然后将该进程（称为 bequeathing）的控制权传递给进程所有者，以下使用术语 bequeath 进程，这显示在进程名称中。

第二种情况下，当用户仍然在同一服务器上但通过监听程序连接时，监听程序创建了称为 forking 的用户进程。 同样，如果用户进程在另一台计算机（例如笔记本电脑）上运行，连接需要通过监听程序，监听程序可能已经创建了该进程。 该进程是由远程服务器创建的，因此进程名称包含子句 LOCAL=NO。 即使 SQL*Plus 会话在同一服务器上运行，但它是一个非 bequeath 连接的事实使其成为非 LOCAL 连接。

（请注意： 根据 OS 的不同，您不能象在 bequeath 连接中查看 SQL*Plus 会话那样查看服务器进程的父 ID。 在某些情况下，即使连接为 bequeath，父 ID 仍将显示为“1”。 因此，不要依赖父 ID 来决定服务器进程的类型；请通过进程名称来决定。

既然您理解了双任务模型；让我们来看一下您是否抓住了整个讨论的重点。 服务器进程由数据库创建并运行，而不是启动了 SQL*Plus 等客户端进程的用户。 服务器进程使用可执行文件“oracle”或“oracle.exe”，因此仅名为“orasoft”（这样命名是为了避免与可执行文件的名称“oracle”这个术语冲突）的 Oracle 软件所有者应该有权执行它们，其他任何人都不可以。 那么，您为什么需要其他用户的权限呢？

简短回答是： 您不需要。您可以通过发出以下命令删除不需要的权限：

$ chmod 4700 $ORACLE_HOME/bin/oracle

执行该命令后，权限将和下面的类似。

-rws------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle

现在我们可以通过 SUID 位转到策略。 在本例中，SUID 位设置为 ON（通过所有者的 rws 权限指示）。

$ chmod 0700 $ORACLE_HOME/bin/oracle

权限现在看起来与下面的类似：

-rwx------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle

结论
这是较大的改动，理解其影响很重要。 当服务器上的用户（非 Oracle 软件所有者）尝试连接一个本地连接时，可执行文件“oracle”将以该用户的名义运行，就好像用户“orasoft”正在运行该文件一样。 这很重要；因为服务器进程将打开“orasoft”拥有的数据文件，该进程必须以“orasoft”身份运行，或者用户必须具有打开数据文件的权限。

例如，假设 UNIX 用户“ananda”登录到数据库所在的服务器，并进行本地连接：

$ sqlplus arup/arup

该用户将立即收到一条错误信息。

ERROR:
ORA-12546: TNS:permission denied

Enter user-name:

原因很简单： 您删除了文件“oracle”上的 SUID 权限。 当用户执行本地连接时，实质上是尝试运行可执行文件“oracle”，但是由于 SUID 未设置，因此不会以用户“orasoft”身份尝试而是以“ananda”身份尝试。 由于用户 ananda 没有运行该文件的权限，因此该文件也不会得到执行，因此出现了 ORA-12546 错误。

那么，ananda 怎样才能连接数据库呢？ 有两种方法。 一个方法是，使所有用户进程在数据库服务器本身之外的服务器上运行，如此就不会存在到数据库的 bequeath 连接，只有非 LOCAL 连接。 因为非 LOCAL 连接经过监听程序进程，监听程序为其衍生了服务器进程，所以服务器进程的所有者是“orasoft”（Oracle 软件所有者），而不是运行客户端进程的用户。 没有需要发布的权限。

或者，如果必须在数据库服务器本身上运行某些用户进程，您可以使用以下命令通过监听程序连接

$ sqlplus arup/arup@dba102

这与从服务器外部连接的用户具有同样的效果。 现在，只有拥有 Oracle 软件的用户（本例为 orasoft）可以通过 bequeath 连接来连接到数据库。

具有单独的操作系统 ID 的 DBA 将不能使用命令 connect / as sysdba 来关闭或启动数据库，即使他们属于 dba 组。 他们可以通过以下命令执行该操作

$ sqlplus /nolog
SQL> connect sys/Password_of_SYS@dba102 as sysdba

是的，该方法使用了 SYS 密码；但是无论如何，与 / as sysdba 相比，该方法要好些。 但是，一种更好的方法是为各个 DBA 创建 Oracle 用户 ID：

connect ANANDA/Password_of_ANANDA@dba102 as sysdba

黑客惯用的伎俩是使用任意帐户登录服务器，然后尝试强行进入数据库。 （典型的“松散门户”是用户“nobody”。） 即使黑客没有进入数据库，他也可以通过 oracle 可执行文件的缓冲区溢出创建拒绝服务攻击。 如果删除了执行该文件的功能，那么该攻击的效果将受到严格限制。 同时，正如所见，您没有删除合法用户的任何功能。 总之，大多数用户使用监听程序连接到数据库，而且并不会受到太大影响。

1. 通过询问
2. 在服务器上搜索进程，查看是否有象 SQL*Plus 一样明显的内容
3. 查看 V$SESSION 的 MACHINE 列

   select program
   from v$session
   where machine = '<machine_name>';
   

   如果出现一些这样的内容，您可以通过打开审计（在后续阶段将学习该功能）并捕获来自该服务器的所有程序来识别运行的确切程序。