记一次数据上传

       周末接到通知有一笔400万左右的数据要传到oracle中。本来不算什么问题，如果顺利10分钟足以结束这项工作。

但考虑到一些非计划中的问题可能会发生，估计最多也就一个小时就能搞定回家。但最终却花了我好几个小时才完

成这项工作。下面总结一下这次数据上传到过程。

 

1.数据文件格式问题（未按照约定格式提供数据）

打开电脑收到邮件，同事已经把数据放到一个公共盘上。文件是xlsx格式的，而不是约定的csv格式。由于机器上装了转换插件，虽然是office2003也能打开xlsx格式的文件。但发现每个附件只有65536行数据。一共5个文件，加起来也就30多万。离400W差点太多。赶紧给同事电话确认。原来数据确实有400多万，但由于office版本的限制，我只能看到65536条。同事告诉了我他的机器是office2010，并告诉了我他的机器密码。登录上他的机器后，把excel转换成了csv。

 

为什么约定用csv格式呢？

a. 历史原因，以往这类数据都用csv格式，比较习惯。

b. csv格式，可以用UltraEdit或其它文本编辑器打开，可以不受office版本影响。

解决了数据文件格式问题后，开始准备测试。

 

2.日期格式问题

约定的日期格式为'yyyy-mm-dd',实际提供的是'mm/dd/yyyy'.这在调试的时候才发现。

于是又重新格式化excel的日期格式，另存为csv。

 

3.测试问题

在测试环境新建表，用sqlldr加载数据。除调整脚本外，其余都比较顺利。尝试加载了90多万条数据，很快就完成了。

于是准备到生产实施。由于测试环境新建表时，只建了我需要插入值的字段，并没有完全模拟生产环境中的表。

所以SQL Loader中设置的rows和BINDSIZE在生产中并不合适。导致第一次数据加载，比较慢。第二次调整rows

和bindsize后加载速度有所提升。

 

4.数据校验发现的问题

数据加载完毕，发现实际导入数据库中的数据，与excel中提供的数据记录并不一致。实际导入的记录竟然比excel中的记录还多。

这一下可有点冒汗了。。。生产环境数据出了问题，会有很大的影响，这可不是闹着玩的，弄不好就会遭到业务部门的投诉。

赶紧使用各种方法查找问题。。。为什么呢？

用history查看历史记录，发现每个数据文件都加载了一遍。没有问题。

又检查了一遍SQL Loader的控制文件，也没发现问题。

只有老老实实的写sql，查问题了。反反复复，搞了将近两个小时。也没发现数据有问题。

最后突然想起SQL Loader的一项伟大的功能.即Sql Loader能将数据加载中错误的数据写到bad文件中。

1.检查日志才发现，的确有些数据由于字段长度超长，没有加载到数据库中。

2.自己统计excel数据的时候，有个小失误，没统计准确。实际加载的数据是比excel中的数据要少的。

 

完成了这两项校验，发现数据没问题后，写邮件通知相关负责人。

回家，上了出租车，一看表已经是凌晨2点了。