Re: Duplicate for standby fails with ORA-01580, ORA-27040

Neither one of us noticed the typo in the SNAPSHOT CONTROLFILE NAME location in the RMAN configuration on the primary. Corrected that, and the duplicte worked, but is now dying on the recover step with RMAN-11003: failure during parse/execution of SQL statement: alter datbase recover logfile '<archivelog_location_and_name>';

So far not finding the resolution to that error.

Thanks for your help with the first error.

On Mon, Mar 18, 2019 at 7:39 AM Sandra Becker <sbecker6925_at_gmail.com> wrote:

> Thanks for the links in MOS. Got sidetracked with family stuff after I
> posted yesterday, so didn't get as much research done as I would have liked.
>
> I cannot post much more than the error given this is in a secure
> environment and I don't have approval to copy it to a non-secure area and
> post. I realize that makes it difficult for people to give suggestions,
> but it's the constraints I have to work under. The duplicate statement
> was pretty basic: duplicate for standby from active database; do recover
> details for the convert and log_archive statements are in the init.ora
> that I can't share.
>
> Mladen is correct that this is a non-RAC environment. I'll check out the
> links Mladen gave me and work with our sys admins today to see what we can
> find regarding mount options. We did look at permissions last week and
> they match the primary.
>
> Sandy
>
> On Mon, Mar 18, 2019 at 5:16 AM Mladen Gogala <gogala.mladen_at_gmail.com>
> wrote:
>
>> Hi Seth,
>>
>> There are not so many "it depends". The error is very specific:
>>
>> [oracle_at_ora18c ~]$ oerr ora 1580
>> 01580, 00000, "error creating control backup file %s"
>> // *Cause: An operating system error occurred while attempting to create
>> a
>> // control file backup.
>> // *Action: Check the error stack for more detailed information
>> [oracle_at_ora18c ~]$
>>
>> There are exactly 2 possibilities:
>>
>> 1. Storage is at fault. Protection, incorrect NFS options (Sandra has
>> NetApp) or something else.
>> 2. Storage is OK, this is an RMAN bug. By knowing her environment, my
>> conclusion is that this is probably a bug. That is why I checked the MOS
>> page first.
>>
>> If this was RAC, and my understanding is that this isn't RAC, there would
>> be a 3rd possibility: backup of control file is not on the shared storage.
>> That is all.
>>
>> Regards
>> On 3/18/19 6:18 AM, Seth Miller wrote:
>>
>> Sandra,
>>
>> There are so many "it depends" here. The spfile in ASM on the primary
>> likely has nothing to do with the error. It would be more helpful if you
>> posted more details, like the rman command you used, the output of the
>> execution, and the contents of the standby pfile.
>>
>> Seth
>>
>>
>>
>> On Sun, Mar 17, 2019 at 2:22 PM Sandra Becker <sbecker6925_at_gmail.com>
>> wrote:
>>
>>> Scenario: Trying to create a second standby database on a new server
>>> before shutting down old standby - both are physical standbys
>>> Oracle EE 11.2.0.4, RHEL6
>>>
>>> For reasons I won't go into, I have to sit with and direct another DBA
>>> to make sure she follows the step-by-step procedures we laid out to create
>>> a physical standby database. I haven't created a standby in several years,
>>> so I find myself asking a lot of why questions (which has been encouraged
>>> by my team lead and manager) for several of the steps. More often than
>>> not, the response is, "because you have to" with no other explanation. Her
>>> original instructions were not ordered correctly and missing several
>>> steps. She said it was ok because she knew what to do and when to do it.
>>> Actually, that's NOT ok because she wasn't going to be creating the
>>> remaining 6 standby databases, which I told her did not help the rest of
>>> the team. (ok, through whining).
>>>
>>> We configured the primary to accommodate the second physical standby,
>>> configured the new standby, made sure all the proper directories were in
>>> place, and kicked off a duplicate for standby from the active database
>>> since the backup disk is extremely slow storage and we are coming up on a
>>> deadline. The duplicate failed very quickly with the ORA-01580 error
>>> creating control backup file xxxx and ORA-27040 file create error, unable
>>> to create file. I'm leaning towards the idea this might be an issue with
>>> the mount options on the new standby server since we verified the path was
>>> correct. The other DBA is positive that having the backup running on the
>>> primary was the cause of the error, along with not creating a controlfile
>>> for the standby before we started.
>>>
>>> From my research on MOS, it doesn't appear we do not need to create a
>>> controlfile. However, it seems one step that was left out of the
>>> instructions we're using was creating an spfile for the standby on ASM from
>>> the primary's spfile. Do we need to add this step? We do have a pfile
>>> with the correct parameters on the standby server $ORACLE_HOME/dbs
>>> directory. Since the directory path on ASM is different for the standby,
>>> will the primary spfile cause us any issues?
>>>
>>> I haven't had a lot of time to do any research on creating a standby on
>>> 11g after I was thrown into the project due to other commitments. I'm
>>> continuing my research today, but any suggestions, pointers to documents
>>> (already found Doc IDs: 1075908.1 & 1617946.1), what our 1580 error is
>>> really indicating, etc., would be greatly appreciated.
>>>
>>> --
>>> Sandy B.
>>>
>>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217
>>
>>
>
> --
> Sandy B.
>
>

-- 
Sandy B.

--
http://www.freelists.org/webpage/oracle-l