Oracle 19c 迁移遇到大容量 lob 表怎么办?

发布于:2020 年 8 月 2 日 10:00

Oracle 19c迁移遇到大容量lob表怎么办?

本文由 dbaplus 社群授权转载。

背景

从 Oracle 数据库官方服务支持生命周期表,我们可以清晰看到 Oracle 11g 已过主支持生命周期,2020 年后不再支持。基于这个背景,某客户的应用系统数据库将从 IBM AIX 小型机环境迁移到某国产数据库一体机,同时数据库版本从 11g 直接升级为 19c。

Oracle 19c迁移遇到大容量lob表怎么办?

LOB 字段带来的问题

经过分析,此数据库的数据量不大,只有区区 3TB,同时由于停机时间非常充分,可以考虑采取数据泵 datapump 的方式实现数据迁移。但是在仔细查看后,发现数据库中有个单表 2TB,仔细再查 2TB 基本全是 lob 字段,且不是分区表,这个问题就有点棘手了。

Oracle 19c迁移遇到大容量lob表怎么办?

根据以往的经验来看,这种大容量 TB 级的 lob 表,使用以往常规导出的方式,大概率会报 Ora-01555。

Oracle 19c迁移遇到大容量lob表怎么办?

稍稍测试一下,果不其然。

解决方法

一般的方法可以修改一下 undo_retention 参数以及 lob 字段的 retention 设置来解决,大致如下:

复制代码
alter system set undo_retention=7200 scope=both;
alter table table_name MODIFY LOB(col_name)(retention);

然而当前的数据库是一个生产环境,参数修改这样的风险工程还是少做为妙,因此需要另辟蹊径。既然 ORA-01555 是由于长时间查询引起,我们可以尝试减少倒出的数据量。

最后决定用 Expdp 的 Query 试一试,但是 2TB 的数据量的单表 lob 还是第一次,那么根据哪个条件进行 Query 导出呢?

首先需考虑到是根据主键和索引列进行导出,这样的效率会比较高。确认后,问题又来了,索引列不满足均匀分批条件,故这个思路走不通了。

要怎样才能均分呢?看来只能用 Rowid 试试看。

首先 Rowid 是用于定位数据库中一条记录的一个相对唯一地址值。通常情况下,该值在该行数据插入到数据库表时即被确定且唯一。Rowid 是一个伪列,它并不实际存在于实体表中。

它是 Oracle 在读取表中数据行时,根据每一行数据的物理地址信息编码而成的一个伪列。所以根据一行数据的 Rowid 能找到一行数据的物理地址信息,从而快速地定位到数据行,而且使用 Rowid 来进行单记录定位速度是最快的。

Oracle 19c迁移遇到大容量lob表怎么办?

上图是 Rowid 的结构图,主要包含 4 个部分:

  • 第一部分 6 位表示:该行数据所在的数据对象的 Data_object_id
  • 第二部分 3 位表示:该行数据所在的相对数据文件的 id
  • 第三部分 6 位表示:该数据行所在的数据块的编号
  • 第四部分 3 位表示:该行数据的行的编号

一个扩展 Rowid 采用 10 个 byte 来存储,共 80bit,其中 obj#32bit, rfile#10bit, block#22bit, row#16bit。所以相对文件号不能超过 1023,也就是一个表空间的数据文件不能超过 1023 个(不存在文件号为 0 的文件),一个 Datafile 只能有 2^22=4M 个 block,一个 block 中不能超过 2^16=64K 行数据的由来。

了解了 Rowid 后,怎么进行均匀分批呢?我们可以利用 Oracle 提供的 DBMS_ROWID 包。

Oracle 19c迁移遇到大容量lob表怎么办?

导出脚本修改如下

Oracle 19c迁移遇到大容量lob表怎么办?

参数说明

  • Content=DATA_ONLY:只导出表中的数据,导出会更快,导入时也更快,index 之类的对象在 data 导入后单独处理;
  • COMPRESSION=DATA_ONLY:数据量太大,节省空间,传输到新环境时效更高;
  • Query=“……”:将表数据根据条件进行分批导出全部数据。

为什么选用 rowid_block_number 呢?因为导出这个大表的需求下,Object_id 就一个,分不了批次,Fileid 只有 150 个,BLOCK_ID 是 126924 个,ROW_NUMBER 是 19,数据量数值进行 Mod 取余分批的差异就越小,所以使用 rowid_block_number。使用这个方法后还是很顺利地导出了数据。

Oracle 19c迁移遇到大容量lob表怎么办?

将参数文件复制并修改取模的余数值,分为十个进程并发执行。查看全部导出日志,每个批次耗时相差不大,满足均匀分批导出的计划。

Oracle 19c迁移遇到大容量lob表怎么办?

小结

