You are welcome :-)
On Tue, Apr 9, 2013 at 10:34 AM, Grigori Solonovitch <
Grigori.Solonovitch AT ahliunited DOT com> wrote:
> Thank you very much.
>
> Grigori G. Solonovitch
> Senior Systems Architect Ahli United Bank Kuwait www.ahliunited.com.kw
>
> Please consider the environment before printing this E-mail
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Carlo Zanelli
> Sent: 09 04 2013 12:12 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] FW: TDPO questions
>
> 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
>
>
> ________________________________
>
> 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.
>
--
Eng. Carlo Zanelli
EMC Ireland, Co. Cork
Mobile: +353-(0)864569250, +39-3491419132
|
