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

Yes, I mis-typed database when I typed in the error message. That was just me fat-fingering. :-( Did find an error in the alert log that said the wallet is not open. Troubleshooting that one now.

Sandy

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

> 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.
>
>

-- 
Sandy B.

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