最近碰到这样一个问题，类似下面的架构形式。
目前应用1是一个另外一个网段的系统，负责一块业务，而应用2是目前我所负责的数据库所在的环境里。
现在因为业务需要，需要从应用1来推送一部分数据到应用2，只在一段时间推送，一段时间过后，就不再需要推送了。
最开始是两个应用team在商量这件事情，结果讨论来讨论去，发现没有DBA参与还搞不定，还好我介入也不算晚。
对于这种问题，其实整体难度来说不大，但是集成的事情很容易有各种不明确的地方，所以自己也从DBA的角度提了几点要求。
大体的需求是应用1需要推送一部分数据直接到数据库服务端，由DBA部署后提供给应用2使用，应用1的部门他们为了方便，推送的格式是csv文件。而且数据推送频率是一天一次。
基本上每天在特定的时间段都需要做一次这样的工作,大体是这样的情况。
对此我从DBA的角度提了几点要求。
首先是推送文件格式的确定，能够直接推送成sqlldr的ctl文件，我直接部署即可，结果商量来商量去，一来也是我怕他们推送的ctl文件格式有误，后面修改来修改去还扯皮，二来他们似乎也是怕有太多的工作量，所以我这边也算妥协了，保证他们推送的文件是csv，逗号分隔即可。
第二是文件推送时间的确定，应用1部门反馈每天早晨大概8点左右需要推送一批数据过来，应用2反馈taeny需要在早晨9点开始使用，所以留给我的时间就是8点到9点，但是每天都要推送这样的数据，时间可能会上下稍有浮动，我是不愿意守在电脑前做这种手工部署，又累又繁琐还没技术含量。所以我倾向于自动部署，所以在这点上我对应用1的要求是既然8点要推送，那么我留出40分钟的缓冲时间，我每天8点40开始运行脚本，这样20分钟后应用2 就可以读到数据了。如果出现其它问题需要过了指定的时间就需要专门发邮件通知，刚好9点我也到公司了。
第三是文件推送的方式，数据库服务器环境是不会对开发team开放的，只是开放指定的监听端口。所以我指提供给他们服务器IP和一个指定目录，除此之外不会提供给他们更多的信息。所以和他们讨论的情况是使用rsync来推送还是不错的选择。
第四是推送的csv文件的数据情况，这个部分在集成中总是会碰到各种各样的问题，所以我需要知道他们提供的表列顺序，初始脚本，数据样本。这样我在本地就可以独立完成这部分功能的测试。
第五点是文件的接收情况，接收文件自动部署听起来简单，怎么判断文件部署了没，还是根据时间戳，所以推送的文件需要有时间戳，精确到日即可，所以只是保证一天部署一次脚本。避免后期在各种文件中埋没。
最后是推送文件的格式，为了避免到时候可能喜欢的兼容问题，都统一采用utf-8的格式推送文件。
所以短短的十几分钟的时间里，我也是从DB的角度来分析，尽可能把事情能落地，结果就在这种讨论之中就很愉快的达成了共识，看来你退一步他让一步着实还是能够提高工作效率，而且面对面的沟通更加直接，比起繁琐冗长的邮件列表确实要精简很多。基本上以上几点能够保证推送过程中的不明确之处。
目前应用1是一个另外一个网段的系统，负责一块业务，而应用2是目前我所负责的数据库所在的环境里。
现在因为业务需要，需要从应用1来推送一部分数据到应用2，只在一段时间推送，一段时间过后，就不再需要推送了。
最开始是两个应用team在商量这件事情，结果讨论来讨论去，发现没有DBA参与还搞不定，还好我介入也不算晚。
对于这种问题，其实整体难度来说不大，但是集成的事情很容易有各种不明确的地方，所以自己也从DBA的角度提了几点要求。
大体的需求是应用1需要推送一部分数据直接到数据库服务端，由DBA部署后提供给应用2使用，应用1的部门他们为了方便，推送的格式是csv文件。而且数据推送频率是一天一次。
基本上每天在特定的时间段都需要做一次这样的工作,大体是这样的情况。
对此我从DBA的角度提了几点要求。
首先是推送文件格式的确定，能够直接推送成sqlldr的ctl文件，我直接部署即可，结果商量来商量去，一来也是我怕他们推送的ctl文件格式有误，后面修改来修改去还扯皮，二来他们似乎也是怕有太多的工作量，所以我这边也算妥协了，保证他们推送的文件是csv，逗号分隔即可。
第二是文件推送时间的确定，应用1部门反馈每天早晨大概8点左右需要推送一批数据过来，应用2反馈taeny需要在早晨9点开始使用，所以留给我的时间就是8点到9点，但是每天都要推送这样的数据，时间可能会上下稍有浮动，我是不愿意守在电脑前做这种手工部署，又累又繁琐还没技术含量。所以我倾向于自动部署，所以在这点上我对应用1的要求是既然8点要推送，那么我留出40分钟的缓冲时间，我每天8点40开始运行脚本，这样20分钟后应用2 就可以读到数据了。如果出现其它问题需要过了指定的时间就需要专门发邮件通知，刚好9点我也到公司了。
第三是文件推送的方式，数据库服务器环境是不会对开发team开放的，只是开放指定的监听端口。所以我指提供给他们服务器IP和一个指定目录，除此之外不会提供给他们更多的信息。所以和他们讨论的情况是使用rsync来推送还是不错的选择。
第四是推送的csv文件的数据情况，这个部分在集成中总是会碰到各种各样的问题，所以我需要知道他们提供的表列顺序，初始脚本，数据样本。这样我在本地就可以独立完成这部分功能的测试。
第五点是文件的接收情况，接收文件自动部署听起来简单，怎么判断文件部署了没，还是根据时间戳，所以推送的文件需要有时间戳，精确到日即可，所以只是保证一天部署一次脚本。避免后期在各种文件中埋没。
最后是推送文件的格式，为了避免到时候可能喜欢的兼容问题，都统一采用utf-8的格式推送文件。
所以短短的十几分钟的时间里，我也是从DB的角度来分析，尽可能把事情能落地，结果就在这种讨论之中就很愉快的达成了共识，看来你退一步他让一步着实还是能够提高工作效率，而且面对面的沟通更加直接，比起繁琐冗长的邮件列表确实要精简很多。基本上以上几点能够保证推送过程中的不明确之处。
