在生产环境中的数据迁移还是很惊心动魄的，毕竟生产的数据不容许有任何潜在的问题，很小的问题也可能导致业务的终端，这个时候dba的角色是很重要的，如果dba犯了一个很细小的问题，在海量数据迁移中可能会导致灾难性的结果，所以今天和大家讨论一下关于由vi误操作导致的问题及总结。
结合今天早上的例子来说明。
目前生产环境已经有大量的用户数据了，需要从老系统迁移一批用户数据过来，一切都在安装好计划进行准备和操作。我是采用了外部表的方式，把一个很大的表分为了几十上百个外部表，采用insert方式加载的。
数据的准备工作很快就完成了，一切都在等待最后的客户确认就准备开始运行脚本做数据批量加载了。结果当时查看系统资源，觉得可以把原本的10个并发进程该为12个。就简单的改了一下脚本。
这个时候就用vi很快的改完了，但是在数据加载的时候报了很多的错误，最开始以为是数据的问题，就发给数据迁移组去检查了。自己也在同时做一些检查，我采用了错误日志的方式来忽略主键冲突，唯一性冲突的数据。
关于错误日志的部分，可以参考数据紧急修复之启用错误日志 http://blog.itpub.net/23718752/viewspace-1192887/
但是奇怪的是，一共有5个表有数据问题，结果检查了3个，最后都是0 rows inserted.我就怀疑是什么地方出现问题了，数据已经加载进去了。应该是在加载第二次的时候全都失败了。
我就开始检查脚本的执行历史，没有发现问题，最后在一个小细节上发现了问题。
在使用ls -l查看文件的时候，有一个很特别的文件引起了我的注意。根据我的印象，这个文件时在用vi编辑的时候，本来退出vi应该为:q ，结果打错了，达成了;q 然后一不留神生成了一个;q的文件。
-rw-r--r-- 1 produser dba 201 Oct 9 23:44 par7_tab_parall.lst
-rw-r--r-- 1 produser dba 208 Oct 9 23:44 par8_tab_parall.lst
-rw-r--r-- 1 produser dba 198 Oct 9 23:44 par9_tab_parall.lst
-rw-r--r-- 1 produser dba 341 Oct 9 23:46 ;q
-rw-r--r-- 1 produser dba 135337 Oct 10 00:34 split_par_10_appendata.log
-rw-r--r-- 1 produser dba 116826 Oct 10 00:26 split_par_11_appendata.log
-rw-r--r-- 1 produser dba 113885 Oct 10 00:56 split_par_12_appendata.log
-rw-r--r-- 1 produser dba 169947 Oct 10 00:39 split_par_1_appendata.log
-rw-r--r-- 1 produser dba 143857 Oct 10 00:09 split_par_2_appendata.log
-rw-r--r-- 1 produser dba 124105 Oct 9 23:59 split_par_3_appendata.log
-rw-r--r-- 1 produser dba 114643 Oct 10 00:49 split_par_4_appendata.log
-rw-r--r-- 1 produser dba 143102 Oct 10 00:18 split_par_5_appendata.log
-rw-r--r-- 1 produser dba 141416 Oct 10 00:32 split_par_6_appendata.log
最后在不经意中查看这个文件的时候却运行了文件的内容。
查看命令历史的时候发现这个命令触发了两次。
281 nohup ksh tmp_split_par_6_appendata.sh > split_par_6_appendata.log &
282 nohup ksh tmp_split_par_7_appendata.sh > split_par_7_appendata.log &
283 ksh check.sh|grep process
...
295 ksh check.sh|grep process
296 nohup ksh tmp_split_par_7_appendata.sh > split_par_7_appendata.log &
297 ksh check.sh|grep process
298 ksh check.sh|grep process
找到问题的来源了，就可以确定问题的影响范围了，通过错误日志对数据进一步进行了检查，发现数据没有问题了。
对于这个问题的总结由以下几点：
首先尽量不要在生产环境进行脚本的修改，不要在生产环境中随意测试脚本，以免不必要的麻烦。这个需要准备工作要更加的充分。
对于数据的导入中，个人建议还是保留主键和唯一性约束，这样可以避免很多数据的误操作带来的大问题。如果数据导入出现问题，要么是约束无法enable，要么主键无法创建，而且越是大的表在创建索引的时候也是需要一定的时间的，如果涉及的表有上百个，不能保证你的操作完全没有问题。可能几个表出现问题就需要花费较多的时间来修复。
对于日志的记录还是建议能够尽量的全面和完整，有些系统升级甚至有截屏之类的，都可以参考，在发生问题之后，能够很快的定位和总结，避免之后再犯。
在数据的迁移之前，对数据的条数进行一个完整的统计，在数据迁移完成之后再进行一个统计，保证没有数据条数不一致的情况。
不管怎么样，误操作是系统升级成败的关键，在发生误操作之后需要冷静，认真的分析问题的原因。可能有些问题还真不是问题，尽量不要着急开始做决定，以免问题雪上加霜。
最后经过确认，这个问题没有造成影响，数据的条数都是完全匹配的。下次注意。