PDB本地管理员不能直接改CDB，因为Oracle 12c容器隔离是硬性架构限制，非权限控制；在PDB中执行ALTER DATABASE或未指定CONTAINER=ALL的ALTER SYSTEM命令会直接报ORA-65040，且PDB内不可见CDB级对象与文件。
为什么PDB本地管理员不能直接改CDB
因为Oracle 12c的容器隔离是硬性限制，不是权限开关。你在PDB里用SYS或SYSTEM登录（哪怕带AS SYSDBA），只要当前容器是PDB，所有ALTER DATABASE、ALTER SYSTEM CONTAINER=CURRENT以外的CDB级命令都会被拦截——不是报“权限不足”，而是直接报ORA-65040: operation not allowed from within a pluggable database。
PDB中执行ALTER SYSTEM能影响CDB吗
不能，除非显式加CONTAINER=ALL，且你必须在CDB$ROOT中以SYS身份执行。在PDB中运行ALTER SYSTEM SET memory_target=2G，只改本PDB的参数（前提是该参数ispdb_modifiable='TRUE'）；漏写CONTAINER=ALL或在PDB里写，Oracle根本不会去查CDB级参数表。
常见误操作：
- 在PDB中执行
ALTER SYSTEM SET open_cursors=500，以为调大了整个实例——其实只改了当前PDB - 用
CONN / AS SYSDBA连上后没检查CON_NAME就跑命令，结果在CDB$ROOT里误删了其他PDB的表空间 - 以为
GRANT DBA TO pdb_admin能让用户跨容器操作——DBA角色在PDB中根本不存在，会触发ORA-01917
如何确认当前会话真正在哪个容器执行
别信连接字符串，要查实时上下文。最可靠的是：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;
而不是SHOW CON_NAME（有些客户端不支持）。如果返回CDB$ROOT，你就在根容器；如果是HRPDB之类的名字，才真正处于PDB上下文。任何管理操作前都该先跑这句——尤其当你用sqlplus / as sysdba连入时，默认就是CDB$ROOT。
真正需要限制PDB管理员越权的场景
实际风险不在SQL命令拦截，而在人为切换容器。比如DBA在PDB里做完应用维护后，顺手ALTER SESSION SET CONTAINER=CDB$ROOT，接着执行DROP PLUGGABLE DATABASE testpdb，这就不是权限问题，是操作路径没卡死。
防御建议：
- 给PDB专用账号（如
pdbadm_hrpdb）只授CREATE SESSION和SET CONTAINER权限——没有SET CONTAINER，它连不到CDB$ROOT - 禁用
CONNECT / AS SYSDBA直连CDB$ROOT，改用带服务名的连接：sqlplus pdbadm_hrpdb@hrpdb，这样默认会话就锁死在PDB - 在CDB$ROOT中创建触发器捕获
ALTER SESSION SET CONTAINER事件，记录并告警（需AUDIT SYSTEM权限）
最关键的其实是目录和路径意识：PDB管理员看不到CDB_USERS，也写不了/opt/oracle/oradata/ORCL/system01.dbf，这种隔离比权限表更底层。一旦开始手动切容器、手写绝对路径、绕过服务名连接，防线就从架构层退到了人工流程层。
