- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
重要系统Oracle数据库U2L迁移场景中,如果客户来问我建议,我都会回复说首选就是XTTS,除非XTTS经测试实在是无法满足停机窗口,否则就不要考虑OGG这类方案。 换句话说,选择OGG做迁移的场景,都是没有其他办法时才会选用的方案了.
而在这类XTTS的迁移项目中,我认为bct的技术是至关重要的, 因为这会直接关系到你的迁移项目正式割接阶段能否成功。 有不少人会说元数据才最重要,我能理解这个讲法,的确,元数据在xtts迁移中也是个非常关键的点,但是它占用割接窗口具体多少时间,基本在测试过程中就可以清楚知道,并不会和测试过程中有太大的出入.
而增量备份就不一样,曾遇到有客户日常演练很的很好,每次增量时间也很满意,结果最后割接做最后一次增量时bct突然失效,直接导致全扫,无法满足计划内割接窗口,只能回退再找时间申请割接,导致各方面影响都很大.
最近有个客户的核心系统也是U2L,决定做XTTS迁移测试,因为在前期测试阶段不允许对生产有任何干涉,所以决定建立一个2级备库,以2级备库模拟源端进行XTTS的流程测试.
因为项目比较典型,各方都比较重视,我还专门为此项目搞了套测试环境,方便帮助现场测试人员分析一些遇到的问题。 我的测试环境架构如下:
生产端:主库 -> 备库 -> 2级备库 db11g -> db11gadg -> db11gcas 。
目标端:RAC rac1, rac2 。
首先我测试模拟的业务用户是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';
到这里,我突然想到,其实,现阶段只测试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的风险.
好多年前给客户做XTTS迁移,那会儿还是用的2.0版本,也遇到不少问题,感兴趣的伙伴也可参见之前的文章《 XTTS系列之一:U2L迁移解决方案之XTTS的使用 》。 如今最新XTTS 4.3的版本,从MOS文档看整个过程,已经大幅简化了操作,也更加成熟稳定了.
最后此篇关于XTTS系列之二:不可忽略的BCT的文章就讲到这里了,如果你想了解更多关于XTTS系列之二:不可忽略的BCT的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我正在尝试将抓取的 xml 输出写入 json。由于项目不可序列化,抓取失败。 从这个问题来看,它建议您需要构建一个管道,未提供的答案超出了问题 SO scrapy serializer 的范围。 所
有没有一种方法可以通过重载函数来区分参数是在编译时可评估还是仅在运行时可评估? 假设我有以下功能: std::string lookup(int x) { return table::va
我正在使用 MVVM 模式编写一个应用程序。我通过将 View 的 DataContext 属性设置为 ViewModel 的实例来向 View 提供数据。一般来说,我只是从那里使用 Binding
对于一个项目,我正在使用带有简单 python module 的传感器收集多个红外命令。 . 我收到如下字节字符串: commando1= b'7g4770CQfwCTVT9bQDAzVEBMagGR
我有一个计算方法,可以在用户使用 Cartridge 作为我的商店框架结账时计算税费。 税 = 税 * 小数(str(settings.SHOP_DEFAULT_TAX_RATE)) 计算工作正常。然
我正在用 pygame 制作一个绘图程序,我想在其中为用户提供一个选项来保存程序的确切状态,然后在稍后重新加载它。在这一点上,我保存了我的全局字典的副本,然后遍历, pickle 每个对象。 pyga
在 C++11 之前,我可以使用它来使类不可复制: private: MyClass(const MyClass&); MyClass& operator=(const MyClass&); 使用 C
大家好 :) 我在我的 VC++ 项目中使用 1.5.4-all (2014-10-22)(适用于 x86 平台的 Microsoft Visual C++ 编译器 18.00.21005.1)。 我
我有一个 python 文件:analysis.py: def svm_analyze_AHE(file_name): # obtain abp file testdata = pd.
这个问题已经有答案了: How to serialize SqlAlchemy result to JSON? (37 个回答) 已关闭 4 年前。 我正在编写小查询来从 mysql 获取数据数据库,
我是 Python 初学者,我在 JSON 方面遇到了一些问题。在我正在使用的教程中有两个函数: def read_json(filename): data = [] if os.pa
我目前正在开发一个针对 iPad 的基于 HTML5 Canvas/JavaScript 的小型绘图应用程序。它在 Safari 中运行。到目前为止,除了一件事之外,一切都进展顺利。 如果我旋转设备,
以下代码无法使用 Visual Studio 2013 编译: #include struct X { X() = default; X(const X&) = delete;
嗨,我制作了一个文本分类分类器,我在其中使用了它,它返回一个数组,我想返回 jsonresponse,但最后一行代码给我错误 'array(['cycling'], dtype =object) 不可
我使用 Flask 和 Flask-Login 进行用户身份验证。 Flask-Sqlalchemy 将这些模型存储在 sqlite 数据库中: ROLE_USER = 0 ROLE_ADMIN =
如果您尝试发送不可 JSON 序列化的对象(列表、字典、整数等以外的任何对象),您会收到以下错误消息: "errorMessage": "Object of type set is not JSON
我在尝试 move std::vector 时遇到崩溃其中 T显然是不可 move 的(没有定义 move 构造函数/赋值运算符,它包含内部指针) 但为什么 vector 的 move 函数要调用 T
我尝试在用户成功登录后将 token 返回给他们,但不断收到以下错误: 类型错误:“字节”类型的对象不可 JSON 序列化 我该如何解决这个问题?这是我到目前为止的代码: if user:
我是一名优秀的程序员,十分优秀!