AWR Does not show where's the problem. Just shows what is happening!

It looks like something that does not need to be said, but is a trap where many junior DBA fall. AWR (or Statspack) can be misleading if we do not keep in mind this detail:

What AWR and Statspack report shows is not where or what is the problem, but just what was happenning in the database at the moment of the snapshot!.

That means, that we need to interpret correctly what we are seeing at the report. Here I'd like to share an example that illustrates this point.

Identifying memory pressure - Part 4

Continue from part 3...

MEMORY AVAILABLE

At this point, I want to introduce a new parameter: MemAvailable.

This parameter is available is included in /proc/meminfo since version 3.14. In Red Hat, can be backported to previous versions from kernel-2.6.32-504.el6. Just need to set the value of sysctl parameter vm.meminfo_legacy_layout to 0. Then check at /proc/meminfo the new parameter MemAvailable.

Identifying memory pressure - Part 3

Continue from part 2....

AND WHAT DO WE DO WITH ALL THIS?

From the point of view of forecasting, (that is, if I want to know the amount of memory I have to put on one server, or if the actual memory of a server will be enough for the current workload), I have taken this approach:

Identifying memory pressure - Part 2

Continue from part 1....

OK, ALL THIS STUFF LOOKS GREAT, BUT HOW COULD I ESTIMATE THE SIZE OF A PROCESS IN MEMORY?

Taking into account what have been told, the Resident Set Size is the closest to the size in memory of a process, but when checking it by means of top, ps, or another Unix tool we find a problem. The output of those commands takes into account the shared memory segments and the shared libraries, so the results are oversized for double counting the sizes.

Identifying memory pressure - Part 1

ALL WHAT COMES NEXT HAVE BEEN TESTED ON RED HAT LINUX V 6. MOST OF IT SHOULD BE APPLIABLE TO ANOTHER UNIX OR LINUX SYSTEMS

THINGS CAN CHANGE DEPENDING ON MANY FACTORS (NUMA, Huge Pages, etc), BUT WHAT COMES NEXT SGOULD BE EASILY ADAPTABLE.

In the beginning, my idea was to check the amount of physical memory used by Oracle processesin order to do some forecasting and capacity planning.

Unfortunately, I've seen that is very difficult to calculate the exact amount of memory used by Oracle due to many reasons: