O/S Choice for Database Servers

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Tue, 15 Feb 2011 21:15:22 +0000
Message-ID: <AANLkTinoVJ3fg3Hrq3+gVO1Y0=JVti5o5D5gqCHbTjjz_at_mail.gmail.com>



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

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 15 2011 - 15:15:22 CST

Original text of this message