http://blog.itpub.net/23135684/viewspace-703620/sql
Alert.log shows No Standby Redo Logfiles Of Size 153600 Blocks Available [ID 405836.1] | |||||
|
|||||
修改時間 05-APR-2011 類型 PROBLEM 狀態 PUBLISHED |
In this Document
Symptoms
Cause
Solution
session
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.5 - Release: 10.1 to 10.2
Information in this document applies to any platform.
***Checked for relevance on 05-APR-2011***oracle
After real time apply works within 24hrs
the following error occurs.
app
Checking the standby logs on standby database, all SRLs are ACTIVE dated from weeks ago- normally we see 1 used for 1 thread and the others will be UNASSIGNED
fetch
In Dec1 SRLs created on LG were not archived/stuck and hence remained ACTIVE and could not longer be assigned. At the that time we see that Primary was archiving every minute and only 1 ARCH available to archive to standby. From standby log_archive_max_processes was set to 2, hence only 1 ARCH archiving Locally and most likely unable to cope with the amount of archiving required.
ui
1. On Standby/Primary set log_archive_max_processes=10
this
OR
2. Another way around this if the logs have been applied as they have in this case, the old standby logs
can be dropped and recreated to clear the problem.
spa
<logfile_name><logfile_name>
.net
#########################################################rest
報錯 :
Sun Oct 21 04:39:06 CST 2018
FAL[client]: Failed to request gap sequence
GAP - thread 2 sequence 101986-101989
解決方法1:
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_101986_fwps5fbo_.arc';
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_101988_fwps7ntp_.arc';
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_101987_fwps7o6j_.arc';
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_101989_fwpsg14g_.arc';
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_102004_fwq5wq6m_.arc';
ALTER DATABASE REGISTER LOGFILE '/tmp/dba/1/o1_mf_2_102005_fwq5wx6s_.arc';
解決方法2:
You could see different symptoms. For example, you get fal archive error as the primary arch process sticks and it doesn't ship the missing archive log files to the standby. The worst case you see is all arch processes stick and no one does local archiving and all online redo log files are full and that causes the primary database hangs. Please see the following errors related to this cause.
Mon Oct 22 13:30:44 CST 2018 <- RFS fetch gap begin failed
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 100641-100641
DBID 2583306402 branch 777418146
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
Mon Oct 22 13:32:44 CST 2018 <- find the reason is network disconnet
RFS[342]: Possible network disconnect with primary database
Mon Oct 22 13:32:46 CST 2018
RFS[341]: Possible network disconnect with primary database
Mon Oct 22 13:52:16 CST 2018 <- after 30 minutes ,RFS retry .
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[350]: Assigned to RFS process 23920798
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 2262-2266
DBID 2591313681 branch 686760021
FAL[client]: All defined FAL servers have been attempted.
SQL> alter session set nls_date_format='YYYY-MON-DD HH24:MI:SS';
SQL> select message, timestamp
from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp;
MESSAGE
-------------------------------------------------------------------------------
TIMESTAMP
--------------------------
Error 12154 received logging on to the standby
OCT-12-2010 15:55:45
PING[ARC1]: Heartbeat failed to connect to standby 'STDBY'. Error is 12154.
OCT-12-2010 15:55:45
in primary :
This won't harm your primary database at all as arch processes will be respawned automatically immediately by Oracle.
% ps -ef |grep -i arc
% kill -9 <ospid of arc process> <ospid of arc process> <ospid of arc process>...
% ps -ef |grep -i arc
(new arch process will respawned quickly,monitor)
NOTE: If you are on Windows Platform you can use either 'orakill'-Command or any OS-Tool to kill Windows Processes/Threads
sqlplus / as sysdba
alter system switch logfile;
in standby db:
just cancle mrp and restart standby instance.