Home/ Questions/Q 844273
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T06:15:35+00:00

I am collecting runtime profiling data from PLSQL stored procedures. The data is collected

  • 0

I am collecting runtime profiling data from PLSQL stored procedures. The data is collected as certain stored procedures execute, but it needs to accumululate across multiple executions of those procedures.

To minimize overhead, I’d like to store that profiling data in some PLSQL-accessable Oracle memory-resident storage somewhere for the duration of the data collection interval, and then dump out the accumulated values. The data collection interval might be seconds or hours; its ok not to store this data across system boots. Something like session state in web servers would do.

What are my choices for storing such data?

The only method I know about are contexts in dbms_sessions:

procedure set_ctx (value in varchar8) as 
begin
    dbms_session.set_context ( 'Test_Ctx', 'AccumulatedValue', value, NULL, 'ProfilerSessionId' );
end set_ctx;

This works, but takes some 50 microseconds(!) per update to the accumulated value.

What I’m hoping for is a way to access/store an array of values in some Oracle memory using vanilla PLSQL statements, with access times typical of array accesses made to package-local arrays.

EDIT (after learning about session-lifetimes of PLSQL package variables):

Are there PLSQL-accessible variables with lifetimes longer than “sessions”? I’d guess such variables would likely need synchronization to enable safe updates from multiple sessions. Weirdly, the kind of performance data I’m collecting wouldn’t be hurt very badly by such synhcronization faults, because the performacne data values simply grow monotonically. A synchronization error would merely mean that we didn’t capture a bit of that value growth, and I don’t think that would damage what I’m doing enought to matter.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The only way I can think of doing this is to have a “listener” process that is constantly running and maintaining the in-memory data. Your other processes would then record information by communicating with the listener via e.g. DBMS_PIPE or DBMS_AQ. There is an example of a Pro*C listener process in the DBMS_PIPE docs.

    However, I have doubts as to whether this would be more efficient for the calling programs than the simpler solution of writing the information to a table via an autonomous transaction.

    • 0