注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

常在心

淡泊明志,人生自在

 
 
 

日志

 
 

No standby redo logfiles available for thread  

2012-06-27 10:37:57|  分类: ORACLE BUG |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Error At Standby Database Ora-16086: Standby Database Does Not Contain Available Standby Log Files [ID 1155773.1]

 Modified 03-MAY-2011     Type PROBLEM     Status PUBLISHED 

In this Document
  Symptoms
  Cause
  Solution
  References


Applies to:

Oracle Server - Enterprise Edition - Version: 9.0.1.0 to 11.2.0.2   [Release: 9.0.1 to 11.2]
Information in this document applies to any platform.
This affects data guard physical standby database from 9i to 11g.

Symptoms

You observe the error below in the physical standby alert.log:

 ORA-16086: standby database does not contain available standby log files.

 
Archived logs are applied to standby, but error appears every time log switch happens.

The standby is in-sync with the primary database.

Thread     Last Seq Received Last Seq Applied 
---------- ------------------- ---------------- 
1              27646                    27646

The standby redo log file size on the standby is the same as the primary online redo log file size.

On physical standby:

select group#,sequence#,bytes,used,archived,status from v$standby_log; 

GROUP# SEQUENCE# BYTES USED ARC STATUS 
---------- ---------- ---------- ---------- --- ---------- 
4 24531 52428800 43322368 NO ACTIVE 
5 24530 52428800 75776 NO ACTIVE 
6 24532 52428800 43310080 NO ACTIVE 
7 24533 52428800 43310080 NO ACTIVE

On primary:

SQL> select group#,thread#,sequence#,bytes,archived,status from v$log; 

GROUP# THREAD# SEQUENCE# BYTES ARC STATUS 
-------- -------- --------- -------- --- ---------------- 
1 1 27646 52428800 YES ACTIVE 
2 1 27645 52428800 YES INACTIVE 
3 1 27647 52428800 NO CURRENT

Cause

1. All standby redo log groups on the standby database are active and no one is available for overwritten.


select group#,sequence#,bytes,used,archived,status from v$standby_log; 

GROUP# SEQUENCE# BYTES USED ARC STATUS 
---------- ---------- ---------- ---------- --- ---------- 
4 24531 52428800 43322368 NO ACTIVE 
5 24530 52428800 75776 NO ACTIVE 
6 24532 52428800 43310080 NO ACTIVE 
7 24533 52428800 43310080 NO ACTIVE

That's why you got the error ORA-16086: standby database does not contain available standby log files.

2. The frequent log switch on the primary database could cause the standby redo log groups on the standby database to be filled up quickly before anyone completes archiving.

3. BUG7159505 11.1.0.7 RDBMS 11.1.0.7 DATAGUARD_TRAN PRODID-5 PORTID-46 
Abstract: PHSB: PARTIAL SRLS DON'T GET PURGED WHEN NO RECOVERY AREA SPACE LEFT 
It is fixed in 10.2.0.4.1, 11.2 and is included in 10.2.0.5.

Solution

Solution 1:

1. Cancel managed recovery on the standby.

SQL>recover managed standby database cancel;

2. Clear the standby redo log groups as all those sequence# 24530, 24531, 24532, 24533 had been applied. Even they are not applied yet, the gap could be resolved through fal archiving.

SQL>alter database clear logfile group 4; 
SQL>alter database clear logfile group 5; 
SQL>alter database clear logfile group 6; 
SQL>alter database clear logfile group 7;

 

Solution 2:

Increasing the online redo log file size on the primary database and increasing the standby redo log file size on the standby database. Please make sure the size of the standby redo log file size is the same as the primary online redo log file size.

You may also consider to create more online redo logs / standby redo logs-groups on primary/standby.

You can get more details in fallowing documents linked below.

Solution 3:

Please apply the fix of bug 7159505 or upgrade your primary and standby databases to the release or patchset that contains the fix.

References

NOTE:1035935.6 - Example of How To Resize the Online Redo Logfiles
NOTE:7159505.8 - Bug 7159505 - Standby MRP stuck when no recovery area space left
NOTE:740675.1 - Online Redo Logs on Physical Standby


注:此错误不影响日志的应用,不过standby日志不能实时应用,这个是由于primary db的日志切换太频繁造成的。我试过solution1和2,但问题仍然存在,但没有试是否可以升级的方式进行。
  评论这张
 
阅读(1673)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017