从Oracle9i开始支持逻辑Standby，通过logminer从日志中挖掘出sql语句重新在备库应用，来达到主备库数据冗余的目的。由于逻辑备库在应用sql的同时是处于open状态了，那么除了可以利用其冗余数据的特性来做冗灾之外，考虑得更多的可能是利用其做为报表查询库，或者做为读写分离的一种解决方案来分担整个系统的负载，可以充分利用做为备库的主机和存储资源。但是9i的逻辑备库有很多不成熟的地方，实际使用的案例也不多。Oracle10g对于Data Guard在易用性和稳定性方面做出了不少的改进。本系列文章打算简单介绍一下10gR2的逻辑备库。

逻辑备库的架构说起来十分的简单，首先利用主库的一个备份来建立逻辑备库，然后主库将日志传递到备库，备库利用logminer从主库的日志中解析出主库所执行过的SQL，然后重新跑一边，从而使得主备库的数据一致。由于Oracle的联机日志是半逻辑半物理结构，所以从日志中解析出来的SQL，只是逻辑上和主库上的等效，而不是完全相同的语句。比如主库执行一条insert语句插入了10条记录，在备库解析出来将是10条insert语句，每条语句插入一条记录。

逻辑备库需要一系列的进程来完成日志的捕获和应用工作。

执行捕获任务的进程主要有：

• 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视图中获得他们的信息 ，

通过v$logstdby_stats视图可以查看逻辑备库的一些统计信息 。

            逻辑备库只是对于主库的一个逻辑意义上的数据冗余，不像物理备库能够在block级别上和主库保持一致。所以有其优点，也有其缺点。比如主库的一个datafile损坏，可以从物理备库拷贝对应的文件过来然后recover datafile就可以恢复，逻辑备库则无法实现这样保护了。由于是SQL APPLY，对于一些数据类型也是有限制的。

不支持的数据类型

Oracle10gR2的logical standby已经能支持大多数的数据类型了，包括CLOB/BLOB/LONG等，但还是有几种类型是不支持的。如果主库中有使用到这些数据类型，则需要使用其他方式进行处理。

BFILE
Collections (including VARRAYS and nested tables)
Encrypted columns
Multimedia data types (including Spatial, Image, and Context)
ROWID, UROWID
User-defined types
XMLType

可以通过查询DBA_LOGSTDBY_UNSUPPORTED视图来查看当前库中是否有table包含了这些不支持的数据类型

摘录自 http://www.ningoo.net/html/2007/oracle10gr2_logical_standby_concept_and_theory.html