备库关联查询的设计思考（r7笔记第41天)

现在有一个需求，目前在开发的同学需要做一些查询，但是涉及的两个表在两个不同的数据库里面。就是下面的形式。从他们的反馈来看还需要做表关联，是统计业务相关，对于数据的实时性要求不是很高。

所以这个需求看起来是需要直接用db link来做关联了，但是两个表都还比较大，一个local,一个remote还是有不少的潜在风险，表的数据量在百万，千万级，所以对于这种关联的统计查询，我是不主张直接在主库用的。所以首先向到了备库。 因为是11g的adg,所以这个问题其实也算是一个不错的思路。 于是实现方式就类似下面的形式。

在db1的备库中创建一个同义词指向db2，使用db link的形式。这种方式看起来还行，但是一个潜在的风险就是这种关联查询在db2中会很可能有较高的负载。 所以这部分压力可以分担开来直接指向db2的备库，类似下面的形式。

基本的读取压力解决了，来看看安全问题。 现在的问题是，目前的这种需求我的主张是不让开发的同学在主库上运行这种查询，从而避免更多的误操作和潜在风险。 那么怎么来实现呢。可以看看下面这个完整的图。

在 这种实现方式中，基本都是备库之间的事儿了，app直接指向两个备库，以db1为基准节点做表关联查询，防火墙在db1,db2之间都是彼此不通的，只在 备库之间开，那么在db1的主库创建了db link之后，因为备库的网路互通，主库网络不互通，所以db link其实只在备库生效。然后在主库创建同义词的ddl会同步到备库去，这样就间接同步了这种结构。 所以备库之间做关联查询大体来看是没有问题的，那么开发的同事需要做什么查询对于DBA来说还是需要做一些改进和审核的，我们也可以提供不少的改进经验进来。