1

我面临数据迁移，我的目标是在不到 8 小时内更新 2.5M 行，这是因为客户有一个有限的时间窗口可以停用服务。而且在这个执行过程中表不能被锁定，因为被其他程序使用，我只能锁定记录。执行将通过批处理完成。在这种情况下，迁移可能不是正确的词，最好说“改变数据”......

系统：Oracle 11g

表信息

表名：Tab1 总行数：520.000.000 平均行数：57

DESC Tab1;
Name             Null?    Type
---------------- -------- -----------
t_id             NOT NULL NUMBER
t_fk1_id                  NUMBER
t_fk2_id                  NUMBER
t_start_date     NOT NULL DATE
t_end_date                DATE
t_del_flag       NOT NULL NUMBER(1)
t_flag1          NOT NULL NUMBER(1)
f_falg2          NOT NULL NUMBER(1)
t_creation_date           DATE
t_creation_user           NUMBER(10)
t_last_update             DATE
t_user_update             NUMBER(10)
t_flag3                   NUMBER(1)

索引是：

  1. T_ID_PK [t_id] UNIQUE
  2. T_IN_1 [t_fk2_id,t_fk1_id,t_start_date,t_del_flag] NONUNIQUE
  3. T_IN_2 [t_last_update,t_fk2_id] NONUNIQUE
  4. T_IN_3 [t_fk2_id,t_fk1_id] NONUNIQUE

目前我已经想到了一些可能的解决方案，其中大部分我已经测试过：

  1. 插入+删除：选择现有数据，插入需要修改的新记录并删除旧记录[这个结果是最慢的方法~21h]
  2. 合并：使用合并命令更新现有数据[这个结果是最快的方法~16h]
  3. 更新：更新现有数据 [~18h]

使用上述解决方案，我遇到了一些问题，例如：如果使用 /*+ parallel(x) / 选项执行表被锁定， / + RESULT_CACHE */ 似乎在所有选择时间都没有影响。我的最后一个想法是按一个新列对表进行分区，并使用它来避免表锁定并继续解决方案 1。

这里用于 Merge 选项的查询（对于其他两个或多或少相同）：

DECLARE
v_recordset NUMBER;
v_row_count NUMBER;
v_start_subset NUMBER;
v_tot_loops NUMBER;
BEGIN
--set the values manually for example purpose, I've use the same values
v_recordset := 10000;
v_tot_loops := 10000;
  BEGIN
    SELECT NVL(MIN(MOD(m_id,v_recordset)), 99999)
    INTO v_start_subset 
    FROM MIGRATION_TABLE
    WHERE m_status = 0; -- 0=not migrated , 1=migrated
  END;
  FOR v_n_subset IN v_start_subset..v_tot_loops
    LOOP
      BEGIN
        MERGE INTO Tab1 T1
        USING (
          SELECT m.m_new_id, c2.c_id, t.t_id
          FROM MIGRATION_TABLE m
            JOIN Tab1 t ON t.t_fk_id = m.m_old_id
            JOIN ChildTable c ON c.c_id = t.t_fk2_id
            JOIN ChildTable c2 ON c.c_name = c2.c_name --c_name is an UNIQUE index of ChildTable
          WHERE MOD(m.m_id,v_recordset) = v_n_subset 
            AND c.c_fk_id = old_product_id --value obtained from another subsystem
            AND c2.c_fk_id = new_product_id --value obtained from another subsystem
            AND t.t_del_flag = 0 --not deleted items
        ) T2
        ON (T1.t_id = T2.t_id)
        WHEN MATCHED THEN
          UPDATE T1.t_fk_id = T2.m_new_id, T1.t_fk2_id = T2.c_id, T1.t_last_update = trunc(sysdate)
        ;
        --Update the record as migrated and proceed
        COMMIT;
      EXCEPTION WHEN OTHERS THEN
        ROLLBACK;
      END;
  END LOOP;
END;

在上面的脚本中，我删除了并行和缓存选项，但我已经测试了两者，但我没有获得任何错误结果。

任何人，请！你们能帮我解决这个问题吗，在一个多星期内我无法达到预期的时间，有什么想法吗？

MIGRATION_TABLE

CREATE TABLE MIGRATION_TABLE(
 m_customer_from VARCHAR2(5 BYTE),
 m_customer_to VARCHAR2(5 BYTE),
 m_old_id NUMBER(10,0) NOT NULL,
 m_new_id NUMBER(10,0) NOT NULL,
 m_status VARCHAR2(100 BYTE),
 CONSTRAINT M_MIG_PK_1
 (
  m_old_id 
 )
 ENABLE
)
CREATE UNIQUE INDEX M_MIG_PK_1 ON MIGRATION_TABLE (m_old_id ASC)

子表

CREATE TABLE ChildTable(
 c_id NUMBER(10, 0) NOTE NULL,
 c_fk_id NUMBER(10, 0),
 c_name VARCHAR2(100 BYTE),
 c_date DATE,
 c_note VARCHAR2(100 BYTE),
 CONSTRAINT C_CT_PK_1
 (
  c_id
 )
 ENABLE
)
CREATE UNIQUE INDEX C_CT_PK_1 ON ChildTable (c_id ASC)
CREATE UNIQUE INDEX C_CT_PK_2 ON ChildTable (c_name ASC, c_fk_id ASC)
4

