应仅授予SELECT权限及ALL_TAB_COLUMNS等必要元数据视图访问权，禁止DBA_*视图和系统级权限，确保增量读取安全稳定低开销。
只给SELECT + 查询元数据权限，别碰DBA视图
Oracle里ETL工具做增量读取，核心诉求就一个：能安全、稳定、低开销地拿到自上次同步以来的新/改记录。给太多权限不仅违反最小原则，还会埋下审计和误操作风险——比如工具脚本意外执行DROP TABLE或UPDATE。实际生产中，绝大多数增量抽取（基于时间戳、SCN、或ROWID）只需要SELECT权限 + 查看表结构的能力。
常见错误是直接授SELECT_CATALOG_ROLE或DBA角色，结果工具能查DBA_TABLESDBA_TAB_COLUMNS甚至V$TRANSACTION，既没必要，又让安全扫描直接报高危。
- 必须授予：
SELECTon source tables（如SOURCE_ORDERS）、SELECTon control table（如ETL_CONTROL） - 推荐授予：
SELECTonALL_TAB_COLUMNS和ALL_TAB_PARTITIONS（用于自动识别字段类型和分区键，避免硬编码） - 绝对禁止：
SELECTonDBA_*视图、EXECUTEonDBMS_FLASHBACK、ALTER SYSTEM等系统级权限
用细粒度对象权限替代角色，避免权限扩散
很多团队图省事，直接给ETL用户授SELECT_CATALOG_ROLE，以为“只读就安全”。但这个角色包含对DBA_OBJECTSDBA_SEGMENTS等20+个高危视图的访问权，一旦ETL配置出错或被注入恶意SQL，后果不可控。正确做法是按需授权具体对象。
例如，某订单同步任务只涉及SOURCE_ORDERS、SOURCE_CUSTOMERS和ETL_CONTROL三张表，那就只执行：
GRANT SELECT ON SOURCE_ORDERS TO etl_user; GRANT SELECT ON SOURCE_CUSTOMERS TO etl_user; GRANT SELECT ON ETL_CONTROL TO etl_user;
如果源表在不同schema下（如app_prod.SOURCE_ORDERS），注意显式带上schema名，别依赖CURRENT_SCHEMA或同义词——ETL工具连接串里通常不设ALTER SESSION SET CURRENT_SCHEMA，权限会失效。
增量依赖字段必须有NOT NULL + 索引，否则权限再小也卡死
权限只是起点，真正影响增量读取能否跑通的是字段设计。比如用LAST_UPDATE_DATE做增量条件，但该字段允许NULL、没索引、甚至被业务逻辑频繁更新为旧值，那SELECT ... WHERE LAST_UPDATE_DATE > :last_ts就会变全表扫描，拖垮源库。
- 确认时间戳字段定义为
NOT NULL，且有B-tree索引（不要用函数索引如INDEX ON TRUNC(LAST_UPDATE_DATE)，ETL条件无法走索引） - 若用
ROWID或ORA_ROWSCN做增量，需确保表启用了ROWDEPENDENCIES（ALTER TABLE ... ENABLE ROW DEPENDENCIES），否则ORA_ROWSCN精度只到块级，漏数据概率极高 - 避免在WHERE条件里对字段做运算，如
WHERE TO_CHAR(LAST_UPDATE_DATE, 'YYYYMMDD') = '20260928'——索引失效，权限再小也扛不住慢查询
测试阶段必须验证“删权限后是否报ORA-00942”而非“功能是否正常”
权限配置完成后，别急着跑全量任务。最有效的验证方式是：临时收回SELECT权限，然后让ETL工具执行一次增量查询，观察是否明确报ORA-00942: table or view does not exist或ORA-01031: insufficient privileges。如果报的是ORA-00904: invalid identifier或ORA-01722: invalid number，说明工具在尝试访问它没权限的字段或视图，权限还没收干净。
这个细节常被忽略——很多人看到“任务跑通了”就认为权限OK，但可能工具正悄悄通过ALL_TAB_COLUMNS动态拼SQL，而你根本没意识到它读了不该读的元数据。
真正的最小权限，不是“够用就行”，而是“少给一格就立刻失败”。边界感越清晰，后期排查越省力。
