不能用 SELECT ANY TRANSACTION 实现 BI 只读，因其仅允许查询 v$transaction 等动态性能视图，不授予业务表 SELECT 权限，也不限制 DML，且违反最小权限原则。
Oracle 中没有“只读事务角色”这个内置概念，SELECT ANY TRANSACTION 是一个高危系统权限，不是事务只读控制手段；BI 报表用户真正需要的是稳定、可审计、不随 schema 变更失效的只读查询能力。
为什么不能用 SELECT ANY TRANSACTION 实现 BI 只读？
该权限允许用户查询 v$transaction 等动态性能视图，用于诊断事务状态，和“让 BI 用户只能查业务表”完全无关。它既不授予对业务表的 SELECT 权限，也不限制 DML——哪怕用户有 UPDATE 权限，该系统权限也起不到约束作用。误授此权限反而暴露数据库内部状态，违反最小权限原则。
BI 报表用户必须满足的四个硬性条件
漏掉任一，报表执行就会失败（比如卡在 GROUP BY、无法解析同义词、连登录都报错）：
-
CREATE SESSION：否则登录直接报ORA-01045 - 显式指定
TEMPORARY TABLESPACE：否则排序/聚合报ORA-01652 - 在
DEFAULT TABLESPACE上有配额（哪怕只建同义词也需要）：否则CREATE SYNONYM失败 - 对象级
SELECT权限（或通过角色间接持有），且目标表未被READ ONLY表空间锁死结构（注意：表空间只读 ≠ 表只读）
推荐做法：用角色封装跨 schema 的 SELECT 权限
避免逐条 GRANT SELECT ON schema.table TO user，改用角色统一管理。关键点：
- 角色本身不带登录能力，必须额外
GRANT CREATE SESSION TO role（或单独授给用户） - 用
DBA_TAB_PRIVS视图生成批量授权语句，例如：SELECT 'GRANT SELECT ON ' || owner || '.' || table_name || ' TO bi_readonly_role;' FROM dba_tables WHERE owner IN ('SALES', 'FINANCE') AND temporary = 'N'; - 若 BI 工具依赖同义词简化 SQL，需额外授
CREATE SYNONYM给角色，并确保用户默认表空间有配额 - 禁用密码重用与交互登录（非必需但建议）：
ALTER USER bi_user PASSWORD EXPIRE;+ALTER USER bi_user ACCOUNT LOCK;
容易被忽略的 BI 特定依赖
BI 工具常触发隐式操作，仅靠表级 SELECT 不够：
- 需要
SELECT权限访问ALL_TAB_COLUMNS、ALL_VIEWS等数据字典视图，否则元数据加载失败（可授SELECT_CATALOG_ROLE，但注意它含SELECT ANY DICTIONARY，应评估风险） - 物化视图日志、分区键信息等可能被 BI 查询引擎自动探测，需确认对应
ALL_*视图权限是否覆盖 - 若报表含 PL/SQL 函数调用（如自定义格式化），需额外
EXECUTE权限，不能只靠SELECT
最易出问题的不是权限没给全，而是默认表空间配额为零、临时表空间缺失、或把 SELECT ANY TABLE 当万能解——它会让 BI 用户意外读到配置表、审计日志甚至其他租户数据，且后续无法按 schema 收回。
