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@xxxxxxxxxxxxxxxxxxxxx>
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
