Re: Slow running Delete query for same data volume

From: Pap <oracle.developer35_at_gmail.com>
Date: Sat, 3 Apr 2021 11:42:44 +0530
Message-ID: <CAEjw_fh2=s0XtcnrC3SOJGiP_uy9EfBTcaZHN3JzqwhROaKxSQ_at_mail.gmail.com>



Thank you Mladen. I have not heard of Veam backup in the past. Is this file system backup but not DB backup? And how can I see the schedule of this backup. Is there any View just like v$rman_backup_job_detail which i can query to see the file system backup schedule and can then confirm if that day(31st march) the schedule changed causing the slow IO and thus application job were impacted just that specific day?

Regards
Pap

On Fri, Apr 2, 2021 at 11:53 PM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> If my memory serves me right, Vn-Vn is "Veeam". Having worked for a backup
> vendor I know that backups don't necessarily user rman. If Veeam supports
> so called "synthetic full", then it uses file system backup, not rman.
> Laurentiu's Observation is rather obvious:
>
> TotalSeconds AAS %This PROGRAM2 EVENT2 FIRST_SEEN LAST_SEEN
> *3390* *4* *34%* *(TNS Vn-Vn) * *ON CPU* *3/31/2021 22:24* *3/31/2021
> 22:29*
> 1610 1.9 16% (JDBC Thin Client) ON CPU 3/31/2021 22:16 3/31/2021 22:29
> 960 1.1 10% (perl) ON CPU 3/31/2021 22:16 3/31/2021 22:29
> 690 0.8 7% (perl) cell multiblock physical read 3/31/2021 22:16 3/31/2021
> 22:29
> 300 0.4 3% (DBWn) db file parallel write 3/31/2021 22:17 3/31/2021 22:29
> 300 0.4 3% (JDBC Thin Client) gc cr block busy 3/31/2021 22:16 3/31/2021
> 22:29
> 270 0.3 3% (JDBC Thin Client) cell single block physical read 3/31/2021
> 22:18 3/31/2021 22:29
> 200 0.2 2% (Pnnn) direct path read temp 3/31/2021 22:16 3/31/2021 22:28
> 180 0.2 2% (LGWR) log file parallel write 3/31/2021 22:16 3/31/2021 22:27
> 170 0.2 2% (pmdtm) ON CPU 3/31/2021 22:16 3/31/2021 22:29
> 160 0.2 2% (LMSn) gcs log flush sync 3/31/2021 22:16 3/31/2021 22:26
> 130 0.2 1% (Pnnn) ON CPU 3/31/2021 22:16 3/31/2021 22:29
> 130 0.2 1% (pmdtm) cell single block physical read 3/31/2021 22:20 3/31/2021
> 22:29
> 110 0.1 1% (LMSn) ON CPU 3/31/2021 22:17 3/31/2021 22:29
> 90 0.1 1% (oracle) ON CPU 3/31/2021 22:20 3/31/2021 22:28
> 90 0.1 1% (oracle) direct path read temp 3/31/2021 22:16 3/31/2021 22:29
> *80* *0.1* *1%* *(TNS Vn-Vn) * *Backup: MML commit backup piece* *3/31/2021
> 22:27* *3/31/2021 22:28*
> 60 0.1 1% (TTnn) ON CPU 3/31/2021 22:16 3/31/2021 22:29
> 50 0.1 1% (ARCn) log file sequential read 3/31/2021 22:17 3/31/2021 22:24
> 50 0.1 1% (pmdtm) direct path read temp 3/31/2021 22:22 3/31/2021 22:23
>
> So, Veam is using rman (Backup MML). The consumption of CPU probably comes
> from compression, deduplication or the combination of both.
>
> On 4/2/21 6:46 AM, Pap wrote:
>
> Thank you. So the program (TNS vn-vn) is the one for backup. But, I am not
> able to see any DB incremental backup run from v$rman_backup_job_detail in
> this database during that time. And we are using ZDLRA , so all are
> incremental backup only. I see there was an archivelog backup running
> between ~10:20PM till 10:30PM. Can that impact to such extent?
>
> Why are you using Veeam if you have ZLDR appliance? Zero Loss appliance in
> itself should be protection enough.
>
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217https://dbwhisperer.wordpress.com
>
> -- http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Apr 03 2021 - 08:12:44 CEST

Original text of this message