l 同步风险:各类同步架构下,数据订正可能导致同步堆积和同步延时,影响正常同步业务,
所以有些大规模订正必须要正确屏蔽同步,并在多个库分别执行相同的订正脚本。
l 缓存:有些表在应用层面做了缓存,制定订正计划的时候要考虑到订正后是否需要更新缓
存。
四、 操作流程
1. 准备工作
a) 需求分析阶段确认项目涉及的数据订正范围和数据量。
b) 跟开发人员确定订正后是否涉及到对缓存的刷新和订正。
c) 根据数据量评估对数据同步的影响,决定是否屏蔽同步。(应用 DBA 必须熟悉同步采用
的技术、正常情况下的同步量和延时、可以容忍的同步延时、屏蔽同步的具体方法。)
d) 注意规划订正速度,以防 undo 消耗殆尽。
e) 订正脚本:
i. 开发接口人直接提供可执行的 SQL 脚本,DBA 只负责拷贝执行。
ii. 开发接口人提供主键及更新字段新值列表,由 DBA 导入数据库,写 SQL 脚本关联原表
批量订正。
iii. 开发接口人提供订正逻辑,由 DBA 翻译为批量提交 SQL 脚本。
iv. 订正脚本要求可断点续跑,可反复执行。
v. 严禁仅用一个事务来处理大规模订正(影响的记录数超过 1 万笔)。超过一万笔的订正
必须分段提交。
vi. 确认订正脚本的执行计划正确。
vii. 脚本中加入“进度报告”,即调用如下包(但是对于 trigger 中判断 client_info 的不允许这
样处理。):
Dbms_Application_Info.set_client_info(n || ‘ rows commit.’);
–n 为变量,累加,表示当前订正的总记录数。
f) 开发阶段跟开发接口人确认数据订正逻辑,完成订正脚本,并跟开发接口人确认脚本是
否正确,同时按照需求准备备份脚本。
g) 测试阶段在测试库执行订正脚本,由开发接口人和测试人员验证订正的正确性,应用
DBA 协助验证。
h) 发布前确定订正速度和并发度,确定订正时间段,预估订正总时长,若涉及量较大,需
要跨天做订正,则应规划好每日订正的数据量和时间段。
i) 备份要求:
i. 新建表初始化:无需备份,回退时直接 truncate 即可。
ii. 现有表新增数据:新建备份表记录下新增记录的主键,或者在新增记录中特定字段标识
区分出订正所新增的数据,回退时定向 delete 这些记录。
iii. 现有表删除数据:新建备份表记录下删除数据的完整记录,回退时直接从备份表中取出
数据 insert 到原表。
iv. 现有表上新增字段初始化:无需备份,回退时将该字段 update 为 NULL 或者开发接口人
要求的值。不得将删除字段作为回退手段。
v. 现有表上现有字段值修改:新建备份表记录下所改动记录的主键及所改动字段的原始值,
回退时将改动过的字段按照主键更新到原表(若应用程序在回滚前已经修改了记录,则要
根据具体业务具体分析回滚方案)。
vi. 备份表:备份表统一命名为 table_name_bak_mmdd_operator,最后的 operator 为操作
评论0
最新资源