DBA_NETWORK_ACL_ADMIN角色不管理监听器，仅控制数据库内PL/SQL网络包（如UTL_HTTP）对外部主机的访问权限；监听器是OS级进程，其启停、配置、状态均依赖操作系统权限，与数据库角色无关。
oracle 12c 中，dba_network_acl_admin 角色 **不用于管理监听器**，它只负责数据库内部的网络访问控制列表（acl）——比如控制 pl/sql 包（如 utl_http、utl_smtp）能否访问外部主机。监听器（lsnrctl）是独立于数据库实例运行的操作系统级进程，其启动、停止、重载等操作依赖操作系统权限，而非数据库角色或 acl。
为什么 DBA_NETWORK_ACL_ADMIN 对监听器完全无效
监听器进程（TNSLSNR）由 Oracle 用户（如 oracle）在 OS 层启动，监听配置文件（listener.ora）的读取、端口绑定、服务注册均由该进程自主完成。数据库用户即使拥有 DBA 或 DBA_NETWORK_ACL_ADMIN，也无法：
- 执行
lsnrctl start/lsnrctl stop（会报open service error或权限拒绝） - 修改
listener.ora文件内容并使其生效（需 OS 层写权限 + 手动 reload） - 查看监听器状态（
lsnrctl status返回的是 OS 进程信息，非 SQL 查询结果）
真正能“管理监听器”的方式只有两种
所有操作都必须在操作系统层面完成，且需具备对应权限：
-
用 Oracle OS 用户直接操作：确保你以安装 Oracle 的系统用户（如
oracle）登录，且该用户对$ORACLE_HOME/bin和$ORACLE_HOME/network/admin有读写执行权限 -
通过 sudo 配置受限命令（生产环境推荐）：例如在
/etc/sudoers中添加：%dba ALL=(oracle) NOPASSWD: /u01/app/oracle/product/12.2.0/dbhome_1/bin/lsnrctl *，然后普通 DBA 用户可执行sudo -u oracle lsnrctl status
DBA_NETWORK_ACL_ADMIN 的真实使用场景
它只在数据库内控制「哪些数据库用户能调用哪些网络包访问哪些外部地址」。典型操作包括：
- 创建 ACL：
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL - 赋予权限：
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL - 添加主机白名单：
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE（例如允许用户app_user用UTL_HTTP访问api.example.com:443）
注意：DBA_NETWORK_ACL_ADMIN 是角色名，不是权限名；授予该角色后，用户才能调用 DBMS_NETWORK_ACL_ADMIN 包里的过程 —— 但它和监听器进程、端口、listener.ora 完全无关。
最容易被忽略的一点：很多 DBA 在监听器连不上时下意识去查数据库权限，结果绕半天才发现问题出在 listener.ora 的 HOST 写成了 localhost 而非实际 IP，或者防火墙没关、SELinux 拦截了 1521 端口 —— 这些全是 OS 层问题，跟任何数据库角色都无关。
