Oracle数据库XTTS迁移踩坑记：一次因TDE和位图块导致的灾难性回滚

我们的文章会在微信公众号“Oracle恢复实录”和博客网站“www.htz.pw” 同步更新，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！由于博客中有大量代码，通过页面浏览效果更佳。

今天来聊一个话题数据库迁移的中王炸的技术，因为采用这个技术最后的结果就是不成功便遗臭万年，这就是XTTS。回想10多年，去IOE风靡全国，当时有很多客户已经蠢蠢欲动。X86架构、Linux平台的逐渐稳定，也得到很多客户的认可，伴随着11.2.0.4的XTTS技术成熟，跨平台的迁移在15年开始逐渐的在国内拥有比较的强的技术实力的公司所采用，那时的我就带领着团队负责某运营商10套以上的小机平台到Linux的迁移，一共涉及到AIX和HP，有ASM、RAW、SFRAC环境。当时团队中除我有几年数据库的经验外，其余人员的都是大学刚毕业，从业时间都低于1年，加上XTTS迁移的步骤确实比较多，并且需要在生产环境上操作，要保证这么多套系统成功的迁移，并且还需要多套系统在一晚上并行的迁移，要保证这样的迁移不出现误操作，全靠我一个人是不现实的，于是编写脚本，固化XTTS的操作，形成标准化的流程是当时唯一的出路。当然有人会说，Mos里面有一个perl版本的脚本，但是在15年那时，perl版本的功能太弱了，不支持备库模式，并行度配置非常有限，不支持增量备份时生产一个备份片就自动转化备份集文件，自动传输到目标端，不支持一条命令自动增量和前滚等等操作。所以也就在10年前的这个时候，我开启了全自动的XTTS脚本的编写，那时应该可以说在国内还是第一人，因为15年那时在国内基本上都还找不到XTTS迁移的案例，从技术研究、脚本编写、到规范的培训一步一步开始的。当时因为这个客户案例的成功和脚本在团队中帮助多个客户成功的实现XTTS迁移，自己在公司也实现了P7升级到P8。

在2023年，我写过一篇文章，总结过XTTS遇到的坑和给出一些关于XTTS迁移的建议，详细内容见：XTTS常见坑分享，但是今天分享这个案例，就是一个典型的失败的案例，如果负责迁移的相关人员原来看过我上面写的文章，肯定不会出现这个XTTS从成功到失败的经历，下面我们就详细的介绍一下这个案例，本案例来至于一次网上朋友针对XTTS迁移的讨论的案例。

为方便大家阅读，我将核心的思考的内容放到前面：

5，此案例的更多思考

此故障的原因虽然是典型的遇到Oracle的BUG，但是更多的还是由于数据库迁移人员整个迁移方案不规范和测试不充分导致的，永远记住数据库迁移的目标不是迁移成功，而是迁移后业务不出问题。特别是针对XTTS迁移方案，其实难的不是迁移技术本身，而是怎么确保迁移之前就可以考虑到可能触发的问题，迁移后怎么保证系统不出故障，如真出现故障，怎么保障数据库回退后对业务不造成大的影响。从这个案例中想和大家分享如下一些观点：

5.1 系统未表现出来故障，不代表系统没有风险

我喜欢打羽毛球，很多羽毛球朋友得过滑膜炎、半月板受损等慢性病，这些病需要我们打羽毛球几年以后身体才会开始疼痛，开始表露出来症状，但是在表露出来之前其实身体就已经受伤了，但是我们并未发现，所以我们认为我们身体好得很。Oracle数据库其实也是一样的，系统当前未表现出来故障，不代表系统没有风险。很有可能我们在一次运维时，就触发了系统的BUG，导致数据库受到影响，给业务或者公司造成不可估量的损失。定期的对系统进行BUG分析和解决高危漏洞是非常有必要的，基本上帮助提前解决很多故障和隐患，降低系统的故障率。其实有些时候真的是想不通很多客户不愿意做RU补丁的升级，我们在生活或者工作中其实常常会向有经验的人学习或者借鉴别人成功的经验，在Oracle运维中也是一样，进行高危漏洞或者BUG分析，就是一种典型的借鉴其它客户的用钱和泪换来的经验，我们直接拿来用就可以。

5.2 重大操作提前进行风险评估

就如前面我们提到国内很多客户并没有升级到最新的RU，所以导致数据库环境存在大量的已知BUG和未知BUG，那么在做重大操作前，一定要提前进行风险评估，在Mos上搜集对应的重大操作是否存在BUG，是否存在哪些风险及风险应该怎么规避。

5.3 重大操作方案需要考虑全面

