In either case, the key is knowing *where* the slow down is occurring. If a PL/SQL procedure consists of a single SQL, then its obvious, but often they have many, or call other procedures etc.

So firstly, run a trace

exec dbms_monitor.session_trace_enable(waits=>true);
exec your_plsql_proc;
exec dbms_monitor.session_trace_disable;

and then run tkprof on the resulting trace file. That now gives you a breakdown of where the time was lost.

The most typical cause for a sudden slow down is normally a poorly running SQL.

For slowly degrading performance, a common cause is looping structures, so on day 1, you loop around something 1 time, 2 times on day 2 etc etc....

But the trace is the key. If the trace does not reveal anything (for example, the plsql code does little or no SQL), then look at the pl/sql profiler to get similar information about the plsql code itself.