文中使用的Oracle版本为10g。

本次介绍的脚本主要用于对同实例中的两个相同的表进行字段的差异比对。听起来很奇怪吧，这都是因为以前开发过程不规范导致的，不然不应该会出现这么荒唐的脚本才对。我说几个关键字估计大家都能够猜想到了，“联合开发”、“异地沟通”、“交叉开发”、“时间紧迫”、“在线排Bug”、“紧急修复”......

在这个脚本出来的时候，我个人还不知道Navicat这款软件（毕竟那时候还是小小的程序员没有想那么多，只着眼解决眼前的问题）不然直接用表结构对比就解决了。有一天线上出现问题，经排查发现上线时执行的数据库脚本存在问题，线上数据库与仿真数据库存在大量表结构差异。

一下子晴天霹雳，这无疑是重大事故。项目经理首当其冲领了盒饭（被辞退），之后就要考虑怎样修复问题。我那时候的提议被采纳了并且修复了这个问题。

以下操作在DBA和项目负责人陪同下一同完成：

1. 找到一个干净的环境，将上线前一天晚上备份的dmp文件进行了还原（注意这里只还原了表结构）；
2. 再将现生产上的所有表进行表结构的备份，在同一个环境下还原；
3. 之后根据以下脚本对表结构进行对比

select a.TABLE_NAME,
a.COLUMN_NAME as  acol, 
b.COLUMN_NAME as bcol, 
a.DATA_TYPE as adt,
a.DATA_LENGTH as adl,
b.DATA_TYPE as bdt,
b.DATA_LENGTH as bdl
from (
  (select a.TABLE_NAME,
     a.COLUMN_NAME,
     a.DATA_TYPE,
     a.DATA_LENGTH
     from DBA_TAB_COLUMNS a
     where a.OWNER = '<owner1>' 
     and a.TABLE_NAME='<table_name>'
    ) a 
  left join 
  (select a.TABLE_NAME,
     a.COLUMN_NAME,
     a.DATA_TYPE,
     a.DATA_LENGTH
     from DBA_TAB_COLUMNS a
     where a.OWNER = '<owner2>' 
     and a.TABLE_NAME='<table_name>'
    ) b 
  on a.COLUMN_NAME = b.COLUMN_NAME)

这个脚本能够定位到被修改过的字段和差异部分内容。

4. 将差异内容导出来后让开发人员自行确认，并整理好修复脚本；

还好，这次事故修改的只是字段，若是触发器或者存储过程就麻烦了。
虽然整个修复过程只耗费了半小时，但是再一次让我觉得这个规范这个东西是很有必要的，很多时候项目为了快裁剪了很多东西后面要补的时候特别费劲。