Re: Application performance hit when performing archived log backups

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Mon, 16 May 2016 13:28:22 -0500
Message-ID: <CAP79kiTJ23tAYrBu=X05EWqT9m-OYkoFa-=j_eD0aqEottoB7g_at_mail.gmail.com>



That's strange - I just ran into that bug today when I noticed a session running for hours in Production. Never had a problem before that I've noticed.

Chris

On Mon, May 16, 2016 at 1:24 PM, Rich J <rjoralist3_at_society.servebeer.com> wrote:

> On 2016/05/16 12:46, Ryan January wrote:
>
> Poking through ASH data the only commonality I found was an increase in
> system IO, which ultimately ended up being RMAN. We were performing very
> simple archived log backups via rman with a parallelism of 4. Backup sets
> are being pushed uncompressed across a 1Gb link to DataDomain mounted via
> NFS.
> App call times went from 1s normally to over 30s at their worst. Backing
> that parallelism off to 1 resulted in a smaller spike with an increased
> duration. Application performance falls off very sharply as the backup
> begins, with a slower 2-3 minute exponential increase in performance as the
> backup completes. The same execution plan has been verified for frequent
> SQL statements during both good and bad times.
>
> ...
>
> Short of that, has anyone seen similar behavior? I would have never
> anticipated archived log backups to have this impact, but the timing
> matches up perfectly with 100% repeatability. If not the root cause, it's
> at least a contributor that we've identified as a fact. I would appreciate
> any suggestions of where we should consider continuing our troubleshooting,
> or guidance on what metrics we should gather.
>
>
>
> Possible you're hitting BUG 17797438 (V$RMAN_STATUS query slow)? I've had
> that inconsistently across a few databases on 11.2.0.3...
>
> Rich
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon May 16 2016 - 20:28:22 CEST

Original text of this message