BCT 预估block change tracking file的大小

Block Change Tracking Inside Out (Doc ID 1528510.1)

详细 

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.1.0.2 and later
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Information in this document applies to any platform.

GOAL

This is a clarification of the documentation for sizing the disk space for the Block Change Tracking File.

The actual size of the Block Change Tracking File is determined by Oracle and cannot be changed by the end user.
The size of the block change tracking file can increase and decrease as the database changes.
The size is not related to the frequency of updates to the database. 多次update也算一个

Block Change Tracking is used to optimize incremental backups.
A new file is introduced:

- Changed blocks are tracked by the CTWR background process as redo is generated

redo产生的时候知道改的那个块，所以就记录下来
- Database backups automatically use the change tracking file

Sizing of this file is important, and even though you can use V$BLOCK_CHANGE_TRACKING view
to monitor the usage, it may in some cases not be easy to change the size, ie when using raw devices.

SOLUTION

The formula is:

<size of change tracking file> = <# of redo threads> * (# of old backups + 2) * (size of db/250000)

Let’s take an example of a 500 GB database, with only one thread, and having eight backups kept
in RMAN. The repository for this will require a block change tracking file of 20 MB.

Threads * (number of old backups+2) * (database size in bytes/250000) = 20 MB

1*10*500000000000/25000=20MB

The amount of data that each bit in the change tracking file covers is 32KB. That's 262144（32*8192？？） bits.      一个字节控制32KB？
That is where the 1/250000 figure comes from. 

 

This is the ratio of the size of *one bitmap* in the
change tracking file, to the size of the database data that the bitmap covers. And, because we
keep up to 8 levels of bitmap history in the file, plus the current bitmap, that reduces the ratio
to about 1/30000, per enabled thread.

Dividing 1TB by 30000, you get 30 MB, per TB, per enabled thread.

So the parameters we use to determine the block change tracking file are:
- Database size
- Number of enabled threads
- Number of old backups. (The block change tracking file keeps a record of all changes between previous backups, up to eight in total)
 

Additional Information found in 12c Documentation
Backing Up the Database

Database Backup and Recovery User's Guide
.
9 Backing Up the Database

...
Using Block Change Tracking to Improve Incremental Backup Performance
...

Size of the Block Change Tracking File

The size of the block change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size of the block change tracking file can increase and decrease as the database changes. The size is not related to the frequency of updates to the database.

Typically, the space required for block change tracking for a single instance is approximately 1/30,000 the size of the data blocks to be tracked. For an Oracle RAC environment, it is 1/30,000 of the size of the database, times the number of enabled threads.

The following factors that may cause the file to be larger than this estimate suggests:

• To avoid the overhead of allocating space as your database grows, the block change tracking file size starts at 10 megabytes. New space is allocated in 10 MB increments.Thus, for any database up to approximately 300 gigabytes, the file size is no smaller than 10 MB, for up to approximately 600 gigabytes the file size is no smaller than 20 megabytes, and so on.
• For each data file, a minimum of 320 kilobytes of space is allocated in the block change tracking file, regardless of the size of the data file. Thus, if you have a large number of relatively small data files, the change tracking file is larger than for databases with a smaller number of larger data files containing the same data.

----