ITPub博客

首页 > 数据库 > Oracle > 海量数据迁移之误操作和防范建议

海量数据迁移之误操作和防范建议

Oracle 作者:rh_linux 时间:2014-10-14 22:40:31 0 删除 编辑
在生产环境的数据迁移中,发生误操作真是很不愿意看到,今天自己总结了一下,从个人的经验来看有以下的几种操作或者是失误导致的问题。有一些错误自己已经犯过。

外键
不管是使用imp/impdp,sqlldr还是使用Insert append的方式导入数据,如果存在外键的约束,在数据导入前最好都设置为disable,要不数据导入的时候很可能发生冲突,因为批量的数据导入很可能开启多个并发进程,如果你不能完全控制导入的先后顺序,最好还是disable掉。

触发器
触发器在数据导入前最好和开发组确认,如果忽略了这个潜在问题,很可能在数据导入之后,会多出来一部分的数据,而且从日志中没有任何错误。

密码的设置
为了杜绝在多个环境中切换带来的问题,最好在一些登录密码的设置上进行严格控制,如果你一边连着测试环境,一边开着生产环境的窗口,不小心把环境混淆的情况下,那就是数据灾难了,而且个人的建议都是通过一些工具,都不要保存密码,这样会提醒你到底连入的是什么环境。

创建临时账户
在数据迁移的时候,如果表的数据都在某一个schema下,个人建议最好创建一个临时的schema,给这个临时的schema赋予指定的权限,比如数据抽取的临时schema只赋予select权限,对于数据加载的临时schema,则只赋予insert的权限。如果你不管三七二十一,在源schema里面做所有的操作,很容易犯低级错误。一旦发生问题,那也是不可挽回的。

关于命令的历史
如果你已经习惯使用ctrl+p,或者上下箭头来运行历史命令,自己不想敲命令的话,一定要小心,
可能上一个命令是nohup命令,那么你一旦操作过快,急急忙忙敲回车的话,也是很严重的问题。


vi可能导致的问题
vi本身不是问题,但是个人建议vi的改动最好还是尽量在另外一个目录下备份一份,改动完成之后从另外的目录copy过来。这样一旦发生问题也能知道是不是改动导致的。

回车和空格

如果你接入一个环境,呈现在你面前的是一个空屏幕,这个时候不要随意按回车键,保守的方式就是空格键,看看是否是光标显示不够完整,有很多时候都是显示的不够完整,但是可能命令已经通过历史记录给调出来了。随意按了回车,就是可能的灾难。

数据备份
数据的备份,这个从系统级,数据库级,表级都可以做一些工作。我在这所说的数据备份,可能更侧重于说表级的备份,如果有足够的空间,可以考虑对很关键数据量大的表做表级备份,如果只是做了exp/expdp的备份,那么一旦出现问题,你还需要大量的时间和系统资源去导入到一个临时的schema或者其他的地方,这个就耗时费力了。可以使用create table xxx nologging的方式,如果表很大,加个并行还是比较快的。

迁移方式
这里想说说大家常用的迁移方式,可能数据量小的时候,使用imp/impdp就可以,数据量稍大一些,impdp或者sqlldr就可以,如果数据量更大,就可以考虑sqlldr或者外部表了。
个人的感觉来说imp/impdp/sqlldr都属于物理级的数据加载,外部表的数据加载才是逻辑级别的。
举几个场景,
如果表很大的情况下,impdp的导入会耗费很多的资源,直到数据完全导入,才是释放Undo资源,一旦发生问题,比如undo资源不足,就会直接报错,这个时候可能会耗费很多的时间和资源。
在数据导入之前,你不可能从imp/impdp的dump文件中查看到表的数据,如果发生数据冲突,也是在数据导入的时候才可能发现,sqlldr可能还可以查看一部分数据,但是不够直观,数据都是行列形式的文件,你不能通过sql语句等形式来检查数据。如果有数据问题,也是在数据导入的过程中才可能发现。
即使你想对数据进行预检查,那么你可能得用Impdp或者sqlldr的形式把数据先加载到一个临时的用户下,那么问题就来了,你得准备足够多的空间资源,而且导入的过程中队系统负载也是很大挑战。在这一点是外部表要更胜一筹,无须准备额外的空间,外部表就更创建一个同义词的感觉一样,加载卸载都是很快的,秒级别的操作。

唯一性约束和主键
如果你在考虑性能的时候,在数据导入前删除了主键和唯一性约束,那么如果存在数据冲突,或者误操作导致数据加载了多次的时候,你就给自己挖了一个坑,到时候出现问题,很难从头查起。个人建议还是保留唯一性约束和主键,尽管性能会打折扣但是也是值得的付出。

网络中断
这个问题自己碰到过几次,如果脚本在运行的过程中发生网络中断,你就会马上崩溃了。这个时候还是保守一些,一些脚本的运行还是考虑使用nohup的形式来。
要不中途发生问题,你都不知道该从哪开始继续。

磁盘空间不足
如果数据导入的过程中发生空间的问题,使用sqlldr的时候你就得仔细的查看日志文件,慢慢一个一个修复吧。最好还是给30%左右的buffer,别自己为难自己。
如果使用外部表的话,可能会有大批的外部表导入失败,那么你就得查看日志,慢慢的手动修复。如果问题比较多,那工作量可想而知。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1696240/viewspace-1298967/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-05-18

  • 博文量
    43
  • 访问量
    163200