首页 > 其他分享 >XTTS系列之二：不可忽略的BCT

XTTS系列之二：不可忽略的BCT

时间：2023-06-30 22:55:04浏览次数：45  
标签：DATAFILE 06 COMPLETED 30 之二 XTTS 2023 BCT 15

重要系统Oracle数据库U2L迁移场景中，如果客户来问我建议，我都会回复说首选就是XTTS，除非XTTS经测试实在是无法满足停机窗口，否则就不要考虑OGG这类方案。
换句话说，选择OGG做迁移的场景，都是没有其他办法时才会选用的方案了。

而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的, 因为这会直接关系到你的迁移项目正式割接阶段能否成功。
有不少人会说元数据才最重要，我能理解这个讲法，的确，元数据在xtts迁移中也是个非常关键的点，但是它占用割接窗口具体多少时间，基本在测试过程中就可以清楚知道，并不会和测试过程中有太大的出入。

而增量备份就不一样，曾遇到有客户日常演练很的很好，每次增量时间也很满意，结果最后割接做最后一次增量时bct突然失效，直接导致全扫，无法满足计划内割接窗口，只能回退再找时间申请割接，导致各方面影响都很大。

最近有个客户的核心系统也是U2L，决定做XTTS迁移测试，因为在前期测试阶段不允许对生产有任何干涉，所以决定建立一个2级备库，以2级备库模拟源端进行XTTS的流程测试。

因为项目比较典型，各方都比较重视，我还专门为此项目搞了套测试环境，方便帮助现场测试人员分析一些遇到的问题。
我的测试环境架构如下：

生产端：主库 -> 备库 -> 2级备库
db11g -> db11gadg -> db11gcas

目标端：RAC
rac1, rac2

1.选定最新XTTS脚本，开启bct

首先我测试模拟的业务用户是JINGYU，表空间是DBS_D_JINGYU, DBS_I_JINGYU，然后对应XTTS的脚本是最新的V4.3：

# @db11g:
select distinct tablespace_name from dba_segments where owner='JINGYU' order by 1;
execute dbms_tts.transport_set_check('DBS_D_JINGYU, DBS_I_JINGYU');
select * from TRANSPORT_SET_VIOLATIONS; 


# @db11gcas, 创建XTTS工作目录
[oracle@db11gcas ~]$ 
mkdir -p /home/oracle/xtt
unzip rman_xttconvert_VER4.3.zip -d /home/oracle/xtt
cd /home/oracle/xtt
ls -lrth


# @db11g, 源端开启bct（block change tracking）
SQL> 
select * from v$block_change_tracking;

Get小知识：db11g开启了bct，但是db11gadg和db11gcas并不会同步开启。
这也说明ADG的同步，bct不会自动同步哦～
以后面试可以问问候选人哪些东西ADG不会同步，哈哈，非常考验候选人功力，看看能说出几个，能说出的估计都是DBA老炮儿了。

现在手工开启，在备库db11gadg和db11gcas也都执行命令：

# @db11gadg, @db11gcas:
alter database enable block change tracking using file '/u01/app/oracle/bct.dbf'; 

alter database disable block change tracking;

# @db11g, @db11gadg, @db11gcas:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
backup incremental level 0 tablespace DBS_D_JINGYU, DBS_I_JINGYU format '/u01/media/%U.bck';

2.ADG备库测试XTTS备份效果

到这里，我突然想到，其实，现阶段只测试bct的话，没必要搞这么复杂，直接在我的一套ADG环境测试下XTTS备份效果就能得出结论，所以先不折腾全过程了，只关注下我们所关注的bct，我这里的环境是19c多租户的，来看下xtt.properties配置文件内容：

按我测试环境修改的xtt.properties：
使用grep过滤以#号开头的注释行 和 空行，显示如下：

[oracle@bogon xtt]$ grep -vE '^#|^$' xtt.properties
tablespaces=TEST
platformid=13
src_scratch_location=/u01/media/src_backups
dest_datafile_location=+DATADG
dest_scratch_location=/xtts
parallel=3
rollparallel=2
getfileparallel=4
srcconnstr=sys/oracle@jingyu
destconnstr=sys/oracle@jingyu
allowstandby=1

设置TMPDIR目录变量：

