Oracle19C特性DML重定向

   上周稀里糊涂就阳性了，所以好几天没写。

   19C发布3年了，这个功能不神秘了。3年前我就是实验过，不过那时候没写公众号。现在搬上来一下。

   对于Oracle来说有ADG是最基本的高可用，我们已经搭建好了ADG。一般来说我们是主库写入数据，然后传给备库。这样备库也有了和主库一样的变化。这个过程是单向的，为什么？因为我们的从库也就是备库是只读的。，他只能接受主库送过来的数据，不能接受其他的变更。很简单，如果主库现在有3条数据：

1 A

2 B

3 C

这个时候我们把主库1的A改成AA。那么从库也是1的A改成AA。

那么试想一下如果把从库的1改成AAA，那么主库会变吗？首先我们改不了，其次如果可以改，那么不是主库1 A 从库1 AAA出现不一致了吗？

当然以上都是过去式了，从19C开始可以改了。刚才说的推翻了吗？这不是不一致了吗？其实没有推翻，这都是源于一个好的设计。就是从库依然不能被直接写入。从库在接收到写入命令时候，把自己接收到的SQL，先发给主库，主库执行完毕，再提交给从库。等于多了一个回合。

这样的设计，让使用者没有感到不适，又保证了数据的一致性，两全其美。不得不说这个是设计的精妙，不得不佩服产品设计人员和实现的方式。

这个特性叫做ADG的重定向或者说DML重定向，我们来实践一下。

这个特点由一个参考控制。打开这个参数，如图1

show parameter adg_redirect_dml

我这里是已经打开了，默认是FALSE，如果没有打开执行

alter system set adg_redirect_dml = true scope = both;

这里的adg1表示主库

                                                                图1

说明一下，可以执行scope=both的话，说明这个参数的开启不用重启数据库实例。

我们登录从库的一个PDB，启动DML重定向。如图2. 这里的ADG2是从库。用户名xxg是我xuexiaogang的缩写，密码也是xxg PDB的名字是p1,在会话级别打开DML重定向。alter session enable adg_redirect_dml;

                                                                 图2

顺便检查一下现在数据库的角色，select open_mode,database_role from v$database; 看到PHYSICAL STANDBY是说明是在从库上。

如果是在主库上，那么角色应该是如图3

                                                                  图3

                                                                        图4

接下来，在主库上写入数据。如图4.

然后到从库上看数据已经同步过来。如图2.

                                                                            图5

接下来，我们在从库修改数据，看看主库能不能一起发生改变。

图6中在从库发起来一次insert和一次update。

                                                        图6

那么看看主库现在的情况。如图7

                                                图7

    实验完毕，这个很简单。不过要说明的是，这个场景一定是使用在偶尔写入的场景。因为它比起直接写入多了一个来回，有一定的延迟，虽然是毫秒级别的，但是也是延迟。直接写主库可能能达到每秒1万次的话，这样通过DML重定向可能只能写1千次，当然这和机器配置网络条件都有关系，在不同硬件条件下的数据不一样。可能衰减没有10倍，也可能大约10倍。一切都要以具体环境而论，使用场景上，一定是偶尔写入，而不是去当做正常的主力写入。