1. 超长的PL/SQL代码

　　影响：可维护性，性能

　　症状：

　　在复杂的企业应用中，存在动辄成百上千行的存储过程或上万行的包。

　　为什么是最差：

　　太长的PL/SQL代码不利于阅读，第三方工具在调试时也会出现代码行混乱等问题。PL/SQL存储对象(存储过程、包、函数、触发器等)行数上限约为6000000行，但实际工作中，当包大小超过5000行就会出现调试问题。

　　解决之道：

　　PL/SQL代码在执行前会被加载到shared pool中，shared pool以字节为单位，UNIX下为64K，桌面环境下为32K，可以通过查询数据字典USER_OBJECT_SIZE的PARSED_SIZE字段查看对象大小。对于较大的包，应采用拆包策略，抽取复用部分，减少重复代码;对于较大的存储过程，应将存储过程组织到包中，易于管理;对于较大的匿名块，应将匿名块重新定义成子过程保存在数据库中。

　　2. 脱离控制的全局变量

　　影响：可维护性

　　症状：在包中使用了全局变量，在多个位置对全局变量进行操作。

　　CREATE OR REPLACE PACKAGE BODY PKG_TEST IS

　　GN_全局变量 NUMBER(12, 2);

　　PROCEDURE 过程A IS

　　BEGIN

　　GN_全局变量:=1;

　　END;

　　PROCEDURE 过程B IS

　　BEGIN

　　GN_全局变量:=2; -- 这里对全局变量进行了另外的操作

　　END;

　　为什么是最差：

　　全局变量可以在整个包范围内被访问到，因此对全局变量的跟踪和调试会比较困难。如果变量是在package中定义的，变量还可以被其他包访问，这将会更为危险。

　　解决之道：

　　减少或取缔全局变量的使用，对于要在过程间交互的变量，通过参数传递来实现。如果必须使用全局变量，应对全局变量进行get/set函数封装，规范对全局变量的访问。