新增字段的类型、长度（精度）是否合适 解决方法：
跟应用明确加字段和改字段的风险，确认新增字段类型正确、长度（精度）合适。 以及跟应用明确老数据是否要订正？如何订正？新增列是否非空？是否有默认值等等。
l 新增字段的非空属性、默认值以及老数据问题。
新增字段如果是 NOT NULL 的，则一定要有默认值，否则老应用的 insert 代码可能报错。 表如果存在老数据，带上默认值的时候会导致 oracle 去订正老的数据行的新增列。 如果老数据非常多，表的并发访问高，很有可能导致大面积的阻塞等待以及产生大事务，甚至有可能 导致 undo 耗尽。倘若回滚，还会因为回滚产生的并发会话导致 load 飙升。
解决方法：先不带 not null 不带默认值加上列，再更改列默认值，再批量订正老数据，然后 再加上 not null 属性。 如果是大表，并且并发访问很高的表，则新增列不允许为 NOT NULL，以简化后面变更步 骤，降低风险！
l 新增字段导致依赖对象失效、sql 游标失效问题。
表的 DML 并发很高的时候，如果表上面还有依赖对象，新增字段会导致依赖对象失效。默 认其他 DML 会话会尝试去自动编译这个依赖对象， 此时很可能会出现大面积的 library cache pin。应用会话的连接时间会加长，进而导致出现后续应用报不能取得连接池错误。应用服 务器 load 由此飙升。 表新增字段也会导致跟该表有关的 SQL 的游标失效，如果 SQL 的并发很高（查询 SQL 或 者 DML SQL） 失效后 SQL 会重新解析， 此时也可能会出现大量的 library cache pin & library cache lock。
解决方法：选择在业务低峰期发布，同时在数据库级别开启 trigger 禁用客户端程序自动编 译功能，字段加完后再禁用该 trigger。
l 表的依赖对象是否要相应调整。
表上面的依赖对象如果有存储过程或触发器等，逻辑是否需要相应调整。
l 是否涉及到同步。
同步中的表需要两地都要变更。涉及到 erosa 的要更新一下数据字典。Erosa 需要重启一下。
l 是否要通知其他关联的部门。
如 DW, ASC 或 CRM 等等。 有些表很多部门都用，需要沟通约定时间一起变更。如果有同步方案，同步方案的变更也要考虑。
来源：https://wenku.baidu.com/view/df7719f259eef8c75ebfb307.html