防患于未然 给Oracle数据库打补丁

核心提示： 更新数据字典时，由于对某些PL/SQL包删除后又重新生成，防患于未然 给Oracle数据库打补丁(8)，造成相关PL/SQL包的状态为异常（invalid），在以后调用这些包时，Oracle公司设计实现了个别补丁安装管理工具opatch.opatch使用一个称为inventory的系统数据

更新数据字典时，由于对某些PL/SQL包删除后又重新生成，造成相关PL/SQL包的状态为异常（invalid）。在以后调用这些包时，检测到其状态为非法，会自动执行编译命令，使状态成为正常（valid）。虽然不会出错，但会造成个别处理第一次执行时变慢。显然，与其留到应用系统运行时再一个个编译，不如之前集中一次重编译所有异常包。

SQL> SHUTDOWN
SQL> STARTUP
SQL> @？/rdbms/admin/utlrp.sql

最后，根据Known Issues中的指示，完成与本系统有关的操作。例如，修改Pro*C的配置文件。这里执行一个修改文件存取权限的“后操作”，以便非同组用户和程序可以存取客户端工具和库函数。

$ cd $ORACLE_HOME/install
$ ./ changePerm.sh

个别补丁管理工具Opatch

如前所述，在发布一个PSR后发现的新BUG，只能把其补丁收入到下一个PSR中。如果对数据库有实质性影响，则这一补丁以个别补丁的形式向用户提供。个别补丁是与某一个特定的PSR关联，是安装在这一PSR之上的。另外，如同其名字表明的，个别补丁只是单一Bug的补丁，不会包含其他个别补丁，即不是累积型的。

在9.2版之前，安装个别补丁的操作完全是手工的。这种手工方式的缺点不仅在于加重DBA的负担，容易造成操作失误，更严重的是无法对已安装的个别补丁进行管理。

为解决手工方式的缺陷，从9.2版开始，Oracle公司设计实现了个别补丁安装管理工具opatch.opatch使用一个称为inventory的系统数据结构（严格说是与oui共享inventory），集中管理所有已安装的个别补丁；个别补丁的安装和卸载都使用opatch命令完成，冲突检测也由opatch在安装时自动完成；提供列表命令可以很方便得到已安装个别补丁的信息。