【数据架构改造必读】一种零业务影响下的大表重构方法

简介:

目录

  • 快速改造表方法

  • 实例

 

随着信息技术的发展,业务的可用性要求越来越高,在高可用的环境中,如果需要改变表的定义是比较棘手的,特别是对于7x24的系统,需要停止业务来改造表定义的代价是非常大的。ORACLE提供的基本语法可以修改表的基本属性,但对于普通表、分区表、索引组织表之间的转换,是无法完成的,那么有哪些方法可以 转换呢?笔者在此给读者一个方法。


Part 1

 
 
 

方法介绍

 

在ORACLE优化过程中,经常会遇到普通表日积月累之后变大了,DBA一般建议改造成分区表,常用的改造方法、步骤如下:


1、 停业务,停监听等;

2、 将全表数据使用数据泵导出;

3、 DROP原表,新建分区表;

4、 将数据导入分区表中,恢复业务;


这样下来,一般需要停机几个小时,甚至需要熬夜实施。现在有一种方法,可以在线实施,并且不会影响业务,它就是在线重定义功能。(笔者已经多次成功实施)


从ORACLE 9i开始,提供了在线重定义的功能,通过调用DBMS_REDEFINITION包来实现,那它是如何实现的呢?我们先来了解下在线重定义。


在线重定义:通过调用DBMS_REDEFINITION包,在瞬间锁表的情况下,将表改造成理想的表。它使用数据同步原理,需要双倍空间(原来的表和索引 算一份),将数据全量同步到目标表,再做一次增量同步,这些过程都不会锁表,不影响业务使用,最后做一次增量数据同步和表定义对换,完成表转换,此时会锁 表,经验告诉笔者锁表时长在1s内(根据增量数据大小略有不同)。


常用场景:

1. 普通表、分区表、索引组织表之间的相互转换;

2. 将表迁移至其他表空间;

3. 修改表的存储属性;

4. 重建表以减少碎片;


优点:

1. 对业务影响非常小,锁表时间非常短,仅在结束时瞬间存在;

2. 速度较快,在实践中15G的表仅用了12min;


缺点:

1. 需要使用与原表同样大小的存储空间,包括索引、LOB字段等;

2. 需要占用一定的系统资源;


实现步骤:

1. 检查表能否进行在线重定义,通过主键或rowid两种方法;

2. 创建目标表结构,空表,索引等不用创建;

3. 开始进行在线重定义,先全量同步一次数据;

4. 同步依赖的对象,包括索引、约束、触发器、权限等;

5. 做一次增量数据同步;

6. 完成在线重定义;

7. 清理旧表,释放空间;

8. 收集统计信息,检查索引名,并行度等;


DBMS_REDEFINITION包:

1. ABSORT_REDEF_TABLE:清理重定义的错误和中止重定义;

2. CAN_REDEF_TABLE:检查表是否可以进行重定义;

3. COPY_TABLE_DEPENDENTS:同步依赖的对象,如索引、权限、约束、触发器等;

4. FINISH_REDEF_TABLE:结束在线重定义;

5. REGISTER_DEPENDENTS_OBJECTS:注册依赖的对象,如索引、约束、触发器等;

6. START_REDEF_TABLE:开始在线重定义;

7. SYNC_INITERIM_TABLE:同步增量数据;

8. UNREGISTER_DEPENDENT_OBJECT:不注册依赖的对象,如索引、约束、触发器等;


在线重定义支持两种重定义的方法,一种是基于主键,一种是基于ROWID。其中ROWID的方法是10G以后才支持,且不能用于索引组织表,而且重定义完成后会存在隐藏列M_ROW$$。默认采用主键的方式。


Part 2

 
 
 

小实验

 

在工作中,普通表转换成分区表是最常见的,今天一起和大家来做个小实验。


背景:需要将HJADM.REC_CODE_RESULT表改造成分区表HJADM. REC_CODE_RESULT_TARGET,目标表已经创建好了,原表存在主键。


第一步: 检查表能否进行在线重定义


\


总结:检查表通过主键可以进行重定义。如果表没有主键,那么使用rowid的方法,调用的是dbms_redefinition.cons_use_rowid。


第二步: 创建目标表


在实施前已经创建好表HJADM. REC_CODE_RESULT_TARGET。


第三步: 开始进行在线重定义


\

总结:开始进行重定义会比较慢,因为需要做一次全量数据同步。全量数据同步完成后,检查了一下记录数,已存在增量数据了。


第四步: 同步依赖的对象


\

总结:复制相关的依赖对象,完成后检查结果没有报错。若是9i的数据库,可以手工建立相关的对象。


第五步: 做一次增量数据同步


\

总结:结束重定义,此时会锁表,交换表涉及的数据字典中的相关数据。


第六步: 完成在线重定义


\

总结:结束重定义,此时会锁表,交换表涉及的数据字典中的相关数据。



第七步: 清理旧表,释放空间


\


总结:将旧表删除,以释放空间。


