O/S Choice for Database Servers

  • From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 15 Feb 2011 21:15:22 +0000

subject changed so I can rant. This is my response to the recent thread
about how to install Oracle in a Windows environment. I've changed the
thread because I think that the main points were answered before we got
here. What we then saw was a surprising (for this list) attribution of
unevidenced or ill thought out suggestions about using Windows as a server
O/S for Oracle Databases:

<rant>

   - Windows platform is not fully compatible with Oracle products so these
   problems always appear.

Really? As opposed to RedHat Linux where Oracle have gone to the bother of a
kernel patch for the o/s itself. Every major version of Windows has had the
current or next release of the database certified on it sharpish. Similarly
look at the certification speed for Oracle E-Business on windows compared to
(say AIX).

   - If your production servers are installed at windows platform ,You
   shouldn't let them to join windows Domain at installation phases, as this is
   a wrong decision for running time performance.
   You should use a Workgroup or primary DNS suffix which allow you to avoid
   such problems you may face at joining windows Domain.

Again a statement with no evidence presented. In general AD does a good job
of policy and security management and certainly a better job than managing
an estate of Windows servers one at a time. If you haven't got your dns
management right and tied into the domain (which the latter suggests, then
you haven't got AD setup correctly)


   - Clusterware was installed with a domain account. That proved to be a
   fatal mistake when this particular domain the account belonged to was shut
   down as part of a migration project. After a scheduled reboot Clusterware
   wouldn't start at all. End of the story was a complete rebuild of the
   environment using local administrator accounts.

The fatal mistake here would seem to be not correctly identifying the
dependencies in the migration project.


   - Windows is just play box it is never for server installation if you are
   using oracle,db2 (I do not whether db2 is avaialble on windows) kind of big
   databases.

I must remember to tell that to the ten billion dollar a year manufacturing
operation that run their multi-terabyte SAP datawarehouse on Windows. :)


   - Oh, and when you have to do maintenance on a DB on a Windows server and
   the IT Security department tells you NOT to log in to ANY server using your
   AD account because there's a virus in the network and we need to contain
   it..

 What has the AD account got to do with this scenario - it makes no
dfference to virus propagation if you log in as local Admin or a domain
account with admin rights to the rights inherited by the executable code on
your machine.

   - . and when they have to reboot a production DB server to apply a hotfix
   (which happens a lot more often than unix patches)

- run up2date on your Linux box and count the number of updates released -
it *will* surprise you. Because Linux admins don't update their servers for
known security holes in general, and windows admins do is not really a great
argument for frequency of patches.

   - or when they need to reboot the DB server because it's been up more
   than 90 days straight... well, that's when you know the platform you've
   chosen is probably not the wisest choice.

nope that's when you know that the admin doesn't understand the platform. I
must reboot every 90 days is an admission that something that I don't
understand is happening.


</rant>

 I had that <insert name of local controversial fugure> in the back of my
cab once :)

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

Other related posts: