通常来讲逻辑备库可为业务提供报表查询来分担主库上的查询压力，而逻辑备库数据同步的缓慢也在一 定程度上影响了用户的正常使用。至于什么样的备库才认为是数据同步缓慢呢,笔者认为这和业务人员对逻辑备库的需求相关，因人而异。下面从几个方面来描述， 如何排查逻辑备库数据同步缓慢的问题。
a) 检查所有的日志是否同步到逻辑备库中
1.确认主库是否配置正确的远程归档路径。例如
log_archive_dest_2="SERVICE=stby LGWR"
log_archive_dest_n的配置可参考
http://czmmiao.iteye.com/blog/1311070
2.确认成功归档到远程归档路径
在主库上进行日志切换后进行如下查询。
SQL> select dest_id "id",
???? status "db_status",
???? destination "Archive_dest",
???? error "Error"
???? from v$archive_dest;
如果远程归档路径没有成功归档，那么上述查询将会显示出错误信息，应从以下几方面进行排查：
检查tnsnames.ora中是否正确配置网络服务名。
检查LOG_ARCHIVE_DEST_n中的网络服务名是否正确配置
检查LOG_ARCHIVE_DEST_STATE_n是否为enable，而不是defer等参数。
检查listener.ora是否正确配置，监听是否启动，逻辑备库是否启动
检查逻辑备库是否被正确创建
检查逻辑备库上的standby_archive_dest路径下是否有最新的归档日志，如果没有配置standby_archive_dest，则到归档路径下查找在逻辑备库上执行如下查询
3.确认逻辑备库的日志应用进程是否正在运行，在逻辑备库上执行如下查询
SQL> select pid, type, status, high_scn
???? from v$logstdby;
仔细关注下HIGH_SCN列，看是否在主库进行归档后的每次查询时都会发生变化，如果没有则说明未启用日志应用进程。
启用逻辑备库上的日志应用即可
SQL> alter database start logical standby apply;
b) 日志gap
逻辑备库上执行如下查询
SQL> select applied_scn,newest_scn from dba_logstdby_progress;
APPLIED_SCN NEWEST_SCN
----------- ----------
???? 162497???? 162497
该查询需多次执行以确认是否正常同步。如果查询结果中 NEWEST_SCN和 APPLIED_SCN一致，说明逻辑备库已经应用了所有接收到的日志。如果不一致，可在主库上执行，如下SQL ，确认是否有日志GAP产生，备库上缺少的是哪些日志文件
SQL> select thread#,sequence#,first_change#
???? from v$archived_log
???? where first_change# > &newest_scn_from_standby;

?? THREAD#? SEQUENCE# FIRST_CHANGE#
---------- ---------- -------------
???????? 1???????? 87??????? 163232
???????? 1???????? 88??????? 163235
从上述查询中可得，产生了GAP，备库上缺失的日志未thread 1的87、88号日志文件。确认远程归档路径是否正确
SQL> select dest_id,target,db_unique_name,status
???? from v$archive_dest
???? where target='STANDBY';

?? DEST_ID TARGET? DB_UNIQUE_NAME???????????????? STATUS
---------- ------- ------------------------------ ---------
???????? 1 STANDBY LR12?????????????????????????? ERROR
查询结果表明归档到逻辑备库