原著作者：Jim Czuprynski
LBL(Looking Before Leaping)三思而後行<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
前面所述的技術只有在開發前計劃一組新的數據庫對象或者修正原有的數據庫對象時，能夠取得很好的效果。但是我總是會發現，當我們在進行這種開發規劃的時候，運行中的應用程序往往不可避免地受到中斷。換句話說，一個好的計劃應該保護現有的應用免受中由於數據庫對象改變引起的重編譯或者無效導致的中斷之苦。
明白在使對象有效前會發生什麼重大影響
在我開始講述改變數據庫對象之前，要重點強調一點，請務必要仔細檢查每一個待改變的數據庫對象防止導致無效錯誤。在過去的幾年內，在焦急的開發員和撓人的主管的催促下，我曾經有意或無意地違反了這些建議，通常會導致應用程序執行性能的下降。
下面的代碼可以幫助你檢查通過重編譯哪些對象將會無效。
在重編譯以後，一定要檢查哪些無效的對象。然後還是再檢查
很多次，我曾經目睹了這樣的情形：UTLRP.SQL重編譯器或者第三方的軟件沒有重編譯所有最近無效的對象。至少，這會導致一些問題；在最壞的情況下，除非有人注意到了這一點,應用程序將完全不能存取數據庫。
舉個例子，不久前我花費了整整90分鐘外加一個下午幫助一個程序員調試PowerBuilder程序訪問ORACLE開發數據庫時遇到的ORA-00942錯誤"table not found",但是相同的代碼卻可以在生產數據庫上正確運行。當我們在調試程序的時候，這個錯誤看上去是間歇出現和重現的。
我想起以前遇到過這種情況並且花費了很多時間來折磨我的大腦，最終具有諷刺意味的是罪魁禍首是無效的數據庫對象。最終發現是因爲另外一個程序員刪除並且重建了原來的一個表，但是有一大堆其他的數據庫對象引用了這個表，而他卻沒有重新編譯這些對象，導致它們都無效了。
密切提防global temporary tables
最後一個告誡：如果你使用全局臨時表(GTTs)來存儲和計算狀態信息，小心程序改變它會帶來的後果。我曾經把進行了一個最平常不過的改動，把GTT的varchar(15)字段改變成varchar(25)。然而這個特殊的GTT通過指定了ON COMMIT PRESERVE ROWS選項，從而可以被一個程序包用來存儲每個連接用戶的信息。ORACLE頑固地拒絕了ALTER TABLE命令除非我要求所有應用程序的用戶都註銷，解除了對GTT的凍結之後才行。也許那個命令只需要一小會兒時間，用戶註銷後也只需要等待一小會兒，但是設想一下如果這種改動要在一個業務高峯時候做的話，這種影響也許會變得非常糟糕。
(全文結束)