The reason I see for this is because Oracle is such a different animal, DBA's don't want to install patches on live servers unless they have the time to fully evaluate the impact they might have.  For example we run both SQL Servers (around 25-30) and 3 Oracle Servers (running under AIX).  Our oracle boxes don't need much maintentance, cache hit ratio is above 97% most of the time and generally all runs well.  We had a software upgrade whcih caused us to move from 10.1 to 10.2.  What we didn't see was that Oracle's query optimiser had been changed signifcantly, in regards to how it handles #joins meaning performance (for us) dropped through the floor and queries that used to take 15-20 seconds now took 2-3 days.  It took months of talking to Oracle support before they picked up on the query optimiser change in the upgrade.  Whilst I have no objections to keeping everything patched, we need to make sure critical systems (especially those running on Oracle) don't get too adversely affected by the update.  With our SQL boxes, it's a hell of a lot easier to remove a patch (or rebuild SQL) than it is Oracle.  As such, with Oracle I take a "not broke, don't fix" attitude (rightly or wrongly).  Plus our servers are safely tucked away behind a couple of firewalls, and as long as our networks boys are doing their job, the servers are safe! :)

Dave

I suppose it all comes down to your own risk assesment.  I'm sure most users of SQL Server are in positions where maintentance of a system that's working fine means they don't even look at patching.  With Oracle, I suppose there's no-one out there whose going to spend the time hacking it, whereas as it's a MS product, it's open season.

But your right - everyone should make sure their systems are patched, but it has to be done with consideration and thought.  Too often people just say "well it was working before I patched it", "really? so what patches did you apply?", "dunno, but they were from Microsoft, so it can't be those!".  The Slammer issue was the other side of this argument, but it speaks volumes that it even caused an issue in the first place.  Security measures should have been in place which stopped anything from going in/out on 1433.  SQL should have been set to another port, or at least completely hidden from the outside world.

I don't suppose we should complain too much however, because it was really simple and there weren't any problems - most of us wouldn't have a job ;)

Dave

Patches and service pack - don't miss about bug-fixes how do you go about it?

Its not sufficient when you have secured the access to the database, may be other means on the network.