Oracle中driving_sites优化SQL的正确姿势[通俗易懂]

概念

日常工作中经常会用到分布式数据库查询，即通过DBLINK同时查询本地表和远程表。分布式查询一般有两种处理方式：一种将远程表数据取回本地，然后和本地表关联查询，获取最终结果，另一种将本地表数据传到远程和远程表关联查询后，再将关联结果取回。前一种处理方式可理解为只有一次网络传输操作比后一种少，也就作为了数据库的默认处理方式；

driving_site提示能够指定执行计划在远程还是本地做，使用driving_site,特别是本地小结果集，远程大结果集，最终结果集较小时，希望计划在远程驱动，这样远程执行完毕，将结果集传输到本地，避免了大结果集的网络传输，从而达到整体优化的效果。

案例分析

XXX银行在日常的存贷通业务中，经常会出现作业超时甚至被挂起的现象，对业务正常开展造成严重影响，经分析定位到被挂起的sql为：

此sql是涉及了分布式查询的DML语句，其中CSSACT为封装了远程表关联的视图，其定义如下：

经测试环境分析，发现在bssdb远程库上borms和boiss表都是23w数据量，视图里两表哈希关联后返回23w的记录，使用了正确的关联方式，不存在性能瓶颈；

而本地表UDT_FNPT_QYXX符合过滤条件的记录数是3w，和ccsact视图关联后最终只有1w的数据量插入到目标表UDT_SALS_GL。

此种情况非常适合添加driving_site提示，从而避免对borms和boiss表的大结果集的网络传输，在不加提示的情况下，执行时间为8秒：

执行计划

添加driving_site提示的情况下，执行时间不到1秒钟(已考虑了物理读的情况，事先清空了buffer_cache)：

但是注意对于DML，DDL语句，driving_site提示是失效的，会自动被ORACLE忽略掉，此时将以目标表所在库为主计划驱动，相当于driving_site(目标表库)；DML，DDL中如果是对本地表做DML，主计划总是在本地做，会将远程数据拉到本地，相当于driving_site(本地表)；如果是对远程表做DML，主计划总是在远程做，会将本地数据送到远程，相当于自动driving_site(远程表)。

为实现DML优化效果，避免大数据量的网络传输，下面调整为在远程库(BSSDB)上将插入UDT_SALS_GL表的语句创建成视图，然后再在本地库上读取此视图来最终完成插入功能。

远程库BSSDB上，创建视图：

本地库CSSDB,改为读取远程视图完成插入，效果同添加了driving_site：

执行计划

要注意看清执行计划中operation为remote处对应的name是什么，是本地表则表示本地的表被推送到远程数据库上；此外，由于实验环境为测试环境，真实生产环境上数据量要大很多，网络开销也会更大，导致的性能差异只会更明显。

优化总结

1. driving_site优化，以减少总体的网络传输数据量为目标；

2. 当driving_site驱动的对象嵌套在视图中时，可通过driving_site(V.T)方式来指定，其中V表示视图别名或名称，T表示视图里表的别名或名称；

3. DML，DDL语句中driving_site提示无效，总是会以目标表所在的库为主计划驱动，此时可以通过视图转换来达到优化目的。