Re: "ORA-00270: error creating archive log" on Standby Database

From: Ramnivas Chaurasia <ramnivaschaurasia_at_gmail.com>
Date: Tue, 24 Nov 2015 03:42:23 +0530
Message-ID: <CAGwus2UBcJUw3kM1555Ex-M6oiRK473R88Lei9ameCSeD1vUyQ_at_mail.gmail.com>



Hi Kathryn,

These steps seem to be working! I made this change 4 hours back and since then this error is not reported on Standby database. The "ARCH: FAL archive failed. Archiver continuing" from primary has also disappeared!

Thanks a lot for the help!

Regards,
Ramniwas

On Sun, Nov 22, 2015 at 2:47 PM, Ramnivas Chaurasia < ramnivaschaurasia_at_gmail.com> wrote:

> Hi,
>
> For the Step 1, I will perform it tomorrow and will update with the
> result.
>
> For question 2, it does not state any Redo logfile number or name. It
> simply gives the below error. But the logs keep applying.
>
>
> ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not
> known to database.
> ORA-00270: error creating archive log
> ORA-17611: ksfd: file '31' cannot be accessed, global open closed
> *************************************************************
> WARNING: A file of type ARCHIVED LOG may exist in
> db_recovery_file_dest that is not known to the database.
> Use the RMAN command CATALOG RECOVERY AREA to re-catalog
> any such files. If files cannot be cataloged, then manually
> delete them using OS command. This is most likely the
> result of a crash during file creation.
> *************************************************************
>
> Regards,
> Ramniwas
>
>
> On Sun, Nov 22, 2015 at 6:46 AM, kathryn axelrod <kat.axe_at_gmail.com>
> wrote:
>
>> without seeing alert logs -
>> 1. i think unsetting max_connections would be worth a try. note 2042222.1
>> refers to restarting the primary, but i don't think that would be needed..
>> I've also had success with manually setting the log_archive_dest_state to
>> reset when having log issues that a normal standby restart won't fix. So
>> maybe try..
>> -stop recovery
>> -standby shutdown
>> -remove (or change to =1) max_connections from primary's log_archive_dest
>> for the standby
>> -change primary's log_archive_dest_state for the standby destination to
>> 'reset'
>> -standby start
>> -recovery started
>> -change log_archive_dest_state_n back to 'enable'
>>
>> 2. when it reports the ora-00270, does it also say which log it's having
>> issues creating? and does that log already exist/has it been applied?
>>
>>
>> On Sat, Nov 21, 2015 at 10:46 AM, Ramnivas Chaurasia <
>> ramnivaschaurasia_at_gmail.com> wrote:
>>
>>> We have already restarted MRP, restarted the Standby Instance but it
>>> didn't help in getting rid of this error. And yes, logs are getting shipped
>>> and applied on standby database.
>>> I will need to check if I can provide the alert.log.
>>> And, yes, we have set max_connections=8. Could that be an issue? The
>>> same parameter is set on other Standby DBs too and working fine.
>>>
>>> Thanks!
>>> Ramniwas
>>>
>>> On Sat, Nov 21, 2015 at 11:43 AM, kathryn axelrod <kat.axe_at_gmail.com>
>>> wrote:
>>>
>>>> what happens when you stop recovery..shutdown the standby..restart it..
>>>> restart recovery?
>>>> you said logs are continuing to be shipped and all have been applied to
>>>> the standby? if so, can you paste a copy of both the standby and primary
>>>> alert logs from a time period that include these errors?
>>>> bug 17607713 looks similar. is the primary's max_connections more than
>>>> 1?
>>>>
>>>> On Friday, November 20, 2015, Ramnivas Chaurasia <
>>>> ramnivaschaurasia_at_gmail.com> wrote:
>>>>
>>>>> There is no FRA space issue:
>>>>>
>>>>> SQL>
>>>>> SQL> select name, value from v$parameter where
>>>>> name='log_archive_dest_1';
>>>>>
>>>>> NAME VALUE
>>>>> --------------------
>>>>> ----------------------------------------------------------------------------------------------------
>>>>> log_archive_dest_1 LOCATION=USE_DB_RECOVERY_FILE_DEST
>>>>> VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=*removed*
>>>>>
>>>>> SQL> show parameter db_rec
>>>>>
>>>>> NAME TYPE VALUE
>>>>> ------------------------------------ -----------
>>>>> ------------------------------
>>>>> db_recovery_file_dest string +FLASH
>>>>> db_recovery_file_dest_size big integer 5000G
>>>>> db_recycle_cache_size big integer 0
>>>>>
>>>>> SQL> select name, total_mb, free_mb,USABLE_FILE_MB from
>>>>> v$asm_diskgroup;
>>>>>
>>>>> NAME TOTAL_MB FREE_MB USABLE_FILE_MB
>>>>> -------------------- ---------- ---------- --------------
>>>>> DATA 5867232 2467928 2467928
>>>>> FLASH 5867232 4680831 4680831
>>>>> SSD 373502 296541 296541
>>>>>
>>>>> SQL> select * from v$flash_recovery_area_usage;
>>>>>
>>>>> FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE
>>>>> NUMBER_OF_FILES
>>>>> -------------------- ------------------ -------------------------
>>>>> ---------------
>>>>> CONTROL FILE 0 0
>>>>> 0
>>>>> REDO LOG 0 0
>>>>> 0
>>>>> ARCHIVED LOG 22.79 0
>>>>> 482
>>>>> BACKUP PIECE 0 0
>>>>> 1
>>>>> IMAGE COPY 0 0
>>>>> 0
>>>>> FLASHBACK LOG 0 0
>>>>> 0
>>>>> FOREIGN ARCHIVED LOG 0 0
>>>>> 0
>>>>>
>>>>>
>>>>> We had issue with the standby redo Logfiles as the given path didn't
>>>>> exist. We dropped them and re-created with proper path.
>>>>>
>>>>> But the error message still keeps appearing along with below in
>>>>> alert.log.
>>>>>
>>>>>
>>>>> *************************************************************
>>>>> WARNING: A file of type ARCHIVED LOG may exist in
>>>>> db_recovery_file_dest that is not known to the database.
>>>>> Use the RMAN command CATALOG RECOVERY AREA to re-catalog
>>>>> any such files. If files cannot be cataloged, then manually
>>>>> delete them using OS command. This is most likely the
>>>>> result of a crash during file creation.
>>>>> *************************************************************
>>>>> I already checked and there is no file not known to the database. Any
>>>>> idea?
>>>>>
>>>>> Thanks!
>>>>> Ramniwas
>>>>>
>>>>>
>>>>> On Sat, Nov 21, 2015 at 7:59 AM, Mladen Gogala <
>>>>> gogala.mladen_at_gmail.com> wrote:
>>>>>
>>>>>> On 11/19/2015 02:37 PM, Ramnivas Chaurasia wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have been receiving the below error on our standby database
>>>>>> continuously since last 4-5 days.
>>>>>>
>>>>>>
>>>>>> *ORA-00270: error creating archive log ORA-17611: ksfd: file '31'
>>>>>> cannot be accessed, global open closed*
>>>>>>
>>>>>> There is no FRA space issue on Primary as well as Standby Database.
>>>>>> No abnormal shutdown on Standby Instance. Redo logs are still being
>>>>>> applied on Standby.
>>>>>>
>>>>>> Please let me know if anyone has faced similar issue or have come
>>>>>> across solution. We have raised SR with Oracle on same, but have not
>>>>>> progressed much.
>>>>>>
>>>>>> DB Version: EE 11.2.0.3.0 - 64bit Production on AIX
>>>>>>
>>>>>> Thanks!
>>>>>> Ramniwas
>>>>>>
>>>>>>
>>>>>> ORA-00270: error creating archive log %s
>>>>>> *Cause: An error was encountered when either creating or opening
>>>>>> the destination file for archiving.
>>>>>> *Action: Check that the archive destination is valid and that there
>>>>>> is sufficient space on the destination device.
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mladen Gogala
>>>>>> Oracle DBAhttp://mgogala.freehostia.com
>>>>>>
>>>>>>
>>>>>
>>>
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Nov 23 2015 - 23:12:23 CET

Original text of this message