一次数据变更的审核过程

   今天正在做一个数据变更操作，突然一个开发的同学找到我，看起来比较着急的样子，说想让我做一个数据变更。
   当然在这种时候，我正在做的数据变更操作已经被打断了，已经有一些不愿意了，而且还要紧急变更，在没有得到脚本，没有环境，没有脚本说明，对于这种三无要求我一向都是比较排斥的。所以我静下来，让他提供这些信息，这些是数据变更的必备条件，哪怕再紧急，这些信息也需要有基本的流程规范。
   所以这位同学就这样无功而返，当然换谁都一样。很快他就确认了环境，是一个使用率不高的在线业务库，当我得到他提供的语句的时候，我已经有些崩溃了，因为打开文件的时候，发现脚本注释都是乱码，所以我还是选择打回。然后等开发的这位同学再次发过来文件的时候，我终于耐着性子开始审核脚本。
    可以从脚本的内容和注释看出，这是通过一个工具导出的脚本，当然了这种脚本还是有很多的问题。
    首先就是导出的脚本中的用户是TEST
脚本中是类似"TEST"."TABLE1"的形式，而我要导入的环境的用户为TEST_OPER，这就给我带来了一些困扰。
其次是导出的脚本中的表空间在目标库中不存在，如果开发的同学不确定，其实这个地方就可以直接省略，而作为DBA会做权衡，当然用户的默认表空间就是相关的表空间。
再次就是导出的环境中的段属性，索引段属性等，其实在目标环境中大部分都不需要。
比如下面的段存储属性：
 SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
其实这些信息都是实际的应用来说没有特别的用户，从上面的内容可以里面有11g的特性segment creation的设置，如果是在10g肯定会报错。而且后面的属性信息也都不需要，完全可以根据当前的数据设置来取得默认值。
    然后看着后面的几行语句，我不禁皱起了眉头，因为这位同学自己添加了几行脚本，DML末尾没有commit。
    当然这个时候我也不能怪这位开发同学的不专业，我需要告诉他的我的建议，于是我从头按照我的建议改了一遍文件，告诉他哪些是要注意的，而不是简单的拿到文件就交给DBA执行。
问题解决了之后，大家都相安无事，他也从中学到了东西。但是下午的时候，他又找到我说，他们访问的时候有个报错是table or view does not exist，然后想问问我早上的变更是否成功，为了尽快平息这种疑问，我就直接登录系统给他看了一下，所以这位同学带着结果又回去了。但是让我快爆发的是，他过了会又找到我说，这个表的变更应该是在另外一个线上库中，这个时候我还是希望得到一个肯定的答复，当初为什么确认是之前的数据库地址？看着这位同学也是模棱两可，我觉得还是需要尽快把这件事情弄清楚，因为尽管确定是这个库，我需要一个清楚的解释，这次他提供的环境是一个非常重要的核心库，一旦出现问题，那就是牵一发而动全身。显然这位同学不知道这个风险。于是我就找到了这个开发的负责同学，向他确认这个需求，业务上大体是什么样的情况，大体了解了下，原来他们有一个业务会涉及两个库，这个业务有一些功能点，有些需要连接数据库1，有些需要连接数据库2，而经过他们的确认，这个功能点是只在数据库2中会被应用调用，所以数据库1的变更是不需要的了。反复确认，开发的同学重新走流程，终于这个问题才算完整解决。
     看起来确实是一个挺让人纠结的问题处理过程，当然我也理解那位开发同学的苦衷，但是不知者无畏，在不了解整个环境的前提下，贸然改动，留给系统的是数不尽的后患，作为DBA是需要严格审核数据的变更和诉求，对于数据变化敏感的操作，需要保留备份，保留操作日志，考虑影响范围等等，也希望在工作中大家都更加专业，尽可能减少一些返工，过度交流的情况。