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

Given that you’re duplicating for standby I believe you now have a standby db. All you need to do recover the standby either via dg or manually by transferring the archived log files across. You do not need the ‘do recover’

Cheers,
Leng

> On 19 Mar 2019, at 6:01 am, Sandra Becker <sbecker6925_at_gmail.com> wrote:
> 
> 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 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.
>>>>>> 

>>> 
>>> 
>>> -- 
>>> Sandy B.
>>> 
>> 
>> 
>> -- 
>> Sandy B.
>> 
> 
> 
> -- 
> Sandy B.
> 

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