Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle 7.3.4 limitations on NT

RE: Oracle 7.3.4 limitations on NT

From: Berg, Guy van den <>
Date: Thu, 15 Jun 2000 10:57:57 +0200
Message-Id: <>

I have to agree. We run alot (over 150 upto 200+GB) of production systems here on NT4 with 7.3.4 and I have to say that I can't remember the time an instance last crashed and needed recovery. We've had some problems, a few ora-600's but these have all been resolved without a problem, there are a few corruption issues with 7.3.4 and oracle suggests patching to anyway to resolve these. Its all too easy to knock NT, I also agree that unix is a better system but there is no reason not to use NT in a production environment.

As for 8.1.6 runs without a problem on NT, needs quite a bit of memory but is altogether a great product!


Guy van den Berg
External Consultant
IS Application Solutions
Compaq EMEA Computing Services
*	Tel : 49-89-9392-2445
*	Fax : 49-89-9392-2657

-----Original Message-----
From: guy ruth hammond []
Sent: 15 June 2000 09:54
To: Multiple recipients of list ORACLE-L
Subject: Re: Oracle 7.3.4 limitations on NT

"Cale, Rick T (Richard)" wrote:

> Not necessarily. I'll be the first to agree that UNIX,etc is a better OS.
> Depending on your needs,etc NT
> can work quite well. I have been running on NT for about 5 yrs supporting
> different Oracle NT shops in
> that 5 years and probably bad luck to say this but I have not had even 1
> crash because of the OS. I have been running 7.3 up to 8.0.5. I know a lot
> of folks on this list use NT successfully.
My $0.02 When NT4 crashes it is almost always either a third party driver, or a problem with the hardware. I've been using it in production (altho' not always with Oracle) for almost 5 years now. The problem is simply that Microsoft, unlike say Sun, have almost no control over the hardware that you run their OS on. Sun can test every driver on every piece of kit they make, whereas Microsoft's ISVs and IHVs are far too numerous for this to happen, particularly in combinations with each other. So faulty drivers get loaded into kernel space, where they can trash the kernel data structures when they fail. This is a fundamental flaw in the NT4 architecture, but it can be avoided if you stick to first tier hardware vendors, and ensure that you only use drivers and hardware that they approve or recommend (even if it costs a bit more). VMS people (I know 'cos I was one once, mmm, FORTRAN :0) ) will laugh at me for saying this, but 6 month uptimes are easily obtainable on NT, and I like to schedule a Just In Case reboot round about that sort of time. Way back when, y'see, Microsoft architected NT 3.51 quite sensibly to avoid this sort of problem. Running SQL 4.2, if the display fell over it wasn't such a problem, the database kept on going, altho' if you wanted the display back you'd have to reboot (!) but at least it meant that your application stayed up. But the problem was, on x86, you pay a speed penalty for working like this, and in those days, the overhead was quite serious, hence the change in NT4. Personally, I would have liked to have a switch in a control panel or something, so I could tell NT4 (and now Win2000) where to run drivers, because I would be willing to drop some performance for the stability. One more thing: Oracle 8 and upwards run very well on NT, great price/ performance ratio. 7.3.4 is definitely less reliable. Cheers, g (who is *not* the SA :0) ) -- guy ruth hammond <> | One is punished for being Technology Analysis & Consulting | weak, not for being cruel. 07879607148 | -- Baudelaire -- Author: guy ruth hammond INET: 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: (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
Received on Thu Jun 15 2000 - 03:57:57 CDT

Original text of this message