遇到超大 lob 表导出需要,一般的思路是尽可能通过分区或者过滤查询减少单表数据导出的数据量,减少整体耗时,办法可以分为:

1、查看是否是分区表,分区表的话按分区导出

复制代码
userid=' / as sysdba'
directory=DMP
dumpfile=export.dmp
logfile=export.log
CONTENT=DATA_ONLY
COMPRESSION=DATA_ONLY
tables=(
onwer.tbale_name:part_name
)

2、业务沟通,是否存在均匀分布的字段值,按照字段值分批导出,例如

复制代码
USERID=' / as sysdba'
directory= DMP
CONTENT=DATA_ONLY
COMPRESSION=DATA_ONLY
dumpfile=export.dmp
logfile=export.log
tables=owner.table_name
QUERY="WHERE column_name > 100000

3、不满足以上的都可以使用本文 rowid 方式进行导出

复制代码
Cat exp_owner_table_seq.par
USERID='/ as sysdba'
directory= DMP
CONTENT=DATA_ONLY
COMPRESSION=DATA_ONLY
dumpfile=export.dmp
logfile=export.log
tables=owner.table_name
QUERY="wheremod(dbms_rowid.rowid_block_number(rowid),10)=1"

作者介绍

梁铭图,新炬网络首席架构师,十多年数据库运维、数据库设计、数据治理以及系统规划建设经验,拥有 Oracle OCM、Togaf 企业架构师(鉴定级)、IBM CATE 等认证,曾获 dbaplus 年度 MVP 以及华为云 MVP 等荣誉,并参与数据资产管理国家标准的编写工作。在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

王涛,新炬网络资深数据库专家,长期服务于运营商、金融、制造业及政企客户。扎根客户一线,多次主导运营商数据库大版本升级,擅长数据割接及同步技术的研究和应用,割接实战经验丰富。

原文链接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650792712&idx=2&sn=742813cf08dccc3eede90b5e477ca083&chksm=f3f9569dc48edf8bf9dd0af84d5d768755b44f98b7e188c2553187aa5f7bbcf507f2c7530b32&scene=27#wechat_redirect

阅读数:892 发布于:2020 年 8 月 2 日 10:00

更多 数据库、Oracle、最佳实践 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 核心系统 Oracle 19c 数据库迁移方式对比与实践

    Oracle 19c及前面版本中引入的许多新特性以及增强属性,例如12c中引入的cdb与pdb,19c中引入的自动化索引(Automatic indexing)等全新特性也吸引着企业逐步将老旧数据库升级迁移到新版本,以应用全新的数据库特性。

    2020 年 9 月 16 日

  • 使用 Apache Hadoop、Impala 和 MySQL 进行数据分析

    Apache Hadoop是目前被大家广泛使用的数据分析平台,它可靠、高效、可伸缩。Percona公司的Alexander Rubin 最近发表了一篇博客文章介绍了他是如何将一个表从MySQL导出到Hadoop、将数据加载到Cloudera Impala并在这上面运行报告的。

    2014 年 5 月 8 日

  • 高性能数据库集群:分库分表

    今天我来介绍常见的分散存储的方法“分库分表”,其中包括“分库”和“分表”两大类。

    2018 年 5 月 31 日

  • 实操:从 Oracle 到 GaussDB 的数据迁移

    本文介绍利用SDR将从Oracle到GaussDB的数据迁移的经验。

    2020 年 2 月 21 日

  • GaussDB 迁移实战:我的 DataSync 工具使用心得

    本文介绍使用DataSync工具进行迁移测试的经验。

    2020 年 3 月 10 日

  • 设计数据持久层(上):理论分析

    讲一讲最后面一层的数据持久层怎样设计,使整个设计层面上的体系变得完整。

    2019 年 11 月 6 日

  • 数据设计测试分析方案

    支付宝从2009年开始进行1111大促开始,从2009年大促600w 的交易量到2013年大促那天2亿的交易量;在这四年中,支付宝系统的容量经历了每年指数级的提升;如果需要支持这么大的容量的话,初步估算,一个支付系统至少得支持每天30亿次的数据库事务,150亿次的dao访问,30T的数据包传输;如果不进行数据库拆分,这么大的开销单靠一台物理db完全是支撑不了的,所以必须对单点的物理db进行拆分

    2014 年 5 月 21 日

  • 为什么这些 SQL 语句逻辑相同,性能却差异巨大?

    今天我给你举了三个例子,其实是在说同一件事儿,即:对索引字段做函数操作,可能会破坏索引值的有序性,因此优化器就决定放弃走树搜索功能。

    2018 年 12 月 24 日

  • 40 丨 SQLite:为什么微信用 SQLite 存储聊天记录?

    当我们在Chrome、Safari和Firefox等浏览器客户端中使用WebSQL时,会直接操作SQLite。

    2019 年 9 月 4 日