February 2010

I have written the first article to the troubleshooting section of my new website tech.E2SN.com:
It’s about a very valuable Oracle troubleshooting tool -> ERRORSTACK trace.
I cover 4 frequently asked questions there:
Reading the current executing SQL statement text from errorstack trace Reading the current executing PL/SQL package and PL/SQL source code line number from errorstack trace Reading the current bind variable values from errostack trace Identifying how much private (UGA) memory a cursor is using You can read it here:

Welcome to my personal blog.  Dr. Paranoid is not a medical site nor a site for those of us with conspiracy theories.  I know there are many DrParanoids out there but in the Oracle Data Guard world, it’s what I get called a lot so it stuck.

I will discuss all things related to Oracle’s Data Guard and Maximum Availability Architecture with forays into High Availability, Disaster Recovery and Business Continuity.

To get you introduced to Data Guard, what it is and how it works,  I was going to start writing but then I thought, why not show you all Chapter One of our book.    Once you’ve read that you’ll be ready to read some more.  Yes, this is a shameless plug for the book!

Larry

I just published a new script and article about calculating the real Oracle process memory usage on Solaris.

The problem with V$PROCESS* views (and the V$SESSTAT) is that they will tell you what Oracle thinks it’s using, not the real amount of memory used. There will be discrepancies due how memory is actually allocated in OS, libraries out of Oracle’s control, the static memory areas inside Oracle binary and of course bugs.

I was working on one of such problems and decided to make my life easier by writing the script. It’s not so much about calculating the exact figures (they will never be 100% correct), but more about presenting the memory usage data in a better and more convenient fashion.

The script is called procmm and stands for Process Memory Matrix as it shows the memory usage in a matrix grid.

Here’s an example output to show what I’m talking about:

I just published a new script and article about calculating the real Oracle process memory usage on Solaris.
The problem with V$PROCESS* views (and the V$SESSTAT) is that they will tell you what Oracle thinks it’s using, not the real amount of memory used. There will be discrepancies due how memory is actually allocated in OS, libraries out of Oracle’s control, the static memory areas inside Oracle binary and of course bugs.