You are welcome :-)
On Tue, Apr 9, 2013 at 10:34 AM, Grigori Solonovitch < grigori.solonovi...@ahliunited.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@VM.MARIST.EDU] On Behalf Of > Carlo Zanelli > Sent: 09 04 2013 12:12 PM > To: ADSM-L@VM.MARIST.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.solonovi...@ahliunited.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
