Re: How to understand SGA?

From: Hans Forbrich <>
Date: Mon, 29 Feb 2016 08:04:18 -0700
Message-ID: <>

Bother are correct. Both are accurate, depending on the required context.

In *nix, process spawned from the oracle executable are classified as 'background' or 'server' processes. Background processes are the autonomous ones that are responsible for the housekeeping - writing the logs, flushing the SGA to disk, monitoring other processes, etc. Server processes are those directly involved in processing user SQL, PL/SQL and in-database Java. In Windows, replace the term process with thread and you would be close.

The definition of instance is: the collection of background processes and server processes as well as the SGA (shared memory) allocated to that collection of processes. The shared memory is allocated in chunks, called granules, each of which which has a standard size (depending on the maximum SGA requested) and each granule is formatted and used for only one main purpose. The purpose is known as a cache, pool or buffer, and you will hear terms like: "buffer cache" (data block cache), "results cache", "shared library pool/cache", "java pool", "large pool", "log buffer".

The best place to learn about these things is the documentation at IN particular, refer to the 'Concepts' manual in the Administration section of the database documents.


On 28/02/2016 10:43 PM, Nan Xiao wrote:
> Hi all,
> For SGA, from wikipedia
> <>, its definition is:
> the System Global Area (SGA) forms the part of the system memory (RAM)
> shared by all the processes belonging to a single Oracle database
> instance.
> But from Oracle 12c For Dummies
> <>,
> its definition is:
> The System Global Area (SGA) is a group of shared memory structures. It
> contains things like data and SQL. It is shared between Oracle background
> processes and server processes.
> So what is the meaning of "server processes" here? Which definition is
> more
> accurate? How to understand SGA?
> Thanks very much in advance!
> Best Regards
> Nan Xiao

Received on Mon Feb 29 2016 - 16:04:18 CET

Original text of this message