与优化器相关的大多数事情一样，这取决于。

如果您为特定查询生成查询计划，查询计划将告诉您本地数据库正在执行什么操作以及远程数据库正在执行哪些操作。最有可能的是，如果对象的统计数据相当准确，并且查询仅引用单个远程数据库中的对象，那么优化器将足够聪明，可以将整个查询推送到远程服务器执行。

唉，优化器并不总是足够聪明来做正确的事情。如果发生这种情况，您很可能可以通过向查询添加适当的 driving_site 提示来解决它。

SELECT /*+ driving_site(F) */ * 
  FROM FOO@DB_LINK F 
       INNER JOIN BAR@DB_LINK B 
          ON F.FOOBAR = B.FOOBAR

根据查询的复杂程度、向查询添加提示的难度以及您在环境中使优化器运行的难度有多大，在远程数据库中创建视图可能是强制查询的另一种方式在远程数据库上运行。如果您在 db_link 上创建一个将两个表连接在一起的视图并通过数据库链接查询该视图，这将（根据我的经验）总是强制在定义视图的远程数据库上执行。鉴于您没有混合本地和远程对象，我不希望需要此选项，但为了完整性我将其包含在内。

一个 100% 的远程查询将被远程实例优化。本地实例仍然需要分配一些内存并使用 CPU 以从远程服务器获取结果，但主要工作（如散列连接和循环等）将由远程实例完成。

发生这种情况时，您将在本地执行计划中收到一条注释

Note
-----
   - fully remote statement

一旦需要在本地服务器上做一些事情（例如插入或加入本地表（包括本地双））作为语句的一部分，那么查询就变成分布式的，只有一个服务器可以被视为驾驶站点，它通常是本地的（我无法提出一个选择远程站点的演示，即使它更便宜，所以它可能不是基于成本的）。通常，这最终会导致您在某处遇到一些问题 - 可能是针对本地计算的远程表的嵌套循环连接。

分布式查询需要记住的一件事 - 优化实例不会查看来自另一个实例的直方图信息。