export TMPDIR=/home/oracle/xtt/tmp

其实直接写入到环境变量中最方便。

然后开始执行XTTS备份测试：

[oracle@bogon xtt]$ 
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

这里需要使用 v$RMAN_BACKUP_JOB_DETAILS 来查看详情：

set lines 180 pages 200  
COL INPUT_TYPE FORMAT a20
COL STATUS FORMAT a20
COL minutes FORMAT 999.999
COL Input_mb FORMAT 99,999.99
COL Output_mb FORMAT 99,999.99

SELECT SESSION_KEY, INPUT_TYPE, STATUS,
TO_CHAR(START_TIME,'yyyy-mm-dd hh24:mi') start_time,
TO_CHAR(END_TIME,'yyyy-mm-dd hh24:mi') end_time,
INPUT_BYTES/1024/1024 Input_mb,
OUTPUT_BYTES/1024/1024 Output_mb,
ELAPSED_SECONDS/60 minutes
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY;

INPUT_BYTES

NUMBER

Sum of all input file sizes backed up by this job

OUTPUT_BYTES

NUMBER

Output size of all pieces generated by this job

从官方文档解释来看，INPUT_BYTES 实际上就是指备份时读取的文件大小，而 OUTPUT_BYTES 指的是备份实际备份出来的文件大小。
如果不看文档说明，这两个参数很容易误会给搞反了。

先看不开启BCT时，实际是这样的效果：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES
----------- -------------------- -------------------- ---------------- ---------------- ---------- ---------- --------
       4891 DATAFILE FULL        COMPLETED            2023-06-30 14:51 2023-06-30 14:51     100.00     100.00     .050
       4894 DATAFILE FULL        COMPLETED            2023-06-30 15:23 2023-06-30 15:23      97.00        .05     .033
       4896 DATAFILE FULL        COMPLETED            2023-06-30 15:30 2023-06-30 15:30      97.00        .05     .067
       4898 DATAFILE FULL        COMPLETED            2023-06-30 15:31 2023-06-30 15:31      97.00        .05     .133

每次备份都读取了接近100M的文件大小。

这里把xtts的tmp整个干掉，重测下bct的效果。
注意：实际测试不能轻易删除整个tmp目录，里面的文件没有了，XTTS脚本就不知道数据文件该从哪开始恢复了。

[oracle@bogon xtt]$ 
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3


SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES
----------- -------------------- -------------------- ---------------- ---------------- ---------- ---------- --------
       4900 DATAFILE FULL        COMPLETED            2023-06-30 15:34 2023-06-30 15:34     100.00     100.00     .033
       4903 DATAFILE FULL        COMPLETED            2023-06-30 15:36 2023-06-30 15:36        .00        .00     .000

看见没？这就是bct的魅力所在，4903这一行，INPUT_MB直接近似为0，因为我这里除了SCN变化，数据一点没变。
但没有bct，就还是像之前那样读取接近整个数据文件的大小，比如上面测试的4894、4896、4898那些。
再测两把，依然是很小的INPUT_MB：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES
----------- -------------------- -------------------- ---------------- ---------------- ---------- ---------- --------
       4905 DATAFILE FULL        COMPLETED            2023-06-30 15:40 2023-06-30 15:40        .01        .05     .067
       4907 DATAFILE FULL        COMPLETED            2023-06-30 15:41 2023-06-30 15:41        .01        .05     .133

那现在来测试下一个场景：
我这里是备库角色，我要激活打开，看BCT是否会失效？

该备库环境已经开启了数据库闪回，新建一个还原点：

create restore point before_read_write guarantee flashback database;

然后置换读写的参考命令：

select database_role, open_mode from v$database;
select name from v$restore_point;
create restore point before_read_write guarantee flashback database;
select name from v$restore_point;
select CONTROLFILE_TYPE from v$database;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
select CONTROLFILE_TYPE from v$database;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
ALTER DATABASE OPEN;
select database_role, open_mode from v$database;
alter pluggable database all open;

实际操作如下：

SQL> select database_role, open_mode from v$database;

DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY

SQL> 
SQL> 
SQL> select name from v$restore_point;

no rows selected

SQL> create restore point before_read_write guarantee flashback database;

