os认证在oracle 12c多租户中仅适用于cdb根容器，无法用于pdb；因设计限制，pdb不支持os身份传递，必须改用密码认证并指定正确service_name连接。
OS认证在PDB中根本不会生效
Oracle 12c 的多租户架构决定了 sqlplus / as sysdba 这类 OS 认证连接默认只作用于 CDB（容器数据库）根容器。当你试图在 PDB 环境下直接使用 OS 认证登录，Oracle 不会去检查 PDB 内部的用户或密码策略，而是直接拒绝——因为底层机制压根不支持跨容器的 OS 身份传递。这不是配置疏漏，是设计限制。
为什么 ALTER SESSION SET CONTAINER 不解决 OS 认证问题
很多人误以为只要先用 sqlplus / as sysdba 连上 CDB，再执行 ALTER SESSION SET CONTAINER = pdb1 就能“切换到 PDB 并继续以 SYSDBA 操作”，但这是错觉。此时你仍处于 CDB 上下文，所有权限、角色、甚至当前用户身份都还是 CDB 级的。PDB 内部没有对应的 OS 认证映射，SHOW USER 显示仍是 SYS，但 SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL 才揭示真相：你只是“看到”了 PDB，并未“成为”PDB 的认证主体。
- OS 认证依赖操作系统组（如
dba）和config.o中硬编码的组名，它只在实例启动时绑定一次，且仅对 CDB 生效 - PDB 启动后不重新触发 OS 组校验，也不维护独立的 OS 用户映射表
- 即使你在 PDB 中创建了本地用户并赋予
SYSDBA角色，也无法通过 OS 认证登录该 PDB —— 因为 Oracle 不允许本地用户拥有SYSDBA权限（会报ORA-65094）
替代方案：必须显式指定用户名/密码 + service_name
要在 PDB 中完成管理操作，唯一可靠路径是放弃 OS 认证，改用密码认证，并确保连接串指向正确的服务名：
- 确认 PDB 已注册服务：
SELECT name, open_mode FROM v$pdbs；若服务名未出现在lsnrctl services输出中，需用DBMS_SERVICE.CREATE_SERVICE显式创建 - 连接串必须用
@host:port/service_name格式（不是@host:port:SID），例如：sqlplus sys/oracle@localhost:1521/pdb1 - 用户必须是全局用户（以
C##开头），且在 CDB 和目标 PDB 中均存在并被授予必要权限；本地用户无法跨容器认证 - 若使用 JDBC，URL 必须为
jdbc:oracle:thin:@localhost:1521/pdb1，冒号后跟 service_name，不能是斜杠加 SID
最容易被忽略的兼容性细节
哪怕你已正确配置 service_name 和全局用户，仍可能卡在 ORA-01017 或 ORA-12514。这不是偶然——Oracle 12c 对密码版本、监听器协议、客户端驱动有隐式约束：
-
sqlnet.ora中必须设置SQLNET.ALLOWED_LOGON_VERSION=8或更高，否则 12c 默认拒绝旧协议握手，导致认证失败 - 监听器必须启用动态服务注册（
local_listener配置正确），静态注册无法自动感知 PDB 启停状态 - 密码大小写敏感是默认行为（11g+），输入
sys和SYS是两个不同口令；而用户默认大写存储，建用户时带引号（如"scott"）会导致后续连接串必须严格匹配大小写 -
config.o若被重链接过，OSDBA 组名可能被清空，导致/ as sysdba在 CDB 层也失效——这会让整个排查链路从起点就断掉
