Re: Block Change Capture Questions

I'm late to the party on this one, but there is a hidden parameter which controls the number of generations of BCT data before the maps recycle and overwrite.
Can't remember the name, but it will have bct in it. (Usual "ask oracle" disclaimer applies.)

Regards
Jonathan Lewi

On Tue, 1 Mar 2022 at 16:49, Jared Still <jkstill_at_gmail.com> wrote:

> 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