讓你的應用程式不再對資料庫的改動“感冒”(三) (轉)

讓你的應用程式不再對資料庫的改動“感冒”(三) (轉)[@more@]

原著作者：to:jczuprynski@zerodefectcomputing.com">Jim Czuprynski

 

LBL(Looking Before Leng)三思而後行:namespace prefix = o ns = "urn:schemas--com::office" />

前面所述的技術只有在開發前計劃一組新的或者修正原有的資料庫物件時，能夠取得很好的效果。但是我總是會發現，當我們在進行這種開發規劃的時候，執行中的應用往往不可避免地受到中斷。換句話說，一個好的計劃應該保護現有的應用免受中由於資料庫物件改變引起的重編譯或者無效導致的中斷之苦。

明白在使物件有效前會發生什麼重大影響

在我開始講述改變資料庫物件之前，要重點強調一點，請務必要仔細檢查每一個待改變的資料庫物件防止導致無效錯誤。在過去的幾年內，在焦急的開發員和撓人的主管的催促下，我曾經有意或無意地違反了這些建議，通常會導致應用程式的下降。

下面的程式碼可以幫助你檢查透過重編譯哪些物件將會無效。

> SET WRAP OFF

SQL> TTITLE CENTER "Parent and Dependent s"

SQL> BREAK ON par_typ SK1 ON par_sts SKIP 1 ON par_obj SKIP 1 NODUPLICATES

SQL> COLUMN par_typ FORMAT A12 HEADING "Type"

SQL> COLUMN par_sts FORMAT A08 HEADING "Status"

SQL> COLUMN par_obj FORMAT A16 HEADING "Parent"

SQL> COLUMN dep_obj FORMAT A16 HEADING "Child"

SQL> COLUMN dep_typ FORMAT A12 HEADING "Type"

SQL> COLUMN dep_sts FORMAT A08 HEADING "Status"

SQL>

  2  O1.object_type par_typ,

  3  O1.status  par_sts,

  4  O1.object_name par_obj,

  5  O2.object_name dep_obj,

  6  O2.object_type dep_typ,

  7  O2.status  dep_sts

  8  FROM

  9  public_dependency PD,

10  all_objects O1,

11  all_objects O2

12  WHERE PD.referenced_object_id = O1.object_id

13  AND PD.object_id = O2.object_id

14  AND O1.object_name = 'EMPLOYEES'

15  ORDER BY par_obj;

 

  Parent and Dependent Objects

Type  Status  Parent  Child  Type  Status

------------ -------- ---------------- ---------------- ------------ --------

TABLE  VALID  EMPLOYEES  PKG_SECURITY  PACKAGE BODY INVALID

  BV_EMPLOYEES  VIEW  VALID

  EMP_DETAILS_VIEW VIEW  VALID

  PKG_SECURITY  PACKAGE BODY VALID

  SECURE_EMPLOYEES TRIGGER  VALID

  UPDATE_JOB_HISTO TRIGGER  VALID

 

6 rows selected.

 

在重編譯以後，一定要檢查哪些無效的物件。然後還是再檢查

很多次，我曾經目睹了這樣的情形：UTLRP.SQL重或者第三方的沒有重編譯所有最近無效的物件。至少，這會導致一些問題；在最壞的情況下，除非有人注意到了這一點,應用程式將完全不能存取資料庫。

舉個例子，不久前我花費了整整90分鐘外加一個下午幫助一個程式設計師PowerBuilder程式訪問開發資料庫時遇到的ORA-00942錯誤"table not found",但是相同的程式碼卻可以在生產資料庫上正確執行。當我們在除錯程式的時候，這個錯誤看上去是間歇出現和重現的。

我想起以前遇到過這種情況並且花費了很多時間來折磨我的大腦，最終具有諷刺意味的是罪魁禍首是無效的資料庫物件。最終發現是因為另外一個程式設計師刪除並且重建了原來的一個表，但是有一大堆其他的資料庫物件引用了這個表，而他卻沒有重新編譯這些物件，導致它們都無效了。

密切提防global temporary tables

最後一個告誡：如果你使用全域性臨時表(GTTs)來和計算狀態資訊，小心程式改變它會帶來的後果。我曾經把進行了一個最平常不過的改動，把GTT的varchar(15)欄位改變成varchar(25)。然而這個特殊的GTT透過指定了ON COMMIT PRESERVE ROWS選項，從而可以被一個程式包用來儲存每個連線的資訊。ORACLE頑固地拒絕了ALTER TABLE命令除非我要求所有應用程式的使用者都登出，解除了對GTT的凍結之後才行。也許那個命令只需要一小會兒時間，使用者登出後也只需要等待一小會兒，但是設想一下如果這種改動要在一個業務高峰時候做的話，這種影響也許會變得非常糟糕。

 

(全文結束)