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

From: kathryn axelrod <kat.axe_at_gmail.com>
Date: Sat, 21 Nov 2015 17:16:03 -0800
Message-ID: <CAEbHM47TRUW9yGTvVdfcQdayUH9qR+w9HaJuPjEeyLjyQdsNAw_at_mail.gmail.com>

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 Sun Nov 22 2015 - 02:16:03 CET