Here are my comments, speaking from personal experience as an Oracle DBA for
3 years on Tru64 UNIX and NT databases.  I am also doubling as the NT
administrator now.  There is another Oracle DBA (more experienced than me),
and there are 3 UNIX system administrators.  10 NT servers (2 old OWS
3.0.1.1., 2 iAs 9i, 1 used to have 5 7.3.4.4. instances on it, one has 3
8.1.7. instances on it), with 5 Digital (sorry, Compaq) Tru64 UNIX servers,
with 1-3 instances on them).

This is my perception at this point.

Microsoft marketing is very strong.  Managers use Windows9x/ME, so they
think WindowsNT/2000 is easy too.  Heck they know little about computers and
they can run MS Office and Outlook no problem, imagine what the techies
downstairs could do with the server OS from Microsoft!  Most managers don't
use computers - they need the latest laptops etc. for office status
purposes, but they don't use them for much more than running MS Office and
Outlook.  They read ComputerWorld and they see PC Magazine and PC World in
the pharmacies, that's about it.  They also notice that none of the UNIX
vendors ever advertise on TV (what's up with that?).  The people who decide
where to spend the money are not the people who have to work with the
systems.  In a good shop they would consult the people below, but often they
end up deciding first and arguing (or delaying purchase indefinitely) if the
techies down below question their decision).

Do they take into account replacing all their servers to keep NT/2000
running?  I imagine their existing machines can't run NT or Windows2000.

The point someone else made about training is a valid one, management may be
thinking that training is not required at all for NT because it's a Windows
OS and the techies can do anything, or that MCSEs are a dime a dozen now so
staff costs will be lower.  Problem is, they will need more staff to keep
the NT servers going than for an equivalent number of UNIX machines - once a
UNIX box runs, it runs reliably.

UNIX machines are not affected by the likes of NIMDA, BackOrifice and other
tools out there.  Most hackers don't have grudges against UNIX systems, but
they certainly do against Microsoft. Have you updated your virus files
lately?  If using McAfee, is your engine up to date?  Have you checked your
Event Viewer security log?  Has auditing even been enabled on your system?
You realize that auditing is shut off by default on NT.  (also not taught in
the NT4 MCSE classes).  Anyone with a copy of a server's ERD can crack the
passwords of all the user accounts that server has seen since the OS was
installed.  If someone gets the ERD from your BDC or PDC, you are royally
screwed.  How many ERDs are lying around in your computer room?  Do
contractors / term / casual employees ever go in there, and do any of them
have any reason to be unhappy with the way your company is treating them?
If one ERD is missing, how long will it take for anyone to notice?  The
attitude that "NT is just Windows" doesn't help security at all, the OS has
to be taken seriously.  If your machines have to be secure, get ready to
spend time doing it.  More time than if it was a UNIX host.

Web servers should use something other than IIS, IIS is popular because...
it's freeware.  The Gardner Group earlier this year advised people not to
use IIS, because it is not secure.  iAS went with Apache on Windows, which
is a bit of an oxymoron, Apache should be running on UNIX.  iAS made the
right decision, but it illustrates that the OS ends up running a UNIX web
server ported to NT.  Like it is used to run a UNIX-based database (Oracle)
on NT.  Why not just use UNIX?

To do remote admin, they will have to purchase a 3rd party tool like PC Duo
if they are using NT.  NT assumes an administrator would be at the server.
You can't telnet to NT systems because NT behaves like a home operating
system, it assumes you are sitting at the machine (may be possible with
Windows2000, not sure).  You can purchase 3rd party telnet software, but you
won't have access to the desktop.

Scripting on NT is not as "user-friendly" as it is in UNIX.  Retrieve from
archives those old DOS scripting books.  NT and Windows2000 offer more
commands, but at the core the scripting is still the same.  The AT command
used to run scripts on schedule in NT 4.0 is 99.9% reliable, but not 100%
reliable.  I ended up having to install a 3rd party utility called crontab
for Windows to keep my backup scripts running reliably.

The time clock keeps slipping back, esp. if your CPU is busy.  So you will
have to hook up the machine to a time server somewhere.

