RMAN Backup is Slow after 19.11 Release Update (Doc ID 2846457.1)
However, we did the suggested steps last week with no change. Support is looking at it, but we match the note identically.
Same mount points for 11g and 19c.
From: Mark W. Farnham <mwf_at_rsiz.com>
Sent: Tuesday, August 23, 2022 11:28 AM
To: Beckstrom, Jeffrey <jbeckstrom_at_gcrta.org>; 'David Barbour' <david.barbour1_at_gmail.com>
Cc: niall.litchfield_at_gmail.com; oracle-l_at_freelists.org
Subject: RE: [EXTERNAL] Re: rman backup slow even after patching it
I'll repeat just this snippet from my earlier remarks:
Without measuring a damn thing, the first thing I would do is check whether the "mount" strings for your destination are different between 11 and 19.
Your 11 install was probably around long enough that someone optimized how the disk was mounted, and if you have anything different with the environment of the 19 install it could easily account for 50 to 100% slower.
Good luck!
From: oracle-l-bounce_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Beckstrom, Jeffrey
Sent: Tuesday, August 23, 2022 9:00 AM
To: David Barbour
Cc: niall.litchfield_at_gmail.com<mailto:niall.litchfield_at_gmail.com>; oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
Subject: RE: [EXTERNAL] Re: rman backup slow even after patching it
Disk using RMAN.
From: David Barbour <david.barbour1_at_gmail.com<mailto:david.barbour1_at_gmail.com>>
Sent: Tuesday, August 23, 2022 8:58 AM
To: Beckstrom, Jeffrey <jbeckstrom_at_gcrta.org<mailto:jbeckstrom_at_gcrta.org>>
Cc: niall.litchfield_at_gmail.com<mailto:niall.litchfield_at_gmail.com>; oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
Subject: Re: [EXTERNAL] Re: rman backup slow even after patching it
Jeffrey - What is your target? Tape/Disk/Cloud? Are you using any type of third-party software or is it straight-up RMAN?
On Tue, Aug 23, 2022 at 6:42 AM Beckstrom, Jeffrey <jbeckstrom_at_gcrta.org<mailto:jbeckstrom_at_gcrta.org>> wrote:
50 to 100% slower
From: niall.litchfield_at_gmail.com<mailto:niall.litchfield_at_gmail.com> <niall.litchfield_at_gmail.com<mailto:niall.litchfield_at_gmail.com>>
Sent: Monday, August 22, 2022 11:28 AM
To: Beckstrom, Jeffrey <jbeckstrom_at_gcrta.org<mailto:jbeckstrom_at_gcrta.org>>
Cc: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
Subject: [EXTERNAL] Re: rman backup slow even after patching it
What does "slow" mean in this context?
On Mon, Aug 15, 2022 at 6:37 PM Beckstrom, Jeffrey <jbeckstrom_at_gcrta.org<mailto:jbeckstrom_at_gcrta.org>> wrote:
In 19.14, rman backup significantly slower than in 11g. This morning I put on some RMAN patches to no effect. In the rman trace file from a running backup I see:
Adjusting buffer count to honor available PGA; old bufcnt: 4, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 4, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 5, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 6, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 4, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 5, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 8, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Adjusting buffer count to honor available PGA; old bufcnt: 16, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 892876434, pga_available: 0
Backup envisage an unusual situation due to PGA memory availability: we are using only 2 read threads (instead of 9) for the current backup session
Adjusting buffer count to honor available PGA; old bufcnt: 4, new bufcnt: 2, pga_agg_limit: 0, pga_agg_target: 0, pga_agg_used: 913692181, pga_available: 0
Pga_aggregate targe is set at the cdb to a value. At the pdb level it is 0.
Pga_aggregate_limit is not set anywhere.
