从Oracle9i开始支持逻辑Standby,通过logminer从日志中挖掘出sql语句重新在备库应用,来达到主备库数据冗余的目的。由于逻辑备库在应用sql的同时是处于open状态了,那么除了可以利用其冗余数据的特性来做冗灾之外,考虑得更多的可能是利用其做为报表查询库,或者做为读写分离的一种解决方案来分担整个系统的负载,可以充分利用做为备库的主机和存储资源。但是9i的逻辑备库有很多不成熟的地方,实际使用的案例也不多。Oracle10g对于Data Guard在易用性和稳定性方面做出了不少的改进。本系列文章打算简单介绍一下10gR2的逻辑备库。
逻辑备库的架构说起来十分的简单,首先利用主库的一个备份来建立逻辑备库,然后主库将日志传递到备库,备库利用logminer从主库的日志中解析出主库所执行过的SQL,然后重新跑一边,从而使得主备库的数据一致。由于Oracle的联机日志是半逻辑半物理结构,所以从日志中解析出来的SQL,只是逻辑上和主库上的等效,而不是完全相同的语句。比如主库执行一条insert语句插入了10条记录,在备库解析出来将是10条insert语句,每条语句插入一条记录。
从上面的描述,我们可以发现逻辑备库和downstream方式的Streams非常的相似,不同的是,Streams可以更灵活,可以方便的过滤数据,也可以在第三方库执行日志解析的工作。但是逻辑备库的实现和维护比起Streams来都要方便很多,因为捕获和应用都是在同一个库中,就不需要使用到AQ(高级队列),从而使得整个数据流变得简单,在高负荷的系统中,越简单的产品越实用。
逻辑备库需要一系列的进程来完成日志的捕获和应用工作。
执行捕获任务的进程主要有:
READER进程从主库传过来的归档或者standby redo logfile中解析重做记录(redo record)
PREPARER进程负责将READER进程解析到的重做记录转换为LCR(Logical change record)。可以开启多个PREPARER进程。解析出来的LCR存放在shared pool的一个叫做LCR cache的区域中。
BUILDER进程将LCR打包成事务。另外还负责管理LCR cache, 执行重启SQL Apply所需要的checkpoint(这个在后面的文章中会介绍),以及过滤不需要数据等任务。
执行应用日志的进程主要有:
ANALYZER进程检查一组LCR中包含的事务片段,过滤掉不需要应用的事务,检查不同事务的依赖关系等
COORDINATOR进程分配事务给APPLIER进程,监控事务依赖关系和协调调度,确认逻辑备库的提交
APPLIER进程将LCR应用到备库,和COORDINATOR进程交互确认事务的依赖关系并提及事务。
上面提到的这些进程,都可以从V$LOGSTDBY_PROCESS视图中获得他们的信息
SYS@standby>select sid,type,status_code,status from v$logstdby_process;
SID TYPE STATUS_CODE STATUS
------- --------- -------- ---------------------------------------------
143 COORDINATOR 16116 ORA-16116: no work available
141 READER 16240 ORA-16240: Waiting for logfile (thread# 1, sequence# 54)
140 BUILDER 16116 ORA-16116: no work available
139 PREPARER 16116 ORA-16116: no work available
137 ANALYZER 16116 ORA-16116: no work available
136 APPLIER 16116 ORA-16116: no work available
135 APPLIER 16116 ORA-16116: no work available
134 APPLIER 16116 ORA-16116: no work available
133 APPLIER 16116 ORA-16116: no work available
132 APPLIER 16116 ORA-16116: no work available
10 rows selected.
呵呵,我的试验库太闲了,除了READER进程在等待主库传日志外,其他的都没事干啦^_^
通过v$logstdby_stats视图可以查看逻辑备库的一些统计信息
SYS@standby>select * from v$logstdby_stats;
NAME VALUE
-------------------------------------------------- ----------
number of preparers 1
number of appliers 5
maximum SGA for LCR cache 30
parallel servers in use 9
maximum events recorded 100
preserve commit order TRUE
transaction consistency FULL
record skip errors Y
record skip DDL Y
record applied DDL N
record unsupported operations N
coordinator state IDLE
transactions ready 8
transactions applied 8
coordinator uptime 410
realtime logmining N
apply delay 0
Log Miner session ID 1
txns delivered to client 1649
DML txns delivered 316
DDL txns delivered 7
CTAS txns delivered 1
Recursive txns delivered 1326
Rolled back txns seen 1
LCRs delivered to client 5762
bytes of redo processed 8944996
bytes paged out 0
seconds spent in pageout 0
bytes checkpointed 0
seconds spent in checkpoint 0
bytes rolled back 0
seconds spent in rollback 0
seconds system is idle 334
33 rows selected.