Every time there is a new version, you have to purchase it and upgrade the
hardware.  Much of your 3rd party and your in-house applications will have
to be ported to the new version.  I don't know if this is the case with UNIX
variants.

NT carries along with it a huge kernel, and a thick layer of graphics on top
of it.  To make all that work at a speed equivalent to UNIX, it needs a lot
of resources.  A dual- or quad-CPU helps.  

I would not run an Oracle on NT database with less than 2G of RAM on the
server.  Because much of NT is inaccessible to the system administrator,
tuning becomes an issue - you will probably have to surf the 'net to find
info on how to speed up NT (e.g. www.arstechnica.com
<http://www.arstechnica.com>   had a whole section on this topic, because
people were frustrated with the OS).  

To improve performance, and to secure an NT server, you must make many
changes in the registry; are you comfortable doing that?  What will happen
when you apply the next service pack?  More time for administrators.  Maybe
they will give up trying, which means higher hardware costs for the same
performance, and less security.

Because much of NT is in the kernel, it is inaccessible to system
administrators.  When things go wrong you tend to either see a Blue Screen
of Death or you get cryptic errors with generic messages.  Because of this
(this is bad practice) many places believe rebooting is the first thing to
try when trying to fix a problem on NT servers.  If they reboot and the
server now runs, the system administrator usually has no idea what went
wrong and whether the problem will reoccur.

It doesn't help either that one of the oldest pieces of code in NT is the
Event Viewer, it has a different API than the rest of NT - programmers don't
like programming for the Event Viewer.  Many 3rd party applications don't
report errors in Event Viewer very well.  Oracle on NT has more info in the
alert log file than it does in Event Viewer... because it makes more sense
to use an alert log file.

I strongly suspect that disk I/O is much slower in NT than it is on UNIX.
Especially if they plan to buy "high-end" PCs instead of purchasing real
servers.  You do not have as many options for the file system as exist for
UNIX (advfs, etc.).

The registry fragments.  Disks fragment.  Even if you are installing
software on a new system with empty disks.  More administration required.
Fragmentation is not as much of an issue on UNIX systems, if at all.

Oracle on NT doesn't like NT virtual memory very much, I find I always have
to have more physical memory than Oracle requires (rdbms + sessions) for the
server to run reliably.  This is probably because Oracle keeps refreshing
the data block system change numbers, NT can't send Oracle to virtual
memory.

Oracle develops the rdbms on UNIX, then ports it to NT.  The developer tools
are written on NT (I think).  Better to be on the platform Oracle is
developing the database on, to be ahead in terms of patchsets and to get
better Oracle support.  UNIX on the back end and for medium to large-sized
databases, Windows for smaller ones (perhaps, because why can't you place
them on a UNIX server since you will have them for the back end).

NT does not allocate memory very quickly.  If you are running an Oracle
database on NT, you can open the Task Manager and look at Memory Commit
Charge, then start the database service.  How long does it take for the OS
to allocate the memory Oracle requires?  Do this, just as a test.  It
allocates memory in little chunks.  Its' almost fun to watch.  It's not fun
if you are in a hurry.  I don't know why it doesn't just say "you want 1G of
memory?  All right, here it is, go wild.  Done."

Registry fields have a fixed maximum length, which poses problems for people
who plan to put many Web applications on one web server.  There may be a
workaround (?) but here we have to map drives to local shares to reduce the
number of characters we put in FORMS60_PATH and REPORTS60_PATH in the
registry.

Given a choice, I would go with Oracle on UNIX every time because of
reliability issues.  NT should be used only to serve smaller groups of
people, not for backend databases.  Perhaps use NT for smaller or front end
databases (middle tier servers).  Even with iAS, I would prefer if I had it
running on Solaris instead of NT, so far iAS 9i 1.0.2.2. on NT (with 8.1.7.
and the OEM on the same machine) has given me a lot of headaches.

If you have any other experiences with NT v. UNIX, I would like to hear
them.  Correct me if I missed something or if I don't understand something.

Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)

Systems Admin & Operations | Admin. et Exploit. des systèmes
Technology Services        | Services technologiques
Informatics Branch         | Direction de l'informatique 
Maritimes Region, DFO      | Région des Maritimes, MPO

E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 





--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Boivin, Patrice J
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to