Oracle 迁移到 OceanBase 数据库常见不兼容对象的处理方式

在从 Oracle 数据库迁移到 OceanBase 数据库 Oracle 模式的过程中，会遇到一些特殊语法或对象需要单独处理。本文介绍遇到的一些不完全兼容对象的处理逻辑。

适用版本

OceanBase 数据库 V2.x、V3.x 版本。

Oracle 中 LOB 数据迁移到 OceanBase 数据库时的处理逻辑

Oracle 中 CLOB 和 BLOB 类型均可达到 4G 大小（以 Oracle 11.2 为例），而 OceanBase 数据库当前版本（V3.2.3.x）所支持的大对象数据类型的信息如下表所示。

考虑到从 Oracle 迁移到 OceanBase 数据库，如果涉及 LOB 字段，可能会存在当 LOB 数据大于 48M 时数据丢失的问题，需要提前发现这类数据并进行处理。

1. 找到 Oracle 数据库表中 LOB 数据的最大长度。

   SELECT MAX(DBMS_LOB.GETLENGTH(C_CLOB)) AS LONGEST_CLOB,
   MAX(DBMS_LOB.GETLENGTH(C_BLOB)) AS LONGEST_BLOB
   FROM T_LOB;
   

2. 获取整个数据库中 LOB 字段值较大的清单。

   SELECT COL.OWNER,
   COL.TABLE_NAME,
   COL.COLUMN_NAME,
   COL.DATA_TYPE,
   COL.AVG_COL_LEN,
   COL.CHAR_LENGTH,
   TAB.NUM_ROWS
   FROM DBA_TABLES TAB, DBA_TAB_COLUMNS COL
   WHERE TAB.OWNER = COL.OWNER
   AND TAB.TABLE_NAME = COL.TABLE_NAME
   AND COL.DATA_TYPE IN ('CLOB', 'BLOB')
   AND COL.OWNER NOT IN ('SYS', 'SYSTEM')
   AND COL.OWNER IN
   (SELECT USERNAME FROM DBA_USERS WHERE ACCOUNT_STATUS = 'OPEN')
   AND COL.TABLE_NAME NOT LIKE 'BIN%';
   

Oracle 中 disable 约束在 OMS 迁移过程中的处理逻辑

在对 Oracle 中的约束类非表对象做一致性校验时，发现部分约束在 OMS 迁移完成后丢失了，需要分析其 OMS 丢失的原因。

• 问题分析

  从 OMS 界面中获取 DDL 的语句可以看到有 2 个 WARN，且类型是 DISCARD，表示 OMS 判断其是 disable 状态的约束，直接选择了舍弃掉。

  -- [WARN] [DISCARD] CONSTRAINT "PK_T_PARTKEY_IS_PK" PRIMARY KEY ("CRT_DTTM") DISABLE NOVALIDATE -> [NULL]
  -- [WARN] [DISCARD] CHECK ("ACT_ID" IS NOT NULL) DISABLE NOVALIDATE -> [NULL]
  CREATE TABLE "T_PARTKEY_IS_PK" (
  "ACT_ID" NUMBER(10,0),
  "SRT_ID" NUMBER(10,0),
  "SRT_ORIGNAL_ID" NUMBER(10,0),
  "CRT_DTTM" DATE,
  "LASTUPT_DTTM" DATE
  )
  

• 问题结论

  Oracle 侧处于 Disable 状态的约束通过 OMS 迁移时，会被舍弃，不会在 OceanBase 数据库侧创建，在对约束对象比对时，需要额外注意 Oracle 端约束的 status 是否处于 disable 状态，本身对业务和功能没有影响。

  可以通过以下语句观测源端 Oracle 约束状态。

  -- 手工将 T_PARTKEY_IS_PK 表的约束都 disable
  ALTER TABLE ZHENXING.T_PARTKEY_IS_PK DISABLE NOVALIDATE CONSTRAINT PK_T_PARTKEY_IS_PK;
  ALTER TABLE ZHENXING.T_PARTKEY_IS_PK DISABLE CONSTRAINT SYS_C0011109;
  
  SELECT OWNER,
  TABLE_NAME,
  CONSTRAINT_NAME,
  CONSTRAINT_TYPE,
  INDEX_NAME,
  STATUS
  FROM DBA_CONSTRAINTS
  WHERE OWNER = 'ZHENXING'
  AND TABLE_NAME = 'T_PARTKEY_IS_PK';
  

Oracle 中分区表迁移到 OceanBase 后，带有的自动分区属性丢失

自动分区属性是 Oracle 11g 的特性，可以用 INTERVAL 语法基于天、月、年做自动分区创建。 示例如下：

create table interval_sales (
prod_id number(6),
time_id date)
partition by range (time_id)
INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
(partition p1 values less than (to_date('2015-01-01','yyyy-mm-dd')));

在通过 OMS 迁移到 OceanBase 数据库后，发现自动分区属性丢失了，会导致当分区未自动创建时导致新增数据没法写入分区表，导致报错。

• 问题分析

  从 OMS 界面中获取 DDL 的语句可以看到有 1 个 WARN，且类型是 DISCARD，表示 OMS 判断其不完全兼容，直接选择了舍弃掉。

  -- OMS 迁移表结构时记录的 WARN 信息，表示自动分区属性由于不兼容会自动 DISCARD 舍弃
  [WARN] [DISCARD]  INTERVAL (NUMTOYMINTERVAL (1,'MONTH')) -> [NULL]
  

• 问题结论

  在 Oracle 迁移到 OceanBase 数据库前，需要把 Oracle 端存在自动分区属性的表提前找出，避免由于迁移到 OceanBase 数据库后分区为未自动创建导致的数据无法插入的报错，并且找出这类分区后，先在 Oracle 端创建足够的多分区，避免迁移过程中源端分区数增加导致比对不一致的情况。并记录清单告知业务开发待后续用其他方式定期生成新分区。

如何找出 Oracle 中自动分区的表

/*
PARTITION_COUNT: Number of partitions in the table. For interval partitioned tables, the value of this column is always 1048575.
*/
SELECT T1.OWNER,
T1.TABLE_NAME,
T1.INTERVAL,
T1.PARTITIONING_TYPE,
T1.PARTITION_COUNT,
T1.SUBPARTITIONING_TYPE      AS SUB_TYPE,
T1.SUBPARTITIONING_KEY_COUNT SUB_COUNT,
T1.STATUS
FROM DBA_PART_TABLES T1
WHERE 1 = 1
AND TABLE_NAME NOT LIKE 'BIN%'
AND (INTERVAL IS NOT NULL OR PARTITION_COUNT = 1048575);