该案例来自某银行客户exadata x7,12.1.0.2的数据库版本,客户备份策略为每周1次0级备份,6次增量备份,增量备份的完成时间不稳定,有时会很慢很慢。
首先非常怀疑BCT并没有生效,没生效的原因常见的首先想到的就是数据文件增量备份次数超过了_bct_bitmaps_per_file
1 2 3 4 |
@ On a database having Block Change Tracking enabled if more than 8 RMAN @ incremental backups are executed without consolidating them into a full @ backup, then the backup process will be very slow since the Block Change @ Tracking won't get used anymore. |
备份是否用的了bct跟踪文件,可以通过v$datafile_backup中USED_CHANGE_TRACKING去判断,客户反应2021年10月16日的增量备份就非常缓慢,可以通过v$datafile_backup看看bct是否生效?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
FILE# INCREMENTAL_LEVEL USE DATAFILE_BLOCKS BLOCKS_READ BLOCKS TO_CHAR(COMPLETION_ ---------- ----------------- --- --------------- ----------- ---------- ------------------- 58 1 YES 4194176 4194176 1 2021-10-16 05:04:27 56 1 YES 4194176 4194176 1 2021-10-16 05:05:05 120 1 YES 4194176 4194176 1 2021-10-16 05:05:05 145 1 YES 4194176 4194176 1 2021-10-16 05:06:06 59 1 YES 4194176 4194176 1 2021-10-16 05:06:59 81 1 YES 4194176 4194176 1 2021-10-16 05:06:59 63 1 YES 4194176 4194176 1 2021-10-16 05:08:08 83 1 YES 4194176 4194176 1 2021-10-16 05:13:38 104 1 YES 4194176 4194176 1 2021-10-16 05:13:38 105 1 YES 4194176 4194176 1 2021-10-16 05:15:00 126 1 YES 4194176 4194176 1 2021-10-16 05:15:00 65 1 YES 4194176 4194176 1 2021-10-16 05:15:24 150 1 YES 4194176 4194176 1 2021-10-16 05:15:24 86 1 YES 4194176 4194176 1 2021-10-16 05:16:29 107 1 YES 4194176 4194176 1 2021-10-16 05:16:29 149 1 YES 4194176 4194176 1 2021-10-16 05:16:29 97 1 YES 4194176 4194176 1 2021-10-16 05:20:36 139 1 YES 4194176 4194176 1 2021-10-16 05:20:36 58 1 YES 4194176 4194176 1 2021-10-16 05:04:27 56 1 YES 4194176 4194176 1 2021-10-16 05:05:05 120 1 YES 4194176 4194176 1 2021-10-16 05:05:05 145 1 YES 4194176 4194176 1 2021-10-16 05:06:06 59 1 YES 4194176 4194176 1 2021-10-16 05:06:59 81 1 YES 4194176 4194176 1 2021-10-16 05:06:59 63 1 YES 4194176 4194176 1 2021-10-16 05:08:08 83 1 YES 4194176 4194176 1 2021-10-16 05:13:38 104 1 YES 4194176 4194176 1 2021-10-16 05:13:38 105 1 YES 4194176 4194176 1 2021-10-16 05:15:00 126 1 YES 4194176 4194176 1 2021-10-16 05:15:00 65 1 YES 4194176 4194176 1 2021-10-16 05:15:24 150 1 YES 4194176 4194176 1 2021-10-16 05:15:24 86 1 YES 4194176 4194176 1 2021-10-16 05:16:29 107 1 YES 4194176 4194176 1 2021-10-16 05:16:29 149 1 YES 4194176 4194176 1 2021-10-16 05:16:29 97 1 YES 4194176 4194176 1 2021-10-16 05:20:36 139 1 YES 4194176 4194176 1 2021-10-16 05:20:36 |
查看了当天增量备份的部分文件发现USED_CHANGE_TRACKING都是yes,但是有一个奇怪的现象,bct启用的情况下部分文件增量备份读取的块数(BLOCKS_READ)与数据文件块数(DATAFILE_BLOCKS)一致,并且都只备份了1个block。通常只有bct启用的情况下,距前一次增量备份该数据文件没有任何修改的情况下,才会去备份1个block(文件头)。
查询mos发现,该案例命中了12.1.0.2上的一个bug。该bug只在12.1.0.2中存在,在12.1.0.2.190716和12.2中修复。
1 |
Bug 21101873 - RMAN BCT Backup optimization may not work in 12.1.0.2 causing slow backups as all blocks from datafile are read instead of using BCT file (Doc ID 21101873.8) |
该bug触发条件和原因为:在12.1.0.2 bct对算法进行了优化,导致当数据文件距上次增量备份未改变的情况下,会读取该文件的所有数据块。