就如这次XTTS迁移一样，上面的报错其实完全可以提前发现的，在迁移方案测试时和迁移完成后对整个数据库做一个全库校验，将源端和目标端的每张表做hash计算，计算完成后对比结果，就采用这一招就可以完全规避上面的问题，然而我们很多迁移的人员在采用XTTS迁移时，会在迁移前在源端创建一张测试表并插入数据，在迁移完成后确认数据是否存在，如果存在就表示迁移成功，这种校验方式是真的高效，但是无任何价值。以后有时间我可以分享一下我在做数据库迁移时，怎么实现的迁移后一键对比源端和目标端的数据的。还记得原来给某客户做XTTS迁移，里面涉及到每个用户的钱，客户直接来了一句，如果迁移后有客户投诉钱不一致，到时会直接报警，你们要对这个事情负责，到时心里面真的是一万匹马飘过，拿着白菜的工资，操作主席的心。

5.4 方案的测试比正式迁移更重要

曾经在给某客户讲解数据库迁移方案时，我们的迁移方案有3次方案测试，第一次是技术验证、第二是迁移方案验证、第三次迁移方案定稿，客户直接来了一句，你们这个迁移方案方案测试次数太多，不要用测试方案来堆人天，我们之前迁移都是当天晚上直接迁移，也从来没有出现过问题，你们这个方案画蛇添足。甲方爸爸的话，你不能反驳，还得表扬一下客户，你们的技术是真的牛逼，在不做任何测试的情况下能一次迁移成功，我们也非常想向你们学习你们在做迁移项目的经验。当时心中想的是，你运气是真的好，100次的成功带来的荣耀可能只需要一次迁移失败就可以抹零，还能直接将人快递到“冷宫”。曾经见过某客户IT的一把手就因为数据库运维的一个决定错误使得他的岗位从天上直接摔到地上，大家可以想象到他后来的结局。

正文开始：

1，故障背景

某客户的一套运行在Aix平台上的数据库，暂时取名为htz，版本为11.2.0.3，计划迁移到Linux 19C环境中。系统为核心系统，且数据库容量和对象个数比较大，负责运维的朋友跟客户他们后决定采用XTTS迁移的技术，采用Mos上V4的脚本。正式割接当晚XTTS迁移非常成功，系统成功启动，随意选择2张表的数据校验没有问题。然而，在业务正式上线之后，系统立即发生了严重的报错问题，伴随着大量的ORA-08031和ORA-00600的错误，最后不得不将业务回迁到AIX平台，一次XTTS迁移就从成功转向到失败，关键是留下很多麻烦的事情，新环境的数据跟老环境的数据已经不一致，业务新产生的数据怎么同步会AIX平台中，这部分工作内容从DBA或者运维团队来说是无法解决的，带来的后果也是无法评估的。对应的报错日志有：

Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_ora_14127223.trc（incident=273831976）
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [0], [0], [0], [16], [1], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_273831976/htzdb1_ora_14127223_157512316.trc

select count(*) from htz.test1;
select count(*) from htz.test1;
                           *
ERROR at line 1:
ORA-08103: object no longer exists

2，故障分析过程

2.1ALERT日志查看

任一找一台数据库实例alert日志查看都可以得到部分如下的信息：

2023-08-11T12:59:53.228701+08:00  
Use ADRCI or Support Workbench to package the incident.  
See Note 411.1 at My Oracle Support for error and packaging details.

2023-08-11T12:59:53.228784+08:00  
Doing block recovery for file 725 block 3  
Resuming block recovery (PMON) for file 725 block 3  
Block recovery from logseq 1329, block 356 to scn 0x0000000000000000  

2023-08-11T12:59:53.231911+08:00  
Recovery of Online Redo Log: Thread 1 Group 5 Seq 1329 Reading mem 0  
Mem# 0: +DATA/HTZDB/ONLINELOG/group_5.289.1145885229  
Block recovery completed at rba 0.0.0, scn 0x00000f3273f420c6  

2023-08-11T12:59:53.234803+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/HTZDB/HTZDB1/trace/HTZDB1_w018_811128.trc:  
ORA-00607: Internal error occurred while making a change to a data block  
ORA-00600: internal error code, arguments: [ktsBlkCheckError], [725], [1124073475], [18018], [], [], [], [], [], [], [], []

2023-08-11T12:59:53.507724+08:00  

2023-08-11T13:39:40.844186+08:00  
Dumping diagnostic data in directory=[cdmp_20230915133940], requested by (instance=1, osid=881197), summary=[incident=5752348].

2023-08-11T13:39:46.625899+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/HTZDB/HTZDB1/trace/HTZDB1_w01y_1472606.trc (incident=6213438) (PDBNAME=YNRAS1):  
ORA-00600: internal error code, arguments: [ktsBlkCheckError], [835], [360710148], [18018], [], [], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/HTZDB/HTZDB1/incident/incdir_6213438/HTZDB1_w01y_1472606_i6213438.trc  

