https://mp.weixin.qq.com/s/dxKMQT9jywXwkgg71KtsHA
BCT(Block Change Tracking)是Oracle从10g开始有的特性。BCT的原理是记录数据文件里每个数据块的变化,并把这些变化信息保存在BCT的跟踪文件中。启动BCT后,RMAN或者XTTS进行增量备份时使用BCT跟踪文件里的信息,只读取改化的数据块,而不用再对全部数据文件进行扫描,从而提高了RMAN或者XTTS增量备份的性能。
检查BCT的配置:
SQL> COL STATUS FORMAT A8
COL FILENAME FORMAT A60
SQL> SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING;
STATUS FILENAME
-------- ------------------------------------------------------------
DISABLED
BCT跟踪文件默认位于系统参数DB_CREATE_FILE_DEST指定的目录下,使用下面的命令可以激活BCT:
SQL> SHOW PARAMETER DB_CREATE_FILE_DEST
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_create_file_dest string +DATA3
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
Database altered.
SQL> col filename form a60
SQL> select filename, status, bytes from v$block_change_tracking;
FILENAME STATUS BYTES
------------------------------------------------------------ -------------------- ----------
+DATA3/ORCL/CHANGETRACKING/ctf.287.1062173021 ENABLED 11599872
用户也可以指定跟踪文件的位置,但注意在RAC环境中,跟踪文件要能被所有的节点都访问到:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u01/app/oracle/oradata/orcl/rman_change_track.f' REUSE; 2
Database altered.
SQL> SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING;
STATUS FILENAME
-------- ------------------------------------------------------------
ENABLED /u01/app/oracle/oradata/orcl/rman_change_track.f
注意:BCT的实施要在全量备份之前,否则增量备份时不会起作用,很多人误以为在增量备份之前即可。
取消BCT的命令如下:
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
BCT跟踪文件采用位图记录对应块的变化,一位(bit)对应32K的数据,BCT跟踪文件会保存8个备份集的块变化,再加上当前状态,因此BCT跟踪文件大小大约是数据库大小的3000分之一,一个1T的数据库对应的BCT跟踪文件的大小是30M,对应RAC环境,BCT跟踪文件大小还要乘以节点数,因此计算公式是:BCT跟踪文件大小=节点数*(数据库大小/30000)。
在启用了块更改跟踪的数据库上,如果执行了8个以上的RMAN增量备份而没有将它们合并为完整备份,BCT跟踪文件可能无法使用。这个限制由隐含参数 “_bct_bitmaps_per_file"参数决定。这个参数设置每个数据文件要存储的位图数,其默认值为8。为了避免此问题,可以运行不超过8个增量备份就进行一次全量备份,也可以增加”_bct_bitmaps_per_file"参数。
下面这个例子在最后一步执行增量备份的时候将无法使用BCT跟踪文件,因为最初的0级备份的信息已经被覆盖了。
增量备份的过程由两部分组成,扫描在全量备份后变化的块和将变化的块写入备份集。激活BCT对增量备份的性能提高和变化的块成正比,最极端的情况是全量备份后没有任何数据块发生变化,激活BCT可以把增量备份的时间降低到几乎为零。一般推荐数据库的块变化小于20%时应该激活BCT。v$backup_datafile视图中包含一个名为used_change_tracking的列,对于增量备份级别>0,此列的值为YES表示RMAN使用了BCT跟踪文件以加速增量备份,这时读取的块和数据文件的总块数之比反应了激活BCT后效率的提升,可以使用下面的SQL查询增量备份中每个数据文件的效率的提升:
SQL> select file#,
avg(datafile_blocks),
avg(blocks_read),
avg(blocks_read/datafile_blocks) * 100 as "% read for backup"
from v$backup_datafile
where incremental_level > 0
and used_change_tracking = 'YES'
group by file#
order by file#; 2 3 4 5 6 7 8 9
FILE# AVG(DATAFILE_BLOCKS) AVG(BLOCKS_READ) % read for backup
---------- -------------------- ---------------- -----------------
1 120320 109 .090591755
3 204800 191 .093261719
4 43520 209 .480238971
7 640 1 .15625
9 37120 17 .045797414
10 60160 1 .001662234
11 776320 13 .001674567
12 640 1 .15625
20 9650176 1 .000010363
21 9043968 1 .000011057
10 rows selected.
这里有一个激活bct之前和之后增量备份对比的例子:
类型 | 全量备份大小 | 增量备份集大小 | 用时 | 备份速度 | 传输速度 |
---|---|---|---|---|---|
激活bct之前增量备份 | 152.13G | 22.99M | 4分钟51秒 | 55.3M/S | 4.3K/S |
激活bct之后增量备份 | 152.13G | 22.8M | 21秒 | 7.2G/S | 57.2K/S |
目前业界的情况是:激活BCT对绝大多数数据库的性能影响几乎为零,但对数据仓库类型的数据库在大量数据导入时会有影响,例如使用ETL工具向数据仓库中大量插入数据时。这要从BCT的原理说起,激活BCT后,Oracle会增加一个进程,进程名类似ora_ctwr_orcl。这个进程跟踪变化的块,并将变化的块记录到内存的一个称之为“CTWR buffer”的私有区域,这个区域的记录会刷新到BCT跟踪文件中。当在短期内有大量的变化数据块,造成CTWR buffer中的记录不能及时刷新到BCT跟踪文件中时,会产生一个等待事件“block change tracking buffer space”,如果监控到这个等待事件在DB time里的占比较高,则说明激活BCT对数据库的性能产生了影响,这时通常有以下3种解决方案:
对大型的生产数据库通常应激活BCT,对联机交易几乎没有影响,同时可以大大提高增量备份的性能。