由于逻辑Standby是通过SQL应用来保持与Primary数据库的同步。SQL应用与REDO应用是有很大的区别，REDO应用实际上是在物理Standby端进行RECOVER；SQL应用则是分析重做日志文件中的REDO信息，并将其转换为SQL语句，在逻辑Standby端执行，因此，需要注意以下几点：
BINARY_DOUBLE、BINARY_FLOAT、BLOB、CHAR、CLOB and NCLOB、 DATE、INTERVAL YEAR TO MONTH、INTERVAL DAY TO SECOND、 LONG、LONG RAW、NCHAR、NUMBER、NVARCHAR2、RAW、TIMESTAMP、
TIMESTAMP WITH LOCAL TIMEZONE、TIMESTAMP WITH TIMEZONE、VARCHAR2 and VARCHAR
说明：下列类型在获取Standby支持时需要注意兼容性：
CLOB，需要Primary数据库的兼容级别运行于10.1或更高。
含LOB字段的索引组织表（IOT），需要Primary数据库的兼容级别运行于10.2或更高。
不含LOB字段的索引组织表（IOT），需要Primary数据库的兼容级别运行于10.1或更高。
BFILE、Encrypted Columns、ROWID, UROWID、XMLType、对象类型、VARRAYS、嵌套表、自定义类型。
也可以通过查询DBA_LOGSTDBY_UNSUPPORTED来确定主数据库中是否含有不支持的对象
SQL> select * from dba_logstdby_unsupported;
注意：该视图的ATTRIBUTES列，显示对象不被SQL应用支持的原因。
逻辑Standby能够支持簇表（Cluster Tables）、索引组织表（Index-Organized Tables）、堆组织表（Heap-Organized Tables），但不支持段压缩（Segment Compression）存储类型。
通常那些不会修改系统元数据（Metadata）的Package在实际应用时不会有问题，如DBMS_OUTPUT、DBMS_RANDOM、DBMS_METADATA之类的包。
，即使它们在Primary执行过，并且被成功传输到逻辑Standby端，也不会执行。如DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_REDEFINITION、DBMS_SCHEDULER及DBMS_AQ等。只有DBMS_JOB例外，Primary数据库的jobs会被复制到逻辑Standby，不过在逻辑Standby数据库不会执行这些job。
元数据，直接理解成对象的物理定义。举例来说，对于某表而言，元数据就是表结构，或表的存储属性等。
在默认情况下，下列SQL语句在逻辑Standby端会被SQL应用自动跳过：
ALTER DATABASE。
ALTER MATERIALIZED VIEW。
ALTER MATERIALIZED VIEW LOG。
ALTER SESSION。
ALTER SYSTEM。
CREATE CONTROL FILE。
CREATE DATABASE。
CREATE DATABASE LINK。
CREATE PFILE FROM SPFILE。
CREATE MATERIALIZED VIEW。
CREATE MATERIALIZED VIEW LOG。
CREATE SCHEMA AUTHORIZATION。
CREATE SPFILE FROM PFILE。
DROP DATABASE LINK。
DROP MATERIALIZED VIEW。
DROP MATERIALIZED VIEW LOG。
EXPLAIN。
LOCK TABLE。
SET CONSTRAINTS。
SET ROLE。
SET TRANSACTION。
另外，由于SQL语句非常灵活，即使是那些能被SQL应用支持的DDL语句，可能在附加了某些特别的参数后，也不会在逻辑Standby端执行，由于数目较多，此处不再一一列举，感兴趣的话请查阅官方文档。
维护逻辑Standby与Primary的数据库同步是通过SQL应用实现，SQL应用转换的SQL语句在执行时，对于INSERT还好说，对于UPDATE、DELETE操作则必须能够唯一定位到数据库待更新的那条记录。问题就在这里，如果Primary库中表设置不当，可能就无法确认唯一条件。
你可能会说可以通过ROWID唯一嘛！千万要谨记啊，逻辑Standby，为啥叫逻辑Standby，就是因为它只是逻辑上与Primary数据库相同，物理上可能与Primary数据库存在相当大差异。一定要认识到，逻辑Standby的物理结构与Primary是不相同的（即使初始逻辑Standby是通过Primary的备份创建）。
因此想通过ROWID更新显然是不好使的，当然也就不能再将其作为唯一条件。下面来看这个问题。
Oracle通过主键、唯一索引/约束的来确定待更新逻辑Standby数据库中的行。当数据库启用了补充日志，每一条UPDATE语句写REDO的时候会附加列值唯一信息，比如：
，则主键列会随同被更新列一起作为UPDATE语句的一部分，以便执行时区分哪些列应该被更新。
，则非空的唯一索引/约束会随同被更新列作为UPDATE语句的一部分，以便执行时区分哪些列应该被更新，如果该表有多个唯一索引/约束，则Oracle自动选择长度最短的那个，以降低生成的重做日志大小。
，所有可定长度的列，连同被更新列同时作为UPDATE语句的一部分。更明确些，可定长度的列是指除LONG、LOB、LONG RAW、OBJECT TYPE、COLLECTION类型外的列。
Oracle 建议你为表创建一个主键或非空的唯一索引/约束，以尽可能确保SQL应用能够有效应用REDO数据，更新逻辑Standby数据库。
下列语句可以用来检查SQL应用能否唯一识别表列，并找出不被支持的表：
SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER, TABLE_N
AME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED)
AND BAD_COLUMN = 'Y';
OWNER TABLE_NAME
----- ---------------
TSMSY SRS$
: 关于, 该视图。如果表中的列包括足够多的信息，通常也可支持在逻辑Standby端的更新，不被支持的表通常是由于列的定义包含了不支持的数据类型。
注意值，该列有两个值：
该表中有采用大数据类型的字段，比如LONG、CLOB。如果表中除LOG列某些行记录完全匹配，则该表无法成功应用于逻辑Standby。Standby会尝试维护这些表，不过你必须保证应用不允许。
该表拥有足够的信息，能够支持在逻辑Standby的更新，不过仍然建议你为该表创建一个主键或者唯一索引/约束，以提高LOG应用效率。
假设在某张表中你可以确认数据是唯一的，但是基于效率方面的考虑，不想为其创建主键或唯一约束，怎么办呢？没关系，Oracle早想到了这一点，你可以创建一个：
如果DBA能够确认表中的行是唯一的，那么可以为该表创建Rely的主键，Rely约束并不会造成系统维护主键的开销，如你对一个表创建了RELY约束，系统则会假定该表中的行是唯一的，这样能够提高SQL应用时的性能。但是需要注意，由于Rely的主键约束只是假定唯一，如果实际并不唯一的话，有可能会造成错误的更新哟。
创建Rely的主键约束非常简单，只要在标准的创建语句后加上RELY DISABLE即可，例如：
SQL> ALTER TABLE USER ADD PRIMARY KEY (ID) RELY DISABLE;
表已更改。
创建逻辑Standby数据库的第一步就是先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。在将其转换为逻辑Standby前，可以随时启动REDO应用，不过一旦决定将其转换为逻辑Standby，就必须先停止该物理Standby的REDO应用，以避免提前应用含LogMiner字典的REDO数据，造成转换为逻辑Standby后，SQL应用时LogMiner字典数据不足而影响到逻辑Standby与Primary的正常同步。
在创建物理Standby数据库时曾经设置过相关数量的初始化参数，用于Primary数据库与物理Standby的角色切换，对于逻辑Standby的角色切换，那些参数同样好使。
不过注意，如果希望Primary数据库能够正常切换为逻辑Standby角色，那么DBA在配置环境时，还需要设置相应的LOG_ARCHIVE_DEST_n初始化参数，并注意该参数的VALID_FOR属性值需要更改成STANDBY_LOGFILES,STANDBY_ROLE。
完成对初始化参数的配置后，必须在Primary数据库端生成LogMiner字典信息，例如：
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
该过程专门用于生成记录的元数据信息到重做日志文件，逻辑Standby未来正是通过这些元数据保持与Primary数据库的同步。
该过程会自动启用Primary数据库的补充日志（Supplemental Logging）功能（如果未启用的话）。
该过程需要等待当前所有事务完成后才能执行，因此如果当前有较长的事务运行，可能该过程的执行也需要多花一些等待时间。
该过程是通过闪回查询的方式来获取数据字典的一致性，，建议设置为3600，并且UNDO表空间也要有足够的空间。
执行下列语句，转换物理Standby为逻辑Standby：
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY DB_NAME;
，不同于物理Standby，，因此建议你指定一个唯一的与Primary不同的数据库名。另外如果当前准逻辑Standby使用SPFILE启动数据库，那么执行该语句时Oracle会自动修改SPFILE中的相关信息，如果使用PFILE启动数据库，那么在下次执行SHUTDOWN的时候，Oracle会提示你去修改DB_NAME初始化参数的值。
。这并不仅仅是因为DB_NAME发生了修改，更主要的原因是逻辑Standby仅是数据与Primary一致，其他如存储结构、SCN等，甚至DBID都不相同。
执行转换的过程中，需要应用全部的与LogMiner字典相关的REDO数据。这部分操作完全依赖于Primary数据库DBMS_LOGSTDBY.BUILD的执行，以及传输到Standby数据库端，需要应用的数据量的规模而定。如果Primary数据库执行DBMS_LOGSTDBY.BUILD失败，则转换操作也不会有结果，这时候你恐怕不得不先cancel它，解决Primary数据库的问题之后再尝试执行转换。取消该操作与取消REDO应用一样，当然实际上，也正是取消REDO应用。
主要是由于转换操作修改了数据库名，因此密码文件也需要重建，这个操作我们做得比较多，这里就不详述了。
[oracle@localhost dbs]$ orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=admin
如果已经存在，就不用创建了。 缺省情况下，win下口令文件的格式是pwdsid.ora，unix下的格式是orapwSID(大小写敏感）
之所以要调整初始化参数，一方面是由于此处我们的逻辑Standby是从物理Standby转换来的，某些参数并不适合，甚至可能造成错误，如LOG_ARCHIVE_DEST_n参数的设置。另一方面，由于逻辑Standby默认是以OPEN READ WRITE模式打开，有可能存在读写操作，因此会读写本地Online Redologs并产生Archive Logs，务必需要注意本地的Archive Logs路径，不要与接收自Primary数据库的重做日志文件路径冲突。
当然归根结底是因为逻辑Standby是从物理Standby转换而来，因此Standby的初始化参数就需要第二次调整（第一次是创建物理Standby）。
修改初始化参数的方式有多种，既可以通过ALTER SYSTEM命令，也可以先生成PFILE并修改相关参数，然后再根据修改过的PFILE生成SPFILE。
由于逻辑Standby与Primary数据库事务并不一致，其实质相当于进行了不完全恢复，因此第一次打开时必须指定RESETLOGS子句，如下：
SQL> ALTER DATABASE OPEN RESETLOGS;
在逻辑Standby端启动SQL应用，可以通过下列语句进行：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
逻辑Standby也可以像物理Standby那样启用实时应用，只需要在启动REDO应用时附加IMMEDIATE子句即可，如：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
如果想停止逻辑Standby数据库的SQL应用，则可通过下列命令进行：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY IMMEDIATE;
关于Logical Standby 完成创建实例及主备切换，请参考blog：
Oracle Data Guard Linux 平台 Logical Standby 创建实例
http://blog.csdn.net/tianlesoftware/archive/2010/05/06/5564179.aspx
可以把该视图看成逻辑Standby操作日志，因此如果发生了错误，可以通过该视图查看近期逻辑Standby都做了些什么。默认情况下，该视图只保留最近100条事件的记录（可以通过相关过程修改保存的记录条数）。
例如：
SQL> SELECT EVENT_TIME,STATUS,EVENT FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;
EVENT_TIM STATUS EVENT
--------- -------------------------------------------------- -------------------
05-MAY-10 ORA-16111: log mining and apply setting up
05-MAY-10 ORA-16257: Switchover initiated stop apply success
该视图用来记录当前的重做日志的应用情况，功能类似于物理Standby中的V$ARCHIVED_LOG。
多数情况下，你只需要关注SEQUENCE#、APPLIED等有限的几个列，即查看日志序号和是否应用，当然该视图还能提供更多信息，如应用的SCN、应用时间等，例如：
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,
TIMESTAMP,APPLIED FROM DBA_LOGSTDBY_LOG;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# TIMESTAMP APPLIED
---------- ------------- ------------ --------- --------
110 572160 572171 05-MAY-10 CURRENT
111 572171 572175 05-MAY-10 NO
通常情况下，该查询只会返回几条记录，如果说你的数据库操作非常频���，可能记录数会稍多一些，但如果记录数非常多，那你就需要关注一下，是不是出了什么问题，难道SQL应用没有启动？
该视图就是用来显示LogMiner的状态等相关信息，例如：
SQL> 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
该视图显示当前日志应用服务的相关信息。常用于诊断归档日志逻辑应用的性能问题（后面优化部分会涉及），包含的信息也很广，包括：
SID、SERIAL#、SPID。
COORDINATOR、READER、BUILDER、PREPARER、ANALYZER、或APPLIER。
：见STATUS_CODE或STATUS列。
：HIGH_SCN列。
例如：
SQL> SELECT SID,SERIAL#,SPID,TYPE,STATUS,HIGH_SCN FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE STATUS
---------- ---------- ------------ --------------- -----------------------------
139 303 6831 COORDINATOR ORA-16116: no work available
153 292 6833 READER ORA-16240: Waiting for logfil
136 5 6835 BUILDER ORA-16116: no work available
137 5 6837 PREPARER ORA-16116: no work available
128 1 6841 ANALYZER ORA-16116: no work available
132 1 6843 APPLIER ORA-16116: no work available
133 2 6845 APPLIER ORA-16116: no work available
130 1 6847 APPLIER ORA-16116: no work available
129 1 6849 APPLIER ORA-16116: no work available
131 1 6851 APPLIER ORA-16116: no work available
该视图显示LOG应用服务当前进展状况，如当前应用到逻辑Standby的SCN及时间，SQL应用开始应用的SCN及时间，最后接收及应用的SCN和时间等。
例如，查看当前应用的SCN信息：
SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN
----------- ---------- ---------- -----------
572164 572232 572166
该视图显示SQL应用的大致状态，如Primary数据库的DBID，是否实时应用，当前SQL应用的状态。。应用日志的过程，也是这几种状态相互转换的过程。
执行ALTER DATABASE START LOGICAL STANDBY APPLY语句，启动SQL应用时，首先就会进入初始化状态，例如：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- ------------------------------
21 INITIALIZING
这个状态存在的时间非常短暂，多数情况下只有当ALTER DATABASE START LOGICAL STANDBY APPLY执行时查看V$LOGSTDBY_STATE视图，会看到初始化状态，一旦该命令执行完，状态就被切换为等待字典日志或应用中的状态了。
指第一次初始化时的状态，如刚从物理Standby转换成逻辑Standby，需要首先应用来自Primary端生成的数据字典，在等待Primary数据字典信息时，就会处于这一状态。例如：
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- ------------------------------
21 WAITING FOR DICTIONARY LOGS
这个过程也非常短暂。
当查询V$LOGSTDBY_STATE视图，显示下列状态时，说明处于加载数据字典的状态：
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- ------------------------------
21 LOADING DICTIONARY
对于比较大型的数据库系统，加载数据字典需要一些时间。此时还可以查询V$lOGMNR_DICTIONARY_LOAD视图获取关于加载的更详细的信息，例如：
SQL>SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD
WHERE SESSION_ID =(SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
APPLYING应用REDO数据。
SQL应用正在处理中，如果要查看当前的处理进度，可以通过V$LOGSTDBY_PROGRESS视图完成。
SQL应用挖掘并应用了所有可用的REDO数据，正等待新的日志文件，也有可能是由于归档文件有中断造成的。如果查询V$LOGSTDBY_STATE视图时发现处于这一状态，应该同时查询V$ARCHIVE_GAP视图，检查是否有中断的归档。
处于这一状态也有可能不是好现象，一方面可能是逻辑Standby处理能力优秀，所有活都干完了；也可能是Primary数据库发送日志或逻辑Standby日志出现了问题，导致SQL应用无活可干，因此处于空闲状态。
如果你发现你的逻辑Standby数据库长期处于这一状态，建议查询DBA_LOGSTDBY_LOG视图，确认Primary端产生的日志文件能被逻辑Standby数据库正常接收。
如果你查询V$LOGSTDBY_STATE视图时发现提示这一状态，说明逻辑Standby数据库根本没启动SQL应用。