3 回答 3

1

方法 2 与方法 1 类似，但它使用的是 ROWID 而不是主键。理论上，它应该因此更快一些。

CREATE TABLE migration_temp NOLOGGING AS
SELECT t.t_id, 
       t.rowid    AS rid,
       m.m_new_id AS new_fk1_id, 
       c2.c_id    AS new_fk2_id 
  FROM MIGRATION_TABLE m
  JOIN Tab1 t        ON t.t_fk1_id = m.m_old_id
  JOIN ChildTable c1 ON c1.c_id = t.t_fk2_id
  JOIN ChildTable c2 ON c1.c_name = c2.c_name
 WHERE t.t_del_flag = 0
 ORDER BY t.rowid;
EXEC DBMS_STATS.GATHER_TABLE_STATS(null,'migration_temp');

MERGE INTO Tab1 t USING migration_temp m ON (t.rowid = m.rid)
 WHEN MATCHED THEN UPDATE SET 
      t.t_fk1_id = m.new_fk1_id,
      t.t_fk2_id = m.new_fk2_id,
      t.t_last_update = trunc(sysdate);

您可以考虑基于 ROWID 块对 MERGE 进行批处理。这些往往在逻辑上位于同一位置，因此应该更快一些。

于 2020-05-06T20:23:42.480 回答
0

哇，5.2 亿行！但是，更新其中的 250 万个只有 0.5%，这应该是可行的。不知道你的数据，我的第一个假设是 MERGE 中 Tab1 x Tab1 的自连接占用了大部分时间。可能还有许多连接到迁移表和子表。并且索引 T_IN_1、2 和 3 也需要维护。

正如您所说的要更新的行是固定的，我会尝试准备繁重的工作。这不会锁定表，也不会计入停机时间：

CREATE TABLE migration_temp NOLOGGING AS
SELECT t.t_id, 
       m.m_new_id AS new_fk1_id, 
       c2.c_id    AS new_fk2_id 
  FROM MIGRATION_TABLE m
  JOIN Tab1 t        ON t.t_fk1_id = m.m_old_id
  JOIN ChildTable c1 ON c1.c_id = t.t_fk2_id
  JOIN ChildTable c2 ON c1.c_name = c2.c_name
 WHERE t.t_del_flag = 0;

我省略了旧/新 product_ids 的位，因为我不完全理解它应该如何工作，但希望这不是问题。

方法 1 是通过主键连接：

ALTER TABLE migration_temp ADD CONSTRAINT pk_migration_temp PRIMARY KEY(t_id);
EXEC DBMS_STATS.GATHER_TABLE_STATS(null,'migration_temp');

MERGE INTO Tab1 t USING migration_temp m ON (t.t_id = m.t_id)
 WHEN MATCHED THEN UPDATE SET 
      t.t_fk1_id = m.new_fk1_id,
      t.t_fk2_id = m.new_fk2_id,
      t.t_last_update = trunc(sysdate);

我不喜欢批量更新。由于您有时间估计，看起来您有一个测试系统。我建议试一试，分批尝试。

于 2020-05-06T20:20:03.963 回答
0

如果方法 1 和 2 仍然太慢，你可以按照你的分区想法。例如，引入一列来区分要迁移的行。因为DEFAULT ... NOT NULL这样会非常快：

ALTER TABLE Tab1 ADD (todo NUMBER DEFAULT 0 NOT NULL);

现在将您的表分成两个部分，一个包含迁移数据，一个包含您不会触及的其余部分。在应用程序运行时引入分区我没有太多经验，但我认为这是可以解决的，例如在线重新定义或

ALTER TABLE Tab1 MODIFY 
  PARTITION BY LIST (todo) (
  PARTITION pdonttouch VALUES (0),
  PARTITION pmigration VALUES (1) 
) ONLINE UPDATE INDEXES (
  T_ID_PK GLOBAL, T_IN_1  GLOBAL,
  T_IN_2  GLOBAL, T_IN_3  GLOBAL
);

现在您可以识别要移动的行。这可以逐行完成，不会影响其他进程，也不应计入您的停机时间。迁移行将从一个分区移动到另一个pdonttouch分区，pmigration因此您需要启用行移动。

ALTER TABLE Tab1 ENABLE ROW MOVEMENT;
UPDATE Tab1 SET todo=1 WHERE .... JOIN ...;

现在您可以在分区上工作PMIGRATION并更新那里的数据。这应该比原始表快得多，因为分区的大小只有整个表的 0.5%。不过，不知道索引。

从理论上讲，您可以创建一个与 具有相同结构和数据PMIGRATION的表，在该表上工作，一旦完成，将分区和工作表与EXCHANGE PARTITION. 再次不知道索引。

于 2020-05-06T21:32:13.177 回答