数据迁移中需要考虑的问题(r2第15天)

在生产环境中,做数据迁移需要考虑很多的可能性和场景,尽量排除可能发生的问题。我自己总结了下,大体有如下需要注意的地方。 1)充分的测试,评估时间,总结经验,提升性能 在生产中进行数据的大批量迁移时,充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考,另外一方面可以基于之前的测试,总结经验,总结不足之处,加入改进,在生产中每一分钟的改进都是很重要的。 2)完整的备份策略 热备甚至冷备 在数据迁移之前进行完整的备份,一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份越充分,出现问题时就有了可靠的保证。 lob数据类型的备份,做表级的备份(create table nologging....) 对于lob的数据类型,在使用imp,impdp的过程中,瓶颈都在lob数据类型上了,哪怕表里的lob数据类型是空的,还是影响很大。 自己在做测试的时候,使用Imp基本是一秒钟一千条的数据速度,impdp速度有所提升,但是parallle没有起作用,速度大概是1秒钟1万条的样子。 如果在数据的导入过程中出了问题,如果有完整快速的备份,自己也有了一定的数据保证,要知道出问题之后再从备份库中导入导出,基本上都是很耗费时间的。 3)网络 网络带宽 网络是很重要的一个因素,数据迁移的时候肯定会从别的服务器中传输大量的文件,dump等,如果网络太慢,无形中就是潜在的问题。 可以使用scp来进行一个简单的测试,如果存储还不错的话,一般在50M左右/每秒 的速度 网络临时中断 网络的问题需要格外重视,可能在运行一些关键的脚本时,网络突然中断,那对于升级就是灾难,所以在准备脚本的时候,需要考虑到这些场景,保留完整的日志记录。 可以使用nohup来做外后台运行某些关键的脚本。这样网络断了以后,还有一线希望。 4)完整的日志 在数据迁移,数据升级的时候,一定要保留完整的日志记录,这样如果稍候有问题,也可以及时查验,也可以避免很多不必要的纷争。如果有争议,可以找出日志来,一目了然。 5)存储 存储也是很重要的一个方面。从系统角度来考虑,需要保证io的高效性。可以使用iostat,sar等来评估 还可以使用如下的脚本简单来测试一下。 time dd if=/dev/zero bs=1M count=204 of=direct_200M 6)归档空间 数据迁移的时候会有大量的日志产生,一定需要保证归档空间足够大,及时的转移归档文件。排除归档爆了以后数据的问题,使用sqlloader,impdp等数据迁移策略的时候,如果归档出了问题,是很头疼的问题。 7)表级nologging 如果条件允许,可以考虑对一些相关的表开启nologging,在数据迁移之后再设置logging. 对速度有一些的提升,如果使用insert /*+append */的时候,那速度就很明显了。 8)index级nologging 数据的insert操作,如果没有index速度很有成倍的提高,但是在生产中可能并不能建议这么做,如果重建索引的时候,也需要一定的时间,还需要一定保证索引和之前一定要没有任何的差错。所以一般来说,如果开启Index的nologging也会有一定的提升。 9)lob级nologging 对于lob数据类型来说,在允许的条件下,可以设置为nologging,速度会有所提升。 10)foreign key 外键的影响需要重视,如果外键存在对于数据的插入顺序无形中对会有一定的约束,所以在大批量的数据并发插入条件下,disable foreign key,可以更加高效,当然在enable foreign key的时候需要花费一些时间,做为数据检查。 11)trigger的影响 tigger在数据的dml操作中都有这潜移默化的影响,所以对于trigger最好和开发部分做确认,是否需要禁用trigger 12)materialized view log的影响 有些外部系统可能为了数据同步,可能会在系统中创建一些物化视图日志,可以和他们做一个确认,删除物化视图日志,减少数据插入的时候物化视图日志的影响, 还有一个问题就是物化视图日志会使rename table等操作无法进行。 13)godlengate的影响 goldengate的影响不容小视,需要和部分做一个确认在数据迁移之前停掉goldengate相关的进程。 14)主键冲突数据排除 主键冲突数据的排查是一个很重要的环节,如果之前的准备工作不到位,到了生产之后,那就是数据灾难。大半夜修复数据的痛苦真是不言而喻啊。如果数据前一部分不给力,你就得给力,想想办法来排查吧。 14)constraint级的数据不一致 这种问题存在而且很隐蔽,比如如下的错误。就是not null constraint在源schema中不存在,在导入目标库的时候出问题了。

cannot insert NULL into ("xxxx"."test_data"."TOT_OBLIGATION_PCT")

对于这类问题需要和数据迁移组协调,尽可能保证constraint的一致性。 15)undo的考虑 对于数据迁移来说,对于undo的空间来说是极大的挑战,可能在Impdp的时候除了Undo的问题,那就是极为奔溃的问题了。 还要考虑undo_retention的设置,可以在数据迁移之前可以把retention调低一些,保证undo的使用率足够用

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-06-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

快速定位隐蔽的sql性能问题及调优(r5笔记第38天)

在前几天,有个开发同事问我一个问题,其实也算是技术救援,他说在有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环...

3656
来自专栏数据库

MongoDB距“干掉”MySQL登上王位还有多远

【IT168 资讯】几十年来,关系型数据库已经成为企业应用程序的基础,自从MySQL在1995年发布以来,深受企业的偏爱。然而随着近年来数据量和数据的不断激增,...

2226
来自专栏BeJavaGod

网站平台架构演变史(三) - 数据库表的查询优化

上篇说道了数据库读写分离,对于大型网站来说这么说是十分有必要的。数据库在整个互联网架构中担当的角色无法有两个,存储和运算,很多时候这两个是并存的,但是在后期,对...

3837
来自专栏CSDN技术头条

容器化RDS|计算存储分离架构下的IO优化

在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Sensi...

3046
来自专栏数据和云

实践实战:在PoC中的Oracle 12c优化器参数推荐

最近,Oracle数据库优化器的产品经理 Nigel Bayliss 发布了一篇文档,介绍:Setting up the Oracle Optimizer fo...

944
来自专栏Java进阶干货

三思!大规模MySQL运维陷阱之基于MyCat的伪分布式架构

分布式数据库,已经进入了全面快速发展阶段,这种发展,是与时俱进的,与人的需求是分不开的,因为现在信息时代的高速发展,导致数据量和交易量越来越大。这种现象首先导致...

4791
来自专栏木子昭的博客

IP查询有啥用?

在线地址: https://fangyuanxiaozhan.com/demo/ip

1213
来自专栏匠心独运的博客

在实践中使用ShardingJdbc组件的正确姿势(一)

在互联网时代,随着业务数量的暴增和应用规模的不断扩大,无论是oracle还是mysql这样子的关系型数据库,都会面临服务器CPU、磁盘IO和内存的各种瓶颈问题。...

1871
来自专栏杨建荣的学习笔记

DBA和开发同事的一些代沟(一)(r7笔记第17天)

DBA同学在工作中不可避免和开发同学打交道,和开发的同学在交流中还是有不少的小插曲,有些想想也蛮有意思,但是有些是痛点。 我举几个例子来说明,可能比较片面,但是...

3505
来自专栏数据和云

在线重定义“巧改”分区表

作者介绍: 曾令军,云和恩墨技术专家,2009年开始接触ORACLE数据库,8年数据库运维经验。思维敏捷,擅长于数据库开发、解决棘手的数据库故障和性能问题。服务...

3636

扫码关注云+社区