February 26, 2007 | Comments: (0)
Use Red-Gate's backup... and Go to Jail???
A reader just informed me that there's a huge problem with Red-Gate's licensing for SQL Backup. I never would have dreamed this, but I checked, and it's true.
The basic problem is this... if you buy a SQL Backup license, it's not transferrable. That means that you buy it for a specific machine, and not for use as a license in your organization. If you get a license and end up decommissioning that machine, you can't reuse that license in your company. You have to buy another license for a new machine. This scenario is very common where you move an application to another box because you initially over or under spec'd the hardware. Or perhaps you are simply consolidating servers and you want to put your SQL Backup licenses back in the general pool. Well, won't happen here. Oh, and if you doubt what I'm saying, it's right on their site. Here's the text from their online license agreement.
All software is licensed on a per computer basis. For example, if you wish to use SQL Backup on more than one computer you will need an additional license for each additional computer on which the software is downloaded and installed. Furthermore, this license is not transferable between computers and as such you may not transfer the software between computers without purchasing an additional license from Red Gate Software.
And here's the link to it so you can see for yourself.
Personally, I find that not only incredible, but maybe even a bit offensive. It shouldn't be that hard to upgrade or downgrade a box. If I buy a license, I should be able to use it any way I like.
Here's my problem with this. What constitutes a server? Is it the motherboard, the CPU, the chassis, the RAM, the disks? What combination of those things is a server? If I change the motherboard is it a new box now? Because Embarcadero has a similar licensing plan. They build the unlock key off of the hardware, so if you change a significant part of the hardware, your box will need to be re-licensed. Now, the big difference is that Embarcadero doesn't charge you for that license. It's wholly transferrable to other servers, you just have to build a new key based off of the new hardware. So that comes back to the question, what makes a server a server? At what point in this scenario am I going to have to buy a new Red-Gate license?
Now, common sense dictates that Red-Gate isn't going to come after you for putting SQL Backup on a new box. If you have to upgrade, I'm sure they understand that. Or maybe they don't, I don't know. The point is though that it's out of their hands. Merely by having that in their license, it's taken out of their hands. So even if Red-Gate doesn't come after you, the auditors still could. And if you're found to be out of compliance, your CEO could officially go to jail. You could get an auditor with some kind of bug up his ass for your company and is looking for any excuse to cause a lot of trouble. Maybe you're being investigated by another government agency and they're working together. Maybe one of the other guys pissed him off and now he's just in a bad mood. Maybe he just hates his job and he's fighting with his wife. It doesn't really matter. In chess we have a saying... never rely on your opponent's stupidity. And in IT we have another saying (actually, I just coined it)... Never rely on the generosity of your auditor.
Keeping up with hardware is a lot easier in a smaller shop, but in a large enterprise, it's almost impossible. Someone could change a major component on a server and you may not even know about it, and next thing you know... BOOM... you're out of compliance. Personally, it's too risky for me. There are too many unanswered questions, and I wouldn't want to hinge my audits on an interpretation of what a "server" is.
This is the kind of thing that will keep a company out of the enterprise market too. That's just not how you do big business. Companies like to do buy-aheads where they anticipate how many licenses they'll need over say the next couple years, and buy in bulk at a discount. That doesn't seem as possible with a licensing model like this.
Of course, I've got other problems with the product too. I just think the architecture wouldn't scale well for a lot of servers. Right now, I've only got a couple dozen servers I'm responsible for, and I wouldn't want to manage my backups with Red-Gate's tool. And in my last gig I literally had hundreds of servers and I couldn't even imagine having to manage that many backups with Red-Gate. It's simply not an enterprise tool. Now I like Red-Gate... I like their products, and I like the people (esp that little cutie that got me to talk in front of the camera at PASS). But I have to tell you guys the truth here, and that truth is, that I just don't think that SQL Backup is an enterprise tool. I personally wouldn't even want to use it on 10 servers because I just don't like the distributed management model.
And of course, all that's just opinion, but the licensing issue isn't... that's fact, and I think it's an important one. And that alone would keep me away from using SQL Backup.
Posted by Sean McCown on February 26, 2007 06:47 AM
February 22, 2007 | Comments: (0)
I'm often curious what drives the new standards of professionalism. It seems like we've swung to the other side from a few decades ago, and I'm waiting for it to even out.
Here's what I mean. It's really gotten so that you can't say anything to anybody that they don't like without being branded as unprofessional. It's the new insult. It's something you say to put someone in their place when you want to skirt around the issues that brought up the topic to begin with.
You shouldn't have used a cursor here. It won't perform well.
Well, I already had it written in another procedure, and I didn't feel like re-writing it here, so I just pasted it in.
Laziness is never an excuse for poor code.
Well, that was unprofessional. You could've just said that it won't work as well and ask me to change it. You don't have to insult me to get your point across.
This kind of crap goes on all the time in IT. Since when did telling the truth become unprofessional? And since when are DBAs paid by the word? Somewhere along the way, it's become a standard of professionalism to say things in as many words as possible to keep from making the other person feel inadequate. I mean, why say in 10 words what you can oversay in 75.
The same goes with getting fed up with situations. You keep having to support this bad system that could be fixed fairly easily. The directors put you under the gun all the time, and you have to drop whatever you're doing to get it going again. This is the most important system they own, yet they refuse to do anything about it. You get frustrated and start to get angry sometimes because you're spending all your time on this issue time and time again, and you've talked 'till you're blue in the face and nothing ever gets done. Yet they continue to claim that this is the most important system they own. So why is it unprofessional to get sick of that? Since when do pros have to put up with idiocy time and time again... not to mention apathy, laziness, and closed mindedness. Why is it less professional to want things to improve and get upset when they refuse to do anything?
Cursing. This is one of my favorite arguments. Who says professionals don't curse? Every professional I know curses from time to time. I've worked in professional kitchens for years with some of the world's best chefs. They all curse up a storm. I've been in board meetings with all the company's officers before. Many of them cursed throughout the meeting. I've been with PMs, and sales execs, and VPs with other companies. They all curse. Sometimes it's the only way to say what you really want to say. I always think back to the movie 'From the Hip' with Judd Nelson. He played an off the hook lawyer. Anyway, he was defending this president of a bank who had slapped one of his subordinates in the face and the guy was suing him. He had the guy on the stand, and he asked him, 'So why did you slap him?' To which the guy replied... 'Because he was an asshole.' Immediately the opposing counsel jumped up and objected the use of profanity in the courtroom. Judd said fine, give me another word... any other word that captures the exact meaning of that one, and I'll have him substitute it. The judge (Ray Walston I believe) couldn't come up with anything.
My point is simply that sometimes there's no other way to express exactly what you're trying to say because cursing is such a well understood medium. Some of the words have such well-established meanings that nothing else has managed to really capture them exactly. That's because most of the adjectives we use are sterile. They lack emotion. Curse words convey such exact meanings because they convey exact emotions that we all go through. Think about the word 'bullshit'. There are words that can come close to the meaning, or even phrases, but nothing quite captures the exact meaning and the exact emotions you feel when faced with a clear case of it. Calling something troublesome, or a nuisance, or ridiculous, just doesn't seem to cut it, now does it? So why is it so unprofessional to use such language when it's appropriate? I thought that part of being a professional was being able to communicate effectively, and if something is truly bullshit, shouldn't you be able to just say so? Wouldn't that make you more professional because you're conveying exactly what you mean?
Being a professional simply means that you get paid for something. It doesn't mean that you exclude everything else you know. And this bullshit of having no child left behind in business has got to go. You know what... I'm not going to be rude, but if you've done a bad job I'm going to say it. If it makes you feel inadequate, then maybe you can use that to improve your code instead of crying to HR that your feelings have been hurt. I agree that there's no reason to insult anybody, but there's also no reason to not call bad code, bad code. The system didn't grow all of these cursors while you were at lunch. Somebody wrote them. Now, did they write them out of ignorance or apathy? It doesn't matter. I'm saying it's not good and it needs to change. Now what are you going to do with that information?
It's like people are so focused on everyone being professionals they've forgotten they're people too. Yes, we still date, and get tired, and frustrated, and mad, and sick to death, and elated, and yes, we DO go to the bathroom. And none of those things makes us unprofessional.
Posted by Sean McCown on February 22, 2007 11:11 AM
February 20, 2007 | Comments: (0)
YOU Made the Bed, So Don't Make US Lie in It
I'm gonna go ahead and finish off the topic I started on yesterday but didn't get to finish. And knowing me, I'll probably expand on it a little too, and maybe even go off on a couple tangents.
I'm talking about the whole salary and loyalty debate.
I've talked before about companies not giving their employees decent raises, and not rewarding them like they do the brass for saving them money. So it's really no wonder why we're forced to give ourselves raises every year or 2 by changing jobs. It seems that companies are always willing to court new talent with decent salaries, but they're not willing to use that tactic to keep it.
I was recently called down by a reader who happens to be recruiter for having changed jobs a lot in the past. He was commenting on that big recruiter series I did a while back. Personally, I think that's a pretty high horse that only a select few can afford to be on. The American corporate environment just doesn't support keeping staff for very long. They say they want loyal employees, but they routinely refuse to reward us for excellent work, give sufficient raises, give us good training, etc.
One thing that this reader didn't take into account is that a lot of times, changing jobs isn't our fault. I know most of us always go into a new job wanting to stay there for a long time. A job is like any other relationship. You never go into a personal relationship with someone expecting it to fail. I remember this joke Rita Rudner used to do. She said, whenever she meets a man she always asks herself, is this the man I want my kids to spend their weekends with?
There are a number of things that can contribute to a high turnover at any given company though. For one thing (and this has happened to me), the big reason you were attracted to a position was to get some real experience in an area you've been looking into, and the company kills the project after you come on board. There was no malicious intent involved, they just killed it for misc. reasons. You could also have come on board because you liked the management style of the hiring manager, and something happens to make him leave. Now you don't get along with the new guy nearly as well, and maybe he's even changed a couple important policies and you can't live with them. The company could have also just outright lied to you about their education policies, or projects they have coming up in order to get you to come. They could have also kept some things from you like they have a strict policies on office hours, they don't match 401K, their healthcare costs double what most people pay, etc... the list could go on and on. Then there's the simple no-fault split. People go through different periods in their lives and sometimes a job just stops doing it for you. You move past that part in your life, or your priorities change somehow. Maybe your family situation changes in such a way that it makes you need to change positions. Though I find changes like this tend to stem from companies not being flexible enough with their people.
The point is that for whatever they may be, there are some legitimate reasons why people changes jobs. Some of it stems from DBAs taking themselves and their jobs too seriously, and some of it stems from companies not even pretending to care whether they stay or go. Because in the end, people will do a lot for you if you just appreciate them and show it somehow.
Another interesting point this reader made was that I must be a fool for not kicking these inexperineced recruiters to the curb. And if I were as experienced as I say I am then I would know how to find a good recruiter by now. Apparently I'm the only one of the two of us who knows how this whole thing works. You don't hire a recruiter to go out and find you a job. You reply to specific jobs and you're stuck with the recruiter who's handling it. You can't say, hey, I think this job sounds good, but you're an idiot so could you point me to another firm more experienced at handling someone of my stature. No, you're pretty much stuck with this guy. So the fact that we're forced to work with these recruiters shouldn't be held against us. We want the job itself, not a relationship with the recruiter. And we have to do whatever it takes quite often to make sure we get presented to that company in a good light.
Of course, all this is coming from someone who claims that really good IT folk don't have to actually look for work or apply for jobs. All the really good ones have to do is post their resumes on their personal URL somewhere and the experienced recruiters have this secret ninja search language they can use to ferret out these people and get them jobs without them having to lift a finger. Whatever dude.
You know, all we're usually asking for is the same level of loyalty from our employers as they're asking from us. Currently, companies act like they're doing us a huge favor by lowering themselves to let us work there. And we'd better be loyal and jump through any hoop they like or they'll go get a college kid who's willing to jump higher and more often... and for half the money.
The same goes with vendors. I've had a bit sales VP with a major vendor ask me what it would take for them to gain my loyalty. I told him it would never happen until they started giving me some of theirs. He was trying to get $500,000 out of me in new license fees and I told him I was thinking of going to someone else. He asked why, and I said, because I've got 3 major issues that you guys are refusing to address at all. You want even more money from me when you're not even taking care of me now. Where's MY loyalty? What are you doing for me? Or is it that you lowered yourself to doing business with me and I should just be grateful and shut up? I don't think so.
The point of all this is that companies these days have drawn the line in the sand. They've made it clear to us that we're not important to them. If we have special circumstances, they don't care. If we need a more flexible schedule, too bad. Work your butt off putting together a warehouse that your VP got a $15mill bonus for supervising... oh well. Save the company $500,000 in license fees and setting them up to pass their audits so the CEO stays out of jail... it's your job, why should we give you anything extra?
So don't be surprised or upset when we treat you with the same reckless disregard you have for us.
Posted by Sean McCown on February 20, 2007 01:14 PM
February 15, 2007 | Comments: (0)
From time to time we all have these epiphanies that bring us back around to where we should be. I had one yesterday and thought I'd share it with you guys in case any of you are in the same funk I was in. In short, we all tend to take ourselves too seriously and start getting really upset with our company and our jobs. It's easy to do. So yesterday I took a step back and realized I was going it, and just called a dead stop.
Here's the situation. As DBAs we quite often have a global vision for our systems and it's not always shared by others in our company. We make recommendations that don't get taken, we advise on standards are are ignored, and we give good solid methodologies that aren't even considered. So tell me again... why am I here? You don't listen to hardly anything I say, yet you're paying me a pretty good salary to give you this advice. so tell me again... why am I here?
It's easy to get offended by stuff like this. But this all goes back to what I was saying in a post a few months ago about why you're here. You're not here to do a good job, nor are you here to make your systems run well, or even to be a good DBA. You're here to do what the company wants you to do. Does that always align with what you feel they should be doing? No. Does that mean that you should be listened to? Not necessarily. What it does mean is that it's not your business and all you can do is advise. Give your advice when you're asked for it, and then ultimately let them make the decisions. Hey, if they wanna pay you 90K to sit there 10hrs/wk and babysit some manual process that impedes other work... well, that's their choice. Again, you're not there to do the best job you can, you're there to do what they want you to do. Would you be able to be more effective if you were allowed to automate the process? Absolutely! For some reason though, they see fit to deny your request for the very simple thing it would take to make that happen. And believe me, I get it... sometimes it just doesn't make sense. What you're asking for is free, takes very little effort, and wouldn't really effect anybody but you, and they still won't let you do it. It makes absolutely NO sense. And those are the things that can just eat you up inside. So take a step back, and remember my famous words... it's not your business. They clearly think that your time is better spent doing stuff manually. It's their call.
The problem is that you can only go so far with stuff like this. You can only babysit so many manual processes before that's basically all you're doing. The catch is that the company still wants you to produce, and watch systems, and be available for other things. Sometimes the big guys up top don't have a firm grasp on what time actually is, and that there's a limited supply of it. Something tells me that they'd change their minds about a lot of this stuff if they had to babysit something like that all the time, yet were still expected to do their normal duties that justified their positions. I have a feeling that their attitudes about automation would change drastically. So when this all blows up, and it will because like I said, they still expect you to produce. What you need to do is go to your boss and give him your list of daily tasks, and your projects and ask him to prioritize them for you. Look, there are only so many hrs in the day, and I refuse to work 90hrs/wk to support manual processes and then be productive as well. And since something has to give, I need you to tell me what priority you want these in. Everything's important, but I don't have the company's insight into their business, so someone else needs to make this call. So basically, either one of two things needs to happen; they either need to allow you to do what needs to be done to free your time, or they need to buy another DBA to help you. Period. Because working 90hrs/wk isn't the answer, and you know what? In my experience putting in all that extra time never buys you anything. It doesn't get you a bigger bonus, it doesn't get you a bigger raise, and it certainly doesn't secure your position. Companies today will still throw you away with no notice for someone cheaper. It happens all the time. Companies don't appreciate their employees anymore, but that's another soapbox.
Now, I know what you're thinking. But Sean, I don't want to spend my time doing manual tasks. I'd rather be doing real DBA work and not that tedious stuff. Well, you're right. And you have a decision to make now don't you? If the job isn't going to be as technically fulfilling as you'd hoped, then you need to decide whether it's time to move on. If you can't be happy with the direction that they want you to go, then your goals clearly aren't aligned, and it's time to start thinking about a change. I don't care what other factors you have in your scenario, it's really just that simple. Paul Simon said it best... you gotta slip out the back, Jack... make a new plan, Stan.
And if you decide that leaving is the best thing for you, then ok. But set yourself up to succeed. Don't complain about your job. Don't spend your days whining to your co-workers. Just quietly do what needs to be done, and look for something else in the background. If something happens and you need to keep this job for longer than you like, then you want to still be in good standing with them. Don't give them a reason to fire you because you thought you'd be out of there soon and started pissing people off. Be cool and handle your business.
This all mirrors something that's going on right now with a friend of mine. He made a recommendation to his company that would save them an initial $13mill, and an on-going $300K/ea to expand the solution as the project grew. In the end they decided to go with the expensive solution even though his was FREE and actually provided more options than the expensive one. He blew it off still wondering why they'd choose to spend all that extra money when they could get a better solution for free. Now here we are a couple months later, and he just had his performance review. He got an excellent score; he showed it to me. But when he got his raise, they only gave him 3%. And against my advice, he's been working his ass off to support some manual processes he asked them to let him automate, but they won't let him. And it's not that they won't let him automate them. They don't care how he does his job. What they won't do is give him what he needs to automate it. Again, another free solution that would take 5mins to implement, but they won't allow it. They don't give reasons, they just say no. OK, back to the point... so he's been doing all this extra stuff and his raise was 3%. So he asked his boss why his raise was so low. He was told that they just didn't have the budget for more. He then asked his boss why it is that they have the budget for a $13mill solution when they had a free one in front of them, but they didn't have the money to pay their people. He didn't get an answer. So my friend clearly has a choice to make. It's clear to me that the company doesn't value him. I've worked with him before, and I think he's one of the better DBAs I've ever worked with. He'd be an excellent addition to any company, and I only wish I could hire him. And I'm sure his boss values him quite a bit, but his boss doesn't make that budget. It's the company. Anyway, that's another post entirely, and I'm sure I'll get back around to that topic pretty soon.
So I know I've jumped around quite a bit here, and maybe even babbled some, so I'll recap to be succinct about my point.
You're not being paid to be good at your job. You're being paid to do what the company wants you to do. So if you find yourself getting too emotional about them not taking your advice or about them making you support things you don't feel you should, take a step back and remember it's not your business. Treat it like a contracting gig. You give advice, and they either follow it or they don't. It makes no difference to you. When things start to get too hairy and you can't get your work done because there's just too much on your plate, then take it to your boss and have him set the priorities. That's his job, not yours. And when things start to get too bad and your goals just don't align with the company's anymore, then continue to do your job. Do a good job, and don't complain. Then look for another gig in the background. Take your time finding it, and pick something that will give you what you're looking for.
Posted by Sean McCown on February 15, 2007 07:48 AM
February 13, 2007 | Comments: (0)
You know, there are some things I just don't get. These network admin backup solutions that everyone keeps trying to push off on is are starting to really get to me. I'm getting on this topic now because I was looking at Microsoft's DPM datasheet. One of the things it stated in there was that "Database administrators have asked for the ability to restore data themselves." Funny, I thought we already had a way to restore our data. It's called native SQL backup.
This is actually a conversation I've had a lot with high-level techs, and even with some at InfoWorld. The question that always comes up is what difference does it make? Why is everyone like Quest(LiteSpeed) and Red-Gate(SQL Backup) fighting over the SQL Server backup arena? Well, I suppose that's a fair question if you don't live in the database world, so here, I'll go ahead and answer it publicly.
The big deal is this... those network-level backups like Microsoft DPM, BackupExec, and ArcServe don't allow DBAs to do what they need to do how they need to do it. Let's say that I have a server that I've backed up and I need to restore it to a dev box. Do I already have the agent deployed to that box? Will it cost me another license? Can I schedule an automatic refresh of that environment every day/week/month? If there's an error, can catch it and try to do some automatic fixing before I get involved? Can I add it to say an SSIS package or other mechanism to be part of a whole recovery workflow? What about sending it to another business unit? Can I restore across their firewall? Do I need another license for that? What's their change control process like for putting another service on that box? Is the data compressed? Can I do mirrored backups for both maximum protection and to help keep dev/QA/test boxes in synch?
What about Yukon? Can I still do page-level restores, or do I give that up in lieu of this other solution? Can I still do filegroup restores? How about object-level recovery? Can I restore an individual table, SP, trigger, etc?
Anyway, you get the point. There are a lot of things to consider when choosing a SQL Server backup solution and these vendors try to make it seem like it's a simple choice. Frankly, I enjoy the freedom that the REAL database backup tools give me.
That holds especially true with LiteSpeed. I just don't know why anybody would choose anything else. Sure, some of the others are cheaper, but the object-level recovery alone is worth its weight in gold. I've had my butt saved more times than I can count by the fact that I could pull a specific object out of my LiteSpeed backup file. And I'll let you guys in on a little secret... LiteSpeed is the ONLY backup solution in the world with object-level recovery for SQL Server.
Even MS, who has spoken out against this functionality in the past, has changed their stance on it and is not in favor of object-level recovery. Look, I'm not putting the other tools down. I've recently taken a look at Red-Gate's tool and it's a solid engine. It does a very good job of compressing your backups quickly and giving you a fast restore. But when it comes to functionality, they just don't compare to LiteSpeed. This also isn't a commercial for LiteSpeed. I'm just telling you like it is. From a logical standpoint, there's no reason to cut yourself off from that functionality. You WILL need it one day.
So why is everyone trying to re-invent my wheel? I dont know, but it kinda pisses me off. Do any of these guys have DBAs on staff? Have they tested these things against the native functionality of SQL backup? I'll tell you who these products are for. They're for NT and network admins who find themselves needing to make sure that the database gets backed up. They need a mechanism that lets them manage backups the way the manage their NT backups. The trouble is that it's just not the right tool for the job. Databases have completely different backup/restore requirements than file servers. I've never seen a multi-terabyte excel file that someone needed to restore just a macro from, or just a couple rows that someone deleted or corrupted.
So stop trying to put square DBAs into your round NT holes (that actually came across a lot dirtier than I intended). And let us do the backing up for our databases.
Posted by Sean McCown on February 13, 2007 08:32 AM
February 12, 2007 | Comments: (0)
That's right! I've claimed my first victim-- Director of Product Management for SQL Server, Francois Ajenstat. Shortly after I posted my blog, I got the most fabulous email from him. And I'm sharing it with all of you guys (with Francois's permission) because it's not only good information, it's just funny.
You almost gave me a hard attack when I read the “Robert was rude” part… I was going to go off and kill him. J Thankfully, the next paragraph made everything much better.
Forums… good or bad… well, let’s just say that every month in our Senior Leadership Meetings, we review the amount of activity on the SQL Server forums, the response rates, dev team participation, etc. The dev team is measured on engaging with customers/community (on top of other things of course). But again, as I mention below, that only works if customers can find the forums and actually use them.
And here's a snippet from another email you'll find impressive.
As an extra piece of info, the SQL Server product team has committed to recording 35,000 hours of customer contact this year through activities such as Customer meetings, Newsgroup/Forum posts, Customer labs, Customer events (like PASS and TechEd), Blogs, etc. That’s a whole lotta customer interactions. And once again, that’s another metric that we review monthly.
Now, I'm gonna have to say that I'm officially impressed. I had no idea that they held their developers accountable for issues brought to the forums. And my guess is that none you you did either, and that's why I'm printing this for everyone. I think that with all the bad press MS has gotten in the past (some of it by my hand) that the community should know the things they do to restore faith and hold themselves accountable to their customers. So with the addition of this new information, this is less of a forum, and more of an online support mechanism... for free. This is the kind of support we dream about. Think about it... you would ordinarily have to open up a case with support to get solid answers on a lot of things like this, but if you've got an issue that's not all that urgent, a forum like this is the perfect place to get answers from the people who actually write the code. I've known for quite some time that MS engineers shark the forums, but it never really meant that much to me because it doesn't really mean anything. Encouraging engineers to shark the forums is like encouraging your kids to clean their rooms. It won't happen often enough to count on. And getting the majority of your answers from the general user community in the forums is also hit and miss. The general public doesn't have the answers I typically need, and the ones who do are usually too busy with their own jobs to post that often. However, when you start holding engineers accountable for the activity in the forums, then that becomes a completely different story. Now you're telling your kids that they can't go out and play until their rooms are clean. It's all of a sudden relevant to them.
I've often said that devs should not only be held accountable for their code, but their bonuses should be based on the number of bugs that hit production. There are some unseen circumstances, but in general, if you've got a dev who consistently puts code into production that has bugs, then his bottomline should be effected. I bet he starts writing better code next year.
Now, as some of you may have noticed, Francois (oddly enough he doesn't have a French accent) made mention of another email in that snippet above("But again, as I mention below..."). So just for completion's sake, here's a piece of that email too, because I think it outlines the SQL team's attitude towards its community.
1. Setup experience: Upgrade/Uninstall scenarios are critical for customers. If we ask them to test our products we should make sure that they have a good experience moving from one CTP to the next or to the RTM. That doesn’t mean that upgrade/uninstall will always be easy but that it can be done and is well documented. I know that this is a top priority for SQL Server as we think of the CTP process for the next releases
2. Forums/community support: I think that I had mentioned it on the phone a while ago but I’m a big fan of the community and using the community for support. In this case, I know that there are very good forums that are monitored by the development team which is a great place to get assistance. We need to do a better job making sure that customers know about these forums and can easily find them.
OK, that's all I've got this time.
Posted by Sean McCown on February 12, 2007 07:06 AM
February 09, 2007 | Comments: (0)
Before I start the actual blog post I've got a little house cleaning to do. I got called down by a reader who says I should define my terms. As it turns out, he's a Unix user and isn't familiar with our acronyms, and while it's usually a safe bet that my readers are Windows guys, this is a small enough request that I certainly don't mind doing whatever it takes. So, just to catch you up, the 2 acronyms I used in the last post are:
CTP: Community Technology Preview... this is the new MS term for a beta. And while I'm sure I'll get an email from some marketing guy explaining the differences, as far as you Unix guys are concerned, it's a beta.
RTM: Release To Manufacture... this is the final version of the product that goes to market.
OK, now on to today's post.
To be brief, of course redemption is possible.
I recently wrote a blog about my bad experience with trying to uninstall VSTE for DBAs. I thought now that the issue is resolved, I should come on and share the results with you guys.
OK, so when we last left our hero(me) he was stuck with having to uninstall VS entirely or rebuild his box. So what I decided to do was uninstall. Unfortunately, that didn't work(I didn't figure it would). So I then used the utility MS gave me that completely wipes any trace of VS or the .NET framework. And you know what... that didn't work either. Everything except VSTE was uninstalled. That's just great. So now, per MS, my only option was to rebuild the box. So I decided to try to get it off myself. I ran a registry search on 'Visual Studio Team Edition' and just killed anything that came up. Oddly enough that worked, and didn't destroy anything else. So, I was able to reinstall and everyting appears to be working just fine now.
Now, here's the new part. I got a call this morning from Robert Merriman. He's the guy who actually wrote the setup for the VSTE in question. Apparently good news travels fast and this blogging thing works after all.
Unfortunately it hasn't changed MS's attitude at all. Robert was rude, insulting, and completely apathetic to my problems. In fact, I got the feeling that he was only calling because someone threatened his job if he didn't. At one point in the conversation he actually told me that MS was starting a list of troublemakers who would never be allowed to install betas again, and he was going to make sure I was on it or die trying. Whatever dude...
Actually, that whole last paragraph was just for fun. I've got this vision in my mind of some exec at MS getting this glazed look over his face and having to remember to breathe as he reads thats. Robert was incredibly helpful, and extremely polite. I can tell that he really likes what he's doing and actually takes pride in the code he writes. That's right, I said Pride. That's not a word you hear too much in the software industry anymore. Anyway, thanks for the help Robert, if only it had been a day sooner.
Robert did share some things with me though that I'd like to pass along to all of you. The first thing is their team forum. Which can be found here: VSTE for DBAs forum. This is evidently the place to go to get some real help with something.
There's also the Team blogs at: Blogs. I'm sure you won't be able to get any actual help here, but it's always good to keep up with things.
Now, how seriously do they take forum problems... that's the question. Because telling people to go to the forum and actually making it worth their time are two different things.
And to this purpose, they've added a customer feedback form and Robert assures me that they take this very seriously, and ordinary DBAs get the same treatment as worldwide celebrities like me.
And that brings up another point... forums. One reason that I don't really go to forums much is that in the past, I've never really gotten much out of them at all. I'd submit a question that would go unanswered. I'd submit it again, and it would again be ignored. So forums in the past haven't really been much help. It's funny isn't it... how long initial impressions can last?
I also didn't know they even had a forum, which is at the heart of something I was talking to MS about a couple months ago. How does a big company like MS get the word out on things like webcasts, forums, and other resources they publish to help the community? Because they were telling me about a webcast I should've seen, and I said, well, I would've had I even known about it. And I consider myself to be someone fairly in-the-know about SQL Server stuff. So if I missed it, then how is the ordinary user going to hear about it?
As well, this whole thing also proves to validate my initial blog on this issue. Why did I have to blog to get decent support? There are all kinds of things I could say about that, but you get the idea.
I also have more to say about the forums and other sources, but I've got a blog on this topic already planned and I don't want to step on my own toes.
I've only got one more thing, and that's on reliability. I touched on this in the original post, but it could stand some elabotation here. Let's look at the situation that I just finished. I got a guy on the phone who gave me less than accurate support, and I blogged on it. Now, look at what that negative press does to a company like MS who, let's face it, hasn't had the easiest time in the press over the last 10yrs. That little bit of negative energy is going to make its way to someone reading this blog, and is going to get told to someone thinking of installing an MS product. Then it's going to get told again and again and again until it's so distorted I wouldn't even recognize it. Now, of course, I'm redeeming them here with this post, but what if not everyone who read the last post reads this one? That's the problem with things like this. You can't be guaranteed you'll reach the same audience every time. And that's why companies need to make a greater effort to please every customer, not just the world-famous ones.
Posted by Sean McCown on February 9, 2007 10:49 AM
February 08, 2007 | Comments: (0)
Another topic that's close to my heart is matching the solution with the problem. This is such a religious debate (for some reason) that I'm not sure where to start, but I'll try to keep it as brief as I can. Too often, people fail to match problems with appropriate solutions and they end up either over or under engineering it.
Let's take a case I recently faced and see how the solutions aligned.
I've got 13 data marts to deploy for the different regions in our company. We have to make the solution swingable... that is, we have to be able to failover to an alternate site for DR purposes... we DBAs sometimes call that 'swinging' because you swing operations over to another site. Anyway though... there are a number of solutions you could go with here.
The first solution proposed was by another DBA in another group, and he swore it was the only solution available. His solution was to buy DMX disks that could be snapshot throughout the day to keep the DBs in synch. Then when you swing, you take the final snapshot and apply it on the other side, and you're up. The process could take around 30mins or so depending on network traffic and comes with a hefty price tag of around $300K from EMC. And that's $300K per data mart. So that's $300K x 13.
So after seeing that price tag, they came to me for alternate solutions, of which I gave them 5 or 6 I think. I'm not really gonna give the full discussion of how we landed on the solution we chose, but ultimately, we chose mirroring (because the DMs are on SQL2K5), and mirrored backups on each side of the swing. So for a little extra code, we got a very workable solution for FREE!!
The SRDF process for synching the DMX disks breaks on our other systems all the time and they're constantly having to fix it. Anyway, the DMX solution is just more than we need... esp for the price tag, the solution definitely doesn't fit the problem.
Another good example is along the same lines. A couple years ago we needed a large dumping ground of disks to house our SQL backups while they were waiting to go to tape. What we needed was fast disk and lots of it. So our network admin took it upon himself to contact HP, NetApp, EMC, etc. All of them came in with good solid recommendations of NAS solutions that had all kinds of redundancy, and snapshot technologies, management, the works...
The problem again was the price tags. It was just ridiculous what these people wanted for a couple TBs of disk. All I wanted was a place to put my backups for a couple hrs. So again, I found a couple disk cabinets and loaded them up with SATA drives and slapped them onto a spare server I had lying around. Is it the most robust solution out there? Surely not, but that's irrelevant. Everything doesn't have to be the most robust solution. It just has to be robust enough.
I've seen it several times when a dev will write a solution to do something simple to copy some data somewhere or run backups, and they over-engineer the thing to the point where you can hardly figure out what's going on.
And actually, I just read back through this and realized I didn't have an example of an under-engineered solution. This one was a couple yrs ago as well, and you'll just love it.
We had a dev who liked to play admin from time to time, and when he designed his solution it had to be replicated to several different sites. His solution, instead of using actual replication, was to use Red-Gate's data compare utility every 30mins and run the compare on each of the servers. I only wish I were kidding. This is such an incredibly under-engineered solution I find I have trouble commenting on it so I'm just gonna leave the story as-is.
In short, you don't need an atomic juicer to squirt some lemon juice into your soup. And you can't use a hand reamer to juice a bushel of oranges.
Posted by Sean McCown on February 8, 2007 10:58 AM
February 07, 2007 | Comments: (0)
Microsoft's Ridiculous CTP Upgrades
With frequent bloggers like myself sometimes coming up with topics can be challenging to say the least. Then at other times topics are thrust upon you no matter how hard you try to fight it. This is one of those times.
I was one of the unfortunate ones who installed the CTP of the Visual Studio Team Edition for DBAs (VSTE for DBAs). Now I'm getting ready to install the RTM version and I'm having trouble uninstalling the CTP. I don't have the CD anymore, and the code isn't up on MSDN. So, I'm stuck with trying to uninstall my CTP so I can install the RTM. And did I mention that the RTM won't uninstall, nor will it install on top of the older version. So, I did what any hard-working conscientious DBA would do... I called my guys at MS to see how to get it uninstalled.
Now, mind you, I've got VS2005 up and running on my Vista box and fully patched and working well. And MS not really trying anything at all to get me uninstalled, their only 2 suggestions have been to uninstall VS entirely along with the .NET framework and WinFX. Then use this tool they have that will completely wipe all traces of it off of my box, and then reinstall and put the new VSTE on there afterwards. The 2nd solution, and you're going to love this one, is to completely rebuild my box from scratch. Again, keep in mind that they've done nothing at all to try to uninstall VSTE by itself.
When Yukon was still Yukon, you could uninstall those CTPs by hand if you needed to. It took a few minutes, but it was far less time than rebuilding your box. And what's really important, you didn't have to hold on to every scrap of media you had in order to get rid of the previous version. It was easier if you did, but it wasn't necessary, and the methods for doing it manually were easy to come by. I think I even posted it in blog to make it even easier.
You would think that it's fair to have to uninstall VS completely since you had to uninstall Yukon completely. However, VSTE for DBAs is just a plug-in to VS. It requires VS Pro. So, you should be able to keep the host application in tact and just deal with the plug-in.
What I'm left with here is a sense of foreboding for end users. I'm lucky in that I'm a journalist and I get special attention that ordinary users don't get. If you top that off with the fact that I'm doing this to try to kick off the official InfoWorld Review of the product and it becomes even more appalling. If I can't get anything out of them, what chance does an ordinary user have? It's typically a good idea to hold off on putting CTPs on your servers unless you have a dedicated test box. It looks like now it's getting practically impossible to expect to be able to install a CTP on your desktop either. If the answer to uninstalling a CTP from my box is to rebuild, then there's something seriously wrong with the CTP program. It's just flatout lazy coding. And I tell my devs all the time that laziness is no excuse for bad code.
MS, here's a hint... whenever you provide someone with beta code, you need to also give them a way to get it off. Perhaps the RTM should have some knowledge of uninstalling components. It's just a thought.
I'm really not writing this out of spite. I can see how it would be taken that way because the timing's right, but I'm not. I'm honestly concerned for the end users who don't have the connections at MS that I have. What is an ordinary user going to do? It's happened to me a few times when a company has blown me or my company off until they found out I was in the press and then they tripped over themselves to fix the problem. Why do I have to have the ability to publicly call you out before you'll own up to your responsibilities? Most customers don't have that luxury, and I really feel for them. They're just stuck. And it's no joke either because not only does word get around, but so does IT staff. People in our industry change jobs like every year or so, and it takes but one bad experience to turn someone against you. And you may not care because they're at a young startup and won't make up hardly any of your customer base, but beware... that guy may go on to a Fortune 500 company next month and if the topic of your software comes up, he will tell everyone what he knows about you and how you deal with your customers. Now you're out a huge client and you'll never know it. I've stopped more software purchases than I can count based on my initial experiences with any given company. And it's funny how long that sticks with you too. People remember a really bad experience for a long time. Putting a dumb support engineer on the phone can ruin a company's reputation. I quite often judge a company's customer service by their pre-sales support on something really small. If they're not very willing to help you spend your money, then they're not very willing to keep it. It's like the cell phone companies who put together these really amazing deals for new customers, and exclude the loyal customers who've been with them for a long time. It's ridiculous. You're going to reward someone who could take off next month by giving them an excellent deal, and punish the ones who have proven you'll get their money. Nice move. Anyway, that's all I had to say.
So instead of spending my evening being productive with anything, I'll be wiping my box clean of VS in an attempt to get this review off the ground.
Posted by Sean McCown on February 7, 2007 01:49 PM
February 06, 2007 | Comments: (0)
Lights Out Database Management
It's days like today when the entire family is home sick(myself included) with a very nasty stomach virus that my thoughts turn to automated alerting and management. We would all like to take a sick day now and then and know that we'll still have a job when we get back, or that things at least won't blow up while we're gone.
I always think... am I catching every error I can? Am I dealing with it? Have I defined a backup contact?
I'll be writing more on this later, but frankly, I just don't feel like writing any more today. But ask yourself those questions and see if you're ready for your next sick day. Will your systems survive your absence?
Posted by Sean McCown on February 6, 2007 08:31 AM
February 05, 2007 | Comments: (0)
OK, here's a tidbit of news that not many of you will hear anywhere else. My friend and secret informant at MS, Donald Farmer, has just left the SSIS team in favor of the data mining team. Now, I talked to Donald about this last week, and he doesn't think he's blog-worthy, but that's where he's wrong and I'll tell you why. After talking to Donald about the reasons for his move, and what he hopes to accomplish, it was clear to me that this is something we all need. Data mining is the future, and as of yet, it's still far too complicated for the ordinary IT guy to grasp. Donald's hope is to bring a much simpler process to data mining, and make it so that any DBA or even educated business user can do it. Why do I think we all need Donald to make this leap? Well, because put simply… Donald actually cares about it. There's a fire in his voice that you don't hear often in this industry anymore, and anyone with that kind of fire can make things happen. It's like being a chef. Someone can teach you how to cook, but you'll never be truly great unless you're a real foodie. That's what Donald is I guess… a data mining foodie! I have another friend at MS right now who's trying to learn to code C++. The only problem is his heart's not in it and I can tell he'll learn just enough to get by. He'll never be great.
So for this reason, I think that Donald is very blog-worthy, and I'm personally very excited at the prospect of having someone with that level of excitement and commitment to data mining looking at the problems I face every day… ok, well, every other day anyway. It's funny isn't it... when somebody's excited about something it's contagious. They get you excited about it too, and I'm psyched about data mining right now.
But hey guys, don't take my word for it. Here are Donald's exact words to me about his move.
I can't see myself as blog-worthy, but certainly I can tell you what I'm up to and why.
My new role will be Principal Program Manager for the SQL Server Data Mining team. It's not really an up or down move. There's just so much fun to be had with customers and partners where the rubber hits the road. I asked for the move, and it's giving me a thrill to do this.
My motivation really goes back to why I am in the BI world at all. BI enables people to build and test their hypotheses against data of a volume and complexity that otherwise they would find difficult to grasp. Data integration is needed to do that, and so it was a great thing to work at that end of the process. But 6 years ago I actually joined MS to work on Analysis Services, because it was the analytic power that appealed to me.
I sometimes compare my passion for analysis with the amazement I felt when I was a kid, when I would help my dad in the garage, pumping the hydraulic jack. A 10-year old kid could lift a car off the ground with one hand! It was awesome. I feel the same about data analysis – imagine being able to make sense of every transaction of every customer for every year. That's a real buzz for me. Hypotheses can be formed, tested, rejected, applied, reviewed, shared ... all hopefully with relative ease.
Predictive analytics takes this a little further. Every single business uses predictive analytics - they just don't know it. When the village shopkeeper orders 2 boxes of valentine's cards, they are performing predictive analysis. In their case it is perhaps informed by knowledge of their customers, some analysis of past sales, and some gut feelings. Predictive analytics with data mining brings gut feeling to BI, captures it, models it and so on. I want to bring that to every user. I want small and medium businesses to have the capabilities of making data-driven decisions without needing to understand the complexities of algorithms or even how to model their data. That's going to be tough. And I want to get predictive analysis into situations where we’re not using it. I want to see DBAs receive predictive warnings about query performance degrading, or which databases are most likely to have issues under different loads – before it happens.
BTW, you'll see talking me more often about predictive analytics than about data mining. It's a fine distinction, but for me data mining is more about the techniques, while predictive analytics is more about the business cases and scenarios. I'm not going to be going all deep and academic on the algorithms – there is an awesome team of smart folks at MS who can do that. They will be marvelous to work with, I'm sure. For myself, I'll be concentrating on how we can change the landscape for BI users.
Finally, I just know I'm going to love working with the customers on these issues. Working with SSIS customers, we directly impacted their technical capabilities, and indirectly saw great benefits to their business. Working with predictive analytics customers, we'll get to see direct business benefits at first hand. That will be very satisfying.
OK Donald... all eyes are on you now brother... let's see whatchu got.
Posted by Sean McCown on February 5, 2007 12:16 PM
TOP STORIES
Top 10 stories of the weekA new place to hide rootkits
Sun exec on OpenSolaris, Linux
AT&T: No free iPhone Wi-Fi info
MS to appeal E.U. fine
XP SP3 causes endless reboots
Vista as insecure as Win 2000
Google grilled on human rights
Java ubiquity an edge in RIA battle
The InfoWorld news quiz
ADDITIONAL RESOURCES
- Application Security: Threats and How to Counter Them
- Why Linux Threats Mean Business
- Virtualization: A Step by Step Approach to Success
- Virtual Test Lab Automation: Manage development infrastructure
- Improve Resource Utilization and Lower Operating Costs
- Protect Your Data with SSL
