今天来感慨一下在工作中碰到的几处数据补丁问题，当然这些细节都是流程之外的控制和规范了，但是也或多或少出现了不少的问题，有些让人纠结，有些让人抓狂，有些让人无奈，但是不管怎么样，数据补丁是修复数据，完善业务的，DBA在这个关键时候就不能麻痹大意，把好这个关口还是很重要的。 让人吐血的dump文件 这是个真实的案例，早上很早到了公司，发现有个开发同事提交了一个数据补丁，需要部署在某某客户环境中，看到补丁的说明还是比较简单的，是需要导入一个dump文件，但是补丁也太简单了，除了这个说明其它什么都没有，也没有附上对应的dump文件，我就感觉纳闷，他的解释说dump文件太大了，有好几百兆，通过图形工具提交申请补丁已经超过最大附件的限制了，看来这个问题还得特事特办了。因为公司环境和客户环境是完全的两套网络，网络映射有了，但是网速还是很慢的。结果就这样scp了一早上，眼睁睁看着dump文件一点一点的传输，最后好不容易传送完成了，按照补丁的说明导入，发现导入的表只有一个，而且导入的数据就100多行，真是让人泪奔啊。 对于这个问题的反思，对于数据补丁的审核还是需要加强，可能开发的同事本身没有意识到很多细节，就会给你提供错误的信息误导你，所以需要自己的火眼金睛来识别了。大文件有大文件的处理方式，小文件有小文件的部署方式，哪些可以自动运行，哪些需要手工校验，检查点哟哪些，这些信息都需要我们来考虑。这样不同的问题就会有不同的处理方式，也就不用那么纠结了。 不统一的导入导出方式 还是数据导入的问题，开发提交了两个数据补丁，按照补丁的提示是需要导入一些表，然后提供了脚本做数据稽核，但是第一个dump文件就让人很纠结了，第二个也没让人省心。第二个在导入的时候报了错误，

IMP-00010: not a valid export file, header failed verification

IMP-00000: Import terminated unsuccessfully

看这个错误，感觉是dump文件出问题了。但是开发的同事坚称在其它环境中已经成功部署了，看来是不是我哪里检查错了，我又从源地址拷贝了一份尝试，还是同样的错误，在本地测试也是这个错误，最后使用strings查看dump的内容的时候，发现dump的内容是xml格式的，这很明显就是使用expdp导出的，这种问题让人很是纠结。 对于这个问题的反思，还是希望能够在提交数据补丁的时候，能够统一一下，尽管严格来说，这也不是错误，但是多多少少会造成一些误导，这种补丁DBA去部署都会产生误解，更不用说自动部署了。 分布式部署环境的集中管理 目前在一个项目中使用的环境有上百套，不同的业务，不同的环境，有时候弄几个数据补丁感觉很费劲，因为很多时间都在找环境上，公司内网的环境，客户的环境，各种类型的测试环境，在文档中描述得还算清晰，但是自己去查找的时候，感觉就跟拿字典查生字的感觉一样，每次都得根据环境编码去一个一个对应环境，感觉有些手工劳动的成分，尽管文档很丰富，很细致，但是自己使用起来还是不够完善。最后下决心改善这种情况，写了几个脚本，我只需要输入环境代号，就会在后台就做各种匹配和验证，然后输出一个报告。这样就能节省很多的额外劳动，手工校验，而且还可能有遗漏。 这个问题带来的反思是很多时候公司会存在大量的分布式环境，如何能够更加灵活的管理，对于自己就是莫大的帮助。因为从架构上，流程上都满足要求，但是如何能够更高效的管理，自己也尽一份力，给复杂繁琐的工作添砖加瓦。 补丁中的update导致的数据问题 这个问题源于一个同事的疑问，因为在环境中某个服务出现了问题，开发同事在查找的时候发现有些地方的数据出现了不一致的情况也不好定位，刚好最近部署了一个数据补丁，就希望我来看看。问题如果细细描述下来涉及业务背景，感觉就很抽象了。自己简单模拟一下。 我们创建两个表， create table test_sub (id number,name varchar2(30)); create table test_temp(id number,name varchar2(30));    然后往两个表中插入数据，test_sub表中的数据是完整的数据，有6条，test_temp中少一些，只有4条。 insert into test_sub values(1,'a'); insert into test_sub values(2,'b'); insert into test_sub values(3,'c'); insert into test_sub values(4,'d'); insert into test_sub values(5,'e'); insert into test_sub values(6,'f'); insert into test_temp values(1,'a'); insert into test_temp values(2,'b'); insert into test_temp values(3,'c'); insert into test_temp values(4,'d'); 然后在update的时候需要关联test_temp表来做数据的变更，可以看到标黄的部分，是明确在子查询中指定id值不为1和2的。 where中的1=1只是想说明这个语句做了一些数据过滤，得到的结果还是一个相对比较完整的结果集。     update test_sub sub    set name=(select name from test_temp tmp where tmp.id=sub.id and id not in (1,2))     where 1=1; 这条语句的更新条数是2行，4行还是6行呢。 简单测试就会发现变更了6行，这可能和预期的结果也有一定的差别。 6 rows updated. 查看变更后的结果，发现对于id为1,2,3,4,5,6的表test_sub和test_temp通过id做了关联，所以过滤后的数据只有4行，但是在子查询中又排除了id为1,2的记录，所以应该只有id为3,4的记录行应该更新。 n1@TEST11G> select *from test_sub;         ID NAME ---------- ------------------------------          1          2          3 c          4 d          5          6 6 rows selected.