1、driving_site用于提示跨数据库操作（分布式）数据时，在哪一侧做数据处理。但对于DML操作，必须以发生DML的一侧为数据处理的所在。这里的问题，主要是当有大量数据需要传输到本地侧时，时间耗时会比较长。
2、对于INSERT INTO table1 select … from table2@dblink 这样的操作，数据处理必定是在本地侧。如果select … from table2@dblink的结果集较小（比如有过滤条件，或集合操作），可以考虑分两步处理，第1步，在另一侧将结果存到一个中间表中。第2步，从中间表中获取数据。由于中间表中的数据少，所以，需要在网络上传输的代价就会降低。反之，如果结果集较大，甚至只是简单地将远端的表“复制”到本地，那么没有什么太好的方法。因为大量的数据传输，是没有什么规避的方法的。
3、但是，当条件允许时，可以考虑建基于DBLINK的物化视图。其目的是将远端的数据以增量的方式同步的本地。其实现的效果是执行 insert into 时，不存在大量的数据传输过程（因为这个传输工作被分散到执行前就做了），从而实现缩短执行特定SQL时的处理时长的目标。但如果远端表的数据无法提前提供，或者创建基于DBLINK的物化视图的方法不能接受，目前看来，暂时没想到什么好的方法。
以上，供参考。

我今天也碰到了这么个现象，insert into 本地表 select from dblink 超级慢，但是单独执行 select from dblink 就秒出，后来仔细看了执行计划，insert的语句，是将driving_site固定到了本地库，无论怎么修改hint提示都无效。

后来采用中间办法，在本地执行  create table temp as select from dblink，就非常快，然后insert into 本地表 select from temp 表，就比较顺利了。