新增字段的類型、長度（精度）是否合適 解決方法：
跟應用明確加字段和改字段的風險，確認新增字段類型正確、長度（精度）合適。 以及跟應用明確老數據是否要訂正？如何訂正？新增列是否非空？是否有默認值等等。
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