让你的应用程序不再对数据库的改动“感冒”(三) (转)-优快云博客

本文探讨了在数据库变更过程中如何避免影响正在运行的应用程序。通过详细解释如何检查和修复因数据库对象改变而导致的问题，提供了实用的SQL脚本来定位受影响的对象，并特别提醒了在修改全局临时表时可能遇到的陷阱。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

让你的应用程序不再对数据库的改动“感冒”(三) (转)[@more@]

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

LBL(Looking Before Leaping)三思而后行XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

前面所述的技术只有在开发前计划一组新的数据库对象或者修正原有的数据库对象时，能够取得很好的效果。但是我总是会发现，当我们在进行这种开发规划的时候，运行中的应用程序往往不可避免地受到中断。换句话说，一个好的计划应该保护现有的应用免受中由于数据库对象改变引起的重编译或者无效导致的中断之苦。

明白在使对象有效前会发生什么重大影响

在我开始讲述改变数据库对象之前，要重点强调一点，请务必要仔细检查每一个待改变的数据库对象防止导致无效错误。在过去的几年内，在焦急的开发员和挠人的主管的催促下，我曾经有意或无意地违反了这些建议，通常会导致应用程序执行性能的下降。

下面的代码可以帮助你检查通过重编译哪些对象将会无效。

sql> SET WRAP OFF

SQL> TTITLE CENTER "Parent and Dependent objects"

SQL> BREAK ON par_typ SKip 1 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> select

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程序访问 ORACLE开发数据库时遇到的ORA-00942错误"table not found",但是相同的代码却可以在生产数据库上正确运行。当我们在调试程序的时候，这个错误看上去是间歇出现和重现的。

我想起以前遇到过这种情况并且花费了很多时间来折磨我的大脑，最终具有讽刺意味的是罪魁祸首是无效的数据库对象。最终发现是因为另外一个程序员删除并且重建了原来的一个表，但是有一大堆其他的数据库对象引用了这个表，而他却没有重新编译这些对象，导致它们都无效了。

密切提防global temporary tables

最后一个告诫：如果你使用全局临时表(GTTs)来存储和计算状态信息，小心程序改变它会带来的后果。我曾经把进行了一个最平常不过的改动，把GTT的varchar(15)字段改变成varchar(25)。然而这个特殊的GTT通过指定了ON COMMIT PRESERVE ROWS选项，从而可以被一个程序包用来存储每个连接用户的信息。ORACLE顽固地拒绝了ALTER TABLE命令除非我要求所有应用程序的用户都注销，解除了对GTT的冻结之后才行。也许那个命令只需要一小会儿时间，用户注销后也只需要等待一小会儿，但是设想一下如果这种改动要在一个业务高峰时候做的话，这种影响也许会变得非常糟糕。

(全文结束)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-961228/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752043/viewspace-961228/