-
Hi All,
I have a Primary database running on 8.1.6 in ARCHIVELOG mode.
There is standby database configured for Primary database.
Primary database has three redo logfile with 2 members each located at different drives size 5mb.
I often get following error while redo logs getting arched [/b] and it terminates instance[/b]
I have marked in bold few lines from my alert log file. This also happens if I manually swith log file.
---------------------------------------------------------------------------------
Thread 1 advanced to log sequence 78
Current log# 3 seq# 78 mem# 0: /data/oradata/ora4/redo03.log
Current log# 3 seq# 78 mem# 1: /opt/oracle/data2/ora4/logfile/redo03m.log
Mon Aug 19 14:53:54 2002
ARC0: Beginning to archive log# 2 seq# 77
ARC0: Completed archiving log# 2 seq# 77
Mon Aug 19 15:09:07 2002
Thread 1 advanced to log sequence 79
Current log# 1 seq# 79 mem# 0: /data/oradata/ora4/redo01.log
Current log# 1 seq# 79 mem# 1: /opt/oracle/data2/ora4/logfile/redo01m.log
Mon Aug 19 15:09:07 2002
ARC0: Beginning to archive log# 3 seq# 78
ARC0: RFS network connection lost at host 'STDB'
ARC0: Error 3113 creating standby archivelog file at host 'STDB'
ARC0: Error 3113 creating archivelog file 'STDB'
ARC0: Failed to archive log# 3 seq# 78
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Aug 19 15:09:08 2002
---------------------------------------------------------------------------------
Archive destination also exists ....
Even if I do bulk which is not so big.. say of 4000 records in one go..
by executing insert into x select * from y .. I get error..
---------------------------------------------------------------------------------
Mon Aug 19 15:09:29 2002
ARC0: Beginning to archive log# 3 seq# 78
ARC0: Archiving not possible: No available destinations
ARC0: Failed to archive log# 3 seq# 78
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Aug 19 15:09:29 2002
ORACLE Instance orcl - Archival Error
ARCH: Connecting to console port...
Mon Aug 19 15:09:29 2002
ORA-16014: log 3 sequence# 78 not archived, no available destinations
ORA-00312: online log 3 thread 1: '/data/oradata/ora4/redo03.log'
ORA-00312: online log 3 thread 1: '/opt/oracle/data2/ora4/logfile/redo03m.log'
ARCH: Connecting to console port...
ARCH:
ORA-16014: log 3 sequence# 78 not archived, no available destinations
ORA-00312: online log 3 thread 1: '/data/oradata/ora4/redo03.log'
ORA-00312: online log 3 thread 1: '/opt/oracle/data2/ora4/logfile/redo03m.log'
Mon Aug 19 15:15:53 2002
ORACLE Instance orcl - Can not allocate log, archival required
Mon Aug 19 15:15:53 2002
ARCH: Connecting to console port...
Thread 1 cannot allocate new log, sequence 81
All online logs needed archiving
Current log# 2 seq# 80 mem# 0: /data/oradata/ora4/redo02.log
Current log# 2 seq# 80 mem# 1: /opt/oracle/data2/ora4/logfile/redo02m.log
Mon Aug 19 15:15:53 2002
ARC0: Beginning to archive log# 3 seq# 78
Mon Aug 19 15:15:54 2002
Errors in file /opt/oracle/data2/ora4/bdump/orcl_arc0_880.trc:
ORA-00600: internal error code, arguments: [kcrrmario.1], [], [], [], [], [], [], []
ARC0: terminating instance due to error 600
Instance terminated by ARC0, pid = 880
Mon Aug 19 15:18:09 2002
---------------------------------------------------------------------------------
Please help me to solve problem.
Thanks
Sameer
[Edited by Sameer on 08-19-2002 at 11:47 AM]
-
Check for permissions on that drive. Probably this could be the reason.
-
Have u checked the error in Metalink?
Here it is:
Problem Explanation:
====================
There are a few possible causes:
- The standby database is down or was bounced.
- The listener on the remote host is down
- There was a network problem.
The standby database must be mounted, open in read only, or operating in a
standby database recovery mode for the remote archival functionality to work.
The ARCH process on the primary has lost the Remote File Server
process on the remote host.
Solution Description:
=====================
You need to reactivate the failed destination to resume the automatic archival
process to the standby host. The RFS process will be re-started at the standby
host during the initial connect phase of the archivelog operation.
1) Make sure the standby database is mounted as a standby.
sqlplus> startup nomount pfile="/xx/xx/initSID.ora"
sqlplus> alter database mount standby database
2) Make sure the listener is up on the standby host and listening
for the standby database.
$ lsnrctl start
$ lsnrctl services
3) Reactivate the failed destination.
Reactivate the failed destination by resetting the corresponding destination
state to ENABLE (default). The following will manually reactive a failed
destination that does, or does not have a specified REOPEN value. For example:
sqlplus> alter system set log_archive_dest_state_n = enable
4) Designate a REOPEN value for future destination failures.
REOPEN is an attribute of a LOG_ARCHIVE_DEST_n parameter defined in the primary's
init.ora file. The REOPEN value designates the amount of time (in seconds)
that must elapse before an archivelog operation will attempt to archive to a
failed destination. If a failed destination has no REOPEN attribute value
specified in the LOG_ARCHIVE_DEST_n parameter, then no further attempts to
archive to it will be made, and user action is required to manually reactivate
the failed destination, as described in step 3 above. The following will not
reactivate a failed destination. It will designate a REOPEN value for use
should the destination fail in the future. It's a good idea to have a REOPEN
value set.
sqlplus> alter system set log_archive_dest_n = 'service=XXXX reopen=120'
If a REOPEN attribute value is already set in the primary's LOG_ARCHIVE_DEST_n
parameter, errors against this particular _n destination will be cleared, and
automatic archiving to the destination will continue with no user intervention.
Whether automatically or manually reset, any subsequent log switches on the
primary should now result in successful remote archival. Tail the alert_SID.log
on the primary host to make sure this is happening.
5) Since remote archival has been restarted, redo logs now archived on the
primary will be sent to the standby host. There may however, be one or more
archive logs missing on the standby database; a "gap" in the sequence. You must
use manual recovery on the standby to bridge the gap, then resume sustained
recovery.
a) Review v$log_history of both primary and standby or look in the archive
destinations to see what archive logs are missing.
b) Manually transfer the missing archive logs to the standby host.
c) Apply the missing archive logs manually using:
sqlplus> recover standby database;
NOTE: You must use manual recovery because the remote archival process
has not updated the standby database controlfile for the missing archive
logs, so sustained recovery mode would not "see" the archive files.
d) When application of the missing archive logs is complete, resume sustained
recovery:
sqlplus> recover managed standby database;
-
Hi,
I had the same problem in 8.1.6, my primary instance was terminated every 2/3 days with this problem.
I logged the call with metalink and was pointed to a bug in 8.1.6.
The solution is to upgrade to 8.1.7 or patch 8.1.6.
Suresh
-
I had loads of problems with Standby Server using 8.1.6. After a number of patches that failed to fix all the problems I moved to 8.1.7 and everything worked properly.
Cheers
-
Thanks for the replies..
Will you please let me know where can I find details of patches I need to apply?.. Because I am not sure whether we will upgrade to 8.1.7 soon.. so for the timebeing I will try applying patches..
Please tell me which patches I need to apply..
Thanks
Sameer
-
Where can I find patches information???
Sameer
-
Patches are at http://ap103aru.us.oracle.com/quicklinks/server.html
Since 8.1.6 has been desupported, I don't see any reason why NOT to upgrade to 8.1.7.4.
-
:-) Just got sign of life from my manager..
will be upgrading to 8.1.7
am dragging too much now for this point..
How do I upgrade my database to 8.1.7, do I need to rebuild it again?
Sameer