Re: RMAN Duplicate - Commvault... Second pair of eyes

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Tue, 4 Dec 2018 16:44:53 -0500
Message-ID: <a78cdacf-26e4-9f26-1321-d72e6f754084_at_gmail.com>



Is your auxiliary configured in such a way that Commvault agent is a member of ASMADMIN group? If not, use cvpkgchg to put it into that group. The error message essentially tells you that Commvault cannot write to +DATA. Also if the ASM disk group names are different between target and auxiliary, you would probably need db_file_name_convert and log_file_name_convert parameters. Do you have RMAN catalog? If you do, you can simplify the procedure considerable, since as of 11R2 it is possible to duplicate database without connecting to the target database. If the problem persists, you can also open a case with Commvault support.

Regards

On 12/4/18 4:28 PM, Ruan Linehan wrote:
> Hi all,
>
> *11g Ent Edition 11.2.0.4 running on a two node RAC cluster on ASM. *
>
> I need to clone a clients production RAC database to a point in time
> from yesterday in order to retrieve some data as it appeared before
> manipulation.
> The duplicate DB also needs to exist on the same cluster for another
> reason.
>
> We have a level 0 backup set which only exists on tape from the 1st
> Dec with required ARC logs still accessible in flash recovery on disk.
> The one caveat is that we are leveraging a Simpana/Commvault MML
> client for the duplicate and I have not interacted with Commvault in a
> while.
>
> I have configured the initial setup for performing the duplicate with
> the usual suspects, single auxiliary instance, SQL Net, password files
> etc.
> All of which I believe are configured correctly. The auxiliary
> instance is initially configured with OMF/ASM "create" params rather
> than file name converts
> in order to handle the file placement. E.g.
> *.control_files='+DATA','+FRA'
> *.db_create_file_dest='+DATA'
> *.db_create_online_log_dest_1='+FRA'
> *.db_recovery_file_dest='+FRA'
> etc.
>
> This is one of the many variations of what I have executed...
> $ rman target sys/password_at_PROD auxiliary sys/password_at_PROD_DUP
> RMAN> run
> {
>  allocate channel ch1 type 'sbt_tape'
> PARAMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,BLKSIZE=1048576,ENV=(CvClientName=prodhost,CvInstanceName=Instance001,CvOraSID=PROD1)";
>  allocate auxiliary channel dev1 type 'sbt_tape'
> PARAMS="SBT_LIBRARY=/opt/commvault/Base/libobk.so,BLKSIZE=1048576";
>  duplicate target database to PROD_DUP
>  until time "to_date('16:00 03-12-2018','hh24:mi dd-mm-yyyy')";
> }
>
> The RMAN duplicate kicks off, allocates channels successfully, alters
> the auxiliary db name, sets the control file path location within ASM,
> db unique name etc as normal.
> Shuts down and starts up the auxiliary instance and then commences the
> restoration from the backup set.
>
> It is at this point that the restore operation completely fails, and
> seems to be fetching back from tape but is unable to write back the
> set via the aux channel
> or create / stage the file in ASM?
>
> Starting restore at 04-DEC-18
> Channel dev1: starting datafile backup set restore
> Channel dev1: restoring control file
> Channel dev1: reading from backup piece c-4575686922-20181202-01
> Channel dev1: ORA-19870 error while restoring backup piece
> c-4575686922-20181202-01
> ORA-19504: failed to create file "+DATA"
> ORA-17502: ksfdcre:4 failed to create file +DATA
> ORA-15001: diskgroup "DATA" does not exist or is not mounted
> ORA-15055: unable to connect to ASM instance
> ORA-12536: TNS:operation would block
>
> 1) Apologies in advance but am I doing something 'stoopid' here, which
> is not apparent to me??
> Or
> 2) Is there some configuration or env param within the Commvault
> config which is necessary to facilitate the proper interaction?
>
> I have tried multiple variations of incorporating file_name_converts
> or even 'set newname' for the restore files but everything is
> appearing to throw back the very same error above?
>
> Regards,
> Ruan

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217


--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 04 2018 - 22:44:53 CET

Original text of this message