Re: TSM Tape performance

From: Freek D'Hooge <freek.dhooge_at_gmail.com>
Date: Thu, 28 Apr 2016 15:10:54 +0200
Message-ID: <1461849054.25419.12.camel_at_dhoogfr-lpt1>



Just to add to this:

Are the backups doing full backups each time or do you use incremental backups as well?
If you are using incrementals, do you use the block change tracking or not?

If Oracle needs to read the entire datafiles to find a relative low number of blocks that changed, it will result in a (relative) low throughput to the backup.
And if this is going directly to tape, it will even be slower as the tape itself might need to stop / rewind each time.

Kind regards,

Freek

On wo, 2016-04-27 at 23:31 +0200, Stefan Koehler wrote:

> Hi Sanjay,
> this is a real tough one without knowing anything about your environment.
>
> > Some are very big double digit terabytes and so rman backup to TSM tape library is taking long time.
>
> Are you really putting it directly to tape or in a disk pool first + migration on threshold? If you really put it to tape, why don't you use a storage
> (LAN-Free) agent? Do you have media waits / waits on drives - are these waits the same all the time? Are you using compression at TSM client / API
> level? How is the interface utilization on TSM side?
>
> > Os level backup using dedicated gigabit vlan backup interface is having not issue.
>
> Is the OS level backup going directly to the same drives? Is the OS level backup running with the same parallelism? OS level backup (usually
> incremental) for comparison usually does not help.
>
> > We worked with TSM and got dedicated vlan backup interface but it is not behaving correctly as sometime backup work good but another backup after
> > one backup take 5-6 time more. Can someone share any experience as how to monitor and trace the issue.
>
> At first you need to find out which RMAN phase (read, copy, write) is the issue. You can easily simulate the read & copy phase by validating the
> database the same way like when you perform a backup. If the performance is stable, then the issue is likely to be in write phase. You can trace
> various locations in TDPO (MML) or TSM API, but this only makes sense if you already isolated the issue furthermore. You also can have issues in read
> phase (e.g. Linux + LVM does not provide proper information for disk ratio) or many many more issues.
>
> Just as an example i recently troubleshooted a performance issue in read phase by a restore from TSM and it was related to TCP Zero Window. This issue
> was also occurring sporadically.
>
> Not quite a specific post or answer to your question, but as i said this is really tough without knowing your environment and configuration.
>
> Best Regards
> Stefan Koehler
>
> Freelance Oracle performance consultant and researcher
> Homepage: http://www.soocs.de
> Twitter: _at_OracleSK
>
> > Sanjay Mishra <dmarc-noreply_at_freelists.org> hat am 27. April 2016 um 21:33 geschrieben:
> >
> > Hi
> >
> > I had a environment which is 11g R2 RAC and have 15 database running on it. Some are very big double digit terabytes and so rman backup to TSM tape
> > library is taking long time. We worked with TSM and got dedicated vlan backup interface but it is not behaving correctly as sometime backup work
> > good but another backup after one backup take 5-6 time more. If using regular interphase the performance is constant. Os level backup using
> > dedicated gigabit vlan backup interface is having not issue. Only RMAN backup is the issue. Can someone share any experience as how to monitor and
> > trace the issue. Ticket was opened with Oracle support but they found nothing on both OS (Using OEL) and Database (11.2.0.4). TSM team saying that
> > OS level backup has no issue and it is only rRMAN which is having issue. Moreover RMAN work good sometime but having intermittent issue.
> >
> > So if someone share how they think this can be handled or any of their experience.
> >
> > TIA
> > Sanjay
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Apr 28 2016 - 15:10:54 CEST

Original text of this message