ADSM-L

Re: [ADSM-L] FW: TDPO questions

2013-04-09 05:14:19
Subject: Re: [ADSM-L] FW: TDPO questions
From: Carlo Zanelli <carlo.zanelli AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 9 Apr 2013 10:12:29 +0100
Thanks Grigori,

no matter how long is the chain after RMAN, rman only demand to the MML (in
this case TSM MML, namely the TDPO library) to write to the channel and
treat it as a black-box.
If something in that black box goes wrong he quits the run {} statement :
RMAN-03009: failure of backup command on t1 channel at 04/07/2013 15:03:42
and the process is marketed as failed due to the returncode not equal to 0:
ANS1315W (RC15)   Unexpected retry request. The server found an error while
writing the data.

So I think that you have two ways here:
a- Ask support if exist a flag for tdpo to mask that failure so the
returncode to RMAN channel will be 0 also in case of failure on the copypool
b- Mantain two separate jobs for the RMAN backups. one to the primary
channel, another to copy that data to the copypool.




On Tue, Apr 9, 2013 at 9:46 AM, Grigori Solonovitch <
Grigori.Solonovitch AT ahliunited DOT com> wrote:

> >>> I think you have that behaviour quite different from a fs backup
> because you are dealing with RMAN, and at this point I do not know if there
> is any way to lower the severity to Warning for that but if is the RMAN
> script to fail in one of this points I do not think so.
> I have set COPYPOOLNAMES in primary pool to have the both primary and copy
> files during export/import for nodes and then I hit problem with TDPO
> backups. RMAN is sending data to TDPO --> TDPO is sending data to TSM
> Client --> TSM Client is sending data to TSM Server --> TSM Server is
> failing. I do not think RMAN can see something on TSM Server. This is TSM
> problem.
>
> > >>What's the output of the RMAN script in that when the job is failing
> due to the copy pool not present?
> RMAN-03009: failure of backup command on t1 channel at 04/07/2013 15:03:42
> ORA-19502: write error on file "/LPAR01/vcen.07.0.1228.1.812127807", block
> number 1121 (block size=8192)
> ORA-27030: skgfwrt: sbtwrite2 returned error
> ORA-19511: Error received from media manager layer, error text:
> ANS1315W (RC15)   Unexpected retry request. The server found an error
> while writing the data.
>
> >>>Why do not make a separate job to copy the data from primary to copy
> pool?
> It is a good question. According to setup decision to propagate files to
> copy pool is made by client site (export/import, TSM agent, etc).
> I was running all copies by separate schedules for many years. Now I am
> not sure what is better write data in parallel to primary and copy pools
> during backup or write to primary pools and then propagate data to copy
> pools.
> It is possible because I am using Data Domain VTL for primary pools
> replicated to disaster site and FILE copy pools.  I understand all possible
> problems with performance, but at the same time I prefer to save time as
> well.
>
> Grigori G. Solonovitch
> Senior Systems Architect  Ahli United Bank Kuwait  www.ahliunited.com.kw
>
> Please consider the environment before printing this E-mail
>
> ________________________________
>
> CONFIDENTIALITY AND WAIVER: The information contained in this electronic
> mail message and any attachments hereto may be legally privileged and
> confidential. The information is intended only for the recipient(s) named
> in this message. If you are not the intended recipient you are notified
> that any use, disclosure, copying or distribution is prohibited. If you
> have received this in error please contact the sender and delete this
> message and any attachments from your computer system. We do not guarantee
> that this message or any attachment to it is secure or free from errors,
> computer viruses or other conditions that may damage or interfere with
> data, hardware or software.
>
>
> Please consider the environment before printing this Email.
>



--
Eng. Carlo Zanelli
EMC Ireland, Co. Cork
Mobile: +353-(0)864569250, +39-3491419132

<Prev in Thread] Current Thread [Next in Thread>