Re: Block Change Capture Questions

Full disclosure:  I was too lazy to find the actual query itself, so I simply described it in my response.  Due to Jared's unexpected praise, I must confess that I originally found the query in Oracle Support note #262853.1
<https://support.oracle.com/epmos/faces/DocumentDisplay?id=262853.1> (entitled "/RMAN Fast Incremental Backups using BCT = Block Change Tracking file/"). So, as some complain of Oracle Support poaching their code, I didn't want to be guilty of a similar crime going in the other direction.

But I'll retain the glow from Jared's praise nevertheless.

For more detail on the hidden parameter "_bct_bitmaps_per_file" mentioned by Jonathan, please review Oracle Support note #2144267.1 <https://support.oracle.com/epmos/faces/DocumentDisplay?id=2144267.1> (entitled "/Higher bitmap switches recorded than scheduled incremental backup causing no use of BCT by cumulative backups/") for a good summary of the issue.

On 3/1/2022 8:55 AM, Jonathan Lewis wrote:
>
> 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 <mailto: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