必须用登录触发器或细粒度访问控制（FGAC）限制服务名，因CREATE USER不支持绑定服务名；用户无SERVICE_NAME属性，服务名由客户端传递且对用户透明，需在会话级通过AFTER LOGON触发器校验SYS_CONTEXT('USERENV', 'SERVICE_NAME')或用DBMS_RLS动态过滤。
不能靠用户属性限制服务名，必须用细粒度访问控制（FGAC）或登录触发器实现。 Oracle 的 CREATE USER 语句本身不支持绑定服务名，所谓“只允许通过特定服务名连接”是会话级策略，需在连接建立后、用户认证完成前干预。
为什么直接指定服务名行不通
Oracle 用户没有 SERVICE_NAME 属性字段，DBA_USERS 或 USER$ 视图里也查不到服务名关联项。服务名是客户端连接描述符里的逻辑标识，由监听器解析后传给实例，对用户对象完全透明。试图用 ALTER USER ... IDENTIFIED EXTERNALLY 或角色限制都无效——只要密码正确、网络可达，任何服务名都能连上该用户。
用登录触发器拦截非授权服务名
这是最常用且可控的方式，在 AFTER LOGON ON DATABASE 触发器中检查 SYS_CONTEXT('USERENV', 'SERVICE_NAME')，不匹配则抛异常中断会话。
- 必须用
DEFINER'S RIGHT创建，且触发器拥有者需有SELECT_CATALOG_ROLE或直接SELECT权限访问V$SESSION - 触发器内避免调用可能失败的函数（如自定义 PL/SQL），否则会导致所有用户无法登录
- 测试时务必先用
SYSTEM或其他高权限账号验证，防止把自己锁死 - 示例代码：
CREATE OR REPLACE TRIGGER chk_service_name_trg
AFTER LOGON ON DATABASE
DECLARE
v_service VARCHAR2(128);
BEGIN
v_service := SYS_CONTEXT('USERENV', 'SERVICE_NAME');
IF v_service NOT IN ('ERP_PROD', 'ERP_REPORT') THEN
RAISE_APPLICATION_ERROR(-20001, 'Access denied: service name "' || v_service || '" not allowed');
END IF;
END;
用细粒度访问控制（FGAC）做更灵活的会话过滤
如果需要按服务名 + IP段 + 时间段组合控制，或者想把规则外置到表里便于运维，就该用 DBMS_RLS 添加动态策略。注意这不是传统意义上的“连接限制”，而是在首次查询时拦截，适合已有应用无法改连接串的场景。
- 策略函数返回的谓词必须是字符串，例如
'1=0'可立即拒绝所有查询 - 策略需绑定到
DUAL或一个空表（如HR.LOGIN_CHECK），否则应用首次执行SELECT 1 FROM DUAL就会触发拦截 - 策略类型设为
SHARED_STATIC可减少解析开销，但规则变更需手动刷新策略 - 容易漏掉的点：PL/SQL 包初始化块、
DBMS_SCHEDULER作业、UTL_HTTP外部调用等隐式会话可能绕过该策略
监听器端配合（仅限硬隔离场景）
若目标是彻底阻止非授权服务名抵达数据库进程，可在 listener.ora 中为不同服务名配置独立 SID_LIST，并用 GLOBAL_DBNAME 和 ORACLE_HOME 绑定特定数据库实例；再配合 sqlnet.ora 的 SQLNET.INVITED_NODES 或防火墙规则，从网络层过滤。但这属于基础设施级控制，和用户权限模型无关，且维护成本高。
真正难的是触发器里那个 SYS_CONTEXT('USERENV', 'SERVICE_NAME') 的值——它依赖客户端实际使用的 TNS 别名或 JDBC URL 中的 service_name 参数，不是数据库自己生成的。很多应用用 tnsnames.ora 配了别名却没填 SERVICE_NAME，结果取出来是空字符串或默认值，这种细节不验一遍，策略就形同虚设。
