Security
-
Hi,
A colleague of mine is on a SQL Server 2005 course and the instructor is not so keen on SQL Server 2005 from a security and bug point of view. He says that he would wait a year before considering using it as a produuction environment. Is he justified in saying this? Using Google I cannot seem to find much negative information.
Best Regards,
Paul
-
Hello Paul,
The security features are better in my opinion. It sounds to me that the person is using the addage that for a MS product you wait until the first service pak is out.
In SQL 2000, passwords do not expire, do not become locked, do not force password complexity, or do not force the password to be changed periodically unless you custom write those scripts. However, in 2005, these are features and the work very well. For example, you can set a SQL password from SQL authentication to be locked after three attempts.
MS has also made the security more granular and provided more security levels/roles and more security options such as certificates and SSL encryption.
In my company we are in the process of upgrading all of our servers primarily because of the security enhancements (we are a HR service firm). We have tested everyone of our applications and everything is working as designed and we have not encountered any problems.
SJ
-
The standard ultra-ultra-conservative reaction is you don't use the first release of anything in production. Like my father would never buy a car the first year a model came out. I might expect that attitude from management, but not coming from an instructor.
What are you comparing it to? You may not want to immediately port from another database system, but if you're running SQL 2000, SQL 2005 has better security features. It probably still has some bugs, but it has been extensively beta-tested and some large systems have been in production for over a year. All database systems, SQL 2000 included, have some bugs. It is certainly prudent to test your code extensively on any new system before putting it in production, but in many cases the new features and better performance are worth the risk.
"Wait a year before considering using it in a production environment" sounds to me like "I can't be bothered educating myself on the new features and doing the testing". Or you may get that excuse from a beancounter who doesn't want to write the check. From an instructor it sounds like "I can't discuss it because it's new and I might risk shattering my aura of godlike omniscience".
-
"Ultra-ultra-conservative", "sounds to me like I can't be bothered"? How long have you been in this game then?
Microsoft products have a long history of critical problems in there first release. If you are serious about deployment, you always take this into consideration.
Paul, there are no identified issues with SQL 2005 security as such, and the security model is much improved in SL 2005. I would assume your colleague is applying the above well-known, well-used principle.
-
I've been around long enough to know that there is a wide spectrum from early adopters to "If it ain't broke, don't fix it" attitudes out there, and many reasons to lean toward one or the other. A consulting agency may want to be the first to brag that all their people are certified to work with the latest technology, a bank probably won't mind being a generation or two behind. How badly do you want or need the new technology vs. how valuable and irreplacable is your data, how much time do you need for testing, and when can you schedule a window to do the upgrade.
It is obviously true that Microsoft products, other software products, and many products in general have critical problems in the first release. They also usually have valueable new features that may make the risk worth taking, depending on how risk-averse your situation is. But I've been around long enough to recognize "Wait a year before considering using it in a production environment" as someone spouting an old rule of thumb rather than expressing a well-thought-out opinion. I can get this for free from any number of technologically ignorant management types, I would not accept it from an instructor that I was presumably paying to educate me. I can remember when "Nobody ever got fired for buying IBM" was considered an intelligent-sounding statement, but even then it was just an excuse to avoid a more detailed evaluation of alternatives.
"Wait a year" - why a year? That may have been a reasonable delay 20 years ago (pre-internet), but I guarantee if there are major flaws in the release version it won't take a year to hear about it. The CTP versions have been out for over a year, some large systems have been in production that long. I haven't heard of any huge problems, and everyone seems to agree it is more secure. Has the year already gone by? Maybe the first CTP version was 1.0 and the release is something like 1.4 or 2.2. Maybe they've reached the magic 3.1. Anyone expressing an opinion either way on this is putting more thought into their response than that instructor did.
"before considering" - (struggling to come up with something polite) balderdash. If you're in charge of a production system, you should already be considering when you will upgrade, even if the answer is several years. Are there any features in the new version that you can see will have a positive impact? SQL 2005 is supposed to be up to 40% faster. What happens if you have to buy extra servers over the next year, then after the upgrade management notices they are underutilized and the old equipment could have handled the workload? Will the excuse "This instructor said wait a year before considering" save your butt? Your environment may be risk-averse enough to justify the wait a year or two attitude, but that doesn't make it a golden rule for everyone.
For the record, the soonest I will upgrade my production systems will be 6 or 9 months. I need more time for testing, and if something evil shows up the upgrade will be delayed. We have to look at the capital budget for next year to decide what servers will be replaced and what will be upgraded. We'll look at production schedules and decide when we can best tolerate the inevitable disruption. But anyone picking 6, 9, or 12 months out of thin air is indulging in astrology or numerology.
The original question was "Was the instructor justified in his statement?" and I say no. His statement equates to "Go away kid, you're bothering me." Why he said it is open to speculation, but it was a meaningless brush-off.
-
Personally I have NEVER waited a year for a Microsoft product. I have been to more "midnight openings" than I care to remember, and sometimes at multiple stores in a night. I have ALWAYS bought the products I use immediately, and always proceeded to test and implement them. There are ALWAYS bugs, and there is nothing that says any given time, or any given release will make it better. There is no clear-cut way to report bugs, or to know when a bug has already been identified. Even in the beta program (and this was my first beta program with MS) there was no way to track other peoples reports - just my own... and frankly, I did not report many. When XP came out (not sure if this is rumor, folk legend, or truth) there were over 65,000 "known bugs" according to sources of dubious reliability. It would be interesting to know how many there are today. I know some "obvious" bugs that existed when it was released that still exist today... it's awfully hard to know what service pack really does what... and with world-wide lawsuits, it's hard to really fully understand how things are packaged or bundled. I am not one to wait. Perhaps I won't turn on all the new features. I have still not used a named instance outside of testing... it broke my proprietary software
I remember when DOS 4.1 was "too buggy to use"... well, so what? LOL Sorry... but there is no reason to wait - especially if there are new features. Does not mean that management or veterans who have been burned won't give you reasons to wait.
My advice is don't wait... to buy or use... or to patch. I have only seen two occurances where MS patches locked you out... and was never affected by either.
You roll the dice and take your chances... every day of your life.
-
The SQL Server 2005 development and testing cycle differeed greatly from previous cycles. Keep in mind that not only were there rounds of beta testing, but Microsoft developed the Community Testing Preview (CTP) process for getting features and bug fixes looked at more quickly by a whole community of people before public release. Also, internal procedures within Microsoft have changed drastically with respect to security and functionality testing from when MS first gained its reputation (XBox 360 and power cables aside). Keep in mind that there were some firms live on Beta 2, including Barnes & Noble. This is very much like Windows Server 2003 which deployed with relatively few bugs and security issues compared to previous OS releases.
K. Brian Kelley
@kbriankelley -
I'll throw in my two cents here. I think waiting a few months after the initial release is the better side of caution. Being resolute to not use it until after SP1 though is not. SQL Server 2000 was better than 7.0 right out of the gate. We are definitely considering 2005 for all of our new initiatives. We're taking a research and plan approach with everything else. There is a balance in any decision like this. There are still people out there who won't convert off of 6.5 and 7.0 because "it's working". The right answer is probably "we're lazy".
Derrick Leggett
Mean Old DBA
When life gives you a lemon, fire the DBA. -
"The original question was "Was the instructor justified in his statement?" and I say no. His statement equates to "Go away kid, you're bothering me." Why he said it is open to speculation, but it was a meaningless brush-off."
I say there is far too much vitriole here. The instructor was quoted as saying "I would wait a year before deploying in production", which is a perfectly normal answer.
Where it is true that bank tend to have a policy of the latest release -1, nobody is suggesting you close your eyes, sing "La, la, I'm not listening" and wait until 2007 regardless.
Fact is they are expecting to release SP1 in June so if you start your planning now (assuming a major deployment) you'll have your ass covered by the time you get to deployment (assuming there as slow in your industry as they are in the ones I've worked in).
Merry Christmas everyone!
-
Read the first post again. He said "Wait a year before CONSIDERING" using it in production. Not deploying for a year may be the right answer in many cases, but only for people who are looking at the risks and benefits in their own situation and coming to an intelligent decision. I don't have an argument with anyone who says the risks outweight the benefits in a particular situation, but I wouldn't listen to anyone who tried to tell me to not even consider it for a year. I want to hear the reasoning behind the opinion and how it applies in real life, I'm too old to accept "Because I say so".
This quote is not about any particular installation or organization where "wait a year" can be rationally justified, this is a statement from an instructor worded as though it is a universal truth. Instead of discussing some reasons why you should be more or less likely to upgrade quickly, he fobbed off a useless aphorism. I think the ability of this student to make a reasoned judgement in future situations is actually being harmed by this statement.
It doesn't matter how many cases "wait a year" is the correct answer, the original question was asking whether the instruction was justified in making this general statement. To which I say No. With vitriol.
-
Fair enough.
Are you on the first Virgin Galactic flight too or are you going to...?
-
Maybe if I was getting paid like an Oracle DBA.
Accepting all invitesViewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply