这里是一个示例SQL查询，用于计算本地数据库中以字母“D”开头的每个部门在远程数据库@richdb上员工的平均工资。
SELECT Avg(emp_salary),
emp_dept
FROM employee@richdb
WHERE emp_dept IN (SELECT dpt_id
FROM department
WHERE dpt_name LIKE ‘D%’)
GROUP BY emp_dept
以下是此SQL的查询计划，它需要9.16秒才能完成。查询计划显示从本地DEPARTMENT到远程EMPLOYEE数据库的嵌套循环。由于EMPLOYEE表的大小比DEPARTMENT表大得多，因此在这种情况下，嵌套循环连接路径不是最优的。
为了要求Oracle考虑在远程数据库@richdb中执行连接操作，我添加了一个提示/*+ DRIVING_SITE(employee) */，告诉Oracle使用EMPLOYEE表的数据库@richdb作为分布式查询的驱动站点。
SELECT /*+ DRIVING_SITE(employee) */ Avg(emp_salary),
emp_dept
FROM employee@richdb
WHERE emp_dept IN (SELECT dpt_id
FROM department
WHERE dpt_name LIKE ‘D%’)
GROUP BY emp_dept
以下查询显示驱动站点已更改为@richdb，并且远程从“本地”数据库检索DEPARTMENT数据。现在速度已经提高到5.94秒。但是查询计划有点复杂，有一个视图，由EMPLOYEE和DEPARTMENT的两个“索引快速完整扫描”的索引哈希连接构成。
我进一步更改了SQL，并在子查询的选择列表中添加了一个虚拟操作Coalesce(dpt_id,dpt_id)，以阻止DEMPARTMENT表的索引快速全扫描。
SELECT /*+ DRIVING_SITE(employee) */ Avg(emp_salary),
emp_dept
FROM employee@richdb
WHERE emp_dept IN (SELECT Coalesce(dpt_id,dpt_id)
FROM department
WHERE dpt_name LIKE ‘D%’)
GROUP BY emp_dept
这个更改给SQL带来了一个新的查询计划，如下所示，性能显著提高至0.71秒。您可以从这个例子中了解虚拟操作Coalesce(dpt_id,dpt_id)如何影响Oracle SQL优化器的决策。
这种重写可以通过Tosska DB Ace for Oracle自动完成，它表明这个重写比原始SQL快了近13倍。
Tosska DB Ace Enterprise for Oracle – Tosska Technologies Limited
