oracle 21c 中不存在“schema only账户”内置类型，它本质是需显式创建并精确授权的普通用户：必须指定表空间、临时表空间及配额（quota 0 on users），禁用 any 权限，授权须按 schema+object 精确授予，且所有操作须在目标 pdb 内执行。
Oracle 21c 中没有“Schema Only账户”这种内置类型，所谓 Schema Only 账户本质是：一个不拥有任何对象、仅被授予特定 schema 下对象访问权限的普通用户。它必须显式创建+显式授权，不能靠角色自动继承或 ANY 权限模糊覆盖。
为什么不能用 CREATE USER ... IDENTIFIED EXTERNALLY 或 PASSWORDLESS 方式
Oracle 21c 确实有一批 AUTHENTICATION_TYPE = 'NONE' 的系统账户（如 AUDSYS、OJVMSYS），但它们是 Oracle 内部管理账户，禁止用于应用连接。尝试对自定义用户设为 passwordless 会直接报 ORA-46385 或拒绝登录——这不是配置选项，而是安全硬限制。
- 所有应用级用户必须有密码（哪怕只是占位符），且需通过
IDENTIFIED BY显式声明 -
IDENTIFIED EXTERNALLY依赖操作系统或目录服务认证，在多数容器/云环境不可靠，且无法与 JDBC/ODBC 标准连接串兼容 - 真正“只读绑定到某 schema”的控制点不在认证层，而在授权层
CREATE USER 必须带表空间、临时表空间和配额
Oracle 21c 强制要求完整语法，漏掉任一就会失败：
CREATE USER app_schema_ro IDENTIFIED BY "RoPass2026!" DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp QUOTA 0 ON users;
-
QUOTA 0 ON users是关键：防止该用户在 schema 内建表、索引等对象，但允许执行查询（临时段仍可用） - 不要省略
TEMPORARY TABLESPACE—— 缺失会导致排序、哈希连接等操作直接报ORA-01536 - 不要依赖 CDB/PDB 默认值，尤其跨 PDB 部署时，
DEFAULT TABLESPACE可能指向不同物理位置
授权必须精确到 schema + object，禁用 SELECT ANY TABLE
SELECT ANY TABLE 在 Oracle 21c（同 19c）中仍是全库级权限，且在 ADG 备库上必然失效。它无法限定 schema，也无法回收粒度控制。
- 正确方式：逐对象授权，例如
GRANT SELECT ON app_schema.orders TO app_schema_ro - 若需批量，用查询生成语句（在目标 PDB 内执行）：
SELECT 'GRANT SELECT ON app_schema.' || table_name || ' TO app_schema_ro;' FROM dba_tables WHERE owner = 'APP_SCHEMA' AND temporary = 'N';
- ORM 或连接池常隐式查
V_$SESSION、V_$SQL，必须额外授权：GRANT SELECT ON V_$SESSION TO app_schema_ro（注意是V_$，不是V$） - 避免使用
CONNECT角色——它只含CREATE SESSION，看似无害，但旧脚本常把它和其它权限捆绑授予，易引发误操作
Schema 名大小写与 EF/Java 连接时的坑
Oracle 默认将未加双引号的标识符转为大写。如果应用用 Entity Framework 或 JDBC 直接写 SELECT * FROM orders，实际查的是 ORDERS 表；但若建表时用了小写名（CREATE TABLE "orders"），就必须用双引号引用。
- EF 中必须调用
modelBuilder.Types().Configure(c => c.ToTable(c.ClrType.Name, "APP_SCHEMA"))，否则生成 SQL 不带 schema 前缀，报ORA-00942 - JDBC 连接串里
user=app_schema_ro不代表自动切换 schema；所有表引用仍需显式前缀，或在会话级执行ALTER SESSION SET CURRENT_SCHEMA = APP_SCHEMA - 不要在授权语句里用小写 schema 名（如
GRANT SELECT ON app_schema.ORDERS）——Oracle 会把它当字面量匹配，而实际对象名是大写的
最易被忽略的一点：PDB 边界。你在 CDB$ROOT 创建的用户默认不可见于 PDB，所有 CREATE USER 和 GRANT 操作必须在目标 PDB 内完成，且角色不能跨 PDB 自动传播。连错容器、授错上下文，权限就等于没授。
