蓝的成长记――追逐DBA（5）：不谈技术谈业务，恼人的应用系统

***************************************声明***************************************

        个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英文形式代替，不会泄露任何企业机密，纯为技术分享。

        创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。

        欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。

***********************************************************************************

想跳的高，需要先学会蹲下身。

                                                                        ――深蓝

***************************************前言***************************************

        这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。

        不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。

        而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。

        在追逐于DBA梦想的道路上步步前行。

***********************************************************************************

2014年北京

        两天的跑来跑去，把问题转移到了研发，不得不吐槽一下，环节、体制仍需要继续建设与完善，业务层、现场层、实施层不同的处理情况，随之产生了不同的现场问题。这次问题的出现貌似很简单，却让实施人员费了半天的时间，揪心的痛让人身心疲惫。绕了半天，是不是有些听晕了，接下来，我来回忆一下这次与业务层有着紧密关系的实施部署。

        情景再现：为完成部署迁移项目，将原应用系统、数据库一同迁移到新的服务器上，部署客户端，环境为64位win7系统（说明一下，生产环境下应用服务器、数据库服务器是分离的，而此次部署为科研项目，其中内容就不便细说了，就此了解下都在一台服务器就行了）。A应用java开发，B/S架构。B、C等应用客户端也为B/S架构，但是基于32位系统开发。就是这个简单的技术细节，开始引发连续的业务问题。

        在主系统A应用重新部署完成后，看似一切正常，在后台费了些周折，修改了密码，终于使用超级管理员用户登录了。然而就在觉得任务完成的时候，展现在技术人员面前的问题出现了，某维护页面无法正常访问，出现权限问题。连续点击测试，业务层又出现新问题，某处理程序无法使用了。诧异的情况是，这次部署并无异议。问题哪里出现的呢。根据提示一步一步排错吧。由于手边没有完善的部署手册，根据提示发现问题所在：一个JDK导致的无法处理。搜索，下载，安装，继续排查，发现缺少某些功能。此时联系研发，业务脚本邮件传来，对于运维的工作事宜，有些汗，跑脚本，问题解决。此时一脸茫然的体会着业务流程与技术实施间的关系到底有没有明确的分界线。可以设想一下，如果在遇到这种问题时，通过技术层面去排错，有点天方夜谭了，恐怕除了再开发一个全新的出来不会有什么正确的解决办法，因为这都是业务中的需求。这是业务层的问题，就是这么简单。开发有业务脚本，跑一下，实现的就是把有些功能表创建下，功能项关联下，权限赋予下，诸如此类等等，问题迎刃而解。说来简单，遇错时思考角度却是关键，协调、反馈有时超过技术本身。

        这只是A应用系统暴漏的问题，还没说到恼人的B、C、D应用系统，这次可以说的上是恼人不已。客户端的程序，访问出现问题。再一次想到的就是开发人员，继续联络。接下来想必可以预见到效果了。不错，再次邮件，替换文件，重新设置。搞定了嘛？这次悲催了，业务层不知怎么了，程序貌似出错了。这次是严重的问题，因为在这一系列的业务系统中，存在着一个关键的“中坚”系统（技术细节不便透漏），可以理解成是一个上传下达的管理平台，基于主业务系统，维护着所有系统信息的一致性（有没有感觉有点像oracle中的undo段，维持着读一致性。哈哈，这里纯为戏谈）。由于此应用部署不能正常使用，致使这一系列的迁移看似完成，却又回到了起点。这次，再一次联系开发。现场人员崩溃了，研发人员也崩溃了。接连几次的邮件往来。配置无果，无法继续下去了。把tomcat日志统统拷贝走，这次需要研发人员亲临现场了（这里，让人不禁想起，曾经也因为之前公司的一个业务问题，项目负责人、实施人员、维护人员、开发人员、甲方众领导、甲方众工程师聚集奔赴现场的壮观场景，哈哈，再次戏谈~~）。当然，这次情况还是在可控范围内的。对于最后业务部署调整仍有一天的时间。按照常理经验，这种客户端问题，研发到场后，根据实际环境，调整相应包、配置文件后，问题都会解决。绕了好一会儿，就在这里暂告段落吧。

        回顾一下，这次问题的出现，很多都不是出在技术上。想想跟技术有关的层面，如客户机连接数据库时需要配置tns、监听；中间件部署、调优；数据迁移等等，都不是引起这次问题的原因所在。问题暴漏在业务应用，现场系统环境的改变，不同业务文件调整、更新上。

        这就是所说的“业务需求”，Oracle技术也需要落地，有时候解决问题思路可能高于技术，技术的探究需要业务的支撑。

***************************************未完待续***************************************

欢迎访问：深蓝的Blog：http://blog.csdn.net/huangyanlong

*****************************************************************************************

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