RE: MS Windows 2008 vs Linux (any flavor)

From: <>
Date: Tue, 22 Oct 2013 22:27:44 +0100
Message-ID: <002d01cecf6d$8c142b40$a43c81c0$>

Hi All,
From security benchmark PoV, Oracle on Windows is more insecure than Oracle on *nix.
See the default ORACLE_BASE directory on 12.1 which points to '/' . This cannot be written to on *nix as Oracle does not have the OS perms. On *Windows* default install Oracle CAN write to '/' and it translates to the root of the C:\ drive..
So anything that can write to a directory in Oracle can, by default, write to the root of C:\ (e.g. Advisor)
This is insecure as our Windows colleagues will confirm. The defenses are to put Oracle on a separate drive from OS, remove the directory, and try to run Oracle as a lower priv'd Windows user. Problem is that there are other issues with Oracle on Windows from security perspective so for now, if security is important, then best keep to *nix as Oracle platform.
Oracle on *nix actually interprets *nix permissions more securely than *nix itself e.g. ignoring parent directory perms when considering file perms from UTL_FILE, and not concatenating all sources of OSDBA membership information - just taking the first source. These can be seen as non-standard, but are good examples of Oracle security being tighter on *nix than the standard *nix security model. This is partly because Oracle is engineered to work on *nix. With Windows there is the risk of a porting issue causing a security hole.
Though integrating with Windows in general is something to work towards, with AD etc.
From performance benchmark PoV I have always understood *nix to be generally better at processing large files, but will defer to the performance experts on the list for the details of that comparison. Cheers,

-----Original Message-----
From: [] On Behalf Of Niall Litchfield
Sent: 21 October 2013 22:07
Cc: oracle-l-freelists; oracle-db-l
Subject: Re: MS Windows 2008 vs Linux (any flavor)

485 million years ago (well in 2009) there was a thread on Windows vs Linux to which I contributed the below. I pretty much stand by the main points still.
1) This could be tested with sensible workload based benchmarks, but I'm not aware of any remotely current ones. (I was complaining in 2009 that someone should redo the tests, I don't think its been done). 2) You should choose O/S according to the capabilities of the people managing it

The thread is at but is full of Burleson being silly and reminiscences about then old hardware. If anyone is aware of any sensible benchmarks (especially for one of the core variants of windows server) I'd be interested in seeing them, I no longer have ready access to test hardware and windows o/s distributions.

message from thread follows

Charles Hooper wrote:

There are a lot of factors which may have contributed to the slower than expected performance on Windows 2003 that you noticed. Those factors include:

* Not collecting system (CPU) statistics on Oracle 9i or higher
* Not collecting data dictionary statistics on Oracle 9i or higher
* Not configuring large page support, if it is able to be used
* Not taking advantage of a battery backed cache to improve write
* Leaving the default db_file_multiblock_read_count set to 16 (I believe that is what the DBCA sets on 10g and above) rather than allowing Oracle to auto-tune the parameter. Limiting extent sizes to smaller than 1MB could also cause performance problems.
* Installing a virus scanner on the server, especially if it is permitted to scan program and data files used by Oracle. * Using inappropriate parameters for memory allocations. * If a database release upgrade was involved, not directly attacking the specific performance problem which is the source of the problem - could just be just a couple bad execution plans, possibly caused by the upgraded query optimizer.
* ... (Niall Litchfield, or someone else might be able to provide additional causes)

Probably the most common reasons are running excessive non-oracle workload on the same server (of which the virus scan is a prime example), but often people I see will compare a combined database and app server running windows against the same system but with the database remotely located on a unix server. The performance difference is then attributed to the o/s and not the architecture.


A couple things to keep in mind about Windows: * Oracle on Windows uses direct, asynchronous I/O, which helps minimize concurrency problems. But, this also means that the operating system's file cache probably is of little use to Oracle on Windows.

conversely Linux, especially older releases of Oracle on Linux, tended to have really poor disk io in comparison to windows. This problem has mostly gone away, but for all its faults NTFS remains a really good FS for Oracle.

  • Oracle on Windows uses a thread model, while Oracle on Linux (and other Unix like operating systems) uses a process model. The thread model is less negatively impacted by context switches than is the process model, which should help improve performance in some cases, such as repeatedly calling a PL/SQL function from a SQL statement.

The single biggest limitation these days however is in addressable memory on the 32bit platform, since all those threads share the same memory space (especially for PGA and session info) as the backgrounds. The simple answer to this is not to use PAE or /3gb or all the rest but to use a 64bit o/s (including windows).

  • Properly configured, the same server running 64 bit Windows should be able to achieve roughly the same performance as the same server running 64 bit Linux (assuming direct, asynchronous I/O is enabled on Linux).
  • ... (Niall Litchfield, or someone else might be able to provide additional things to keep in mind)

The tests that I and others have done (*in the 2.4 kernel timeframe*) showed that workload based tests (as opposed to Roby's operation based tests) gave windows about a 5-15% *advantage* when properly configured. It's high time these tests were re done though.


The general advice that you will likely receive is to use the operating system that you know best for Oracle.

That would be mine, technology doesn't break databases, people do.


On Mon, Oct 21, 2013 at 7:51 PM, Jeffrey Beckstrom <>wrote:

> I am looking for a benchmark comparing the two OS'es on identical
> hardware. I found a number of benchmarks, but the hardware differed
> in the comparisons. Can anyone point me to relevant documents.
> Jeffrey Beckstrom
> Database Administrator
> Greater Cleveland Regional Transit Authority Information Systems
> 1240 W. 6th Street
> Cleveland, Ohio 44113
> .
> --

Niall Litchfield
Oracle DBA


Received on Tue Oct 22 2013 - 23:27:44 CEST

Original text of this message