Re: Block Change Capture Questions

From: Jared Still <jkstill_at_gmail.com>
Date: Tue, 1 Mar 2022 08:49:17 -0800
Message-ID: <CAORjz=PbPsquzO7m_E1ndSEs88hCTvMO7MwxjyyFCAPLHG_Gug_at_mail.gmail.com>



Ohhh, nice query Tim.

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Principal Consultant at Pythian
Oracle ACE Alumni
Pythian Blog
http://www.pythian.com/blog/author/still/ Github: https://github.com/jkstill
Personality: http://www.personalitypage.com/INTJ.html

On Tue, Feb 22, 2022 at 7:03 AM Tim Gorman <tim.evdbt_at_gmail.com> wrote:

> Scott,
>
> Block Change Tracking (BCT) has been a feature since 10.1, so it has been
> more than 15 years (at least) since it was introduced. It has been turned
> on for some extremely "busy" production databases, impact on transaction
> performance is negligible if anything, and the impact on incremental backup
> duration is generally dramatic. The BCT file itself should be treated like
> any other Oracle datafile, is self-purging, and is backed up by RMAN.
>
> BCT is not a perfect mechanism, and usage patterns where there are more
> than 7-8 incrementals between each full backup can overwhelm the purported
> 8-bit tracking byte, causing incremental backups to revert to pre-BCT
> behavior and duration. Periodically querying V$BACKUP_DATAFILE to check
> whether DATAFILE_BLOCKS *0.75 > BLOCKS_READ where USED_CHANGE_TRACKING =
> 'YES' can let you know if this is happening by checking if incremental
> backups are still generating a lot of I/O (i.e. 75% the size of the
> datafile at time of backup) despite BCT being enabled.
>
> Also, enabling BCT on a physical standby database is a trigger for
> licensing the Active DataGuard option, which can be an unpleasant surprise
> if not intended.
>
> Hope this helps,
>
> -Tim
>
>
>
> On 2/22/2022 6:39 AM, Scott Canaan wrote:
>
> We use CommVault for database backups. CommVault interfaces with RMAN.
> We do hot backups on prod databases, with one full backup each night and
> several incrementals throughout the day. Our CommVault administrator sent
> a message from CommVault that says:
>
>
>
> Severity: Minor
>
> Job ID: 4778016
>
> Event Date: Mon Feb 21 03:01:11 2022
>
> Program: ClOraAgent
>
> Client: rpiddevl2
>
> Description: Block Change Tracking is found DISABLED on Oracle
> DB [RPIDDEVL]. Incremental backups may run slow.
>
>
>
> He wants us to look into this. We have and are concerned that the
> overhead will be more than the benefits.
>
>
>
> Has anyone turned this on? If so, what was the overhead? Did it help
> with backups?
>
>
>
> Thank you,
>
>
>
> *Scott Canaan ‘88*
>
> *Sr Database Administrator *Information & Technology Services
> Finance & Administration
>
>
> *Rochester Institute of Technology *o: (585) 475-7886 | f: (585) 475-7520
>
> *srcdco_at_rit.edu <srcdco_at_rit.edu>* | c: (585) 339-8659
>
> *CONFIDENTIALITY NOTE*: The information transmitted, including
> attachments, is intended only for the person(s) or entity to which it is
> addressed and may contain confidential and/or privileged material. Any
> review, retransmission, dissemination or other use of, or taking of any
> action in reliance upon this information by persons or entities other than
> the intended recipient is prohibited. If you received this in error, please
> contact the sender and destroy any copies of this information.
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Mar 01 2022 - 17:49:17 CET

Original text of this message