DBAsupport.com Forums - Powered by vBulletin
Results 1 to 9 of 9

Thread: ARC0: terminating instance due to error

  1. #1
    Join Date
    Sep 2001
    Location
    Düsseldorf, Germany.
    Posts
    588

    Question

    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]

  2. #2
    Join Date
    Mar 2000
    Location
    CA
    Posts
    317
    Check for permissions on that drive. Probably this could be the reason.
    Thanks
    Kishore Kumar

  3. #3
    Join Date
    Jul 2002
    Posts
    132
    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;

  4. #4
    Join Date
    Apr 2001
    Location
    London
    Posts
    725
    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



    Once you have eliminated all of the impossible,
    whatever remains however improbable,
    must be true.

  5. #5
    Join Date
    Dec 2001
    Location
    UK
    Posts
    1,684
    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
    Tim...
    OCP DBA 7.3, 8, 8i, 9i, 10g, 11g
    OCA PL/SQL Developer
    Oracle ACE Director
    My website: oracle-base.com
    My blog: oracle-base.com/blog

  6. #6
    Join Date
    Sep 2001
    Location
    Düsseldorf, Germany.
    Posts
    588
    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

  7. #7
    Join Date
    Sep 2001
    Location
    Düsseldorf, Germany.
    Posts
    588
    Where can I find patches information???

    Sameer

  8. #8
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    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.
    Jeff Hunter

  9. #9
    Join Date
    Sep 2001
    Location
    Düsseldorf, Germany.
    Posts
    588
    :-) 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


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width