Managing PL/SQL Code, Compiler Settings, and Dependencies
Compiler parameters
PLSQL_WARNINGS controls static analysis ('ENABLE:ALL', 'DISABLE:PERFORMANCE', 'ERROR:SEVERE'). PLSQL_CODE_TYPE selects INTERPRETED (default) or NATIVE. PLSQL_OPTIMIZE_LEVEL runs 0 to 3, default 2. PLSQL_DEBUG adds debug information at a performance cost. These can be set at session or object level; when recompiling with inline settings, always add REUSE SETTINGS, otherwise unlisted parameters silently revert to their defaults.
Warnings
Warnings carry PLW- codes and are reported at compile time, not run time. DBMS_WARNING manipulates them from PL/SQL so a build script can escalate or suppress specific codes.
Dependencies and recompilation
USER_DEPENDENCIES, ALL_DEPENDENCIES and USER_OBJECTS expose referenced objects and status (VALID/INVALID). Invalid units recompile automatically on next reference, but bulk repair is faster with UTL_RECOMP or DBMS_UTILITY.COMPILE_SCHEMA, which recompile in dependency order. Fine-grained dependency tracking (11g) means changing an unrelated column no longer invalidates a unit, but a change to a package specification invalidates all dependents regardless.
Conditional compilation
$$PLSQL_UNIT, $$PLSQL_LINE and $IF $$flag $THEN ... $END controlled by PLSQL_CCFLAGS resolve at compile time, letting one source produce different code per environment at no run-time cost.
Rule of thumb: after any change to a package spec, expect dependents to be INVALID and recompile in dependency order before testing.