Restore point created.

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
BEFORE_READ_WRITE

SQL> 
SQL> select CONTROLFILE_TYPE from v$database;

CONTROL
-------
STANDBY

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Database altered.

SQL> select CONTROLFILE_TYPE from v$database;

CONTROL
-------
CURRENT

SQL> 
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Database altered.

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> 
SQL> select database_role, open_mode from v$database;

DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PRIMARY          READ WRITE

SQL> 

SQL> alter pluggable database all open;

Pluggable database altered.

之后再次进行测试，也就是模拟XTTS在备库测试，需要打开读写后做最后一次增量测试：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES
----------- -------------------- -------------------- ---------------- ---------------- ---------- ---------- --------
       4900 DATAFILE FULL        COMPLETED            2023-06-30 15:34 2023-06-30 15:34     100.00     100.00     .033
       4903 DATAFILE FULL        COMPLETED            2023-06-30 15:36 2023-06-30 15:36        .00        .00     .000
       4905 DATAFILE FULL        COMPLETED            2023-06-30 15:40 2023-06-30 15:40        .01        .05     .067
       4907 DATAFILE FULL        COMPLETED            2023-06-30 15:41 2023-06-30 15:41        .01        .05     .133
       4909 DATAFILE FULL        COMPLETED            2023-06-30 15:56 2023-06-30 15:56     100.00        .05     .033

看到没，最新的4909就是模拟的最后一次增量，INPUT_MB读取了整个数据文件的大小。

重现了测试问题，也就是bct失效的确是由于置换成读写导致的。
那如果数据库就是读写状态（模拟主库场景），后续bct会不会一直不失效呢？我记着之前有同事曾遇到过超过8次失效的问题，验证下：

SESSION_KEY INPUT_TYPE           STATUS               START_TIME       END_TIME           INPUT_MB  OUTPUT_MB  MINUTES
----------- -------------------- -------------------- ---------------- ---------------- ---------- ---------- --------
       4909 DATAFILE FULL        COMPLETED            2023-06-30 15:56 2023-06-30 15:56     100.00        .05     .033
       4911 DATAFILE FULL        COMPLETED            2023-06-30 15:59 2023-06-30 15:59        .01        .05     .033
       4913 DATAFILE FULL        COMPLETED            2023-06-30 16:00 2023-06-30 16:00        .01        .05     .033
       4915 DATAFILE FULL        COMPLETED            2023-06-30 16:00 2023-06-30 16:00        .01        .05     .033
       4917 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .017
       4919 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .017
       4921 DATAFILE FULL        COMPLETED            2023-06-30 16:01 2023-06-30 16:01        .01        .05     .033
       4923 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033
       4925 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033
       4927 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033
       4929 DATAFILE FULL        COMPLETED            2023-06-30 16:02 2023-06-30 16:02        .01        .05     .033
       4931 DATAFILE FULL        COMPLETED            2023-06-30 17:38 2023-06-30 17:38        .01        .05     .033

看来这里并没有出现8次后失效的现象，这个所谓8次对应了一个隐藏参数：_bct_bitmaps_per_file

NAME                                DESCRIPTION                                                        VALUE
----------------------------------- ------------------------------------------------------------------ ------------------------------
_bct_bitmaps_per_file               number of bitmaps to store for each datafile                       8

不过，保险起见，如果你可能要做超过8次的增量备份，还是建议将这个参数设置大一些。或者干脆避免超过8次引发bct失效问题，做得太多也会增大遇到bug的风险。

3.总结

  • 1）备库测试最后阶段若打开激活备库为读写，那bct会失效；
  • 2）建议有规划，不要做太多次增量，以免遇到参数影响或其他bug导致bct失效；
  • 3）如果确认选用XTTS迁移，提前适当修改调大_bct_bitmaps_per_file

好多年前给客户做XTTS迁移，那会儿还是用的2.0版本，也遇到不少问题，感兴趣的伙伴也可参见之前的文章《XTTS系列之一：U2L迁移解决方案之XTTS的使用》。
如今最新XTTS 4.3的版本，从MOS文档看整个过程，已经大幅简化了操作，也更加成熟稳定了。

