从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 READER16240 ORA-16240: Waiting for logfile (thread# 1, sequence# 54)
140 BUILDER16116 ORA-16116: no work available
139 PREPARER16116 ORA-16116: no work available
137 ANALYZER16116 ORA-16116: no work available
136 APPLIER16116 ORA-16116: no work available
135 APPLIER16116 ORA-16116: no work available
134 APPLIER16116 ORA-16116: no work available
133 APPLIER16116 ORA-16116: no work available
132 APPLIER16116 ORA-16116: no work available
10 rows selected.
呵呵，我的试验库太闲了，除了READER进程在等待主库传日志外，其他的都没事干啦^_^
通过v$logstdby_stats视图可以查看逻辑备库的一些统计信息
SYS@standby>select * from v$logstdby_stats;
NAME VALUE
-------------------------------------------------- ----------
number of preparers1
number of appliers5
maximum SGA for LCR cache 30
parallel servers in use 9
maximum events recorded 100
preserve commit orderTRUE
transaction consistency FULL
record skip errorsY
record skip DDL Y
record applied DDLN
record unsupported operations N
coordinator state IDLE
transactions ready8
transactions applied8
coordinator uptime410
realtime logminingN
apply delay0
Log Miner session ID1
txns delivered to client 1649
DML txns delivered316
DDL txns delivered7
CTAS txns delivered1
Recursive txns delivered 1326
Rolled back txns seen1
LCRs delivered to client 5762
bytes of redo processed 8944996
bytes paged out 0
seconds spent in pageout 0
bytes checkpointed0
seconds spent in checkpoint 0
bytes rolled back 0
seconds spent in rollback 0
seconds system is idle 334
33 rows selected.
