售前问题

做PL/SQL包时，最容易出问题的往往不是语法入口，而是先后顺序和规范对齐没有先想清楚。Oracle官方文档把这条链路分得很明确，包先有规范，也就是package specification，再有包体，也就是package body；规范负责声明公开对象，包体负责实现这些对象。

在Oracle里写PL/SQL定时任务，当前更常用的是DBMS_SCHEDULER。官方文档说明，这个包专门用于创建和管理调度任务，任务既可以执行存储过程，也可以执行PL/SQL块；而repeat_interval用的是日历表达式，若start_date和repeat_interval都为空，任务会在启用后尽快运行。

写PL/SQL存储过程时，先把它当成一段可被反复调用的业务动作：入口接收参数，内部做校验与处理，出口要么返回结果要么抛出可追踪的异常。参数传递则是另一套规则，IN负责输入，OUT负责输出，IN OUT负责输入后再带着新值返回，三者用对了，调用端才能稳定拿到结果。

PL/SQL触发器写得好，能把数据口径、审计留痕、写入校验这些事收在数据库侧，避免业务端各写一套。写得不好也很容易变成隐形成本，插入变慢、更新被拦、问题还不好定位。下面按先建得出来、再控得住、最后好维护的顺序，把创建与条件表达式两件事拆成可执行步骤。

你写存储过程时，最常见的卡点不是语法，而是接口没想清楚，参数模式选错，调用端不知道怎么接收返回值，最后就变成反复改一堆细节还跑不通。要把过程写得能用、好维护，思路是先定输入输出与事务边界，再把核心SQL塞进一个最短闭环里，最后用固定的调试动作把编译与传参问题一次性排干净。

PL/SQL里的动态SQL本身不是问题，问题出在把外部输入直接拼进SQL字符串后再执行，这会把输入从数据变成可被解释的SQL片段，形成SQL注入即SQL Injection风险。Oracle文档在EXECUTE IMMEDIATE相关说明中也明确提示动态SQL需要警惕SQL注入。