生产环境数据迁移问题汇总(r2第16天)

在测试环境中做了3轮数据迁移的演练,最终到了生产环境中,还是出现了不少问题,经过大半夜的奋战,终于是数据都迁移成功了。 1)共享存储的配置问题 共享存储使用NFS来共享存储,但是在实际操作中发现配置出了问题,原因是因为两台服务器上的用户不同在,目标机器上没有任何写权限。

-rw-r--r-- 1 3160 dba      6608 Jun 26 23:35 tmp_gunzip.sh        
-rw-r--r-- 1 3160 dba       624 Jun 26 23:30 tmp_gzip.sh          
oraccbs1@ccbdbpr3:/ccbs/migration/ext_datapump/DUMP> ksh gunzip.sh
gunzip.sh[1]: tmp_gunzip.sh: cannot create [Permission denied]    

最终还是采取了保守的方式,使用scp来传输文件。压缩文件后,文件的大小还是可以接受的。而且可以在数据迁移之前完成,虽然在稍后更正了nfs的配置,还是保守的使用了本地文件。 2)人为失误,遗漏了脚本 在数据迁移之前运行了一些脚本来设置table nologging,index nologging,disable trigger..结果把最重要的foreign key的脚本给遗漏了,结果在使用sqlldr加载数据的时候reject了部分的数据。 幸亏及时发现。赶紧执行disable的脚本,报了如下的错误,好吧,对于已经收影响的数据来说,只能通过.bad文件来逐一恢复数据了。 不过个人总结还是觉得对于异常情况的考虑需要需要比较充分,在出问题的时候才不会乱了阵脚。

ALTER TABLE xxxx DISABLE  CONSTRAINT xxxxx_ACCOUNT_1FK
            *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
ALTER TABLE xxxx_ACCOUNT disable  CONSTRAINT xxxx_ACCOUNT_1FK
            *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

最后使用如下的脚本来修复,收到影响的文件有70多个,大半夜修复数据真是压力和痛苦啊。不过还好,数据都最后成功加载了。

 #sqlldr xxxx/xxxx@xxxxcontrol=./TEST_LOG/TEST_BEN_sqlldr.ctl log=./TEST_LOG/Imp_sqlldr_TEST_BEN_10.log  direct=false parallel=true errors=10000000 bindsize=7500000 readsize=7500000 streamsize=7500000 rows=50000 data=./TEST_DUMP/TEST_BEN_10.dat  discard=./TEST_LOG/TEST_BEN_10.di               

3)内存导致的问题 在数据加载的过程中,cpu使用率一直上不去,开启了150个并行的insert进程,但是cpu使用率还是在90%左右,速度上不去。这和之前在测试环境的测试结果又很大的出入。 180G的内存,但是剩余内存却只有400多M

 top - 03:48:47 up 413 days, 57 min, 11 users,  load average: 7.22, 8.40, 8.79
Tasks: 1906 total,   1 running, 1905 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  0.6%sy,  0.0%ni, 98.9%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  189675188k total, 189233496k used,   441692k free,    30368k buffers
Swap: 377487328k total,    25844k used, 377461484k free, 117830432k cached

根据我的监控,发现对于大的分区表来说,剩余内存就耗尽了。并行插入数据的时候遇到了瓶颈,可能和生产库没有开启异步io有关,数据库参数为filesystem_io,当前设置为none,而在测试环境中则为setall. 而且根据我的观察Undo的使用率极高,按照之前的统计数据来说不会这么异常。 4)升级的过程中环境非法访问 按照约定,在升级的过程中,环境是不允许开发访问的,但是在这次数据迁移中,发现有一些资源消耗比较的sql语句都是从客户端发过来的。经过确认是客户的卡发人员想查验数据迁移的情况,这个会对数据的迁移造成一定的影响。可以通过修改数据库listener的端口号来进行屏蔽,在数据迁移完成之后,在修改端口重启监听即可,对于外部来说,就可以排除不必要的影响 5)统计信息的收集 数据迁移之后,统计信息的收集也是一个很关键的步骤,如果不进行统计信息收集,会导致执行计划有较大的误差。可能导致严重的性能问题。 但是生产系统中时间是最高贵的资源。收集统计信息会耗费不少的时间,这个时候可以根据表的大小来进行统计信息比例的调整。对于比较大的表来说,比例可以在40%左右,开启并行,速度会有一定的提升。 6)外部表加载的性能问题 在之前的测试中,外部表加载的性能还是不错的,但是在生产中发现速度一下子打了折扣,本来一分钟150万的数据加载速度。结果在生产中大概在4,5分钟的样子(150万条数据) 对于这个问题,可能还需要考虑并行的情况。因为cpu的使用率一直没有上去。需要考虑稍后抓取ash报告来查验当时倒底有哪些瓶颈。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏美团技术团队

美团点评数据平台Kerberos优化实战

28010
来自专栏IT大咖说

618大促,苏宁如何通过citus打造分布式数据库抗住DB高负载

内容来源:2017 年 10 月 20 日,苏宁云商IT总部资深技术经理陈华军在“PostgreSQL 2017中国技术大会”进行《苏宁citus分布式数据库应...

2142
来自专栏FreeBuf

搭建dvwa环境学习从MySql注入到GetShell

是啊,在项目上的系统每周每个月经过几十遍的过滤,平时看到提交参数的地方也就sqlmap跑一跑,对于最基础的手工注入都没有扎实的学会,于是我决定要知道如何搭建环境...

1203
来自专栏乐沙弥的世界

联机日志文件过小引发的log file 相关等待

      Oracle 联机重做日志文件记录了数据库的所有变化(DML,DDL或管理员对数据所作的结构性更改等),用于对于意外删除或宕机利用日志文件实现数据恢...

892
来自专栏数据和云

DBLINK分布式事务失败又遭遇RAC热点块争用

编辑手记:在DBLINK中由于远端数据库无法正常执行分布式事务,又遭遇RAC热块争用,两者共同作用导致数据库严重故障。接下来我们从AWR报告分析入手,一步步分析...

2995
来自专栏沃趣科技

Oracle压缩黑科技(一)—基础表压缩

原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-oracle-basic-ta...

2748
来自专栏腾讯技术工程官方号的专栏

PGXZ 腾讯分布式关系数据集群—架构解析

本文作者:数据平台部存储引擎组PGXZ项目负责人,2013年从华为加入腾讯,从事数据库和存储相关的工作。多年来一直致力于数据库引擎的研究和开发,从事过多款数据库...

31011
来自专栏安恒信息

安全漏洞公告

1 Apache Struts ParametersInterceptor任意代码执行漏洞 Apache Struts ParametersIntercepto...

2785
来自专栏数据和云

老司机带你在MySQL领域“大吉大利,晚上吃鸡”

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

702
来自专栏黑白安全

注入利器之“四人帮”

“注入”者,名如其义,在与对方数据库的一次次“别有用心”刺探访问中猜解出那些敏感信息的长要、范围,最终精确到点,颇有些让自己战友悄悄地打入敌人内部一样。看危险漫...

721

扫码关注云+社区