创建只读用户前必须明确三件事：一是禁用SELECT_ANY_TABLE等高危权限，仅对目标Schema中具体对象手动授予SELECT；二是分类型显式处理表、视图、物化视图、同义词等，避免误授或遗漏；三是封装脚本时限定对象来源并跳过临时表、审计表等敏感对象，授权后须验证基础查询可行性。
创建只读用户前必须明确的三件事
oracle里没有“只读用户”这个内置角色，select_catalog_role 或 select any dictionary 看似省事，但实际会赋予远超预期的权限（比如能查 v$session、dba_tables），生产环境禁用。真正安全的做法是：**只授权目标 schema 中具体对象的 select 权限**，且不依赖通配符或动态 sql 自动生成——后者容易漏对象、错对象，也难审计。
手动授权比脚本生成更可控
虽然可以用 DBA_TAB_PRIVS + GRANT SELECT ON ... TO ... 拼 SQL，但首次建用户时，表、视图、物化视图、序列（如果只读也要查 USER_SEQUENCES）类型不同，权限语义也不同。推荐分类型显式处理：
- 普通表和视图：对每个
TABLE或VIEW执行GRANT SELECT ON schema_name.table_name TO read_only_user - 物化视图：同样用
GRANT SELECT，但注意它本质是表，不能误当成普通视图处理 - 同义词（
SYNONYM）：只读用户若通过同义词访问，需确保同义词指向的对象已授权，且同义词本身无需额外授权 - 不要给
SELECT ANY TABLE：该权限绕过对象级控制，等于开放整个数据库
封装成存储过程时避开两个坑
如果真要封装（比如多环境批量部署），别写成“遍历 ALL_TABLES 自动授所有 SELECT”，而应限定来源：
- 只查
DBA_OBJECTS WHERE OWNER = 'TARGET_SCHEMA' AND OBJECT_TYPE IN ('TABLE','VIEW','MATERIALIZED VIEW')，避免误授其他 Schema 对象 - 跳过临时表（
OBJECT_NAME LIKE 'BIN$%'）、审计表（如AUD$）、应用自维护元数据表（如配置表、日志表）——这些通常不该被只读用户看到 - 过程内用
EXECUTE IMMEDIATE执行GRANT时，务必捕获ORA-01917: user or role 'xxx' does not exist和ORA-01927: cannot revoke privileges you did not grant类错误，否则一个失败就中断整批授权
权限生效后必须验证的最小检查集
授权完成不等于可用。登录 read_only_user 后，至少执行这三类验证：
- 查一张表：
SELECT COUNT(*) FROM target_schema.some_table—— 确认基础 SELECT 可行 - 查一张视图：
SELECT * FROM target_schema.some_view WHERE ROWNUM —— 视图可能依赖未授权的底层表 - 尝试越权操作：
INSERT INTO target_schema.some_table VALUES (...)应报ORA-01031: insufficient privileges，而非静默失败或报其他错
特别注意：如果目标 Schema 有函数或过程返回结果集（如 pipelined function），只授 SELECT 不够，还需 EXECUTE 权限——但这已超出“只读”范畴，得按业务逻辑单独评估。
