能否通过VPD或同类方案在后台自动扩展数据库用户执行的所有SELECT查询

报错原因 #

你遇到的ORA-28113错误是VPD的设计特性导致的：VPD返回的谓词只能是合法的WHERE子句条件片段，系统会自动把这个字符串拼接到原查询的WHERE子句末尾，你返回的内容带UNION关键字，拼接后会生成语法错误的SQL：

-- 你预期的SQL
select * from mytable union all select * from different_schema.mytable
-- 实际VPD拼接后的SQL
select * from mytable WHERE 1=1 union all select * from different_schema.mytable

显然WHERE子句中不允许出现UNION结构，所以直接触发语法错误，VPD本身是为行级/列级权限控制设计的，不支持直接改写SQL的查询结构，这条路走不通。

可行的替代方案 #

注意：所有带UNION ALL的实现都要求两边表的字段数量、类型、顺序完全一致，否则查询时会触发字段不匹配的错误。

方案1：视图+同义词（最推荐，实现成本最低） #

这个就是你已知的动态UNION视图方案，搭配同义词可以做到用户完全无感知：

1. 把原表重命名为别名，比如mytable_base
2. 创建统一查询视图：

CREATE OR REPLACE VIEW mytable AS
SELECT * FROM mytable_base
UNION ALL
SELECT * FROM different_schema.mytable;

3. 给用户授予视图的查询权限，用户执行select * from mytable的时候完全感知不到底层是UNION的视图，和查询原表体验完全一致，性能也最稳定。
   如果涉及的表数量多，可以写存储过程批量生成对应视图和同义词。

方案2：SQL翻译框架（适合批量改写场景） #

如果需要对大量表做统一的透明改写，不想逐个创建视图，可以用Oracle自带的SQL翻译框架：

1. 开启SQL翻译功能相关参数
2. 创建翻译配置，定义匹配规则：只要是对对应表的SELECT查询，自动替换为带UNION ALL的目标SQL
3. 把翻译配置绑定到对应用户，用户执行的所有符合规则的查询都会在后台自动改写，完全不需要修改业务代码。
   这个方案的缺点是调试难度高，出现SQL问题的时候容易忘了存在改写规则，排查成本高。

方案3：分区外部表（适合跨库/多实例场景） #

如果你的目标扩展表在其他实例，可以把远程表映射成本地的分区外部表，用户查本地表的时候自动拉取远程数据，也是透明的，但配置复杂度比视图方案高。

内容的提问来源于stack exchange，提问作者njank