Setting Server Swap Space for Oracle
Oracle Database Tips by Donald BurlesonApril 14, 2015
One important system administration task
is allocating the "swap space" for an Oracle server. In cases of servers
with multi-speed RAM (Fast T1, located near the CPU), and slower T2 RAM, The
UNIX/Linux system administrator will frequently allocate T1 RAM for the Oracle
An Oracle ACE notes:
For those of us who review the Oracle
installation documentation, we know that Oracle suggests that you configure
a substantial amount of swap space.
If you have between 1 and 2G RAM, you
need to configure 1.5x RAM for swap space.
For 2 to 8G RAM, swap space has to
For RAM more than 8G, swap needs to be - RAM.
No doubt your system administrator (in
Linux or Unix) will tell you that that is more swap than you need. He may
tell you that you only need one or two gig of swap when you have plenty of
Despite what the official Oracle
documentation says, my recommendation is that the minimum swap space should
be equal to the available RAM, and 2x swap to RAM is the maximum amount that
should be needed.
I can tell you from personal experience,
that your system administrator is wrong if he tells you that. I have been
there, and done that as the saying goes. Make sure you configure the full
amount of swap recommended by Oracle, more if possible. Here's why:
In a Unix operating system, there are
two methods of allocating swap, eager swap and lazy swap. Under lazy
swap, swap space is allocated only when needed, that is when an active
process needs additional memory and all real memory is used up. If there
is insufficient swap space available, the Operating system will create
more swap space by killing idle processes. Obviously this is a dangerous
and undesirable situation.
Under Eager swap, as a process
consumes memory, it also marks the same amount of swap space as used,
so, for example, if your oracle database has 6G RAM allocated in the SGA,
it will allocate both 6G RAM and 6G swap. If there is insufficient swap
space, it won't kill other processes to make space. It will lock up the
program attempting to allocate space, and eventually any other processes
on the system that need swap space will also hang. In Solaris, I have
seen such errors as ?unable to fork a process? or Solaris error 12, not
enough space. In oracle, you will get messages like this: TNS-12500,
TNS-12540, TNS-12560, TNS-00510. Usually your server will lock up
shortly after the note enough space or unable to fork a process message.
In this example above, the TNS errors were
my fault. I had given the Unix system administrator the requirements,
including the amount of swap required. However, I had not followed up to
make sure the settings were actually in effect. As it turns out, the Unix
administrator had only allocated about 1/3 of the system RAM for swap,
relying on his knowledge and understanding of swap.
This was my fault because as an Oracle
DBA, it was my job to verify everything before you hand the installation
over to the users. That includes the system level settings. If you can't see
the settings (but as a DBA you should be able to see the settings), you have
to rely on your system administrators word. But I could see the settings, I
just didn't follow up and verify them.
Some Oracle DBA's I have talked to have
allocated twice as much swap space as system RAM, following the older Oracle
guidelines. After doing some researched I have discovered that Unix can be
configured used to hold an image of the operating system processes for
diagnostic purposes in the event of a system crash.
I'd like to reply. (6/25/2010)
Most sysadmins that I've met are
as passionate about eking performance out of their systems as the DBA's.
In the best situations there's a meeting of the minds that leads to both
harmony and performance.
Other times there's disagreement, generally
with reasoned arguments on both sides. In this case, I think the post
referenced misses a couple of points.
I believe one should have a
pretty good idea of how a system is going to be used before setting it up.
This implies that you have an idea of how many users, how much bandwidth,
disk space, memory, and CPU are going to be required in order to for the
system to do the tasks assigned. If you're configuring based on
guesswork, then you should expect problems. In the bad old days when
systems didn't support much memory and it was very expensive, using more
swap could make some economic sense.
If you are configuring based
upon an understanding of the requirements, then (assuming you have the
resources to buy what you need) you have already decided how much memory is
needed in order to do the job. In this case, unless there is some
reason why you want to slow the system down by knowingly setting it up to do
lots of paging, you then have to determine the relationship between swap
disk and memory in your particular case.
Most modern *nix operating
systems either default to or can be configured to use lazy swap, and even
most of those that use eager swap don't require a 1-1 match for RAM.
Given this, my contention is that if you have configured the server properly
(acquired the proper model and populated it with the proper amount of RAM)
then you just need enough to cover unanticipated shortfalls due to unusual
If you haven't configured enough physical memory, then configure more!
In today's systems and at today's memory prices, swap disk should not be
used as a substitute for adequate RAM. Besides that, you can get
out-of-space errors even with more swap configured if you didn't work out
the system configuration properly to begin with.
Sometimes there are
cases where you're stuck with something older (HW and/or OS) or more
limited, that isn't optimal for your use. If this is the case, please
be sure to discuss the situation with the administrator -- this is a
Related on on server swap allocation for Oracle
See my related notes on configuring server
If you like Oracle tuning, you
might enjoy my book "Oracle
Tuning: The Definitive Reference", with 950 pages of tuning tips and
You can buy it direct from the publisher for 30%-off and get instant
access to the code depot of Oracle tuning scripts.