January 21, 2008 at 10:08 pm
Comments posted to this topic are about the item Oracle Slackers
January 22, 2008 at 1:46 am
I can understand fokes hesitant to patches. After all, with todays producs it's of higher importance to sell the product then to make the product perfect since selling the product brings in cash while making the product perfect takes time and is expensive, at least that's the view of some people, a view I disslike but understand. After all, no company can survive without income.
However, patches are to make a product better, but history has lernd us that these patches can go wrong and have buggs. Thus one should have a testlab where they first apply the patch and test the system then apply the patch to the prod system. Having a testlab is always a great thing to test everything new for a product/ system and every company should have it. Hence it should not be such a problem to apply patches since not 2/3 of them inclues buggs, not that I know about anyway. So does this mean that 2/3's of the oracle guys does not have testlabs or are lazy or are very stressed on time or does not know how to test? Or is it costly for those that uses oracle to have a testlab? In any case, sounds relly bad and weird to me..
January 22, 2008 at 8:01 am
IF one deals with multiple vendors for SQL databases (i.e. software that uses SQL databases), one may need to receive approval from the vendor that the patch has been tested and approved. We're a small college and must have at least half a dozen different ones. Larger organizations may have many more.
January 22, 2008 at 8:35 am
Well, I think there are lots of reasons behind this, and as Steve said the details of the questions certainly would be helpful. It basically comes down to a risk evaluation. I am much more diligent of any patches for databases that are used in support of a web site compared to databases that are completely within the corporate firewall. This article (http://www.networkworld.com/news/2007/111407-database-servers-no-firewall.html) estimates that there are 3 times more SQL Server databases exposed to the internet then there are Oracle databases although it doesn't talk about how well patched they are.
Because of the ease of use and volume of Microsoft SQL Server in web development, I believe it is more often used for web applications and as such people think of it as more vulnerable and therefore may be more diligent in applying patches. The bottom line is that its easier for a hacker with minimal skills to find attacks that work against MS SQL Server then it is for attacks on Oracle. Still its no excuse not to patch your DB.
In a previous job I worked in a very regulated environment where we had a 6 month process to validate new versions of software going into the production environment. Because of this, we did very little patching and tried to make sure the environment was well secured and had intrusion detection systems in place. This happened to be an Oracle environment; in fact it was an Oracle application that was only certified to run on the previous major release of the Oracle database!
January 22, 2008 at 3:30 pm
IMHO we, as humble DBA's, are held accountable for 'patches' released by Software vendors. Rightly or wrongly, I expect the patch (or SP) to not introduce more bugs than it's supposed to fix. I cite Mal Vs SP2 for SQL server 2005 for example. This patch caused a total re-write of our reporting suite. Why ?? Because they introduced a bug in the DatePicker control- It defaults (internally) to american date format, Check this out.
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=271099"> http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=271099
But whos' fault was it ? Mine.... cause I patched our SQL2005 servers.:sick: No, of course, it wasn't in the release notes.
Can I undo it No....not without a sh!t load of work and a rebuild of the SQL Server.:crazy: Unless some SQL Guru here can point me in the right direction of reverting back to SP1 heaven !!
' NOT HAPPY JAN !' :angry: (Aussie joke !)
So in response to the Editorial .....
Damned if you do
Damned if you don't.
CodeOn 😛
October 14, 2010 at 9:33 pm
I apologize for late entrance.
The way MS operates, they release patches without DBA's intervention, how cool is that. NO, why? You have some background processes that run in the middle of night, which get in the middle of Windows updates, thereby a Server reboot in the middle of the night, DBA wakes up.
The above sh1t happens, when you do not have:
- Patch Managment
- Windows updates are not disabled (Often, you cannot disable Windows updates), pretty cool, haa.
See SQL Server DBA's, You guys do not worry, because MS will provide job security, reason, MS cannot get their act together to release a SOLID Product. Their SQL Server Kernel developers constantly work on COPYING other RDBMS platform work and try implementing in MS SQL Server. So they loose focus on a SOLID product release, then they release mandatory updates, hotfixes, and service packs to SQL Server.
Company's depend on SQL Server as backend, they are used to hearing that SQL Server rebooted last night, sh1t broke because SQL Server need a DLL update (hotfix + service pack).
Sorry fellas, this is a messed SQL Server DBA's life. Oh, guess what, hotfix + service pack information can be found at http://www.google.com, very funny, isnt it.
Mahidhar Vattem
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply