systemtap probe at specific oracle function offset + BONUS

This is a trick i use to be able to put a systemtap probe at specific function offset in an oracle executable.That mean beside function entry and exit we can also probe at a specific offset such as “r0_aes_cbc_loop_dec_x86_intel+224”. Although this can be easily done using perf  (perf probe -oracle r0_aes_cbc_loop_dec_x86_intel+224)  or ftrace it seem not possible to do that using systemtap due to the lack of debuginfo .

This can be useful as a workaround for the error “registration error (rc 0)” described here or for other purpose !

Continue reading

Playing with oracle DB 18c on-premises before official release

Rodrigo Jorge has already explained a great way to install and play with Oracle 18c DB instance on-premises using Exadata binaries downloaded from edelivery. The basic idea is to install the oracle exadata binaries and before creating the database replace the library “libserver18.a” with the  version gotten from an oracle cloud instance  (Using Oracle Cloud trial account). And that’s it !

But for those like me that don’t have an international credit card required to create an Oracle Cloud trial account  (Yes i don’t have one 😦 ) or don’t want to create one  ! How to proceed to get a copy of this working libserver18.a library ? May be ask one of the oracle folks to upload it to somewhere and hope that there is no backdoor on it :p  or just try to hack it your self 😀

Continue reading

From memory request to PL/SQL source line [ errorstack dump ]

In my last blog post i described a geeky way to trace back the responsible PL/SQL code for a particular memory request into the PGA. It was based essentially on a dynamic tracing tool “systemtap” to probe on  specific functions entry such as KGHAL memory allocator functions (Based on Stefan Koehler dtrace script )  and relied on calling an internal oracle function “pfrln0lookup” using “oradebug call” to  get the actual PL/SQL line number.It would have been safer if we reverse engineered the function “pfrln0lookup” to extract only the thing that matter and avoid calling it but this need time and is forbidden :p  !

So here i will describe a safer and simpler approach relying only on collecting multiple errorstack dump samples and a little shell script to parse the trace file !

Continue reading

Tracing PL/SQL subprogram calls with parameters values [Dynamic tracing]

The purpose of this blog post is demonstrate again the power of Linux dynamic tracing/instrumentation tools.

In my last blog post Enhancing DBMS_OUTPUT using systemtap i showed how we can track  the parameter values passed to “dbms_output.put_line” routine using systemtap.That was a very simple example because we already know the type of the arguments passed (a simple VARCHAR2) and also because there is only ONE parameter.

Tracking PL/SQL routine calls arguments using dynamic tracing utility like perf or systemtap can become quite complex depending on many things like :

  • Argument types
  • Argument number
  • Argument passed  By Value/By reference
  • Subprograms type (nested/package/standalone subprogram)
  • Optimization level (ex: inlining of call of procedure)

Time for the serious stuff  with dynamic tracing tool PERF ! 

Continue reading

Enhancing DBMS_OUTPUT using systemtap

This is a short and quick note to show how we can enhance DBMS_OUTPUT capabilities using a small systemtap script without modifying the source code.Basically it will allow us to display the DBMS_OUTPUT message incrementally (the program don’t need to finish it’s execution) by attaching to an already running session (no need to enable DBMS_OUTPUT). The output can also be easily redirected to a file.

The idea is to try to access the function parameters.This can become complex in case of different arguments types and number but in our case there is only one argument of type varchar2.

Continue reading