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