February 3, 2003 at 6:22 am
re: DBA's lazy...
At every place that I have ever worked, it has been the users whose data resides in that SQL Server database that tend to drive what is applied and when.
I can make my best case to my management who can make their best case to the business user management, who essentially says 'yea' or 'nay'. The SQL Slammer situation does have an upside. It enables a DBA to be able to say "Do you remember what happened with the SQL Slammer outbreak?". In our case though, our servers weren't the problem, it was the desktops that had the data engine installed.
February 3, 2003 at 10:49 am
In our environment the main barriers to deploying hotfixes and service packs are the third party supplier support issue and, above all, losing out to developers in contention for testing and pre-production rig time and tester resource. As someone previously mentioned, our base problem is that the business areas call the shots and they find developers projects - with promises of added functionality, bug resolution, etc. compared to operations changes that give no user-visible pluses. Given that most of the business area decision makers do not have any useful technical background, their appreciation of our proposals is that they appear abstract, guards against possible future events, which contrast badly, from a business POV, with the "Immediate Gratification" sexiness of "more stuff".
Thankfully we escaped any infection although it did mean scrambling people last weekend for emergency deployment of patches. Given that perhaps you can understand that from our (techies) POV, the scare may be a good thing in the medium term as an education exercise for the business owners - from now on the Slammer virus will no doubt be mentioned in all of our lobbying of business to get testing resources for new patches.
February 3, 2003 at 10:58 am
Amen, brother. Those of us who are concerned with the security side of SQL Server wanted to apply MS02-039 when it rolled out but we had to go through the testing cycle and there weren't resources available, etc. You get the idea. Thankfully we have very restricted VPN access (Citrix is a blessing) and the folks managing the firewall are as paranoid as I am. As a result, we escaped infection, but we did go around mad patching lots of systems. I think there is a greater awareness now of how what some see as an insignificant flaw can wreak havoc.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 3, 2003 at 10:59 am
My two cents...
I just wanted to amplify (vent, rant, rave, etc.) on what has already been said about third party support restrictions.
We work with a mid-market accounting package that has a history of specifying exact version requirements (nothing lower, nothing higher) for the OS, SQL and other system components. Receiving the notifications from MS that there is a Critical Patch available puts us in a real Catch-22. If we don't apply the patch(es), there's now a known exposure with a detailed description on how to exploit it and sometimes even code. If we do apply the patch(es), the vendor disavows any responsibility for anything that goes wrong.
We've tried raising this issue with the vendor but got the usual response (We can't test all versions....)
Give me strength!!!
Steve Hendricks
MCSD, MCDBA
AFS Consulting Group
(949) 588-9800 x15
Steve Hendricks
MCSD, MCDBA
Data Matrix
shendricks@afsconsulting.com
(949) 588-9800 x15
February 3, 2003 at 1:06 pm
This was the subject of a message by Russ on NTBugTraq. Basically exposing the vendors who are not ponying up support. When I called a couple of vendors I got the response, "We haven't tested it, we only test the major version (SQL Server 7 and 2000), but so far we haven't heard any customers having issues." In their defense, they were willing to support if we had an issue.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 4, 2003 at 2:22 am
I have an issue with some legacy systems that are running MS SiteServer 3.0.
If you've ever dealt with this package you will know that you have to follow a 16 point installation plan to the letter with no deviations.
Want to install an updated MDAC? Bye bye Site Server app.
Site Server can even break if you reboot the machine.
OK its obsolete technology and moaning about it is just letting off steam, but for anyone looking after legacy apps you're caught on the horns of a dilemna!
February 4, 2003 at 7:51 am
Site Server is a real bear. I hated working with it. It never made it into production in our environment because it was just a royal mess to support. Any plans to upgrade soon?
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 4, 2003 at 9:47 am
I WISH!!!
The problem is that it is on a client's site and is working fine. It is a case of "if it ain't broke, don't fix it".
All(!?!) we have to do is support it!
I have no idea what would happen if I tried to patch the SQL Server in this environment, and frankly I'm making sure that the buck doesn't even slow down near my desk for this one!
February 24, 2003 at 11:41 am
DBAs are "lazy"? Seems harsh. Most DBAs I know work at least a forty-five hour week. Some work sixty. Some work more. I don't think characterizing DBAs as lazy even begins to explain the situation.
When people opine on matters like this, generally, it follows the classic ad hominem form: "You &^!%@^%&^% people should have done such-and-such."
My observation is that, for the person who doesn't have to do it, no job is too difficult.
My response to such arguments is, generally, to the point, concise, thorough, and as polite as possible under the circumstances: "Bite me."
February 26, 2003 at 8:10 am
Part of what fostered the lazy argument was that there was more than a handful of folks that complained publically about the fact that the hotfixes were too hard to install because they involved copying files and running scripts. It wasn't a pretty GUI and some organizations didn't have personnel who could operate any other way. Another reason is because the vulnerability was known about in July.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 26, 2003 at 3:04 pm
quote:
Part of what fostered the lazy argument was that there was more than a handful of folks....
That's interesting, because I'm here to tell you, I would much rather install a hotfix than run one of those scary wizards.
Wizards are great when they do what they're s'posed to. That is, 95% of the time. But the other 5% is when you learn how to think to yourself, "Omigod, what have I done?" At times like that, you are hit with the obvious fact that you are merely the passenger, while the pilot (Captain Wizard, that is) is aiming the plane straight into the side of a mountain, and grinning ear to ear the whole time.
I come from an Oracle/Sun/Unix background. I am much happier when I am the pilot. Just gimme a checklist, and we're off. At least when I botch something that way, I know who to blame.
My worst experience with wizards, so far, was during our upgrade about a year ago from SQL Server 7 to 2000. The doc really leads you down the primrose path, downplaying any chance of failure. On two of our servers, however, I ran into problems. On one of them, I actually had to uninstall SQL Server reinstall it, and then reconnect the databases. Not for the faint of heart. Since then, if it's a Microsoft Wizard, I don't care how cheery the language sounds, I have my six-shooter handy.
February 27, 2003 at 7:11 am
I'm a command-line junkie from my background with DOS and Unix, so I don't have any issues with patching in this manner, but keep in mind that are still quite a few small companies out there who can't afford to have a full-time DBA on staff. So running scripts, etc., on SQL Server is always going to be foreign to whoever their admins are because chances are they touch SQL Server infrequently at best.
Also, there is a "new generation" of admins and DBAs who have experienced nothing but the GUI, and asking 'em to go down to a non-wizard install is a major paradigm shift.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 27, 2003 at 7:17 am
I have to agree with Bkelly and Lee about command line interfaces. When you do it yourself you know what was backed-up, changed, where/when, etc... YOu also know how to back it out and fix it if there is ever a problem.
I also come from a command-line background and MUCH prefer using the Query analyzer then to trusting a wizard. I hate having to be the "passenger" . We are told it is our responsibility to ensure the servers are functional, etc.. However, all that goes out the window when we have to rely on wizards to do patches etc...
AJ Ahrens
SQL DBA
Custom Billing AT&T Labs
Good Hunting!
AJ Ahrens
webmaster@kritter.net
Viewing 13 posts - 31 through 42 (of 42 total)
You must be logged in to reply to this topic. Login to reply