When writing my blog post Write consistency and DML restart i noticed something that had motivated me to dig deeper. And here we go !
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 !
Here is a little experimental script based on a great blog post by Stefan Koehler entitled Trace back to responsible SQL or PL/SQL code for a particular (PGA) memory request by intercepting process with DTrace and one of my old blog post Geeky PL/SQL tracer/profiler : First step
And here is what it does :
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.
This is my second post under the theme of how to extend our capabilities to trace and profile PL/SQL code.This time motivated by a comment from Luca Canali on my previous post :
So based on my previous work on geeky PL/SQL tracer let’s see how we can obtain a geeky PL/SQL on-CPU Flame Graph !
This blog post is about how to extend our capabilities to trace and profile PL/SQL code.It’s primarily motivated by few tweets from Franck Pachot and of course because it’s FUN !
So in the first part of this series we are going to answer to this questions : Can we map those underling function to the source PL/SQL object and line number ? Can we obtain a full trace ? Of course yes otherwise there will be no blog post :p
Here is the followup to my previous blog post Getting Latch holder info out of the state objects in SGA memory where i described how we can extract latch state objects directly from the SGA memory. So let’s begin !
In one of my previous blog post i demonstrated that the amount of work needed for IN-MEMORY population/[trickle] re-population in oracle 220.127.116.11.6 is more than we may expect : IN-MEMORY population/[trickle] re-population : How much work ? You may be surprised !
Let’s do a very quick check on how this is now handled in oracle 18.104.22.168/OEL 6/UEK4
This is my third blog post about an issue that we may encounter with uprobes and the recent kernel/oracle version.
- Part 1 :uprobes issue with oracle 12c
- Part 2 :Workaround for Linux Perf Probes issue for Oracle Tracing
As the name of this article suggest i will show here how we can put a probe point on oracle functions using systemtap based on the workaround that i described previously.