第八步: 收集表的统计信息,检查索引名、并行度等,检查无效对象,最好编译一下


PS:此步比较容易忘记。


总结:此表约有5G的数据,整个操作过程约10min完成,仅在完成重定义的时候锁了一下表,在1s内完成,对业务的影响几乎为零。


在线重定义的功能对7x24的OLTP系统有非常大的优势,在重定义的过程中,也不影响业务的使用,业务仍然可以对其访问、修改、新增、删除等操作,是实现数据库高可用的一个很实用的方法。分享就到此了,希望大家有所收获。


作者介绍:温伟灵

 

  • 新炬网络高级技术专家

  • 拥有六年的IT运维经验,从工作开始接触ORACLE数据库,精通ORACLE数据库的内 存结构、RAC、DataGuard等,在备份恢复、GoldenGate方面有深入的钻研。

  • 具有30TB级的OLTP数据库运维经验,擅长故障诊断、处 理。

  • 目前负责十多个客户的数据库运维工作,具有交通、金融、政府、移动、医疗等行业的运维经验。


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2015-12-27
目录
相关文章
|
3月前
|
存储 BI Shell
Doris基础-架构、数据模型、数据划分
Apache Doris 是一款高性能、实时分析型数据库,基于MPP架构,支持高并发查询与复杂分析。其前身是百度的Palo项目,现为Apache顶级项目。Doris适用于报表分析、数据仓库构建、日志检索等场景,具备存算一体与存算分离两种架构,灵活适应不同业务需求。它提供主键、明细和聚合三种数据模型,便于高效处理更新、存储与统计汇总操作,广泛应用于大数据分析领域。
381 2
|
2月前
|
数据采集 缓存 前端开发
如何开发门店业绩上报管理系统中的商品数据板块?(附架构图+流程图+代码参考)
本文深入讲解门店业绩上报系统中商品数据板块的设计与实现,涵盖商品类别、信息、档案等内容,详细阐述技术架构、业务流程、数据库设计及开发技巧,并提供完整代码示例,助力企业构建稳定、可扩展的商品数据系统。
|
14天前
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
83 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
3月前
|
SQL 缓存 前端开发
如何开发进销存系统中的基础数据板块?(附架构图+流程图+代码参考)
进销存系统是企业管理采购、销售与库存的核心工具,能有效提升运营效率。其中,“基础数据板块”作为系统基石,决定了后续业务的准确性与扩展性。本文详解产品与仓库模块的设计实现,涵盖功能概述、表结构设计、前后端代码示例及数据流架构,助力企业构建高效稳定的数字化管理体系。
|
23天前
|
JSON 供应链 监控
1688商品详情API技术深度解析:从接口架构到数据融合实战
1688商品详情API(item_get接口)可通过商品ID获取标题、价格、库存、SKU等核心数据,适用于价格监控、供应链管理等场景。支持JSON格式返回,需企业认证。Python示例展示如何调用接口获取商品信息。
|
2月前
|
数据采集 监控 数据可视化
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
本案例讲述了在豆瓣电影数据采集过程中,面对数据量激增和限制机制带来的挑战,如何通过引入爬虫代理、分布式架构与异步IO等技术手段,实现采集系统的优化与扩展,最终支撑起百万级请求的稳定抓取。
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
|
2月前
|
缓存 前端开发 BI
如何开发门店业绩上报管理系统中的门店数据板块?(附架构图+流程图+代码参考)
门店业绩上报管理是将门店营业、动销、人效等数据按标准化流程上报至企业中台或BI系统,用于考核、分析和决策。其核心在于构建“数据底座”,涵盖门店信息管理、数据采集、校验、汇总与对接。实现时需解决数据脏、上报慢、分析无据等问题。本文详解了实现路径,包括系统架构、数据模型、业务流程、开发要点、三大代码块(数据库、后端、前端)及FAQ,助你构建高效门店数据管理体系。
|
3月前
|
数据采集 存储 分布式计算
一文读懂数据中台架构,高效构建企业数据价值
在数字化时代,企业面临数据分散、难以统一管理的问题。数据中台架构通过整合、清洗和管理数据,打破信息孤岛,提升决策效率。本文详解其核心组成、搭建步骤及常见挑战,助力企业高效用数。
1054 24
|
2月前
|
SQL 数据采集 数据处理
终于有人把数据架构讲清楚了!
本文深入浅出地解析了数据架构的核心逻辑,涵盖其定义、作用、设计方法及常见误区,助力读者构建贴合业务的数据架构。
|
3月前
|
存储 Java 数据库连接
简单学Spring Boot | 博客项目的三层架构重构
本案例通过采用三层架构(数据访问层、业务逻辑层、表现层)重构项目,解决了集中式开发导致的代码臃肿问题。各层职责清晰,结合依赖注入实现解耦,提升了系统的可维护性、可测试性和可扩展性,为后续接入真实数据库奠定基础。
275 0

热门文章

最新文章