oracle DG 归档日志不能应用问题
主库和备库参数文件 密码文件 网络互联 监听器 文件路径都检查好几遍了 没啥问题 日志可以正常从主库传输到备库，
就是不能应用，在主库的警告文件中这样提示着：
Sun May 09 00:12:11 2010
Thread 1 advanced to log sequence 58146
Current log# 2 seq# 58146 mem# 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\CBDB\REDO02.LOG
Current log# 2 seq# 58146 mem# 1: E:\ORACLE\PRODUCT\10.2.0\ORADATA\CBDB\REDO022.LOG
Current log# 2 seq# 58146 mem# 2: E:\ORACLE\PRODUCT\10.2.0\ORADATA\CBDB\REDO0222.LOG
Sun May 09 00:12:32 2010
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 6-105
DBID 3163648218 branch 718483759
Sun May 09 00:16:48 2010
Shutting down archive processes
Sun May 09 00:16:53 2010
ARCH shutting down
ARC2: Archival stopped
大家帮我分析一下哪的问题
主库参数
cbdb.__db_cache_size=1409286144
cbdb.__java_pool_size=16777216
cbdb.__large_pool_size=8388608
cbdb.__shared_pool_size=218103808
cbdb.__streams_pool_size=0
*.audit_file_dest='E:\oracle\product\10.2.0/admin/cbdb/adump'
*.background_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/bdump'
*.compatible='10.2.0.1.0'
*.control_files='E:\oracle\product\10.2.0/oradata/cbdb/\control01.ctl','E:\oracle\product\10.2.0/oradata/cbdb/\control02.ctl','E:\oracle\product\10.2.0/oradata/cbdb/\control03.ctl'
*.core_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.DB_FILE_NAME_CONVERT='E:\oracle\product\10.2.0\oradata\cbdb','E:\oracle\product\10.2.0\oradata\cbdb','G:\oradata','G:\oradata'
*.db_name='cbdb'
*.db_recovery_file_dest='g:\temp'
*.db_recovery_file_dest_size=161061273600
*.db_unique_name='CBDB_P'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=cbdbXDB)'
*.FAL_CLIENT='cbdb_10.78.245.220'
*.FAL_SERVER='cbdb_10.78.173.198'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(cbdb_p,cbdb_s)'
*.log_archive_dest_1='LOCATION=g:\temp VALID_FOR=(all_logfiles,all_roles) db_unique_name=cbdb_p'
*.LOG_ARCHIVE_DEST_2='SERVICE=cbdb_10.78.173.198 ARCH VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=cbdb_s'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='ARC%S_%R.%T'
*.LOG_FILE_NAME_CONVERT='E:\oracle\product\10.2.0\oradata\cbdb','E:\oracle\product\10.2.0\oradata\cbdb','G:\oradata','G:\oradata'
*.nls_language='SIMPLIFIED CHINESE'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.recovery_parallelism=5
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1660944384
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/udump'
备库参数：
cbdb.__db_cache_size=1409286144
cbdb.__java_pool_size=16777216
cbdb.__large_pool_size=8388608
cbdb.__shared_pool_size=218103808
cbdb.__streams_pool_size=0
*.audit_file_dest='E:\oracle\product\10.2.0/admin/cbdb/adump'
*.background_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/bdump'
*.compatible='10.2.0.1.0'
*.control_files='E:\oracle\product\10.2.0/oradata/cbdb/\control01.ctl','E:\oracle\product\10.2.0/oradata/cbdb/\control02.ctl','E:\oracle\product\10.2.0/oradata/cbdb/\control03.ctl'
*.core_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.DB_FILE_NAME_CONVERT='E:\oracle\product\10.2.0\oradata\cbdb','E:\oracle\product\10.2.0\oradata\cbdb','G:\oradata','G:\oradata'
*.db_name='cbdb'
*.db_recovery_file_dest='g:\temp'
*.db_recovery_file_dest_size=161061273600
*.db_unique_name='CBDB_S'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=cbdbXDB)'
*.FAL_CLIENT='cbdb_10.78.173.198'
*.FAL_SERVER='cbdb_10.78.245.220'
*.job_queue_processes=10
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(cbdb_p,cbdb_s)'
*.log_archive_dest_1='LOCATION=E:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS VALID_FOR=(all_logfiles,all_roles) db_unique_name=cbdb_s'
*.LOG_ARCHIVE_DEST_2='SERVICE=cbdb_10.78.245.220 ARCH VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=cbdb_p'
*.log_archive_dest_state_1='enable'
*.log_archive_dest_state_2='enable'
*.log_archive_format='ARC%S_%R.%T'
*.LOG_FILE_NAME_CONVERT='E:\oracle\product\10.2.0\oradata\cbdb','E:\oracle\product\10.2.0\oradata\cbdb','G:\oradata','G:\oradata'
*.nls_language='SIMPLIFIED CHINESE'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.recovery_parallelism=5
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1660944384
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:\oracle\product\10.2.0/admin/cbdb/udump'
[解决办法]
Oracle Data Gurad Physical Standby 相关说明
http://blog.csdn.net/tianlesoftware/archive/2010/05/04/5557410.aspx
用SQL 查看2边的日志是否一致。
select sequence#,applied from v$archived_log;
standby 库上要做2件事，接收log，应用log。 有时候能接收，但是不能应用。 就要看下2边的alert log 日志。 看提示什么信息， Data Guard 找错，2边的log 都要看。
------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
网上资源： http://tianlesoftware.download.csdn.net
相关视频：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
DBA1 群：62697716(满); DBA2 群：62697977
[解决办法]
能同步过去就说明参数没有问题。 现在不能applied。 可能是因为你的数据库copy的时候出现了问题。
比如备库的控制文件中记录的的相关信息和主库的不一致。 造成因缺少归档文件而无法应用。
可以尝试一下方法：
1. 在主库上创建备库的控制文件。
2. 把主库oradata 目录下的所有文件copy 到备库，注意控制文件用自己创建的。
3. 启动备库并开始接收归档
4. 启动主库。
注意的事要先创建文件，还有在此期间主库不要做其他操作。 因为控制文件里记录了一些信息。 在用sql 查看一下，是否能应用。 这样的错误，在备库的alert log 里应该有比较详细的说明。 这只是我个人的猜测。
[解决办法]
FAL Message In Alert.log When No Gap In Standby [ID 601841.1]
--------------------------------------------
Modified 20-APR-2009 Type PROBLEM Status MODERATED
In this Document
Symptoms
Cause
Solution
References
--------------------------------------------
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.3
This problem can occur on any platform.
Symptoms
When using ARCH transport, gaps could be flagged in the alert log even though the single log gap was for a log that had not been written at the primary yet.
alert.log on primary shows:
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 63962-63962
DBID 1243807152 branch 631898097
or alert.log on standby shows:
Fetching gap sequence in thread 1, gap sequence 63962-63962
Thu Jan 24 14:36:30 2008
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 63962-63962
DBID 2004523329 branch 594300676
FAL[client]: All defined FAL servers have been attempted.
v$archive_gap returns no rows
SQL> select * from v$archive_gap;
no rows selected
Cause
Bug 5526409 - FAL gaps reported at standby for log not yet written at primary
Solution
Bug 5526409 is fixed in 10.2.0.4 and 11.1.
Upgrade to 10.2.0.4 as Bug 5526409 is fixed in 10.2.0.4.
Their is no impact of these messages on the database. You can safely ignore these messages.
One-off Patch for Bug 5526409 on top of 10.2.0.3 is available for some platforms. Please check Patch 5526409 for your platform.
References
BUG:5526409 - FAL[CLIENT]: FAILED TO REQUEST GAP SEQUENCE BUT NO GAPS FOUND
PATCH:5526409 - FAL[CLIENT]: FAILED TO REQUEST GAP SEQUENCE BUT NO GAPS FOUND
--------------------------------------------
Related
--------------------------------------------
Products
--------------------------------------------
Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