2023-08-11T13:39:47.838845+08:00  
Use ADRCI or Support Workbench to package the incident.  
See Note 411.1 at My Oracle Support for error and packaging details.

2023-08-11T13:39:47.838952+08:00  
Doing block recovery for file 835 block 4  
Resuming block recovery (PMON) for file 835 block 4  
Block recovery from logseq 923, block 92937 to scn 0x00000ee763fbe053  

2023-08-11T13:39:47.842374+08:00  
Recovery of Online Redo Log: Thread 1 Group 5 Seq 923 Reading mem 0  
Mem# 0: +DATA/HTZDB/ONLINELOG/group_5.289.1145885229  
Block recovery completed at rba 933.92937.16, scn 0x00000ee763fcf19e

从上面的信息中可以看到报错的数据块都在block3和block4，这些快是Oracle数据文件管理的位图快，控制数据文件快的使用情况。

继续往下看，还有如下的日志：

2023-08-11T03:01:23.207818+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_p021_1443143.trc (incident=5753052) :  
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [4], [0], [0], [16], [1], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_5753052/htzdb1_p021_1443143_i5753052.trc  


2023-08-11T03:01:30.794561+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_ora_1443172.trc (incident=5753076) :  
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [4], [0], [0], [16], [1], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_5753076/htzdb1_ora_1443172_i5753076.trc


2023-08-11T03:01:33.209667+08:00  
Use ADRCI or Support Workbench to package the incident.  
See Note 411.1 at My Oracle Support for error and packaging details.

2023-08-11T03:02:26.109849+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_p026_1443112.trc (incident=5752932) :  
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [4], [0], [0], [16], [1], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_5752932/htzdb1_p026_1443112_i5752932.trc

2023-08-11T03:02:26.116911+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_p021_1443143.trc (incident=5753053) :  
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [4], [0], [0], [16], [1], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_5753053/htzdb1_p021_1443143_i5753053.trc

2023-08-11T03:02:26.137545+08:00  
Errors in file /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/trace/htzdb1_p02e_1443129.trc (incident=5752996) :  
ORA-00600: internal error code, arguments: [kcbtse_encdec_tbsblk_11], [4], [0], [0], [16], [1], [], [], [], [], [], []  
Incident details in: /oracle/app/oracle/diag/rdbms/htzdb/htzdb1/incident/incdir_5752996/htzdb1_p02e_1443129_i5752996.trc

2.2 表空间位图信息校验

Oracle提供了dbms_space_admin可以检验表空间位图信息是否正确，他会将位图中的信息与dba_extents中的信息做对比，确保信息是一致的。

SQL> begin
  2  dbms_space_admin.tablespace_verify('HTZ_TABLESPACE');
  3  end;
  4  /
begin
*
ERROR at line 1:
ORA-20000: Extent Map Entry Marked Partially Free in BitMap:
SegDBA: 0x02833aa2 : TSN 24 ExtNo 25 UetDBA 0x01851980: ExtNbk: 128
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 83
ORA-06512: at line 2

通过上面可以得到位图中信息和extents中的信息不一致，这里面信息的不一致跟上面ktsBlkCheckError报错一致。

2.3 加密表空间

ORA-00600 kcbtse_encdec_tbsblk_11报错是跟加密表空间有问题，确认表空间在目标环境中属性正确：

SQL> col WRL_TYPE for a10
SQL> col WRL_PARAMETER for a55
SQL> col status for a10
SQL> select * from v$encryption_wallet;

WRL_TYPE   WRL_PARAMETER                                           STATUS
---------- ------------------------------------------------------- ----------
file       /oracle/app/oracle/admin/htzdb/wallet                   OPEN

加密秘钥这些都是打开，并且是一致的，没有任何问题。

2.4 kcbtse_encdec_tbsblk_11报错的信息日志

查看htzdb1_p02e_1443129_i5752996.trc中的详细日志，可以得到如下的信息：

...

Stack Trace:
kcbz_encdec_tbsblk <- kcbtse_encdec_tbsblk_pdb1 <- kcbr_validate_read
<- kcbr_flush_reads <- kcbr_issue_read <- kcbr_media_apply <- krp_slave_apply
<- krp_slave_main <- ksvrdp_int <- opirip <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main
...
(session) sid: 916 ser: 41 trans: (nil), creator: 0x4033e5a18
flags: (0x41) USR/- flags2: (0x2080409) -/-/INC
flags_idl: (0x1) status: BSY/-/-/- kill: -/-/-/-
DID: 0001-0042-000000020000-0000-00000000, short-term DID:
txn branch: (nil)
edition#: 0 user#/name: 0/SYS
oct: 0, prv: 0, sql: (nil), psql: (nil)
stats: 0x3df0ec490, PX stats: 0x13505c44
service name: SYS$USERS
client details:
O/S info: user: oracle, term: UNKNOWN, ospid: 1065