标签：DATAFILE,06,COMPLETED,30,之二,XTTS,2023,BCT,15
From： https://www.cnblogs.com/jyzhao/p/17517982.html

相关文章

  • 动态规划之二维费用的背包问题
    问题二维费用的背包问题是指：对于每件物品，具有两种不同的费用；选择这件物品必须同时付出这两种代价；对于每种代价都有一个可付出的最大值（背包容量）。问怎样选择物品可以得到最大的价值。设这两种代价分别为代价1和代价2，第i件物品所需的两种代价分别为a[i]和b[i]。两种代价可付出的最......
  • 揭秘腾讯研究院：三分之二精力打造免费产品
    本文发表于2009-10-2008:4310/27/20091:41:33PM低调已经成了腾讯管理层共同的标签，却让我们更想认识他们神秘的技术带头人郑全战。他和他的团队在做什么？承担着怎样的使命？记者零距离解密腾讯研究院。9月底，全国上下期待着60周年国庆庆典的到来，而郑全战也在为另一场盛事摩拳擦掌。......
  • 9. 使用JdbcTemplate【从零开始学Spring Boot】
      整体步骤：(1)  在pom.xml加入jdbcTemplate的依赖；(2)  编写DemoDao类，声明为：@Repository，引入JdbcTemplate(3)  编写DemoService类，引入DemoDao进行使用(4)  编写Demo2Controller进行简单测试。 具体操作流程如下： 使用JdbcTemplate类需要加入（如果在JPA已经加入的话，这......
  • PROFINET设备描述文件GSD文件说讲之二
    设备访问点DeviceAccessPoint是设备描述点，简称DAP，是设备描述文件中重要的信息，其组成结构如下图所示：DAP基本信息结构DAP包含了不少关键信息，各个属性及其值详细解释如下表所示：DeviceAccessPointItem说明ID="IDD_1"PNIO_Version="V2.4"PROFINETIO设备的GSD文件版......
  • Python 算法之二分查找
    Python算法之二分查找二分查找二分查找又称折半查找优点是比较次数少，查找速度快，平均性能好缺点是要求待查表为有序表，且插入删除困难折半查找方法适用于不经常变动而查找频繁的有序列表。猜数字游戏1、生成一个有序列表2、用户猜测某个数字是否在列表中代码#!/usr......
  • kafka的学习之二_kafka的压测与GUI管理
    kafka的学习之二_kafka的压测与GUI管理第一部分创建topiccd/root/kafka_2.13-3.5.0bin/kafka-topics.sh--create--bootstrap-server10.110.139.184:9093--command-configconfig/sasl.conf--replication-factor3--partitions3--topiczhaobsh01bin/kafka-topics......
  • ASP.NET Core Identity 系列之二
    转自：https://mp.weixin.qq.com/s?__biz=MzA3NDM1MzIyMQ==&mid=2247486148&idx=1&sn=dae55b414e123c6718e470c21c8c8c21桂迹，微信公众号这节我们主要演示在ASP.NETCoreIdentity中创建、修改、删除、查询用户1.ASP.NETCoreIdentityUserManager类UserManager类位于Microsof......
  • 使用NamedParameterJdbcTemplate指定命名参数
    在本文中，我们将介绍如何在连接到后端Postgres数据库的Spring启动应用程序中使用NamedParameterJdbcTemplate。我们将使用NamedParameterJdbcTemplate从PostgresDB插入，更新和删除员工。为了保持设计的合理性，我将dao，service和controller分开了。服务只是本文的一个转折点。概观Named......
  • Spring — JdbcTemplate
    Spring—JdbcTemplateJdbcTemplate做持久层的操作导入包aop、ccbe(四核心)、spring-jdbc、c3p0、mysql-connector-java配置数据源编写数据库配置文件db.properties(driver、url、user、pwd)mysql5：Class.forName("com.mysql.jdbc.Driver");Stringurl="......
  • 计算机底层的秘密读书笔记之二
    计算机底层的秘密读书笔记之二内存部分内存部分之前自己看过很多资料了:主要是虚拟内存以及TLB相关的内容本书的角度与之前角度都不太一样,更加新颖一些.这次总结想倒着来写.1.SSD的带宽和延迟都比较好了,但是是无法代替内存的内存的寻址可以到字节,然后都是按照内......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99