3，故障原因

3.1 kcbtse_encdec_tbsblk_11的原因

通过上面的stack Trace，可以在Mos中确认的是触发了BUG：

Bug 35403506 - ORA-600 [kcbtse_encdec_tbsblk_11], [28], [0], [0], [16], [1], (Doc ID 35403506.8)

其中Oracle给出的原因如下：

数据库开始为每个表空间（tablespace）分配独立的加密密钥（TS Key），并逐渐限制使用数据库通用密钥（DB key）后，当系统无法为某个数据文件找到有效密钥时，将强制回退使用数据库级别的密钥（DB key）来尝试解密，偶尔会在数据库中出现被错误加密的数据块。

3.2 ktsBlkCheckError的原因

XTTS在元数据导入时，会自动重建位图信息，可能在重建位图信息时，出现一些异常，导致位图信息和DBA_EXTENTS中结果不一致，最后出现上面的报错信息

4，解决方案

在XTTS中出现上面解决方案回退是最好的解决方案，当日想从根本上解决问题，可以做如下的一些操作：

打35403506补丁或者升级到19.22的RU。

元数据导入添加TRANSPORTABLE=NO_BITMAP_REBUILD参数。

5，此案例的更多思考

此故障的原因虽然是典型的遇到Oracle的BUG，但是更多的还是由于数据库迁移人员整个迁移方案不规范和测试不充分导致的，特别是针对XTTS迁移方案，其实难的不是迁移本身，而是怎么确保迁移之前就可以考虑到可能触发的问题，迁移后怎么保证系统不出故障，如真出现故障，怎么保障数据库回退后对业务不造成大的影响。从这个案例中想和大家分享如下一些观点：

5.1 系统未表现出来故障，不代表系统没有风险

我喜欢打羽毛球，很多羽毛球朋友得过滑膜炎、半月板受损等慢性病，这些病需要我们打羽毛球几年以后身体才会开始表露出来，但是在表露出来之前其实身体就已经受伤了。Oracle数据库其实也是一样的，系统当前未表现出来故障，不代表系统没有风险，很有可能我们在一次运维时，就触发了系统的BUG，导致数据库受到影响，给业务或者公司造成不可估量的损失。定期的对系统进行BUG分析和解决高危漏洞是非常有必要的。其实有些时候真的是想不通很多可以不愿意做RU补丁的升级，我们在生活或者工作中其实常常会向有经验的人学习或者借鉴别人成功的经验，在Oracle中，其实进行高危漏洞或者BUG分析，就是一种典型的借鉴其它客户的用钱和泪换来的经验，我们直接拿来用就可以。

5.2 重大操作提前进行风险评估

5.3 重大操作方案需要考虑全面

就如这次XTTS迁移一样，上面的报错其实完全可以提前发现的，在迁移方案测试时和迁移完成后对整个数据库做一个全库校验，将源端和目标端的每张表做hash计算，计算完成后对比结果，就采用这一招就可以完全规避上面的问题，然而我们很多迁移的人员在迁移采用XTTS迁移时，会在迁移前在源端创建一张测试表并插入数据，在迁移完成后确认数据是否存在，如果存在就表示迁移成功，这种校验方式是真的高效，但是无任何价值。以后有时间我可以分享一下我在做数据库迁移时，怎么实现的迁移后一键对比源端和目标端的数据的。还记得原来给某客户做XTTS迁移，里面设计到每个用户的钱，客户直接来了一句，如果迁移后有客户投诉钱不一致，到时会直接报警，你们要对这个事情负责，到时心里面真的是一万匹马飘过，拿着白菜的工资，操作主席的心。

5.4 方案的测试比正式迁移更重要

曾经在给某客户讲解数据库迁移方案时，我们的迁移方案有3次方案测试，第一次是技术验证、第二是迁移方案验证、第三次迁移方案定稿，客户直接来了一句，你们这个迁移方案方案测试次数太多，不要用测试方案来堆人天，我们之前迁移都是当天晚上直接迁移，也从来没有出现过问题。甲方爸爸的话，你不能反驳，还得表扬一下客户，你们的技术是真的牛逼，在不做任何测试的情况下能一次迁移成功，我们也非常想向你们学习你们再做迁移项目的经验。当时心中想的是，你运气是真的好，100次的成功带来的荣耀可能只需要一次迁移失败就可以抹零，还能直接将人快递到“冷宫”。曾经见过某客户IT的一把手就以为数据库运维的一个决定错误岗位从天上直接摔到地上。